今回の記事では、UEFI の署名ポリシーに関する変更点を説明します。これらの変更点は、セキュア ブートをセキュリティ要件に対応させ、UEFI サブミッション署名の審査の長期化を避けるために欠かせないものになります。その他、UEFI 署名ポリシーに関する既存の重要なライセンス条項を改めて紹介します。
UEFI 署名は Windows デベロッパー センターのハードウェア ダッシュボードで利用できるサービスです。x86 または x64 向けの UEFI ファームウェア バイナリをここから提出して Microsoft の署名を受けることで、Windows コンピューターへのインストール手順を簡素化し、UEFI CA 署名を持つコードを実行できるようになります。
要件の一覧を以下に示します (サブミッションに対する署名の可否を判断する権利は常に Microsoft が独自に有するものとします)。サブミッション署名の審査期間を短縮し、サブミッション取り消しを回避するため、これらすべてを遵守してください。Microsoft は、署名の前にこれらの要件に関するフォローアップ レビューを実施する場合があります。レビューの内容には、アンケート、パッケージのテスト、その他のセキュリティ テストなどがあります。
1.2014 年 3 月より、UEFI 署名のサブミッションは、EV 証明書を登録済みの SysDev アカウントによるもの以外は受け付けられなくなります。UEFI 署名のサブミッションを提出するには、これまでのサブミッション資格で登録されている証明書を EV 証明書で更新する必要があります。
2.UEFI 署名には、お客様が利用するものと同等の、製品レベルの品質のコードが必要です。たとえば、テスト モジュールやデバッグ モジュールではなく「RTM」コードが必要で、社内だけで使用するコードやツールは対象になりません。社内専用のコードでは、セキュア ブートを無効化するか、セキュア ブート データベースに接続するためのキーを開発やテストの際に独自に追加することをお勧めします。
3.UEFI 署名の取得を目的に提出されるコードには、GPLv3 や、認証キーを要求する権利を許可し、改変されたコードのデバイスへのインストールを可能にするすべてのライセンスが適用されていない必要があります。このようなライセンスが適用され、既に署名を取得しているコードの場合、署名が却下される場合があります。たとえば、GPLv3 に基づきライセンスされる GRUB 2 には署名されません。
4.特定の技術を使用するためのコードに既知のマルウェア攻撃が存在する場合、そのコードは署名されず、取り消しの対象となります。たとえば、セキュア ブート非対応バージョンの GRUB には署名されません。
5.実行するすべてのコード モジュールが認証されている必要があります。認証されていない場合、サブミッションは署名されません。既に署名済みの場合は取り消しの対象となります。
a. GRUB またはその他のローダーを読み込むサブミッションの場合、ローダーがセキュア ブートに対応している必要があります。
たとえば、最新の GRUB 2 にはセキュア ブート パッチが適用されています。
b. セキュア ブートのセキュリティ要件を満たしていると見なされるのは、最初のブートが完了することによってではありません。たとえば、未認証のコードが実行され別のオペレーティング システムが起動できるようなセキュリティ ブート システムの場合、セキュア ブートに十分なセキュリティが確保されているとは見なされません。このような脆弱性がある場合、サブミッションは取り消しの対象となります。
6.サブミッションが shim (別のブートローダーに処理を引き渡す) の場合は、以下の要件が適用されます。
a. shim に埋め込まれている証明書がすべて EV 証明書である必要があります。また、埋め込まれている証明書すべての Organization 属性が、SysDev アカウントで登録されている EV 証明書の Organization 属性と同一である必要があります。
b. キーが失われた場合、キーが不適切に使用されている場合、キーにセキュリティリークが発生している場合、そのキーを使用するすべてのサブミッションは取り消されます。
c. セキュア ブート システムに脆弱性をもたらす shim がいくつか確認されています。署名の審査期間を短縮するために、GitHub ブランチにある shimの、0.7 以上のソース コードを使用することをお勧めします。
7.署名を取得するための提出の前に、サブミッション事前テスト用ドキュメント (UEFI サブミッション向け) に従って製品をテストしてください。