暗号化されたRAMを備えたOS？
暗号化された仮想メモリに焦点を当てたアプリケーション、JITフレームワーク、オペレーティングシステム、または同様のことを行う仮想マシンはありますか？完全に暗号化されたシステムを可能にするプロセッサ（古い、遅い、弱い）があることは知っていますが、OSやアプリケーションがx86またはその子孫の1つに適切なソリューションを考え出すことはまだありません。
L1/L2/L3キャッシュ、DMAバッファなどは、ハードウェアサポートなしでは暗号化できないが、確かに少なくとも特定のカーネル構造とほとんどのユーザーモードメモリ（つまり、割り当てられたもの）プロセスによって）コンパイル時にサポートが与えられれば暗号化できますか？
また、ユーザーモードのメモリを自動的に暗号化するコードを生成する既存のJITコンパイラ（.NET CLRなど）を変換することが理論的には可能である（明らかに難しい）かどうかも知りたいです。
これらの線に沿ったあらゆる種類の既存のソリューションは、見てみるのがとても楽しいでしょう。
また、ユーザーモードのメモリを自動的に暗号化するコードを生成する既存のJITコンパイラ（.NET CLRなど）を変換することが理論的には可能である（明らかに難しい）かどうかも知りたいです。
これは、OSがプログラムの代わりに行うのが非常に難しい場合があります。これは、オペレーティングシステムによって割り当てられた仮想ページが実際にはCPUによって制御されているためです-OSは、CPUにストレージ領域の観点から必要なものを指示し、CPUは、プログラムごとにそれに基づいてオフセットを計算します結果を直接適用します。 [〜＃〜] mmu [〜＃〜] と x86のページング を読んでください。
つまり、プログラムがmov eax, [edi+something]を計算すると、MMU /ページングがアドレス変換を処理し、ページが見つからない場合にページ違反を発行します。これにより、必要に応じて、ページをストレージからロードできます。
したがって、メモリアクセスはカーネル自体を経由しないため、ファイルの読み取りまたは書き込みのようにフックして処理することはできません（読み取りと書き込みは、適切なシステムコールを通じて適切なファイルシステム構造に変換されます。このような場合、OSはデータが通過するときにデータを認識します。RAMに書き込むためのシステムコールは必要ありません。RAMに書き込むことはできますが、それを呼び出すプログラムでのみ機能し、ほとんどのプログラムでは機能しません）。
ただし、これは、JITプロセスがアプリケーションに代わってこれを実行できなかった、またはアプリケーション自体がレジスタにロードする必要があるまでデータを暗号化したままにできず、データを渡すときに復号化することを意味するわけではありません。 。
その場合、あなたは問題に入ります SteveS はうまくカバーします-あなたはキーストレージの問題を抱えています。キー自体もRAMのどこかにある必要があります。これはカメの問題です。基本的に、キーを「安全」に保つことは不可能です。
最後に、別のアプリケーションのRAMを読み取るには、CPU（つまりカーネルスペース）へのスーパーバイザモードアクセスが必要であるため、ソフトウェアの傍受が懸念される場合は、さらに大きな問題が発生する可能性があります。ハードウェアに懸念がある場合は、物理的なセキュリティがリスクを軽減するより良い方法であると思います。
編集論文を探しました。これが CryptKeeper と呼ばれるものです。彼らのテクニックは、大きな暗号化された「RAMディスク」をスワップファイルとして使用し、使用されていない場合はすべてのページをスワップアウトすることです。
ソフトウェアで暗号化された仮想メモリマネージャーであるCryptkeeper（CK）を使用して、この脆弱性を緩和します。従来のプロセッサは暗号化されたデータを操作できないため、CKはRAMをClearと呼ばれる小さなワーキングセットとCryptと呼ばれるより大きな暗号化RAMデバイスに分割します。作業領域がいっぱいになると、ページは自動的にメモリの暗号化された部分にスワップされ、必要に応じて復号化されます。
パフォーマンスはそれほど悪くないようですが、まだ実装されていないと思います。
編集2したがって、CryptKeeperと OpenBSD Swap Encryptionメカニズム は非常に類似したレベルで機能することがわかります。実際に物理メモリを暗号化するのではなく、物理メモリをスワップ構造として使用して、ページフォールトを強制し、データを暗号化/復号化して解決します。
2018年12月の質問作成者による編集：AMDが SME命令セット拡張 をサポートするようになり、RAMページに加えて、フルメモリ暗号化用のTSME、および仮想化で暗号化メモリを使用するためのSEV。これにより、最新のAMD64プラットフォームでシステム全体のメモリ暗号化が有効になるようです。
OpenBSD オペレーティングシステムには、仮想メモリの自動暗号化が含まれています。バージョン3.9以降、デフォルトで有効になっています。
暗号化ハードウェアが組み込まれたCPUがない場合、キャッシュおよび物理RAMのデータは実際には暗号化できません。CPUはそれを使用できないためですが、「RAMブロックのコピー先」のような「仮想メモリ」そして「ディスクから」はオペレーティングシステムの完全な制御下にあるため、OSは自由に暗号化できます。これはOpenBSDが行うことです。ある程度、mostRAM=のうち、ディスク（RAMベースの仮想ディスク上のスワップファイル）のように使用することで、暗号化を維持できます。 ）。
RAMの内容は、電源を切ると自動的に消えるはずです（実際には、温度にもよりますが、約1分程度かかります）。
何か存在するかどうか知りたいのですが、ハードウェアの介入なしに存在できるかどうかは完全にはわかりません。
私の論理は、メモリが暗号化されるためには、キーがカーネルレベルにある引数のために直接アクセスしているプロセスによって知られている必要があるということです。ある時点で、プロセッサは暗号化されたデータを直接操作できないため、そのキーを暗号化されていないメモリに移動して、物事を暗号化または復号化する必要があります。このキーが暗号化されていないメモリに格納されると、メモリダンプ、カーネルドライバ、物理プローブなど、いくつかの方法でアクセスできます。
理論的には、メモリダンプがディスクに書き込まれるのを防ぎ、ドライバーがインストールされるのを防ぐことができます。また、デバイスを金庫にロックして海に落とし（できれば防水金庫）、物理的にアクセスできないようにすることもできますが、システムを劇的に使用します。
では、最初のステートメントを言い換えます。ハードウェアが介入しなくても存在する可能性がありますが、どれほど安全かはわかりません。
他の質問については可能ですが、それでも同じ基本的な問題に遭遇します。コンパイラとJITインタプリタを変更する必要があり、exeは独自のメモリ空間にキーを格納します。 exeは暗号を処理するためにインタープリターにキーを渡す必要があります。この問題は、暗号化されていないメモリのどこかに鍵を保存する必要があることです。実際、キーがexeにハードコードされている場合は、ファイルをクラックして開いて検索することができます。
それにもかかわらず、それは見るのにクールなものになるでしょう。
Cryptkeeperアプローチの問題は、重要なデータが平文のままであるということです（通常のシステムよりはるかに少ないですが）。私はこの1年間この問題を調査してきましたが、あなたが求めていることを実行していることはないと思います（私がある程度の改善に取り組んでいるもの）。 INTELは、今後数年間で、RAMのすべての内容を自動的に暗号化するチップをリリースすると思います。
暗号化RAMは、バスダンプから保護し、メモリ破損攻撃のクラス全体を軽減するためにのみ役立ちます。問題は、MMUまたは高速バスDMA OSをサポートするPCIe TEEのようなデバイス。
ゲストOSに対して透過的に実行するリング-1（VM）システムがありますが、これはゲストまたはホストでのコード実行攻撃を軽減するためには何もしません。
面白い事実：Pay TVは90年代からそれを行っており、Xbox 360とOneもそれを行っています。 MMU=ベースです。サテライトチップでも使用されている可能性があります。このようなシステムでは、lib攻撃に戻ることすらできません。