ハードウェア セキュリティの検証可能性に関する仕様

  • [アーティクル]

はじめに

HSTI を使用して、Windows デバイスのセキュリティ機能について構成の誤りを防ぎます。 顧客の場合は、HSTI により、購入するマシンが既定でセキュリティで保護されるというベスト エフォートの保証が提供されます。 IHV と IBV の場合は、HSTI により、セキュリティ保証が確実に維持されます。 OEM と ODM の場合は、追加設定なしで安全に構成されているシステムを出荷して、独自のソリューションを開発することなく、セキュリティで保護された状態を維持するように容易に保証できます。

HSTI テストの結果は Windows 互換性テストによって使用され、サポートされているセキュリティ機能を有効にするようにデバイスが正しく構成されていることを検証するために使用できます。 これらのテストは、セキュリティで保護されていないテスト キーを含む可能性があるエンジニアリング デバイスなど、現場でセキュリティで保護されていないエンジニアリング デバイスを識別するために使用できます。 これらのテストの結果は、セキュリティで保護されていないデバイスにウォーターマーク (または同様のインジケーター) を表示するために、Windows OS によって使用される場合があります。

Note

  プラットフォームがハードウェア インターフェイスを実装し、このトピックで指定されているドキュメントとツールを共有する必要があります。

背景

読者は、UEFI の基礎を理解し、UEFI 仕様のセクション 27 "セキュリティ" や NIST SP 800-147 など、セキュア ブートのテクノロジについて理解している必要があります。

この要件には、次の 3 つの側面があります。

  • ハードウェアとファームウェアのセキュリティ状態を照会するための、プラットフォームに依存しないインターフェイス
  • 上記のインターフェイス実装の設計と省略可能なコード レビュー
  • ドキュメントとツールの共有

高レベルの実装

ビットフィールド

IHV は、プラットフォームのテスト可能なセキュリティ機能を表すビットフィールドを定義します。 このビットフィールドは、IHV、IBV、または OEM の HSTI テストから返される HSTI オブジェクトで使用可能なすべての定義可能ビットを完全に含んでいます。 IHV の実装者は、IBV が HSTI テストの結果を正しく返すために、ビットフィールドの定義を設計し、適切なドキュメントを提供する必要があります。

SecurityFeaturesRequired

SecurityFeaturesRequired フィールドは、フィールドが IHV の HSTI オブジェクトで、必須のセキュリティ機能のビットフィールドの定義に IHV が使用するメソッドである場合の処理にのみ使用されます。

SecurityFeaturesImplemented

これは、HSTI オブジェクトを返すテストで実装されるセキュリティ機能のビットフィールドです。

SecurityFeaturesVerified

これは、HSTI オブジェクトを返すテストで検証されるセキュリティ機能のビットフィールドです。

実装ガイドライン

IHV は、Windows 互換性要件に準拠したプラットフォームの参照セキュリティ設計を開発します。 さらに、IHV と IBV は、参照セキュリティ実装の適切な有効化を検証するプログラム テストも実装し、ハードウェア セキュリティ テスト インターフェイスを介して結果を報告します。 これらのテストは、コンパイル済みのモジュール (ソースではない) として OEM と ODM に提供され、変更なしで動作する必要があります。 OEM または ODM が参照セキュリティ設計から逸脱した場合、これらのテスト モジュールで、エラーが報告される可能性があり、OEM または ODM は Microsoft に連絡して変更点を確認し、これらの例外を報告する追加の HSTI インスタンスを実装する必要があります。 OEM は、参照設計とドキュメントに従うことで、変更なしで、これらのセキュリティ モジュールを活用できなくてはなりません。 OEM がセキュリティ モジュールの追加やセキュリティ モジュールの動作の変更を行うには、Microsoft の設計レビューを受ける必要があります。

テスト モジュールの実装の一部として、実装者は構造体を含めます。 この構造体のプロトタイプは、後述の「プロトタイプ」セクションに記載されています。 IHV は、セキュリティ参照チェックリストの各ビットの意味を定義します。 IHV はさらに、ビットフィールド内の各ビットの意味を定義します。 最後に、IHV は OEM 構造体に "Required" ビットフィールドを含めます。プログラムでテストできるすべての要件について、"Implemented" ビットフィールドのビットを設定します。

IBV と OEM は、これらのビットによって表されるセキュリティ機能の存在をプログラム的にチェックする設計を Microsoft に提示している場合、"Implemented" フィールドのビットを設定できます。 これらのテストに合格した場合は、それぞれの構造体に "Verified" フィールドを設定できます。

IHV、IBV、OEM のテスト モジュールは、存在する場合に実行される必要があります。 SecurityFeaturesEnabled フィールドのビットに設定された true 値は、合格したテスト結果を示します。 テストが実行されない場合、または合格しない場合は、対応ビットに 0 が設定されるはずです。

結果処理ロジックの例

この例は、結果処理で使用されるロジックを表しています。 実装されるビットフィールドが従う形式で、1 は実装されていることを意味し、0 は実装されていないことを意味します。 何かが実装されている場合、それは必須です。 結果ビットフィールドが従う形式で、0 は失敗またはテストが存在しないことを意味し、1 は合格したことを肯定することのみを意味します。

すべての結果が計算された後、IHV 結果ビットフィールドは、その必須ビットフィールドと NXOR 演算されます。 IHV 以外のすべての結果ビットフィールドは、それぞれの実装ビットフィールドと AND 演算されます。 結果のビットフィールドはすべて合わせて OR 演算され、全体的な結果が得られます。 この演算の合格結果は、すべて 1 で構成されるビットフィールドになります。

成果物および所有権

独立系ハードウェア ベンダー (IHV) と独立系 BIOS ベンダー (IBV)

Connected Standby システムをサポートするシリコン サプライヤーと IBV は、その参照プラットフォームの各ハードウェアとファームウェアのセキュリティ状態を照会するために、プラットフォームに依存しないインターフェイスを実装する必要があります。 これらの実装は、コンパイル済みモジュールとして提供される必要があります。 これらのモジュールは署名され、実行時に署名チェックが実行されることが望ましいです。 その目的は、ハードウェアとファームウェアの設計と状態を照会して、プラットフォームの適切なセキュリティ プロビジョニングを報告することです。

OEM と ODM

OEM と ODM は、ベンダーから提供されている HSTI テストを変更または改ざんしてはいけません。 OEM と ODM は、そのシステムが、Windows 認証要件の構成要素として、HSTI テストに合格することを保証する必要があります。

Windows ハードウェア認定要件 - Windows 8.1 WHCR

  • System.Fundamentals.Firmware.UEFISecureBoot
  • System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby

変更の代わりに、OEM が同等またはそれ以上のセキュリティを提供する代替方法を提供する方法を必要とする場合、その OEM は追加のセキュリティ チェックを提供することがあります。 OEM セキュリティ チェックは少なくとも 1 つの IHV または IBV セキュリティ テストを完全に含む必要があります。 使用する前に、OEM は Microsoft が行う設計レビューに提出する必要があり、他の HSTI テスト プロバイダーと同じドキュメントおよびツールの開示要件が適用されます。 Microsoft の承認を得ると、OEM はセキュリティ テストを含めて、IHV および IBV テストを拡張できます。

OEM 構成証明を HSTI 設計に含める必要はありません。 HSTI は OEM の要件のリストではなく、ファームウェア、ハードウェア、および構成パラメーターのプログラムによる効果的なセキュリティ テストを保証するためのインターフェイスです。

セキュリティ状態のインターフェイス

このインターフェイスは、UEFI バージョン 2.4 で定義されている EFI アダプター情報プロトコルを基に構築されています。

プラットフォーム セキュリティ状態のインターフェイス

まとめ

プラットフォーム セキュリティ情報 - プラットフォームが Windows ハードウェア認定要件 System.Fundamentals.Firmware.CS.UEFISecureBoot、System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby、System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning に適合していることについての情報を返します。

プロトタイプ

InformationType

#define ADAPTER_INFO_PLATFORM_SECURITY_GUID \
     {0x6be272c7, 0x1320, 0x4ccd, { 0x90, 0x17, 0xd4, 0x61, 0x2c, 0x01, 0x2b, 0x25 }}

#define PLATFORM_SECURITY_VERSION_VNEXTCS   0x00000003

#define PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE   0x00000001  // IHV
#define PLATFORM_SECURITY_ROLE_PLATFORM_IBV 0x00000002
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_OEM 0x00000003 
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_ODM  0x00000004

対応する InformationBlock:

typedef struct { 
    UINT32  Version,
    UINT32  Role,
    CHAR16  ImplementationID[256],
    UINT32  SecurityFeaturesSize,
    UINT8   SecurityFeaturesRequired[],     //Ignored for non-IHV
    UINT8   SecurityFeaturesImplemented[],
    UINT8   SecurityFeaturesVerified[],
    // CHAR16   ErrorString[];
} ADAPTER_INFO_PLATFORM_SECURITY;
期間 説明

Version

PLATFORM_SECURITY_VERSION_VNEXTCS を返す

Role

このインターフェイスの発行元の役割。 IHV や IBV などの参照プラットフォーム設計者は、それぞれ PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE と PLATFORM_SECURITY_ROLE_PLATFORM_IBV を返すことが期待されています。 設計者からのテスト モジュールがすべてのセキュリティ機能を完全に検証できない場合、プラットフォーム実装者、OEM、ODM は、実装者の役割を使ってこのインターフェイスを公開する必要があります。

ImplementationID

人間に解読可能な、この実装のベンダー、モデル、バージョン。 たとえば、"SiliconVendorX Chip1234 v1" や "BIOSvendorY BIOSz v2" などです。

SecurityFeaturesSize

SecurityFeaturesRequired 配列と SecurityFeaturesEnabled 配列のサイズ (バイト単位)。 配列は同じサイズである必要があります。

SecurityFeaturesRequired

すべてのセキュリティ機能に対応するビットフィールド。IHV が定義し、PLATFORM_SECURITY_VERSION Version で定義されるセキュリティ要件を満たすために実装する必要があります。 たとえば、Version を満たすために 7 つの機能を実装する必要がある場合、値 0b01111111 が報告される可能性があります。

SecurityFeaturesImplemented

このモジュールでプログラム テストを実装したすべてのセキュリティ機能に対応するビットフィールド。発行元が定義します。

SecurityFeaturesVerified

この実装によって実装が検証されているすべてのセキュリティ機能に対応するビットフィールド。発行元が定義します。

ErrorString

Null 終端の文字列、1 行 (CR/LF で終了) に 1 つのエラー。OEM と ODM がエラー修復の手順を説明するドキュメントを見つけるために使用できる一意の識別子を含みます。ドキュメントの URL が推奨されます。 たとえば、次のように入力します。

0x4827 JTAG not disabled http://somewhere.net/docs/remediate4827.html \r\n0x2744 Platform Secure Boot key not provisioned http://somewhere.net/docs/remediate2744.html

メモリ管理に関する考慮事項

HSTI モジュール間の互換性のために、実装者は、AllocatePages() ではなく、AllocatePool() を使用する必要があります。

HSTI 実装の設計レビュー

Microsoft は、すべてのテスト インターフェイスの実装について、事前の設計レビューを実施するものとします。 設計レビューで問うことができる質問の例については、「HSTI の設計に関する考慮事項」セクションを参照してください。

省略可能なコード レビュー

HSTI 実装者が、Microsoft にコード レビューの実行を依頼することがあります。 コード レビューは場合によってリソースの優先度と可用性に基づいて提供されるため、保証はされません。 コード レビューは、機密保持契約に従って行われます。

ドキュメントとツールの共有

シリコンおよびファームウェアのサプライヤーは、OEM に提供する必要なセキュリティ関連の参照ドキュメントとツールのすべてを Microsoft が利用できるようにする必要があります。 このドキュメントとツールは、Windows OEM に提供されるまでに利用できるようにする必要があります。 これには、ファームウェアの融合、インストール、および更新、ファームウェアとブートの回復、ハードウェア診断、ファームウェア診断、ブート診断に関するすべてのドキュメントとツールが含まれますが、これに限定されるものではありません。 提供されるこのドキュメントとツールは、ラボ環境で HSTI チェックを実行するのに十分なものである必要があります。

HSTI の設計に関する考慮事項

HSTI 実装者が HSTI 実装について考慮する必要がある設計上の考慮事項の実例リストを次に示します。 これは、要件の厳密なリストではなく、考慮事項の完全なリストでもありません。 HSTI 実装者として、可能な限り包括的な範囲に向けて作業しているセキュリティ機能を検証するためのテストを作成します。 Microsoft の設計レビューの前に、インスピレーションを得るためにこのリストを確認し、これらの機能を実装する場合に、できるだけ広範囲にわたってテストすることを Microsoft が望むだろうという点を考慮するようにお勧めします。

シリコン サプライヤーまたはベンダー (IHV) の HSTI チェック

  1. RSA 2048 と SHA256 のみ (または同様の暗号強度) を使用しますか
  2. ファームウェア コードは、保護された記憶域に存在する必要があります
    1. spiflash を保護しますか?
    2. eMMC パーティションのリセットまで読み取り専用を実装しますか
    3. 署名付きのファームウェア チェックをサポートしますか - OEM によってインストールされたファームウェアは、読み取り専用であるか、セキュリティで保護されたファームウェアの更新プロセスによって保護されています。
  3. 安全なファームウェア更新プロセス
    1. 安全なファームウェア更新プロセスは、テスト キーを使用して既定でオンになっていますか? (推奨)
    2. テスト キーが実稼働環境で使用されているかどうかをチェックしますか?
    3. 安全でないファームウェア バージョンへのロールバックを許可しますか? 「はい」の場合、保護メカニズムは何ですか? ロールバックが発生したときに TPM をクリアしますか?
  4. セキュアブートをオーバーライドするバックドアがありますか
    1. システムで、セキュアブートをバイパスするようにインライン プロンプトをサポートしますか? 「はい」の場合、セキュアブートが有効になっている間は無効ですか?
    2. 製造バックドアがありますか? セキュアブートが有効な間は無効化され、実稼働システムで常に無効になっているかどうかをチェックしますか?
  5. [CS]ブート整合性のサポート
    1. ブート整合性をサポートしますか? 既定で有効ですか?
    2. プラットフォームは、オンダイ ROM または 1 回のみプログラミング可能な (OTP) メモリを使用して初期ブートコードを格納し、オンダイ ROM またはセキュリティで保護されたオンダイ SRAM から実行する電源オンリセット ロジックを提供します。
  6. [CS]内部および外部 DMA からの保護
    1. ブート時に必要なコンポーネントに対してのみ内部 DMA をオンにし続けますか? また、他のすべてのコンポーネントに対して無効ですか。
    2. ブート時に必要なコンポーネントに対してのみ外部 DMA をオンにし続けますか? また、他のすべてのコンポーネントに対して無効ですか。
    3. ファームウェアに DMA 保護を有効および無効にするオプションがある場合、出荷構成で、既定で DMA 保護を有効にする必要があります
    4. どのバスまたはデバイス (ヒューズ、セキュリティ エンジン、TZ、ビデオ、キャッシュ、IMEM、カーネル メモリ) が異なる NV および揮発性ストレージ領域への DMA アクセスが可能で、どのように保護されますか?
    5. MOR ビットの実装をサポートしますか
  7. 外部ハードウェア デバッガーに対する保護
    1. JTAG をサポートしますか? セキュアブートがオンのときに JTAG はオフですか
    2. JTAG 保護を無効にするために、製造バックドアを提供しますか? このバックドアが実稼働システムに存在しないかどうかをチェックしますか?
    3. JTAG が有効になったとき、TPM をクリアしますか?
    4. その他のハードウェア デバッガーをサポートしますか? それに対して同じチェックを行いますか。
  8. デバイスごとに一意のシークレットを正しくプロビジョニングしていますか?
  9. 使用しているセキュリティ ヒューズは何ですか (ベンダー固有)
    1. SOC セキュアブート ヒューズ
    2. 承認または encypherment のヒューズなど、デバイスごとに一意のシークレット
    3. JTAG ヒューズ
    4. SOC Apps プロセッサ セキュアブート ヒューズ
    5. SOC MBA プロセッサ セキュアブート ヒューズ
    6. SOC Modern プロセッサ セキュアブート ヒューズ
    7. プラットフォームのその他の SOC 固有のヒューズすべて

IBV の HSTI チェック

  1. RSA 2048 と SHA256 のみ (これ以上でも、これ以下でもない) を使用しますか
  2. 互換性サポートモジュール (CSM)
    1. CSM を有効にするオプションを提供しますか
    2. セキュアブートが有効になっている場合、CSM の読み込みのブロックをチェックしますか
    3. [CS]CSM が CS システムに永続的に存在しないかどうかをチェックしますか
  3. ファームウェア コードは、保護された記憶域に存在する必要があります
    1. spiflash を保護しますか?
    2. eMMC パーティションのリセットまで読み取り専用を実装しますか
    3. 署名付きのファームウェア チェックをサポートしますか - OEM によってインストールされたファームウェアは、読み取り専用であるか、セキュリティで保護されたファームウェアの更新プロセスによって保護されています。
  4. 安全なファームウェア更新プロセス
    1. 安全なファームウェア更新プロセスは、テスト キーを使用して既定でオンになっていますか?
    2. テスト キーが実稼働環境で使用されているかどうかをチェックしますか?
    3. 安全でないファームウェア バージョンへのロールバックを許可しますか? 「はい」の場合、保護メカニズムは何ですか? ロールバックが発生したときに TPM をクリアしますか?
    4. テスト キーは使用されていますか?
  5. セキュアブートをオーバーライドするバックドアがありますか
    1. システムで、セキュアブートをバイパスするようにインライン プロンプトをサポートしますか? 「はい」の場合、セキュアブートが有効になっている間は無効ですか?
    2. 製造バックドアがありますか? セキュアブートが有効な間は無効化され、実稼働システムで常に無効になっているかどうかをチェックしますか?
  6. [CS]内部および外部 DMA からの保護
    1. ブート時に必要なコンポーネントに対してのみ内部 DMA をオンにし続けますか? また、他のすべてのコンポーネントに対して無効ですか。
    2. ブート時に必要なコンポーネントに対してのみ外部 DMA をオンにし続けますか? また、他のすべてのコンポーネントに対して無効ですか。
    3. ファームウェアに DMA 保護を有効および無効にするオプションがある場合、出荷構成で、既定で DMA 保護を有効にする必要があります
    4. どのバスまたはデバイス (ヒューズ、セキュリティ エンジン、TZ、ビデオ、キャッシュ、IMEM、カーネル メモリ) が異なる NV および揮発性ストレージ領域への DMA アクセスが可能で、どのように保護されますか?
    5. MOR ビットの実装をサポートしますか