RSA秘密鍵のPKCS＃1およびPKCS＃8形式

Question

RSAキーが文字どおりこれらの形式でどのように保存されているかを理解できる人はいますか？ PKCS形式とエンコード（DER、PEM）の違いを知りたいです。私が理解していることから、PEMはより人間が読める形式です。キー/証明書のPEM/DERは文字のUTF-8/16に似ていますか？ DER/PEMの重要性は何ですか？あまりにも多くの質問を申し訳ありませんが、グーグルでうんざりしてあいまいな答えを得る。ありがとう。

Luke Joshua Park · Accepted Answer

PKCS＃1およびPKCS＃8（公開キー暗号化標準）は、特定の暗号プリミティブ、パディングなどの使用を管理する標準です。どちらも、キー、証明書、およびその他の関連情報を格納するために使用されるファイル形式を定義します。

PEMとDERはもう少し興味深いものです。 DERは、キーや証明書などのASN.1エンコードであり、Googleで十分に確認できます。秘密鍵と証明書はDERを使用してエンコードされ、このように直接保存できます。ただし、これらのファイルはバイナリであり、簡単にコピーして貼り付けることはできないため、多くの（ほとんどではないにしても）実装はPEMエンコードファイルも受け入れます。 PEMは基本的にbase64でエンコードされたDERです。ヘッダー、オプションのメタデータ、base64でエンコードされたDERデータを追加し、PEMファイルを作成します。

dave_thompson_085 · Answer

（編集には、私が感じる以上に拡張するのが適切です。）

PKCS1、いくつかのバージョンでrfcs 2313 2437 3447および 8017 として使用可能です。主に暗号化を含む暗号化にRSAアルゴリズムを使用することです。署名の復号化と検証。ただし、暗号はシステム間または少なくともプログラム間で使用されることが多いため、キーの定義済みの相互運用可能なフォーマットを使用すると便利です。PKCS1は、付録A.1のRSA公開キーと秘密キーのかなり最小限のフォーマットを定義しますLukeが示唆しているように、これは ASN.1は従来DERとしてエンコードされていましたを使用します。

PKCS8は、 rfc5208 として利用可能です。これは、RSAだけでなく、すべてのアルゴリズムの秘密鍵を処理するための標準です。また、ASN.1 DERを使用し、X.509で定義されたASN.1構造（最初の）であるAlgorithmIdentifierと、アルゴリズムをそれほど驚くほど識別しない単純なOCTET STRINGは、アルゴリズムに応じた方法でキーの表現を含みます。 OID rsaEncryptionを意味するAlgorithmIdentifierによって識別されるアルゴリズムRSAの場合、OCTET STRINGにはPKCS1秘密鍵エンコーディングが含まれます。PKCS8では任意の「属性」を追加できますが、これはほとんど使用されません（例。jksを.pkcs12に変換できません：余分な秘密鍵）

PKCS8は、パスワードベースの暗号化を使用して秘密鍵を暗号化するオプションも提供します（実際には明示的に必要ではありませんが）。これは、特にPKCS8がPKCS12/PFXの秘密鍵部分として使用されている場合に一般的ですが、普遍的ではありません。

今日のほとんどのシステムは複数のアルゴリズムをサポートする必要があり、開発された新しいアルゴリズムに適応できるようにしたいので、PKCS8は秘密鍵に、X.509で公開鍵に定義された同様の任意のアルゴリズムに適しています。多くの場合、PKCS12/PFXが両方に優先されます。

これらはどちらも証明書やCSR、CRL、OCSP、SCTなどの他のPKIオブジェクトとは関係ありません。これらは、PKCSシリーズの他のメンバーを含む、他の標準によって定義されています-keysこれらの標準で定義されています。

PEMフォーマットは、ルークが言ったように、より便利な方法で（ほぼすべての）バイナリ/ DERデータをフォーマットまたは（スーパー）エンコーディングする方法です。これは、Privacy-Enhanced Mailという名前の安全な電子メールでの1990年代の試みから派生したものです。当時の電子メールシステムは、限られた文字セット、多くの場合、限られた行長の印刷可能なテキストのみを送信、または少なくとも確実に送信できるため、PEMはバイナリデータを行長64のbase64としてエンコードしていました。成功し、PGPやS/MIMEのような他のものに取って代わられましたが、それが定義した形式はまだ使用されています。最近の電子メールシステムは、しばしばバイナリデータを送信しますcan、しかしルークが言ったように、コピーアンドペーストはしばしば表示された文字しか扱えないので、PEMは依然として有用であり、さらに人間にとっても簡単です認めるために。

より正確に言うと、PEMは、PKCS1またはPKCS8キーorなどのデータをエンコードします。ただし、証明書、CSRなどは次のようになります。

5つのハイフン、Word BEGIN、データの種類を定義する1つまたはいくつかの（スペース区切り）ワード、および5つのハイフンで構成される行
空行で終了するオプションの（そしてまれな）rfc822スタイルのヘッダー
データのbase64、64文字の行に分割（最後を除く）。一部のプログラムは、代わりに76文字の（わずかに新しい）MIME制限を使用します
bEGIN行のような行ですが、代わりにENDがあります

行の長さとEND行をチェック/強制する読者もいれば、そうしない読者もいるので、もしこれらの間違いを犯した場合、時には動作し、時には動作しないファイルを作成する可能性があり、デバッグするのは面倒です。

したがって、たとえば、PEMのPKCS1秘密鍵（暗号化されていない）は次のようになります。

暗号化されていないPKCS8の同じキー：

およびPKCS8暗号化：

各ファイル（または他のデータユニット）のデータのタイプがBEGIN/END行から簡単に認識されることを確認します。データ内の実際のキー値はツールなしでは簡単に読み取れませんが、実際には秘密情報（暗号化に使用されるパスワード）のみが必要です。