web-dev-qa-db-ja.com

DPAPI.Protectのエントロピーパラメータの目的は何ですか？

したがって、Windowsでは、Data Protection APIを呼び出すときに、いくつかのバイトを「エントロピー」として指定できます。

私には、これは塩のように聞こえます。 PBKDF2では、ソルトは缶詰であり、実際にはプレーンテキストとして格納する必要があります。アルゴリズムのセキュリティを損なうことはありません。アルゴリズムの実装の一部です。

DPAPIに渡す「エントロピー」は同じ機能を果たしますか？ログインユーザーがDPAPIで保存されたキーを読み取った場合、エントロピーなしでは暗号化されたデータを解読できなかったという点で、キーがある程度アプリケーション固有になっていることをすべて読みました。もちろん、エントロピーはプレーンテキストとして保存する必要があります（そうしないと、無限のリグレッションが発生します）。

それで、エントロピーをプレーンテキストとして保存してもいいですか（多分それをハードコードします）？

dr jimbobに感謝：

エントロピーパラメータは、「アプリケーションによって提供されるオプションのエントロピーであり、キーの派生に追加されます[...]デフォルトでは、DPAPIはすでに各blobに異なるエントロピーを使用しているため、実際には追加のエントロピーを追加するとnot = [太字で追加]暗号化のセキュリティを向上させます。ドキュメントによると、その目的は、DPAPIに依存するアプリケーションが他のアプリケーションによってシークレットが盗まれるリスクを軽減できるようにすることです。このテストでは、GTalkのみが条件付きエントロピーを使用していることがわかりました。その値はレジストリキーに格納されているため、攻撃者にとって実際のハードルではありません。」

encryptionwindows
13
John

ブラウジングから： http://msdn.Microsoft.com/en-us/library/ms229741.aspx

エントロピーは、暗号化ソルトではなく、16バイト（128ビット） 初期化ベクトル を提供します。

通常、IVを秘密にしておく必要はありません [1] 、同じIVを再利用しないように注意する必要があります（ランダムに生成された場合は発生しません）。128 可能な値）。

初期化ベクトルの目的は、暗号化する前にメッセージを最初にランダム化することです（通常、最初のブロックのみ）。

IVを必要としない Electronic CodeBook（ECB） と、IVを必要とする Cipher-Block Chaining を比較してください。

固定サイズ（128ビットなど）のデータのブロックを取り、秘密の暗号化キーを受け取り、暗号化されたデータのブロックを返す暗号化関数encrypted_block = Encrypt(block, key)があり、block = Decrypt(encrypted_block, key)。したがって、128ビットのブロックサイズで10 kBのファイルを暗号化する場合、暗号化するブロックは640になります。元の2つのブロックが同一である場合（エントロピーがほとんどない画像など）、最後の暗号化されたブロックは同一になり、パターンが識別されることがよくあります。したがって、ECBは基本的にファイルをブロックに分割し、暗号化機能を各ブロックに個別に適用します（前のブロックの出力に依存しません）。

次に、初期化ベクトル（IV）を使用するCBCのようなスキームを見てみましょう。最初のブロックはencrypted_block_0 = Encrypt(block_0 ^ IV, key)によって暗号化されます。ここで、^はXOR（ビット単位の排他的OR演算子）です。次のブロックはencrypted_block_1 = Encrypt(block_1 ^ encrypted_block_0, key)で暗号化されます;つまり、前のブロックの暗号化の結果を使用して、暗号化関数に入力する前に現在のブロックを「ランダム化」します。これで、最初のブロックに初期化ベクトルを使用しなかった場合は、最初の2つのブロック。たとえば、同じ初期化ベクトルを持つ2つの暗号化ファイルがあり、最初の10ブロックが同一であることがわかった場合、プレーンテキストファイルの最初の10ブロックは同一であり、追加の情報を取得します。複雑な非線形Encrypt関数の中にあり、秘密keyを知らずに元に戻すことはできないため、プレーンテキストでIVを知っているだけではまったく役に立ちません。

編集：実際には、16バイトがDPAPIの初期化ベクトルとして使用されていると想定するのは間違っていたと思います。ここにマイクロソフトの秘密のDPAPIのリバースエンジニアリングがあります： http://cdn.ly.tl/publications/Recovering-Windows-Secrets-and-EFS-Certi%EF%AC%81cates-Of%EF%AC% 82ine.pdf

4
dr jimbob

MSDNドキュメント は、それを説明するのに非常に優れています。

ログオンパスワードを使用する場合の小さな欠点は、同じユーザーで実行されているすべてのアプリケーションが、保護されているデータにアクセスできることです。もちろん、アプリケーションは独自の保護されたデータを格納する必要があるため、データへのアクセスを取得することは他のアプリケーションにとって多少難しいかもしれませんが、不可能ではありません。

基本的に、誰かが保護されたデータ（たとえば、レジ​​ストリに保存された暗号化された接続文字列）を発見した場合、ユーザーのコンテキストで実行される単純なアプリケーションがDPAPIを使用して保護されたデータを解読できます。

これに対抗するために、DPAPIでは、アプリケーションがデータを保護するときに追加のシークレットを使用できます。この追加のシークレットは、データの保護を解除するために必要です。

技術的には、この「秘密」は二次エントロピーと呼ばれるべきです。データの暗号化に使用されるキーは強化されませんが、同じユーザーで実行されている1つのアプリケーションが別のアプリケーションの暗号化キーを危険にさらすことが難しくなるため、二次的なものです。アプリケーションは、このエントロピーをどのように使用および格納するかについて注意する必要があります。単純に保護されていないファイルに保存された場合、攻撃者はエントロピーにアクセスし、それを使用してアプリケーションのデータの保護を解除できます。

エントロピーをプレーンテキストで明らかに保護されたデータと同じ場所に保存すると、目的が完全に無効になります。

パラメーターについては、以下でさらに説明します。

内部保護機能

pOptionalEntropy
データの保護に使用される追加のエントロピーを含むDATA_BLOBへのポインター。 cbDataメンバーは、オプションのエントロピーを含むpbDataメンバーのバイト文字列の長さを保持します。保護呼び出しで使用されるDATA_BLOBは、保護解除呼び出しでも使用する必要があります。これは、前述のアプリケーション固有の「秘密」です。
このパラメータはオプションであり、NULLにすることができます。

内部保護解除機能

pOptionalEntropy
データが保護されたときに使用された追加のエントロピーを含むDATA_BLOBへのポインター。 cbDataメンバーは、オプションのエントロピーを含むpbDataメンバーのバイト文字列の長さを保持します。これは、前述のアプリケーション固有の「秘密」です。
このパラメータはオプションであり、NULLにすることができます。ただし、オプションのエントロピーが保護呼び出しで使用された場合、同じエントロピーが非保護呼び出しでも使用される必要があります。

したがって、エントロピーパラメータを使用して、エントロピー値を見つけることを少し難しくすることで、他のアプリケーション（またはユーザー）に対する保護を強化できます。

それで、エントロピーをプレーンテキストとして保存してもいいですか（多分それをハードコードします）？

場所が見つからない、またはアクセスが難しい場合は、平文で問題ありません。保護されたデータと同じ場所に配置しても意味がありません。

すでにユーザーアクセスがあり、十分な時間とリソースがある攻撃に対しては、「完全なセキュリティ」を得ることができません。しかし、それらを遅くするためにできることがいくつかあります：

  • アプリケーションでエントロピー値をハードコーディングすると、バイナリで見つけることができます。しかし、これはより困難です。
  • 単純な変換（XORなど）を使用する前にエントロピー値に適用する場合、攻撃者が何をすべきかを知るために、アプリケーションを逆コンパイルするか、ソースコードを改ざんする必要があります。
  • エントロピー値をリモートで保存できます。つまり、攻撃者はそれを見つける場所を知る必要があります。それにアクセスするには、適切な他の資格情報が必要です。 （もちろん、他の資格情報もアプリケーションにアクセスできる必要があると述べたため、このシナリオで「完全なセキュリティ」を実現することはできません。）
12
Disillusioned