Linux 上で ecryptfs を使用して /home パーティションを暗号化すると、/boot または /(root) の悪意のある変更をどのように防ぐのでしょうか?

Question

これは、ecryptfs の開発者が ecryptfs と dm-crypt の違いを説明しているページです。https://stackoverflow.com/questions/18230784/what-is-difference-between-linux-kernel-subsystem-dm-crypt-and-ecryptfs/18234635#18234635/homeしかし、ecryptfs がパーティションのみを暗号化する場合、悪意のあるハッカーがパーティションを変更して暗号化パスワードを盗聴したり、プログラムを変更したりするのを何が阻止するのか/という/boot疑問が残りました。

つまり、自分のコンピューターのデータが権限のない人に読み取られないだけでなく、自分の知らないうちにコンピューター上のデータが変更されないことをどうしたら確信できるのでしょうか?

また、ある時点で、プロセッサが理解できるようにブート コードを暗号化解除する必要があるため、これはどこで終わるのでしょうか? (何らかのハードウェア復号化を使用しない限り) しかし、定義上、暗号化されていないものはすべて変更できますか?

(余談ですが、ブート シーケンスの整合性を判断する方法として、ブート コードの暗号化されていない部分のハッシュを暗号化された部分に保持し、復号化時に、事前に計算されたハッシュとブート シーケンスの暗号化されていない部分のハッシュを実行時に比較する方法があります。ただし、これは暗号化されていない領域があるという問題を解決するものではなく、事後に何かが変更されたかどうかを知る方法にすぎません)

Answer 1

簡単に答えると、ハッカーが /boot を変更するのを阻止できるのは「ほとんどない」ということです。実際には、時間、検出されない物理アクセス、およびキーロガーを使用して initrd を再コンパイルする機能だけです。

悪意のあるハッカーが物理的なシステム アクセス権を持っている場合、ecryptfs ベースの / または /boot を変更するのを阻止することはできません。ただし、後述しますが、これはこの問題の目的ではありません。

「/」はLUKSのようなディスク全体の暗号化を使用して保護できます（ただし、私の知る限り、ファイルごとの暗号化ではありません）。システムは最初に/bootから起動されるため、initrdは/をマウントする前にボリュームのロックを解除するために必要なパスフレーズを要求できます。

あなたはフルディスク暗号化の能力を過大評価していると思います。フルディスク暗号化は、ラップトップが盗まれた場合や、個人情報が入ったハードドライブを RMA したい場合など、非永続的な脅威から人々を保護するように設計されていると私は考えています。どちらの場合も、データはもう役に立ちませんが、未知の第三者がアクセスするのを阻止する必要があります。また、多くの場合、ドキュメントのファイルベースの暗号化で十分です。システム バイナリの暗号化されていないコピーがあっても、誰が気にするでしょうか。いずれにせよ、それらはオープン ソースです。

ローカル アクセスを持つ権限のないユーザーからシステムを保護することはできません。そのため、この解決策は、物理的アクセスを防止することです。すべてのシステム ファイルのチェックサムを計算し、オフライン バックアップと比較することで、知らないうちに変更されていないことをある程度保証できます。ただし、変更されていないチェックサム プログラムを実行していることを確認する必要があり、衝突ハッシュの再作成が事実上不可能になるので、これは完全ではありません。[ファイル システムを分離して一部を読み取り専用にし、読み取り専用パーティションごとに 1 つのハッシュを保持すると、これを簡素化できる可能性があります]。ただし、このプロセス全体は面倒です。

フルディスク暗号化「/」を使用する場合、アップグレードなどを除いて、通常はコンピュータを「ルート」として使用しません。これにより、かなりの程度の