Android応援と悪魔の攻撃
（Linuxベースのサーバーのコンテキストでの）フルディスク暗号化と、真のセキュリティを提供するスキームと、セキュリティの幻想のみを提供するスキームについて詳しく知りたいと思っています。
私が理解しているように、ほとんど（すべて？）のソフトウェアベースのフルディスク暗号化設定では、いくつかのソフトウェア（多くの場合、ブートローダー）を暗号化せずに復号プロセスを開始する必要があります。この結果、「悪のメイド」タイプの攻撃者は、暗号化されていないソフトウェアを変更されたバージョンに置き換えて、システムのセキュリティを危険にさらすことができます。
この問題に対するいくつかの解決策を見てきました。
/bootいつでも携帯できるフラッシュドライブ。もちろん、サーバーのコンテキストでは、不在時に再起動する必要がある場合は、SOLです。- ハードウェアベースのFDEを使用します。しかし、BIOSはATAパスワードの収集をサポートする必要があります。また、再起動すると、パスワードを入力するために物理的な存在が必要になります。
Android=電話です。一部の電話では、不可能ではないにしても、ルートするのは非常に難しいようです。プロセスについてはほとんど知りませんが、なぜ悪を実行できないのか私たちの電話に対するメイド攻撃？私たちはデバイスを100％物理的に制御しています。
明らかに、これは単純ではありませんが、何が欠けていますか？ Android電話をサーバーに適用するために使用されているのと同じテクニックはありますか？
Android Verified Boot をご覧ください。 Android 4.4以降で利用可能で、ハードウェアの信頼のルートを介して）ブートローダーの改ざんを防止し、認証されていない変更が行われた場合に警告します。
どこで利用できるのか、どれほど簡単に使えるのかわかりません。これはベンダー次第です。ベンダーがクラスBを実装してデバイスをロック解除してフラッシュできる場合を除き、カスタムROMで動作しない可能性があります（ブート状態のオレンジ、参照 https://source.Android.com/security/images/verified_boot.png ）。