web-dev-qa-db-ja.com

AESキーとパスフレーズについて

私はAESがどのように機能するかについて頭を動かそうとしています。特に、キーの生成と「パスフレーズ」に関するクエリがあります。

私の理解では、AESのブロックサイズは128ビットですが、キーの長さは、使用するバリエーションによって異なります。たとえば、AES256は256ビットのキーを使用します。

  1. 暗号化がキーに依存している場合、256ビットのキーを生成するために、暗号で保護された擬似乱数ジェネレータを使用する必要がありますか?
  2. これを見ると サイト キーを生成するときにパスフレーズを設定することもできます。キーを生成するときにパスフレーズはどのような役割を果たしますか?
  3. ポリシーによりAESキーをローテーションする必要があった場合、新しいキーで再暗号化する前に、古いキーを使用して暗号化されたデータを復号化する必要がありますか?これはアプリケーションログイン内で構築する必要があると思いますか?
1
deltzy

この質問は広すぎたり狭すぎたりしますが、何ができるか見ていきます。

AESブロックとキーサイズについてのあなたの理解は正しいです。

  1. 通常、はい、暗号化された安全な(P)RNGを使用して暗号鍵を生成します(AESを含むすべての暗号)。ただし、人間がキーを覚える(またはキーを生成するために使用できるデータを覚える)必要がある場合など、これが実用的でない場合もあります。そのような状況では、「秘密」(場合によってはパスワード/パスフレーズ)をキーに変換する key-derivation functions があります。 KDFは実際にはエントロピーを追加しないため、結果のキーは真にランダムなものよりもブルートフォースの影響を受けやすくなります(真にランダムな128ビットキーはブルートフォースすることが事実上不可能であり、256ビットキーよりはるかに少ない)。 、しかし時にはそれはあなたが受け入れなければならないリスクです。 KDFは通常、故意に遅く、時には(比較的)RAMを集中的に使用するため、潜在的なシークレットのプール(通常は大きい)から総当たりのキーを実行すると、並列化がはるかに遅く/困難になります。
  2. 私はそのサイトが何をしているのかわからないので、そのソースコードを調べないと、「何をしているのか」と言っても、自信を持って言えませんでした。どこかで書き込み。パスフレーズは必要ありません(パスフレーズがないと、バグのある出力が生成されます)。 PRNG(secure or not))を使用して「塩」を生成し、KDFを使用してそのソルトとパスフレーズからキーを生成する場合があります。PRNG-安全かどうか-これにより、「エントロピーを追加」し、パスフレーズを追加エントロピーとして挿入し、そのキーからPRNGを直接生成することができます。これは技術的に安全ではありません。しかし、一般的には無意味で誤解を招く可能性があります(たとえば、JavaのSecureRandomクラスcan追加のエントロピーを受け入れますが、これを行う正当な理由はほぼありません)。そのサイトに関する詳細情報が必要な場合は、別の質問で。
  3. 何らかの理由(ポリシーを含む)で暗号化キー(AESを含む)をローテーションする必要がある場合は、古いキーを破棄する前に古いキーを使用してデータを復号化する必要があります。そうしないと、データが失われます。次に、新しいキーを使用してデータを再暗号化する必要があります。そうしないと、データはプレーンテキストになります。これを実行する通常の方法は、データを暗号化および復号化するために実際に使用される「マスターキー」を生成し、ユーザーキー(パスフレーズから導出される可能性がある)でマスターキーを暗号化(および復号化)することです。ファイル内など)。マスターキーはプレーンテキストで保存されることはなく、データの暗号化または復号化、またはユーザーキーのローテーションが必要な場合にのみ短時間で復号化されます。このように、ユーザーキーをローテーションするには、マスターキーを復号化し、新しいユーザーキーで再暗号化する必要があります。データ本体全体を復号化および再暗号化する必要はありません。マスターキー自体は暗号化されて保存され、ユーザーや他のシステムに公開されることはないため(少なくともプレーンテキストではありません)、侵害された疑いがない限り、ローテーションは必要ありません。これは、フルディスク暗号化ユーティリティなど、大量のデータを暗号化する必要があるシステムの数です。

アプリケーションがどのように機能し、その目的が何であるかについての詳細な情報がなければ、キーローテーションプロセスがいつどこで発生するかについてはコメントできません。特定の暗号システムの設計について支援が必要な場合は、ここで別の質問をすることができますが、本当に暗号システムの設計に詳しい人を雇う必要があります。暗号化は困難であり、独自の設計を展開することは、おそらく独自のプリミティブの独自の実装を展開するよりも安全ですが、独自のプリミティブの設計ははるかに少ないですが、依然としてリスクのあるビジネスです。

4
CBHacking

3つ目の質問の補足として、キーローテーションは、状況によって意味が異なります。鍵管理システムを使用する場合、鍵のローテーションとは、将来の暗号化に使用する新しい鍵を生成することを意味します。ただし、古いキーはシステムに残り、復号化のために保持されます。暗号化されたすべてのデータには、暗号化に使用されたキーのIDがタグ付けされ、暗号化に使用されたのと同じキーでデータを復号化できます。これにより、一括データのバッチを再暗号化するリスクを回避できます。多くの場合、場所全体に散らばっており、時には鍵の所有者の制御が及ばないデータ。

これにより、暗号化の暗号化期間と復号化の暗号化期間が異なることも可能になります。たとえば、キーマネージャーに最後の12個のキーのみを保持するだけで、キーを毎月ローテーションし、古いキーを毎年削除できます。

ただし、このようなシステムには欠点があります。彼らはしばしば他と相互運用しない独自のタグ付けシステムを使用します(たとえば、暗号化キーを識別するためにCMS形式のエンベロープを使用するものは見たことがありません。)これはベンダーのロックインを強力に促進します。データを復号化します。

1
John Deters