Microsoft UEFI CA の署名ポリシーが更新されました

今回の記事では、UEFI の署名ポリシーに関する変更点を説明します。これらの変更点は、セキュア ブートをセキュリティ要件に対応させ、UEFI サブミッション署名の審査の長期化を避けるために欠かせないものになります。その他、UEFI 署名ポリシーに関する既存の重要なライセンス条項を改めて紹介します。

UEFI 署名は Windows デベロッパー センターのハードウェア ダッシュボードで利用できるサービスです。x86 または x64 向けの UEFI ファームウェア バイナリをここから提出して Microsoft の署名を受けることで、Windows コンピューターへのインストール手順を簡素化し、UEFI CA 署名を持つコードを実行できるようになります。

要件の一覧を以下に示します (サブミッションに対する署名の可否を判断する権利は常に Microsoft が独自に有するものとします)。サブミッション署名の審査期間を短縮し、サブミッション取り消しを回避するため、これらすべてを遵守してください。Microsoft は、署名の前にこれらの要件に関するフォローアップ レビューを実施する場合があります。レビューの内容には、アンケート、パッケージのテスト、その他のセキュリティ テストなどがあります。

1. 2014 年 3 月 15 日より、UEFI 署名のサブミッションには EV 証明書が必要となります。

a. 2014 年 3 月 15 日より、新規サブミッションおよび更新において、SysDev (ハードウェア ダッシュボード) では DigiCert または VeriSign によって発行された EV 証明書の受け付けを開始します。

b. 既存の申請者は、2014 年 8 月 15 日までに、既存の EV ではないコード署名証明書から EV コード署名証明書へ移行してください。今回の期間延長は、スムーズな移行を実現するために設けられています。

2. UEFI 署名には、お客様が利用するものと同等の、製品レベルの品質のコードが必要です。たとえば、テスト モジュールやデバッグ モジュールではなく「RTM」コードが必要で、社内だけで使用するコードやツールは対象になりません。社内専用のコードでは、セキュア ブートを無効化するか、セキュア ブート データベースに接続するためのキーを開発やテストの際に独自に追加することをお勧めします。

3. UEFI 署名の取得を目的に提出されるコードには、GPLv3 や、認証キーを要求する権利を許可し、改変されたコードのデバイスへのインストールを可能にするすべてのライセンスが適用されていない必要があります。このようなライセンスが適用され、既に署名を取得しているコードの場合、署名が却下される場合があります。たとえば、GPLv3 に基づきライセンスされる GRUB 2 には署名されません。

4. 特定の技術を使用するためのコードに既知のマルウェア攻撃が存在する場合、そのコードは署名されず、取り消しの対象となります。たとえば、セキュア ブート非対応バージョンの GRUB には署名されません。

5. 実行するすべてのコード モジュールが認証されている必要があります。認証されていない場合、サブミッションは署名されません。既に署名済みの場合は取り消しの対象となります。

a. GRUB またはその他のローダーを読み込むサブミッションの場合、ローダーがセキュア ブートに対応している必要があります。
たとえば、最新の GRUB 2 にはセキュア ブート パッチが適用されています。

b. セキュア ブートのセキュリティ要件を満たしていると見なされるのは、最初のブートが完了することによってではありません。たとえば、未認証のコードが実行され別のオペレーティング システムが起動できるようなセキュリティ ブート システムの場合、セキュア ブートに十分なセキュリティが確保されているとは見なされません。このような脆弱性がある場合、サブミッションは取り消しの対象となります。

6. サブミッションが shim (別のブートローダーに処理を引き渡す) の場合は、以下の要件が適用されます。

a. コード署名に使用するキーは、信頼済みの役割の担当者が 2 要素認証を使用し、物理的に安全が確保された環境でバックアップ、保存、復元する必要があります。

• 秘密キーはハードウェア暗号化モジュールで保護する必要があります。このモジュールには HSM、スマート カード、スマート カード型の USB トークン、TPM などが該当しますが、これらに限定されません。
• 運用環境には、少なくとも FIPS 140-2 Level 2 と同等のセキュリティ レベルを実現していることが求められます。

埋め込まれている証明書が EV 証明書の場合、上記の要件すべてを遵守する必要があります。UEFI CA 署名の審査期間短縮のため、EV 証明書の使用をお勧めします。

b. サブミッションを提出する場合、shim が直接または間接的に読み込む項目すべてについて、取り消しを実行する強力なメカニズムを設計し実装する必要があります。

c. キーが失われた場合、キーが不適切に使用されている場合、キーにセキュリティリークが発生している場合、そのキーを使用するすべてのサブミッションは取り消されます。

d. セキュア ブート システムに脆弱性をもたらす shim がいくつか確認されています。署名の審査期間を短縮するために、 GitHub ブランチにある shim の、0.7 以上のソース コードを使用することをお勧めします。

7.署名を取得するための提出の前に、サブミッション事前テストに関するドキュメント (UEFI サブミッション向け) に従って製品をテストしてください。

8.サブミッションのコードに既知のセキュリティ脆弱性が含まれている場合、そのコードが機能的に公開されないコードであっても、サブミッションは署名されません。たとえば、安全が確認されている OpenSSL の最新バージョンは 0.9.8za および 1.0.1h ですが、既知の脆弱性を含む以前のバージョンがサブミッションに含まれている場合、サブミッションは署名されません。