web-dev-qa-db-ja.com

AESキー管理

私はdbフィールドの秘密を暗号化しています。

256ビットキーと暗号化ごとにランダムIVを使用してAESを使用して暗号化しています。

これらのAESキーはコードにハードコードされています。各IVは、暗号文を含む行の別のフィールドに平文で保存されます。

この暗号化を改善するにはどうすればよいですか? AESキーを暗号化する必要があると思いますが、最適なスキームがわかりません。お知らせ下さい。

シークレットは、同じコンポーネントによって暗号化および復号化されます。私はこの(の暗号文)秘密を永続化する必要があります。 C#を使用しています。

3
Sam Leach

AESキーはコードにハードコードされています。

これが問題です。しかし、いいえ、キーを別のキーで暗号化しても(コードにハードコードされます)、実質的に問題は改善されません。

次のことを行う必要があります攻撃モデルを書き留めます。暗号化を実行しているのには理由があります。悪意のある個人が実行しようとすることを信じています...正確には何ですか?これが攻撃モデルのポイントです。想定される攻撃者が実行できること、および攻撃者が達成したいことをdefineすることです。明確に定義された攻撃モデルを使用して初めて、どのセキュリティアルゴリズムとプロトコルが役立つかについて考えることができます。

たとえば、暗号化は機密性に適したツールです。これは、攻撃者がデータを読みたいが、攻撃者が成功したくない場合です。 暗号化は解決しません解決機密性;それは単に問題を集中させます。暗号化では、データを機密に保つ問題はkeyを機密に保つ問題になります。キーが短いので、これにより問題の処理が容易になる場合とそうでない場合があります。重要な点は、whoがデータにアクセスできるようにする必要があることを決定することです。

話を簡潔に言うと、データが攻撃者のマシンで解読されることになっている場合(たとえば、攻撃者がユーザーであり、生のデータに次のようにアクセスできないようにしたい場合)ある種のライセンスまたはDRMスキームの一部)、それから、端的に言えば、あなたは負けます。自分のハードウェアを流れるデータに誰かがアクセスするのを確実かつ一貫して防止することはできません。 リバースエンジニアリング がうまく機能するからです。暗号化レイヤー(キーが別のキーで暗号化される別のキーで暗号化されるなど、ハードコーディングされた初期キーまで)を積み上げる場合、開発時間とリバースエンジニアリング時間の両方を増やすだけです。攻撃者よりも時間がかかる可能性があります。

5
Thomas Pornin