UEFIセキュアブート仕様に対するLinuxサポートの技術的な詳細について書きました。 ライセンスとキー配布の問題を無視することを明示的に示したという事実にもかかわらず、それに依存する人々は、最小限の労力でセキュアブートサポートをLinuxに追加できると主張しています。 ある意味では、彼らは正しいです。 実装の技術的な詳細は非常に簡単です。 しかし、困難はそこにはありません。
セーフブートでは、ハードウェアとやり取りするすべてのコードが信頼されている必要があります。
現在、OSをロードする前に信頼できないコードを実行できる場合、OSで何でもできます。 セキュアブートは、そのようなシナリオから保護するために設計された、信頼できるコードのみを実行することを保証するメカニズムを提供します。 したがって、UEFIドライバーはデジタル署名され、ブートローダーもデジタル署名され、署名されたカーネルのみをロードできます。 ダウンロードに信頼できるコードのみを使用した場合は、OSが安全であることを確認できます。 ただし、信頼できるコードのダウンロードとは異なり、セキュアブートでは、信頼できるコードのみが実行されることを確認できません。 これは、OSポリシーによって提供される必要があります。
一見、これは大きな問題ではありません。 しかし、実際に彼女に表示されます。 署名済みのLinuxブートローダーと署名済みのLinuxカーネルがあり、これらの署名はグローバルな信頼できるキーを使用して作成されていると想像してください。 セキュアブートを使用して任意のハードウェアで起動します。 ここで、攻撃者が、偽のUEFI環境を作成し、コードのカーネル実行を中断し、Windowsブートローダーを呼び出すカーネルモジュールを作成することを想像してください。 Windowsブートローダーは、セキュアブートで実行されることは確かですが、実際には、信頼できると信じているものはすべて、攻撃者によって書かれた偽のUEFIコードです。 ユーザー暗号化キーが書き込まれ、WindowsカーネルはLinuxコードを隠すように変更されます。すべてが素晴らしく見えるにもかかわらず、クレジットカード情報はすでに中国に向かっています。 このシナリオでは、署名されたLinuxカーネルはマルウェアダウンローダーとして単に使用されます。 何かが間違っているという唯一の兆候は、OSのロードがわずかに長いことです。
署名されたカーネルでは不十分です。 署名されたLinuxカーネルは、署名されていないカーネルモジュールのロードを防ぐ必要があります。 Linux上のVirtualBox？ またね Nvidiaバイナリドライバー？ またね 標準のカーネルモジュールを超えるものはありますか？ また次回まで。 新しいドライバーの自己組み立て？ 別の時間。 これは明らかに人々を幸せにするものではありません。
（もちろん、同じことがWindowsにも当てはまります。Windows7では、ドライバーのデジタル署名検証を禁止できますが、Windows 8では、システムがセキュアブートメカニズムを使用している場合、これを許可しません）。
免許
GPLv3には、署名に使用されるキーの可用性に関するさまざまな要件があります。 Microsoftの新しい要件によると、システムはユーザーキーのインストールをサポートする必要があります。これにより、ユーザーは独自のOSローダーを使用できるようになります。これは、ライセンス要件に準拠するのに十分な場合があります。 しかし、マイクロソフトに依存するようになります。この要件を削除すると、ユーザーは自由を失い、ライセンスの問題で厄介な状況に陥ります。 この場合に何ができるかについての議論はまだ進行中ですが、現時点ではこの問題は解決されていません。
キー配布
UEFI仕様では、誰が中央認証局となるかを定義していません。 マイクロソフトは、誰もが自分の鍵を持っていると主張しています。 もちろん、独自のキーを生成することもできますが、機器メーカーにとってそれほど簡単ではありません。 すべての鉄生産者がそれらを支援することを保証する方法はありません。 そして、明らかに、キーを生成する場合、そのプライベート部分を第三者に単純に転送することはできません。 これは、秘密鍵を受け取らずに他の人に基づいて独自の配布をリリースすることが不可能になることを意味します。 キーを取得するには、何らかの種類のID検証手順が必要になりますが、これにはコストがかかる可能性が高く、また、ID検証を保証するために法的に登録された組織が必要になる場合があります。 Startssl Freeではなく、Extended Validation証明書になると思います。 したがって、愛好家が作成したLinuxディストリビューションは過去のものになります。
カスタムモードはこの問題を解決しませんか？
Microsoft認定要件は、すべてのシステムがカスタムモードをサポートする必要があることを示しています。この機能の実装は、ユーザーが独自のキーを設定できるようにする必要があります。 Linuxメーカーは、ディストリビューションで独自のキーを提供し、独自のポリシーを設定できます。 誰もが幸せです。 実際、すべてがそれほど良くはありません。 単にCDをドライブに挿入するのではなく、Linuxのインストールに膨大な時間と労力を費やす必要があります。 ファームウェアとその再構成を変更する必要があるため、障壁が追加され、Linuxをインストールする能力が技術的に有能なユーザーのみに制限されます。 そして、これはさらに悪いことです。 カスタムモードの要件の完全な説明は次のとおりです。
1.物理的にデバイスの背後にいるユーザーの場合、カスタムモードを使用して、セキュアブートおよびPK署名（翻訳者のメモ：PK-秘密キー）のデータベースの内容を変更できる必要があります。
2.ユーザーがPKを削除した場合、カスタムモードを終了すると、システムはセットアップモードで機能し、デフォルトでセキュアブートが無効になります。
3.ファームウェア設定メニューは、セキュアブートが有効になっていることと、標準モードまたはカスタムモードの動作モードを通知する必要があります。 また、セットアップメニューは、工場出荷時のデフォルト設定を復元して、カスタムモードから標準モードに戻る機会を提供する必要があります。
ここに何かが欠けています。例えば：
-UIの説明。 これにより、最初のステップが（a）混乱し、（b）ベンダー固有である場合、Linuxインストールプロセスを文書化することは事実上不可能になります。 鉄の製造業者は、独自の独自のファームウェアインターフェイスを提供することで差別化を図ろうとしています。 それらのカスタムモードは、まったく異なって見える場合があります。
-キー形式の説明。 単純なバイナリキー表現？ または、EFI_SIGNATURE_DATA構造ですか？ Base64エンコードキー、ROT13でさらに保護されていますか？ 知りません。
-OSインストールの無人バージョンでカスタムモードを使用する方法。 ファームウェアインターフェイスには、ユーザーの物理的な存在が必要です。 ネットワーク経由でOSを数千台のマシンにインストールしますか？ これはスケーラブルなアプローチではありません。
-...そして些細なことですが、実際、ユーザーが自分でキーを追加するための要件はどこにもありません。鉄の生産者はこれを利用して、キーのみを削除できます。 ユーザーがPKを削除できる限り、これは悪いことではありません。ユーザーがセットアップモードに戻り、インストーラーからキーをインストールできるようになるためですが、実際には問題が発生します。
それでも、カスタムモードではすべての問題が解決されるわけではありません。 UIとキー形式を厳密に定義したカスタムモードの方がはるかに優れていますが、それでもOSの自動無人バージョンインストールの問題は解決しません。
おわりに
Linuxでセキュアブートをサポートするために必要なコードを短時間で記述できます。実際、そのほとんどはすでに完了しています。 しかし、重大な実用上の問題が残っており、現在まで、それらのいずれにも有効な解決策はありません。