21

背景: データベースで AES (対称暗号) で暗号化されたデータを取得しました。(想定) 安全で隔離された Linux ボックスで実行されるサーバー側アプリケーションは、このデータを使用します。DB から暗号化されたデータを読み取り、暗号化されたデータを書き戻し、メモリ内の暗号化されていないデータのみを処理します。そのため、これを行うには、アプリでキーをメモリに保存する必要があります。

問題は、これに対する適切なベスト プラクティスがあるかどうかです。メモリ内のキーを保護します。

いくつかのアイデア:

  1. スワップできないメモリに保持する (Linux の場合: ?SHM_LOCKで設定shmctl(2))
  2. キーを複数のメモリ ロケーションに分割します。
  3. キーの暗号化。キーキーを安全に保管するには、何を使用し、どのようにしますか?
  4. 必要なたびにファイルからキーをロードします (時間がかかり、悪意のある人物が私たちの記憶を読み取ることができれば、おそらくファイルも読み取ることができます)

キーが漏洩する可能性がある理由に関するいくつかのシナリオ: 悪者がメモリ ダンプ/コア ダンプを取得する。情報漏えいにつながるコード内の不適切な境界チェック。

最初の 1 つは、実行するのが適切で非常に単純なことのように思えますが、残りはどうですか? 他のアイデア？標準仕様/ベストプラクティスはありますか?

ご意見ありがとうございます。

4

6 に答える 6

12

すべては、あなたのパラノイアのレベルとキー/データの機密性に依存します。極端な場合、暗号化されていないキーがメモリにあるとすぐに、コールドブート技術を使用してそれを取得できます。それを打破しようとする興味深い開発が、frozencacheで行われています。何気なく読んだだけで、実際にやってみたわけではありませんが、やってみると面白いアプローチのようです。

ただし、アルミ箔の帽子を脱いで - (1)、(2)、(3) は合理的に見えます。(4) あなたが言った理由で正確にカットしません。（遅いだけでなく、スタックに読み込むと仮定すると、スタックの深さが異なると、キーが複数回表示される可能性があります）。

復号化されたデータに価値があり、それがスワップ可能なメモリにあると仮定すると、スワップ自体も暗号化する必要があります。また、ルート、/tmp パーティションも暗号化する必要があります。これは、OS のほとんどのガイドですぐに利用できるかなり標準的なセットアップです。

そしてもちろん、マシン自体の高レベルの物理的セキュリティを確保し、マシンが実行する機能を最小限に抑える必要があります。実行されるコードが少なければ少ないほど、露出は少なくなります。また、このマシンへのリモート アクセスの可能性を最小限に抑える方法も確認したい場合があります。つまり、RSA キー ベースの ssh を使用すると、別のホストから制御される別の ACL によってブロックされます。ポートノッキングは、その 2 番目のホストにログインできるようになる前に、認証の追加ベクトルの 1 つとして使用できます。ホストが危険にさらされると、データを取り出すことがより難しくなります。このホストがインターネットへの直接ルーティング可能な接続を持っていないことを確認してください。一般に、機密データにアクセスするのに苦労すればするほど、誰かがそこにたどり着く可能性は低くなりますが、通常のユーザーの生活も苦痛になります。残高。

アプリケーションが深刻で、問題の量が多い場合は、より明確な全体的な脅威モデルを構築し、予測可能な攻撃ベクトルを確認し、セットアップがそれらを効果的に処理することを確認することをお勧めします。（そして人的要因を含めることを忘れないでください:-)

更新: 実際、特殊なハードウェアを使用して暗号化/復号化を処理する場合があります。その後、キーの保管に対処する必要はありません - ハミッシュの回答を参照してください。

于 2009-08-11T22:53:36.650 に答える
7

セキュリティを真剣に考えている場合は、別の暗号化サブシステムを検討することをお勧めします。できれば、FIPS 140-2/3認定 (認定モジュールのリスト) を取得したものを使用してください。
その後、キーは改ざん防止メモリ (抽出不可) に保持され、すべての暗号操作は暗号境界内で実行されます。
高価ですが、一部のアプリケーションには必要です。

于 2009-08-11T23:04:00.607 に答える
3

また、コア ダンプの脅威とメモリがスワップ アウトされることも忘れないでください。

POSIX (Linux など) と Windows システムの両方で、C 言語を扱っている場合にそれを防ぐ手法があります - CERT Secure Coding Standards の次のセクションを参照してください。

MEM06-C. 機密データがディスクに書き出されないようにする

于 2010-03-24T16:00:19.843 に答える
1

大きな問題は、プログラムがどこかからキーを読み取らなければならないことです。サーバーが再起動するたびに直接キーボード入力を受け入れない限り、ディスクのどこかに存在する必要があります。

一般に、悪者はルート レベルのオペレーティング システムやハードウェアにアクセスできないと想定する必要があります。その場合、たとえそれが RAM にしかなくても、最終的にキーを取得することができるからです。

したがって、サーバーの OS は安全であると想定します。しかし、誰かがハードドライブを盗みに来て、サーバーを起動するとキーが得られるとしましょう。次に、サーバーが別のサーバーにキーの半分を要求すると、リモート サーバーは (IP、秘密/公開キーのペアを使用して) 要求を検証し、キーの半分を提供します。次に、サーバーには完全なキーがあり、リモート サーバーには半分以上のキーがありません。それは私には改善されたレベルの保護のようです。

于 2009-08-11T22:58:58.653 に答える
1

私は何を見ているだろう

鍵を取り扱う際に行ってください。彼らはそのようなセキュリティ問題について十分に偏執的です...

于 2009-08-11T23:07:54.000 に答える
1

「スーパー スーパー ユーザー」ハードウェア メモリの使用が理想的です。すべての Intel Mac にはこの SecureEnclave メモリ領域があり、アプリケーションとオペレーティング システムが生の秘密鍵にアクセスできないように、ハードウェアに AES 復号化も含まれています。マシンが起動すると、パスワードが入力され (オプション)、SecureEnclave はコールド フラッシュ メモリで暗号化されたバージョンのキーを、メインのオペレーティング システムからアクセスできない RAM 領域に復号化します。

良い副作用は、ハードウェア アクセラレーションによる暗号化です。新しくフォーマットされた暗号化ディスク上の PCIe ストレージへの 600 MB/秒の書き込みをベンチマークしました。

クラウドでは、Amazon はこの AWS Key Management Service (KMS) マネージド サービスを使用して、データの暗号化に使用される暗号化キーの作成と制御を容易にし、FIPS 140-2 検証済みのハードウェア セキュリティ モジュールを使用してセキュリティを保護します。キー: https://aws.amazon.com/kms/

于 2018-04-02T03:24:11.587 に答える