web-dev-qa-db-ja.com

PGPマスター鍵に単一のサブ鍵しかなく、認証をデフォルトで署名と結び付けるのはなぜですか？

PGPサブキーと、（S）igning、（E）ncryption、（A）uthentication、（C）ertificationの役割を分割する方法についてさらに学習した後、ほとんどの場合（？）デフォルトのマスターキーにサブキーがあることを発見しました暗号化の仕事を分離する：

_pub  2048R/AAAAAAAA  usage: SC
sub  2048R/BBBBBBBB  usage: E
_

ここで、AAAAAAAAはマスターキーです。 Sではコンテンツに署名でき、Cでは新しいサブキーを作成できます。 （これの1つの利点は、AAAAAAAAにBBBBBBBBより長い有効期限を与え、AAAAAAAAの使用権限があるため、Cで新しい暗号化キーを作成できることです。）

ただし、次の方法は、1台のマシンで作業しているユーザーにとってはそれほど安全ではないが、たとえば職場や自宅などから暗号化されたメールを受信したいユーザーに対してより多くのセキュリティを提供すると思われます。

_pub  2048R/AAAAAAAA  usage: C
sub  2048R/BBBBBBBB  usage: E
sub  2048R/CCCCCCCC  usage: S
_

この設定では、マスターキーAAAAAAAAは署名/検証または暗号化/復号化できませんが、信頼を収集できます。したがって、マスターAAAAAAAAキーの有効期限を長くし、それを使用して新しいサブキーを追加できます。次に、BBBBBBBBおよびCCCCCCCCを、たとえば、より多くの場所に移動し、安全性の低い別の仕事用コンピューターにエクスポートすることにより、マスターキーなしの場合、仕事用のコンピューターが危険にさらされている場合、評判を失うことなく、サブキーを取り消して新しいキーを追加できます。

（もちろん、マスター証明書キーのsecret部分をスーパーセキュアシークレットバンカーに保持することもできます。）

私はこれをGUIから設定することは不可能であるように見えることを知っています（それらは、マスターキーができることとできないことの制御は言うまでもなく、表示または編集のいずれのサブキーにも熱心ではないようです）。

これが既存のPGP実装では実行されない特定の理由はありますか？秘密鍵を認証特権なしで他のマシンにエクスポートすることは、大きなセキュリティになると思われます勝つ。 （GUIだけで簡単になった場合）私の唯一の考えは、（gpg(1)のマニュアルページで）_--export-secret-subkeys_のヒントのように、不自然なマスターシークレットキーでシークレットサブキーをインポートすることは、広くサポートされていない可能性があるということです。で：

_--export-secret-keys

--export-secret-subkeys
       Same  as --export, but exports the secret keys instead.  This is
       normally not very useful and a security risk.  The  second  form
       of  the  command  has  the special property to render the secret
       part of the primary key useless; this  is  a  GNU  extension  to
       OpenPGP  and  other  implementations can not be expected to suc‐
       cessfully import such a key.  See the option  --simple-sk-check‐
       sum  if  you  want  to import such an exported key with an older
       OpenPGP implementation.
_

編集：Debianはこれと同じ慣習に従っているように見えますか？ https://wiki.debian.org/subkeys

encryptioncryptographypublic-key-infrastructurepgp
36
Adam Prescott

この問題には2つの視点があります。1つは歴史的事実に基づいており（少し技術的です）、もう1つは純粋に私自身の独創的な意見です。

いずれにしても、署名用に別のキーを使用する方が実際には安全であるか、少なくとも便利のようです。こうすることで、マスターキーを認証にのみ使用し（保存することができます）、キーが危険にさらされた場合にすべての認証プロセス（IRLミーティング）をやり直す必要がなくなります。

歴史的事実

安定したGnuPGバージョン（1.4および2.0）のCソースコードを注意深く確認した後、公開鍵のデフォルト機能を設定する機能を見つけました。コード（ファイルg10/misc.c内）は次のようになります。

476 int
477 openpgp_pk_algo_usage ( int algo )
478 {
479     int use = 0;
480
481     /* They are hardwired in gpg 1.0. */
482     switch ( algo ) {
483       case PUBKEY_ALGO_RSA:
484           use = (PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG
485                  | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH);
486           break;
487       case PUBKEY_ALGO_RSA_E:
488           use = PUBKEY_USAGE_ENC;
489           break;
490       case PUBKEY_ALGO_RSA_S:
491           use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG;
492           break;
...
509       default:
510           break;
511     }
512     return use;
513 }

この関数を見つけたのは、キーの生成方法（g10/keygen.c）を最初に調べたためです。実際、GnuPGがキーの「役割」を提供できるのは（サブ）キーの生成中です。マスターキーが作成されると、その機能を変更することはできません。

ソースコードはあまりわかりませんでしたが（signingのRSAキーにはcertifyingの機能も含まれている）が、コメント（上記の481行目）のWeb検索を実行すると、2005-08-03にgnupg-usersメーリングリストに投稿されたメッセージにメッセージが送られました saying ：

GnuPGはまだCとSを区別していません。そのため、これを選択する方法を持つことはあまり意味がありません。

したがって、これらのデフォルト設定は、GnuPGが署名キーと認証キーを区別していなかったからといって存在しているようです。

さらに、これらのデフォルト設定は [〜＃〜] dsa [〜＃〜] のために適切に設定されている可能性があります Simon Richterが指摘した ：

かなり長い間、gpgはデフォルトでDSAキーを使用していました。これは署名にのみ使用でき、完全に機能するキーを取得するにはelGamalサブキー（暗号化にのみ使用できます）をアタッチする必要がありました。

RSAの場合は必要ありませんが、何らかの理由で保持されました。

「署名のみ」または「暗号化のみ」のRSAサブタイプは、アルゴリズムの技術的な制限ではありません。

元の事実

今日、私はそれの唯一の理由（SCだけではなくCに設定されたデフォルトの主キー機能）がを助けると信じています）通常のユーザーと署名の検証。

鍵リングに次の2つの鍵があるとします。

pub  4096R/00000001  1970-01-01       usage: C
uid                  Alice Owl
sub  4096R/AE687A0C  1970-01-01       usage: S
sub  4096R/F77A9AF1  1970-01-01       usage: E

pub  4096R/FFFFFFFE  1970-01-01       usage: CS
uid                  Bob Penguin
sub  4096R/00FF42CD  1970-01-01       usage: E
  • Alice Owlは通常のGnuPGユーザーであり、OpenPGPに自信があり、GnuPGの--expertフラグでキーペアを生成したため、独自のキー機能を設定できました。主キーにはCフラグ もちろん がありますが、彼女はサブキーを使用してドキュメントに署名します。
  • Bob Penguinは、暗号化についてほとんど何も知りません。彼が望んでいる唯一のことは少しプライバシー/親密さです。彼は通常のユーザーがするように彼のキーを生成しました（彼が理解していない設定には触れませんでした）。

さて、あなた–読者–も初心者だとしましょう。アリスとボブの両方から署名入りの書類を受け取ります。あなたはgnupgの基本を知っています、そして特に：

  • ユーザーは主キーで識別されます：
    • Aliceが00000001であることを知っているし、BobがFFFFFFFE。
  • GnuPGの--verifyまたは--verify-filesオプションを使用してメッセージを確認できます。

それでは、彼らがあなたに送った書類を確認しましょう。

$ gpg --verify from-bob.txt.asc
gpg: Signature made <date> using RSA key ID FFFFFFFE
gpg: Good signature from "Bob Penguin"

$ gpg --verify from-alice.txt.asc
gpg: Signature made <date> using RSA key ID AE687A0C
gpg: Good signature from "Alice Owl"

待って、何？アリスの鍵は00000001か？

実際、ドキュメントの署名は必ずしもマスターキーで作成されるわけではありません。これらは、署名機能（S）を持つ鍵で作成されます。初心者がそれを知っているとは思えない。

たぶん、実際の説明にはこの仮定に関係する何もない（「SCキーを使用する初心者が多いほど、他の初心者にとってはより良い"）ですが、GnuPGの貢献者を煩わせずに思いつくことができる唯一の説明です。

27
Diti

ディティは歴史的文脈についてほぼ正しいですが、本当の歴史的理由は彼/彼女が省略した部分にあります。

かなり長い間、gpgはデフォルトでDSAキーを使用していました。これは署名にのみ使用でき、完全に機能するキーを取得するためにelGamalサブキー（暗号化にのみ使用できます）をアタッチする必要がありました。

RSAの場合は必要ありませんが、何らかの理由で保持されました。

「署名のみ」または「暗号化のみ」のRSAサブタイプは、アルゴリズムの技術的な制限ではありません。

8
Simon Richter

データの署名用と証明書の署名用に異なるキーを作成する場合、「キーに署名する」人は実際にはcertificationキーに署名する必要があり、データには署名しません-署名鍵;そうでない場合、 Web of Trust はキーを通過しません。ただし、メールに署名するときは、認証鍵ではなくデータ署名鍵を使用して行います。これは、メールにコピーされるデータ署名公開鍵です。

したがって、署名キーと認証キーを分離することは可能ですが、関係者やソフトウェアの実装は、署名および配布するものについてより注意する必要があります。ユーザビリティの問題が発生する可能性があると想像できます。

6
Tom Leek