web-dev-qa-db-ja.com

クエリに含めることができるように、データベース内のフィールドを暗号化するための最も安全でない方法

（PKを除いて）すべての列を暗号化する必要があるテーブルがあります。これは、アプリケーションレベルでAESを使用して実現されます。ただし、検索可能なままにする必要がある特定のフィールドが1つあります。

たとえば、メッセージテーブルには次のものが含まれます。

  • MessageTitle（暗号化）
  • MessageBody（暗号化）
  • SenderID（暗号化されているが一致可能）

PlainText SenderIDを指定すると、関連するすべてのメッセージを選択できるはずです。

いくつかの制約/決定：

  1. この列を含め、保存データを暗号化する必要があります。私は選択肢がありません。
  2. SenderIDは固定形式であるため、値をハッシュするとブルートフォースは難しくありません。
  3. 私は、データベース全体（TDE）ではなく特定のフィールドを暗号化して、盗まれたディスク以外の脅威を軽減することを選択しました。

現在、私の推奨する解決策は、固定IVでSenderID（およびSenderIDのみ）を暗号化することです。このように、データは暗号化されたままですが、クエリでそれを照合することができます。

このアプローチの欠点は、プレーンテキスト攻撃がデータに発生する可能性があることです。 DBAは、異なるSenderIDでレコードを作成し、一致するレコードを見つけようとする可能性があります。ただし、適切なアクセス制御と監視を行うことで、暗号化サービスでこれを軽減できると思います。

これは有効な解決策のように見えますか？

encryptiondatabasessql-server
3
Dan Rowlands

あなたが私たちに言ったことを考えると、私はまだハッシュ関数を使用します：それはまさに彼らが設計されたものです。

残念ながら、クリアテキスト値のみに基づいて特定のレコードを検索できるようにしたいが、ハッシュ値をソルトすることはできませんが、 [〜＃〜] hmac [〜＃〜] を使用できます直接攻撃から保護するためのアルゴリズム：攻撃者は、特定のクリアテキストからハッシュを導出するために、HMACの計算で使用されるキーにアクセスする必要があります。アプリケーション）、SenderIDは非表示のままですが、簡単な検索でいつでも見つけることができます。

SenderIDのエントロピーが低い場合は、HMACを使用することも役立ちます（ただし、その問題は完全には解決されません）。

HMACの計算で使用されるキーにアクセスできる（または取得できる）ユーザーは、与えられたクリアテキストをデータと照合しようとすることができますが、それは手助けできないと思います。

ただし、インストールごとに異なるキーを使用することはできますが、そうする必要がありますが、後でそのキーを変更することはできません。そうしないと、レコードを見つけることができなくなります。これを回避する1つの方法は、SenderIDの暗号化されたバージョンをレコードに追加することです。すべてのキーを再入力する必要がある場合は、それを使用して新しいハッシュを再計算できます。

ただし、HMACには強力で最新のハッシュ関数を使用することをお勧めします。 （ SHA- 、たとえば、最終的な仕様がまだ公開されていない場合でも）

2
Stephane

ハッシュの場合、同じフレーズで同じハッシュ値が作成されるため、ハッシュを計算してその値を使用して検索できます。 SenderIDは一意であると想定しているため、必ずしもこのハッシュをソルトする必要はないかもしれませんが、ソルティングは決して悪い考えではありません。また、senderIDだけにパスワードが必要なのはなぜですか？メッセージ本文を検索可能にする必要がある場合は、暗号化されたコンテンツを取得し、復号化してから一致するものを探します。

たとえば、単語bobは常にmd5を使用して9f9d51bc70ef21ca5c14f307980a29d8に計算されるため、senderIDが偶然bobの場合、ユーザーはbobを入力します。コードはその文字列をハッシュして9f9d51bc70ef21ca5c14f307980a29d8を取得し、* from email where senderid = '9f9d51bc70ef21ca5c14f307980a29d8'を選択します

1
Four_0h_Three