派生キー/ IVを使用するAES。それは弱点をもたらしますか？

Question

大規模なWebアプリケーション全体で使用される単一のグローバルキーを使用して、AESでデータベースの複数のフィールドを暗号化する効率的な方法を探しています。

明らかに、このキーを再利用するために、暗号化されるフィールドごとに一意のランダムIVが必要です。

これらのIVのそれぞれを格納するために、データベースにフィールドを追加したくないので、プログラムによるアプローチでは、これらのIVをなんらかの方法で導出するようです。

私はどちらかを使って遊んでいます：

key = sha256(global_key + table_name) iv = sha256(column_name + primary_key)

あるいは単に：

key = global_key iv = sha256(table_name + column_name + primary_key)

テーブルごとのキーを生成するために、前者に傾いています。

私はすでに読んだ IVを秘密にする必要がないことを確認しました。したがって、私は（アルゴリズムが既知になった場合でも）派生キーまたはIVが他の非秘密のIVよりも安全でないという仮定に取り組んでいます元のキーが秘密のままである限り。

質問は：

私のアプローチに致命的な欠陥はありますか？攻撃者がデータベースのコピーを入手した場合に、プレーンテキストデータを簡単に取得できる深刻な弱点を紹介しますか？

私はそれが1つのWordの回答を潜在的に求めていることを理解しています。

代替/より優れたスキームの提案、および既存の作業への参照と、それらが同様のシナリオを実装する方法を歓迎します。

Stephen Touset · Accepted Answer

潜在的に優れたアプローチは、IVと暗号文を1つの列に格納することです。これにより、暗号化モードの選択に最も適した方法でIVを生成できると同時に、列を追加する必要がなくなります。

"$AES-128-CBC$" + Base64.encode64(iv) + "$" + Base64.encode64(ciphertext)のようなものはcryptで使用される形式に似ており、簡単に解析できます。また、コマンドラインクライアントを使用してデータベースでクエリを実行する場合は、Base64エンコードされている方が少し便利です。

D.W. · Answer

あなたのアプローチは安全ではありません。データベースの値を変更すると、以前の値の暗号化に使用したのと同じIVを使用して新しい値を暗号化します。（データは同じ場所に格納されるため、テーブル名、列名、および主キーは変更されません。）これにより、機密性が損なわれる可能性があります。ストリーム暗号またはAES-CTRまたは同様のモードを使用している場合、妥協は特に悪いです。同じストリームを使用して2つの異なる値を暗号化したため、古典的なキーストリーム再利用の脆弱性です（2タイムパッドは非常に安全ではありません）。。

代わりに、他の人が推奨するように実行することをお勧めします。ランダムIVを生成し、暗号文と一緒に保存します。実際、ほとんどの操作モードでは、IVを暗号文の一部と見なすことができます。

rook · Answer

CBCモードを使用していると思います...

これは CWE-329違反であると私は主張します。 IVは攻撃者に知られている可能性がありますが、ランダムである必要があります。問題に対するより一般的な解決策は、非常に安全なランダム値を格納し、これを「IV」として使用することです。

「secret」という名前のテーブルがあるとします。攻撃者にはSQLインジェクションの脆弱性があり、このテーブルを見ると、現在の主キーの値もわかります。単純なsha256ハッシュを計算することで、次のIVを予測したり、将来のIVのテーブルを計算することさえできます。（プラットフォームによっては、SQLインジェクションの脆弱性が復号化Oracleに変わる可能性があります！Nasty！）

これをビルドする場合、PBKDF2などの適切な Key Derivation Function を使用します。これらはより重い関数であり、攻撃者がore-computeまたはまとめて計算することを困難にします。それほど重いものである必要はありませんが、結果の値は暗号と同じサイズである必要があります。

別の可能な解決策は、グローバルな「IVシークレット」を持つことです。パス iv_secret + column_name + primary_keyをキー導出関数に追加して、IVを生成します。シークレットの使用により、IVは予測可能な値ではなくなり、CWE-329違反ではなくなりました。さらに、この値はナンスでもあり、同じIVが2つの異なる値に対して2回生成される可能性はほとんどありません（更新を行わない限り、違反になります）。これを緩和するには、「バージョン番号」または最終変更のタイムスタンプをIV計算に追加します。