3

Java Keytool ユーティリティを使用してキー ストアを構築する場合、キーはどのように保護されますか? ドキュメントを読んだところ、各秘密鍵には鍵のパスワードがあり、ストアにはストアのパスワードがあることがわかりました。

しかし、データを保護するためにどのようなメカニズムが使用されているのでしょうか? 暗号化暗号ですか？もしそうなら、アルゴリズムは何ですか？特に、keytool が JKS ファイルを作成する際にどのように保護を行うかに焦点を当てています。

4

3 に答える 3

7

注Java 9 以降の Java バージョンのデフォルトは、JKS ではなく PKCS#12 鍵ストア・タイプです。

Sun のデフォルトの JKS キーストアは、主に標準アルゴリズムのエクスポート制限を回避するために独自のアルゴリズムを使用します。アルゴリズムはこのクラスで実装され、

  sun.security.provider.KeyProtector

アルゴリズムの説明です。

これは、機密鍵を保護 (または平文バージョンを回復) するときに使用することを目的とした、Sun 独自のエクスポート可能なアルゴリズムの実装です。このアルゴリズムは、汎用暗号として意図されていません。キー保護のアルゴリズムは次のように機能します。 p - ユーザー パスワード s - ランダム ソルト X - xor キー P - 保護されるキー Y - 保護されたキー R - キーストアに格納されるもの ステップ 1: ユーザーのパスワードを取得します。それに (固定サイズの) ランダムなソルトを追加し、それをハッシュします: d1 = digest(p, s) X に d1 を格納します。 dn = ダイジェスト (p, dn-1)。dn を X に保存します (以前に保存したダイジェストに追加します)。X の長さが秘密鍵 P の長さと一致するまで、この手順を繰り返します。手順 3: X と P の XOR を実行し、結果を Y に格納します: Y = X XOR P. 手順 4: s、Y、digest(p, P) を結果バッファー R に格納します。R = s + Y + digest(p, P)、ここで "+" は連結を表します。(注: digest(p, P) は結果バッファーに格納されるため、キーが復元されたときに、復元されたキーが元のキーと実際に一致するかどうかを確認できます。) R はキーストアに格納されます。保護されたキーは次のように復元されます。ステップ 1 とステップ 2 は上記と同じですが、ソルトがランダムに生成されず、ステップ 4 の結果 R (最初の長さのバイト) から取得される点が異なります。ステップ 3 (XOR 演算) により、平文のキーが生成されます。次に、パスワードを復元されたキーと連結し、R の最後の長さ (digest(p, P)) バイトと比較します。それらが一致する場合、復元されたキーは確かに元のキーと同じキーです。(注: digest(p, P) は結果バッファーに格納されるため、キーが復元されたときに、復元されたキーが元のキーと実際に一致するかどうかを確認できます。) R はキーストアに格納されます。保護されたキーは次のように復元されます。ステップ 1 とステップ 2 は上記と同じですが、ソルトがランダムに生成されず、ステップ 4 の結果 R (最初の長さのバイト) から取得される点が異なります。ステップ 3 (XOR 演算) により、平文のキーが生成されます。次に、パスワードを復元されたキーと連結し、R の最後の長さ (digest(p, P)) バイトと比較します。それらが一致する場合、復元されたキーは確かに元のキーと同じキーです。(注: digest(p, P) は結果バッファーに格納されるため、キーが復元されたときに、復元されたキーが元のキーと実際に一致するかどうかを確認できます。) R はキーストアに格納されます。保護されたキーは次のように復元されます。ステップ 1 とステップ 2 は上記と同じですが、ソルトがランダムに生成されず、ステップ 4 の結果 R (最初の長さのバイト) から取得される点が異なります。ステップ 3 (XOR 演算) により、平文のキーが生成されます。次に、パスワードを復元されたキーと連結し、R の最後の長さ (digest(p, P)) バイトと比較します。それらが一致する場合、復元されたキーは確かに元のキーと同じキーです。ステップ 1 とステップ 2 は、ソルトがランダムに生成されず、ステップ 4 の結果 R (最初の長さのバイト) から取得されることを除いて、上記と同じです。ステップ 3 (XOR 演算) により、平文のキーが生成されます。次に、パスワードを復元されたキーと連結し、R の最後の長さ (digest(p, P)) バイトと比較します。それらが一致する場合、復元されたキーは確かに元のキーと同じキーです。ステップ 1 とステップ 2 は、ソルトがランダムに生成されず、ステップ 4 の結果 R (最初の長さのバイト) から取得されることを除いて、上記と同じです。ステップ 3 (XOR 演算) により、平文のキーが生成されます。次に、パスワードを復元されたキーと連結し、R の最後の長さ (digest(p, P)) バイトと比較します。それらが一致する場合、復元されたキーは確かに元のキーと同じキーです。

于 2009-12-23T23:10:47.273 に答える
3

使用されるアルゴリズムは、使用するキーストアによって異なります (たとえば、SmartCard など)。

Sun が JDK に同梱するデフォルトのキーストアは、次の3 つの暗号化オプションを使用してソフト トークンを (ディスク ファイル上に) 作成します。

  1. デフォルト: "jks"、独自のキーストア タイプ (形式)。アルゴリズムについては不明です。

  2. 「jceks」、3-DES を使用した代替独自フォーマット

  3. 「pkcs12」、標準形式 (OpenSSL で読み取ることができる) で、いくつかのオプションがありますが、通常は秘密鍵用の 3-DES と証明書用の RC2-40 です。

3 つのケースすべてで、プライベート データが暗号化され (個別のパスワードを使用して対称的に)、キー ストア全体の整合性が暗号化ダイジェストによって保護されています (キーストア パスワードを使用)。

于 2009-12-23T22:36:54.257 に答える