時々私は書くべき主題を探していて、私がカバーしたと思うものがあることに気づきますが、検索すると、私がカバーしていないことに気づきます。それらのトピックの1つは、測定されたブートと信頼できるブートです。誤解を招くように「セキュアブート」と呼ばれることもあります。これらの用語を大文字で使用する特定の手順（例：セキュアブート）がありますが、この記事での説明は避けようとしています。私は、詳細の内外を調べようとするよりも、一般的なプロセスと、潜在的な大きな落ち込みに興味があります。以下は、Wileyのコンピューティングとクラウドへの信頼に関する私の近刊の本からの（大幅に編集された）抜粋です。
その他のLinuxリソース
- Linuxコマンドのチートシート
- 高度なLinuxコマンドのチートシート
- 無料のオンラインコース：RHELの技術概要
- Linuxネットワーキングのチートシート
- SELinuxチートシート
- Linuxの一般的なコマンドのチートシート
- Linuxコンテナとは何ですか？
- 最新のLinux記事
測定されたブートと信頼できるブートの目的を理解するために、Linux仮想化スタック（Linuxマシンで仮想マシン（VM）を使用する場合に実行するコンポーネント）を確認してください。この説明はおそらく過度に単純化されていますが、（上記で述べたように）私は詳細には興味がありませんが、私が達成しようとしていることに興味があります。私は下の4つの層に集中します（抽象化のかなり単純なレベルで）：CPU/管理エンジン。 BIOS / EFI;ファームウェア;ハイパーバイザーですが、レイヤーについても検討します トラステッドプラットフォームモジュール（TPM）と2つのプロセスのいずれかを実行する方法に関するいくつかの指示（測定されたブート）を介在させるCPU/管理エンジンの上 および信頼できるブート ）。システムの起動が開始されると、TPMがトリガーされ、作業が開始されます。ハードウェアセキュリティモジュール（HSM）などの代替の信頼ルートも使用できますが、このコンテキストで最も一般的な例であるTPMを使用します。
どちらの場合（トラステッドブートと測定されたブート）でも、基本的なフローは、TPMがBIOS/EFIレイヤーの測定を実行することから始まります。この測定には、このレイヤーによって実行されるバイナリ命令をチェックし、バイナリイメージの暗号化ハッシュを作成することが含まれます。生成されたハッシュは、TPMのいくつかのプラットフォーム構成レジスタ（PCR）「スロット」の1つに格納されます。これらは、後で読み取ることができるメモリの一部と考えることができます。その目的のためにTPMによって、またはTPMの外部のエンティティによって読み取ることができますが、一度書き込まれると変更することはできません。これらのメモリは、最初に書き込まれたときから完全に保護されています。これにより、TPMによって値がPCRに書き込まれると、電源を切るか再起動するまで、システムの存続期間中は一定であると見なすことができます。
BIOS / EFIレイヤーを測定した後、次のレイヤー（ファームウェア）を測定します。この場合、結果のハッシュは前のハッシュ（PCRスロットに保存されていた）と結合され、PCRスロットにも保存されます。このプロセスは、プロセスに関係するすべてのレイヤーが測定され、ハッシュの結果が保存されるまで続きます。元のTPM値を設定し（簡単にするためにプロセスのより低レベルのステップのいくつかをスキップしました）、アップグレードまたはセキュリティパッチの適用のためにレイヤーへの変更を許可する（できれば許可された）プロセスがあります（時には非常に複雑です）。 、 例えば。この「測定されたブート」プロセスにより、エンティティはプロセスの完了後にTPMを照会し、PCRスロットの値が、さまざまなレイヤーの「既知の正常な」バージョンで事前に計算された期待値に対応するかどうかを確認できます。 、出所と整合性がすでに確立されている事前チェック済みバージョン。
パーティを外部できるようにするためのさまざまなプロトコルが存在します TPMが正しいことを証明する値を（たとえば、ネットワーク接続を介して）システムにチェックします。外部システムからそのような値を受信してチェックするプロセスは、「リモートアテステーション」と呼ばれます。
このプロセス（測定されたブート）により、システムの基盤である最下層が、自分が考えているものであるかどうかを確認できます。しかし、そうでない場合はどうなりますか？測定されたブート（当然のことながら、名前が付けられています）は測定しますが、他のアクションは実行しません。
別の「信頼できるブート」はさらに一歩進んだものです。信頼できるブートプロセスが実行されると、プロセスは各値を測定するだけでなく、既知の（そして期待される！）適切な値に対して同時にチェックを実行します。チェックが失敗すると、プロセスは停止し、システムの起動は失敗します。これは、システムを採用するためのかなり極端なアプローチのように聞こえるかもしれませんが、完全に正しいアプローチである場合もあります。検討中のシステムが危険にさらされている可能性がある場合（信頼できるブートプロセスの失敗から推測できる可能性があります）、欠陥のある期待に基づいて実行するよりも、まったく利用できない方がよいでしょう。
>私が測定対象のシステムの所有者であり、測定対象のさまざまなコンポーネント（および測定値）をすべてチェックし、起動されているものが私が望むものであることに満足している場合、これはすべて非常にうまくいきます。しかし、たとえば、クラウド上のシステム、または他の誰かが所有および管理しているシステムを使用している場合はどうなりますか？その場合、私は2つのことでクラウドプロバイダー（または所有者/マネージャー）を信頼しています：
- すべての測定を正しく行い、正しい結果を私に報告します
- そもそも信頼すべきものを構築する
これは、「信頼できるブート」、さらに悪いことに「セキュアブート」という命名法の問題です。どちらも、明らかにそうではない場合に、システムの絶対的で客観的な特性が確立されていることを意味します。つまり、「信頼できる」または「安全な」ということです。明らかに、そのようなプロセスの設計者が障害状態（「信頼できないブート」または「安全でないブート」）にちなんで名前を付けることを期待するのは不公平ですが、システムの所有者がステップを実行することを信頼できると確信できない限り、 2つが完全に正しく（そして、システムの所有者としてではなく、システムのユーザーとしての私の最善の利益のために）、私はより強力な主張をすることはできません。
信頼できるブートプロセスを経たシステムを、最高のときに「信頼できるシステム」とラベル付けしたいという、大きな誘惑があります。 あなたが作ることができる主張は、測定されたおよび/または信頼されたブートプロセスで測定された特定のレイヤーが、プロセスが存在することを期待するものであると主張されているということです。このようなプロセスは、動作の保証を提供するためのレイヤーの適合性についても、それらの上にある後続のレイヤーの正確さ（または動作の保証を提供するための適合性）についても何も述べていません。
TPMの設計者は、何が主張されているかを非常に明確にしており、信頼に関する主張は慎重かつ慎重に行う必要があることに注意することが重要です。ただし、残念ながら、システムの複雑さ、信頼の一般的な低レベルの理解、およびコンテキストと推移的な信頼の複雑さにより、システムの設計者と実装者は、間違ったことを実行し、システムが正常に実行されたと想定することが非常に簡単になります。信頼できるブートプロセスは「信頼できる」と見なすことができます。また、TPMは、ハードウェアの信頼のルーツとして、設計または実装する可能性のあるシステムの信頼の鎖を確立するために利用できる最良のメカニズムの1つを提供することを覚えておくことも非常に重要です。私は、TPMについてすぐに記事を書く予定です。
- これは多くのであることが判明しましたが 思ったより難しい！
この記事は、もともとアリス、イブ、ボブに公開されており、著者の許可を得て転載しています。