web-dev-qa-db-ja.com

短い列挙値のハッシュの保護

システムは、短い文字列の機密データを管理および保存します。

機密データは既知の値のセットが限定された列挙型であるため、攻撃者は可能なすべての値を簡単に反復して、レインボーテーブルを生成し、辞書ベースの攻撃を利用する可能性があります。

したがって、これらの脅威に対抗するには、ハッシュする前にデータをソルト処理する必要があります。もちろん、「塩」も秘密にされ、暗号的に安全でなければなりません。アプリケーションは入力に対してハッシュ検索を行うため、ソルトはすべてのレコードに共通でなければなりません。つまり、ハッシュは確定的でなければなりません。

「シークレットソルト」のキー管理や秘密保持の側面など、列挙データタイプのハッシュを処理するためのベストプラクティスは何ですか？シークレットを保存するために、ハッシュでHSMを利用する予定です。

encryptionhashkey-managementsalthsm
3
Tuomas Toivonen

ソルトはすべてのレコードに共通でなければなりません。

これは、塩ではなく「コショウ」として知られています。

攻撃者はすべての可能な値を簡単に反復できる

サーチスペースがbcryptのような高コストのハッシュでもブルートフォースにできるほど小さい場合は、ブルートフォースを防ぐために「ペッパー」の機密性に完全に依存しています。この場合は、代わりに秘密鍵付きのHMACを使用することもできます。 HSMを使用してランダムなキーを格納し、HMACを処理することは、あなたが得ることができるのと同じくらい良いことです。

ハッシュを検索する機能が必要なため、同じデータは常に同じハッシュ値を持つことに注意してください。 Kevinの回答 がより詳細になるため、重複したハッシュ値が他のデータと関連付けられて情報が漏洩する可能性があります。

ハッシュを元に戻すことは理想的ですが、メッセージスペースが小さい場合は不可能です。あなたができる最善のことは、ハッシュを逆にするためにHSMのみが使用できることを確認することです。これはデータ漏洩を防ぐのに役立ちますが、アプリケーションレイヤーがブルートフォースにならないように注意する必要があります。

10
AndrolGenhald

[回答よりも長いコメントです]

あなたは質問 encryption にタグを付けましたが、ソルトとハッシュについて話しています。ご指摘のとおり、ハッシュ関数は小さなメッセージスペース（典型的な例：メッセージが「はい」または「いいえ」のいずれか）を保護するのに不適切であるため、これらすべてのソルトアンドペッパーとHMACキーを追加する必要があります。

ただし、適切な暗号化、具体的にはブロック暗号は、「はい/いいえ」のメッセージスペースでも安全になるように設計されています。実際のAES暗号化を使用できない理由はありますか？ （ボーナスポイントの場合は、AES復号化キーをHSMに保存します）。

2
Mike Ounsworth

簡単な答えを見てみましょう。あなたは自分のやりたいことができません。あんまり。

簡単に推測できる一連の値を暗号化してデータベースに保存したいので、データベースを壊した人は誰でもそれらが何であるかを知ることができません...しかし、その用語でデータベースを検索できるようにしたいとします。つまり、機密性の高いすべての「タグ」は、まったく同じ値に暗号化する必要があります。

さて、例はどうですか。

Name     MedicalStatus
----------------------
Kevin    Dying
Bob      Alive
Charlie  Dying
Diana    Alive
Elaine   Alive
.... followed by 10k more rows of 'Alive' or 'Dying'

...持つことの安全性はどれくらいか：

Name     MedicalStatus
----------------------
Kevin    dk3jnnd832jj3fd
Bob      cx32d89dh32gf1x
Charlie  dk3jnnd832jj3fd
Diana    cx32d89dh32gf1x
Elaine   cx32d89dh32gf1x
... followed by 10k more rows of either 'dk3....' or 'cx32d...'

値を「解読」する必要さえありません。 guess one-結局のところ、それらは簡単に推測できると言っていました-そして、テーブル内の他のすべての一致するエントリをクラックしました。これらの値を覆い隠そうとする船外活動の程度や、使用するテクノロジーの「安全」の程度は関係ありません。攻撃者の観点からは、何が起こっているのかは非常に明白です。

（そう、彼らが私のようなものなら、彼らはそれを楽しいパズルと見なします;義務 https://xkcd.com/1286/ ）または、彼らが怠惰なのなら、彼らはアプリレイヤーを使用してデータベースにいくつかのレコードを作成し、値がどのように格納されているかを確認します。

だから、それは...あなたは何ができるのですか？

オプションA：高速クエリ要件を破棄します。実際のソルト（ペッパーではない）を使用し、可逆暗号化アルゴリズムを使用してエントリを安全にすることができます。しかし、マイナス面は、ご存知のように、検索では検索中に各エントリを復号化する必要があることです。

オプションB：Obscurityによるセキュリティ。ええ、あなたはこのオプションが醜いものになることを知っています（通常、セキュリティは不明瞭です）。しかし、フィールドを作成することもできますcallハッシュ-しかし、単にXORその機密カラムを介してデータをスクランブルします。検索を実行すると、フィールド自体は検索されなくなりますが、XORコンボです。これは、インデックスシークを実行できなくなったことを意味します（インデックススキャンを解決する必要があります）。厳密な設定ではありませんが、少なくとも、すべての同じエントリがまったく同じ値を持つよりは優れています。

オプションC：ルックアップを実行する人が検索できるハッシュのみを持ちます。別名、各人に固有のキーを使用してエントリをハッシュします。確かに、これはglobal lookupが存在できないことを意味します。ただし、少なくともユーザーが一致するレコードを検索することはできますtheirレコード。

オプションD：再考して再設計します。真剣に、あなたの要件は本当にここではうまくいっていません、そして私はあなたがまったく安全でないシステムを作ることになるだろうと私は感じています。ここでのあなたの目標は、「要件XとYを可能な限り安全に守るシステムを作ること」ではありません。あなたの目標は、「XとYの要件を満たそうとする安全なシステムを作ること」です。目的を安全に達成できない場合は、決してそれを行うべきではありません。

2
Kevin

コショウ/塩/その他のハッシュメカニズムの管理で生活を複雑にすることなく、HSMを展開することを示したので、適切な暗号化を使用して列挙値を保護することをお勧めします。

HSMは暗号化コンピューティングハードウェアモジュールであり、保護されたキーストアは明確に定義されたインターフェイスプロトコルで動作し、妥協は困難です。

使用できる対称/非対称キーは次のとおりです。

  • 対称：AES、3DES、Blowfishな​​ど
  • 非対称：RSA、DSA、Diffie-Hellmanなど

HSMは、鍵の生成、鍵の転送、鍵の保管の保護、鍵の処理、鍵のバックアップ/リカバリー機能の提供など、さまざまな方法でユーザーを支援できます。

1
Sayan