AliceとBobがセキュアチャネルを使用して通信していて、どちらも暗号化/復号化に対称鍵アルゴ(AES)を使用しているとします。 シナリオは似ています
1. Alice encrypt data M1 with secret key K and sends cipher text C1 to Bob.
2. Bob receives cipher text C1 and decrypt it to get plaintext M1.
3. Bob encrypt data M2 with secret key K and sends cipher text C2 to Alice.
4. Alice receives cipher text C2 and decrypt it to get plaintext M2.
これらのシーケンスは、通信が終了するまで繰り返し行われます。
アリスとボブの両方が最新のカーネルを備えたLinuxシステムを使用しています。
セキュリティの観点から次の質問があります。
侵入者がなんとかしてアリスのシステムでroot権限を獲得できた場合、侵入者は、アリスが復号化操作を実行している間、メモリに保存されている平文M2をキャプチャできますか?
暗号化/復号化の実行中に秘密鍵Kがメモリに格納されている場合(そうであるかどうかは不明です**)、Intruderも同じ方法で秘密鍵Kを取得できますか?
編集1:
両方の答えから、それはMEMORY DUMPを使用して知られています、秘密鍵と平文を回復することが可能です。
例で説明できますか?
この質問には実装コンテキスト、つまり問題のアルゴリズムを実装するソフトウェアがありません。その警告があれば、答えは「はい」と「はい」です。ルート権限を持つ侵入者は、プレーンテキストメッセージとキーの両方を抽出できます。
最近の実装はこれを非常に意識しており、メモリからできるだけ早くキーを消去しようとします(この「できるだけ早く」の解釈はさまざまです)。ただし、メッセージとキーの両方の露出をゼロに下げることは実際には不可能です。
せいぜい、鍵はハードウェア支援ソリューション( [〜#〜] sgx [〜#〜] または [〜#〜 ] hsm [〜#〜] )-または別の復号化ソリューション(あなたが暗示しているのではない)-同じシステム/カーネルでの復号化。
そのシステムで使用するために必要である限り、メッセージ自体は保護できません。ただし、一部のあいまいさは管理できます。たとえば、一部のソフトウェアは、単純な「文字列」分析に勝る手法を使用しています。参照をどこかに保存したいのですが。ここにリンクできません。
はい、両方の質問に。使用しているカーネルやOSは関係ありません。解読された平文willはメモリ内にあります。ただし、平文を一度に1バイトずつ送信し、後でメモリ構造を無害化する非常に特殊なシステムを使用している場合を除きます。
平文を難読化することは可能です(たとえば、Feistelネットワークや正方形のSボックスなどのスクランブルマッピングを介して保存する)が、スクランブルパラメータをメモリに置く必要があるため、この「難読化によるセキュリティ」としたがって、セキュリティはまったくありません。
同じことが秘密鍵にも当てはまります。さらに、秘密鍵はhasが復号化全体で利用可能です。これにより、平文の送信とその後のクリアリングが無意味になります(暗号文は傍受によって攻撃者に知られていると見なされます。Kが回復すると、ゲームはAliceとBobが行うことができるすべてのことをはるかに上回ります)。