Skip to content

MS_TPM

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 3 revisions

TPM（Trusted Platform Module）

概要

  • マザーボードに搭載するセキュリティチップ

  • リソースの限られたパッシブ コンポーネント

  • FIDOなどで使用される。

補足（最新化：Windows 11 で必須化）: 元ページ執筆時点では
「推奨」の位置づけだったが、Windows 11 は TPM 2.0 を最小要件としている
（2021 年）。したがって現行の PC には事実上必ず搭載されている。

TPM が支えている代表的な機能は次の通り。

機能 TPM の役割
BitLocker ボリューム暗号化キーの封印（構成が変わると解錠しない）
Windows Hello for Business サインイン用の秘密鍵を格納・使用制限
Device Health Attestation 起動時の測定値の署名付き報告
資格情報ガード（Credential Guard） LSA シークレットの保護
仮想スマートカード スマートカード相当の鍵ストア

構成

  • 以下を 1 つのコンポーネントにまとめたもの。

    • RSA 2048 ビット キー ジェネレーター
    • 乱数ジェネレーター
    • EK、SRK、AIK を格納する不揮発性メモリ
    • 暗号化、暗号化解除、署名を行う暗号化エンジン
    • PCR と RSA キーを格納する不揮発性メモリ

  • ハードウェア ベースのセキュリティ関連の関数を提供する。

    • セキュリティで保護された暗号化プロセッサが暗号化の操作を実行するために用意されている。
    • 複数の物理的なセキュリティ メカニズム、改ざんされ難くすることが含まれている。
    • 処理に独自の内部ファームウェアおよび論理回路を使用するため、
      OS に依存せず、OS や APP に存在する可能性がある脆弱性にさらされることが無い。

移行メモ（正誤）: 「PCR と RSA キーを格納する不揮発性メモリ」とあるが、
PCR（プラットフォーム構成レジスタ）は揮発性である。
電源投入のたびに 0（または -1）に初期化され、
起動過程の測定値で「拡張（Extend）」されていく。
だからこそ「起動時の構成」を表す値として使える。

機能

Trusted Computing Group (TCG) による仕様を満たす制御が実装される。
※ TCG : コンピュータの信頼性と安全性を向上させるための標準技術を策定する団体

  • 暗号化キーの生成、格納、使用制限。

  • EK（保証キー）を使うことで、TPM テクノロジを使ってプラットフォーム デバイスを認証。

  • セキュリティ対策を取得して格納することで、プラットフォームの整合性を保つ。

  • TPM は受動的なデバイスで、コマンドを受信して応答を返す。

Ver

TPM 1.2

  • 最初の TPM の仕様

    • TCG によって 2005 年 2 月に公開
    • ISO/IEC 11889 標準で標準化

  • RSA と SHA-1 ハッシュ アルゴリズムの使用のみが許可。
    セキュリティ上の理由から、一部のエンティティは SHA-1 の使用を避け始めている。

  • マザーボード上にはんだ付けされたディスクリートなシリコン コンポーネント

  • ディスクリートとファームウェアでポリシー設定に違いがある。

  • ロックアウトのポリシーが異なるため、サポートの問題が生じることがある。

TPM 2.0

  • 最新の TPM の仕様

    • 2014 年 4 月に公開
    • ISO/IEC Joint Technical Committee (JTC) によって、
      ISO 標準 (ISO/IEC 11889:2015) として承認

  • 暗号化アルゴリズムをより柔軟にすることで、より高速な暗号化を実現。

    • SHA-256 と ECC をサポート
    • ECC は、署名とキー生成のパフォーマンスを高める場合に重要。

  • 最新のセキュリティ ニーズを満たす暗号強度の更新

    • PCR に対する SHA-256 のサポート
    • HMAC コマンドのサポート

  • 政府のニーズをサポートする暗号アルゴリズムの柔軟性

    • TPM 1.2 では、サポートできるアルゴリズムが制限されている。
    • TPM 2.0 では、TCG の仕様ドキュメントに小規模な更新を加えた
      任意のアルゴリズムをサポート

  • 実装全体の整合性

    • TPM 1.2 では、ベンダーが実装の詳細を自由に選ぶことができる。
    • TPM 2.0 では、この点が大幅に標準化されている。

  • OEM において、特定の国や地域のために標準構成に例外を設ける必要をなくすために役立つ

    • 異なる実装間でより一貫性のあるエクスペリエンスを実現。
    • デバイス間で一貫したロックアウト エクスペリエンスを確立。

補足（最新化）: TPM 1.2 は既にサポート対象外と考えてよい。

  • Windows 11 は TPM 2.0 のみ。
  • TPM 1.2 は SHA-1 しか扱えず、SHA-1 は 2017 年に衝突が実証されている。
  • TPM 2.0 の仕様自体も改訂が続いており（1.59 → 1.83 など）、
    実装のファームウェア更新が必要になる場合がある
    （例: 2017 年の ROCA 脆弱性（CVE-2017-15361）では、
    Infineon 製 TPM が生成した RSA 鍵が素因数分解可能となり、
    ファームウェア更新と鍵の再生成    が必要になった）。

ディスクリートとファームウェア

  • ディスクリート TPM、ファームウェア TPM、統合 TPM がある。

  • ディスクリートとファームウェアの特性は同じ

    • ハードウェア ベースのセキュリティで保護された実行を使用。
    • TPM 機能の一部にファームウェアを使う。
    • 改ざんに対して抵抗する機能が備わっている。
    • セキュリティに関する固有の制限事項 / リスクがある。
種別 実体
ディスクリート TPM（dTPM） TPM 独自の半導体パッケージ内にある個別のコンポーネント
ファームウェア TPM（fTPM） システムのメイン SoC 上の信頼された実行環境 (TEE) で動作する、ファームウェア ベースのコンポーネント
統合 TPM 1 つ以上の半導体パッケージに他のコンポーネントと共に統合された専用のハードウェア

  • ファームウェア TPM の実装例

    • Intel — Intel Management Engine (ME) / Converged Security Engine (CSE)
    • AMD — AMD Security Processor（fTPM）
    • ARM — Trustzone Trusted Application (TA)

  • デスクトップ Windows システム用のファームウェア TPM
    チップ ベンダーは、ファームウェア TPM の実装を
    他のチップ ファームウェアと共に OEM に提供。

補足（実務上の注意）: ディスクリート TPM は
マザーボードとチップ間のバス（LPC / SPI）を流れる情報を
物理的に盗聴する攻撃（TPM sniffing）が実証されている。
高い保証が要る環境では、BitLocker に
TPM + PIN を併用するのが定石である。

一方 fTPM は CPU 内部で動くためバス盗聴には強いが、
CPU の脆弱性の影響を受けるという別のリスクがある。

TPMとWindows

  • TPM は、将来的に、主要なセキュリティ機能のコンポーネントとなる可能性がある。

  • Windows 10

    • TCG によるバージョン 1.2 と 2.0 の TPM の仕様を認識

    • 最新のセキュリティ機能については、TPM 2.0 のみをサポート。

    • 2016 年 7 月 28 日以降に出荷されるすべての Windows 10 デバイスは、
      TPM 2.0 ディスクリートまたはファームウェアを使用している。

    • デバイスの正常性の認証には、TPM 2.0 が必要。

      • 脅威への対抗 — ハードウェア依存型のセキュリティ防御
      • 情報の保護 — アクセス制御ソリューションの提供
      • ID の保護 — Microsoft は FIDO Alliance に参加している。

    • Windows Hello や Windows Hello for Businessで使用されている。

正常性認証サービス

マイクロソフトが運営する信頼されたクラウド サービス

  • 一連の正常性チェックを実行（TPM 2.0 が必要）し、
  • 有効なセキュリティ機能を MDM にレポートする。

正常性チェック

ハードウェア ベースの方法で、一連の正常性チェックを実行する。

正常性の認証プロセス

  • HW のブート コンポーネントが測定される。

    • ファームウェア
    • UEFI ドライバー
    • CPU のマイクロコード

  • OS のブート コンポーネントが測定される。

  • Device Guard ポリシーが測定される。

  • Windows カーネルが測定される。

  • ウイルス対策ソフトウェアが開始される。

  • ブート開始ドライバが測定される。

  • MDM サーバーが、正常性認証構成サービス プロバイダ(CSP) を利用し、
    MDM エージェントを介して正常性チェック コマンドを発行。

    • 正常性暗号化 BLOB を送ることで、デバイスの正常性状態を伝える。
    • 未処理の測定値は TPM PCR レジスタに格納される。

  • TCG ログと PCR 値がリモートの Microsoft クラウド サービスに送られる。

    • 正常性認証サービスが正常性アサーションを評価し、
      デバイスが正常であるかどうかを決定する。
    • すべてのイベントの詳細は TCG ログで確認できる。

補足（最新化）: この仕組みは現在
Device Health Attestation (DHA) と呼ばれ、
Microsoft Intune および Microsoft Entra ID の
条件付きアクセスと連動する。
検証基盤としては Microsoft Azure Attestation が使われる。

「デバイスが正常でなければ、
ID が正しくてもアクセスさせない」という制御は、
ゼロトラストの中核的な考え方である。

Device Guard

  • Windows 10 Enterprise の新機能

    • デバイスをロックダウンする
    • 信頼されていないソフトウェアを実行できないようにする

  • 次の 3 つから構成される。

    • 以下を組み合わせた一連のハードウェア セキュリティ機能
      システムの起動時に実行されるデバイスを制御できる。

      • TPM
      • UEFI
      • セキュア ブート

    • コード整合性エンジン

      • コード整合性が完全に構成
      • 分離ユーザー モード（仮想化ベースのセキュリティで保護されるメモリの一部）に存在。

    • 管理機能
      以下を介して公開される。

  • ソフトウェアの信頼性の判断

    • Hyper-V 保護コンテナーで実行される Hyper-V コード整合性を使って実行される。

    • Hyper-V コード整合性は、ドライバーやシステム ファイルがメモリに読み込まれるたびに、
      その整合性を検証する機能。

    • 以下を検出する。

      • 未署名のドライバーやシステム ファイルがカーネルに読み込まれるかどうか
      • 管理者特権アカウントで実行されている悪意のあるソフトウェアによって
        システム ファイルが変更されているかどうか

    • x64 の Windows 10 では、カーネル モード ドライバにデジタル署名が必要になる。

    • Windows ストア インフラストラクチャを利用

      • ユニバーサル Windows アプリと従来の Windows アプリに署名して配布。
      • 組織のメンバーの基幹業務 (LOB) アプリは、プライベート ストアを使用して配布。

補足（最新化：名称が分割された）: 「Device Guard」という名称は
2017 年以降使われていない。機能は次の 2 つに分割・改称された。

旧 現在の名称
Device Guard のコード整合性ポリシー WDAC（Windows Defender Application Control）→ 現 App Control for Business
Device Guard の仮想化ベースのコード整合性 メモリ整合性（HVCI）／仮想化ベースのセキュリティ（VBS）

ドキュメントを探す際は新しい名称で検索する必要がある。

正常性認証構成サービス プロバイダ(CSP)

CSP へのアクセスをマルウェア対策や MDM エージェントなどのアプリケーションに許可して、
アプリケーションが正常性認証トークンを要求できるようにすることで、
正常性の認証シナリオをサポートする。

正常性暗号化 BLOB

測定値とその署名をまとめた、MDM 経由で送られる不透明なデータ。

MDM ソリューション

Microsoft Intune やサード パーティの MDM ソリューション

  • セキュリティ ベースラインを定義

    • コード整合性ポリシー（ドライバー / システム ファイル /
      従来のデスクトップ アプリケーション / スクリプト）

  • デバイスの準拠レベルを定期的に調査

    • インストールされているソフトウェア
    • 適用されている構成
    • デバイスの正常性状態

  • リモート デバイスの正常性の認証

    • デバイスが正常
      IdP（Microsoft Entra ID）にアクセスを許可できるように通知する。
    • デバイスが異常
      アクセスをブロック、または修復を要求する。

TPM キー

キーの作成

"ラッピング" / "バインディング"

TPM が組み込まれたコンピューターは、
TPM だけが暗号化を解除できるように、
暗号化キーを作成して、キーを暗号化できる。

"封印" / "開封"

  • 封印
    特定のプラットフォーム測定値に関連付けられたキーを作成。

  • 開封
    プラットフォーム測定値がキー作成時の値と一致する場合にのみラップ解除。

補足（BitLocker の挙動の理由）: BitLocker が
「UEFI 設定を変えたら回復キーを求めてきた」というのは、この封印の仕組みによる。
起動構成が変われば PCR の値が変わり、
封印されたキーが開封できなくなるためである。
障害ではなく設計通りの動作であり、
だからこそ回復キーの保管が必須になる。

キーの組のプライベート部分

  • キーの組のプライベート部分は、OS で制御されるメモリとは別に保持される。
  • 署名と、TPM によって定義された限られた操作にだけ使うことができる。
  • キーを封印できるので、キーを使用するために開封するまでは、
    システムの状態に関して一定の保証（システムの "信頼性" を規定する保証）ができる。

構成証明

  • TPM キーの構成証明は、キーが TPM にバインドされていることを暗号で証明するプロトコル。
  • 構成証明を使うことで、特定の暗号化操作が特定のコンピューターの TPM で
    行われたことを保証できる。

仕組み

  • CA は、EKPub または EKCert 経由で TPM の信頼を確立。
  • 構成証明情報を要求したサーバに送信、これを検証する。

構成証明情報

検証対象

生成された

  • RSA キー
  • AIK（認証 ID キー）証明書
  • 構成証明ステートメント

検証項目

上記をサーバーが受け取った場合、サーバーは次の項目を確認する。

  • AIK（認証 ID キー）証明書

    • 署名が有効であること。
    • 期間が有効であること。
    • チェーン
      • 信頼されたルートに到達できること。
      • EKU OID 2.23.133.8.3（フレンドリ名は "認証 ID キーの証明書"）に対して
        有効になっていること。
      • 発行元の CA の証明書がすべて有効期間内にあり、失効していないこと。

  • 構成証明ステートメント

    • KeyAttestation BLOB の署名は、AIK 公開キーを使う。
    • KeyAttestation BLOB に含まれる公開キーは、
      クライアントが構成証明ステートメントと共に送信した公開 RSA キーと一致する。

EK（保証キー）

  • TPM には、保証キーと呼ばれる非対称キーのペア（RSA サイズ 2048 ビット）が
    （製造時から）埋め込まれている。

  • 保証キーは、TPM の身分証明書として機能する。

    • すべての TPM を識別できる。
    • 変更、削除したりすることはできない。

  • 保証キーには、多くの場合、1 つまたは 2 つのデジタル証明書が付属する。

キーペア

内容
EKPub 保証キーの公開キー。所有者パスワードの定義ハッシュを含む TPM の所有権を得る場合など、機密性の高いパラメタを安全に送るために使われる
EKPriv 保証キーの秘密キー。AIK（認証 ID キー）などのセカンダリ キーを作成する際に使われる

証明書

EKCert: EK（保証キー）証明書

  • EKPub の製造元から発行された EK 証明書（TPM を初めて初期化するときに作成される）

    • TPM の製造時
    • オンライン サービスと通信時

  • ローカル プロセス、アプリケーション、クラウド サービスに対して TPM の信頼性
    （例えば、特定のメーカによって製造された本物の TPM であること）を証明するために使われる。

  • この TPM で生成されるその他のすべてのキーのルート信頼が作成される。

プラットフォーム証明書

特定の TPM が特定のデバイスに統合されていることを示す。

所有

SRK（ストレージ ルート キー）

  • ストレージ ルート キーはユーザが TPM の所有権を取得するときに作成される。
  • 都度、作成される TPM キーが TPM 無しで使用されることがないように
    キーを保護する事が目的。

補足（TPM 2.0 では用語が変わっている）: SRK は TPM 1.2 の用語で、
TPM 2.0 では 階層（Hierarchy）と Primary Key という概念に置き換わった。

階層 用途
Endorsement Hierarchy EK。デバイスの身元
Storage Hierarchy SRK 相当。鍵の保護
Platform Hierarchy ファームウェア／OEM 用
Null Hierarchy 一時利用（再起動でリセット）

用途ごとに独立した階層を持つため、
「所有者パスワードは 1 つだけ」という TPM 1.2 の制約も解消されている。

所有者パスワード

  • TPM の所有者が誰であるかを定義する。

  • 所有者パスワードを設定できるユーザが TPM を所有していることになる。

    • 1 つの TPM に設定できる所有者パスワードは 1 つだけ。
    • パスワードを知っているすべてのユーザーが事実上の TPM 所有者になる。

AIK（認証IDキー）

非対称キーのペア（RSA サイズ 2048 ビット）

用途

  • TPM 2.0 の認証機能を使ってデバイスの正常性をレポートする。
  • しかし、EK（保証キー）証明書ではプライバシーに関する問題が発生する可能性がある。
  • この問題を防ぐため、TPM の ID として代替される。
  • これにより、暗号証明（TPM キーの構成証明）などの機能を提供する。

補足（プライバシー問題の中身）: EK は
TPM ごとに一意で、変更も削除もできない。
これをそのまま認証に使うと、
すべてのサービスから同一端末として追跡可能になる（スーパー Cookie 化）。

そこで、EK では「本物の TPM であること」だけを証明し、
実際の署名には用途ごとに作った AIK を使う。
PPID（Private Personal Identifier）と同じ発想である。

AIK（認証IDキー）証明書

  • AIK（認証 ID キー）に対応する証明書は、AIK（認証 ID キー）証明書

用途

  • TPM 内に AIK（認証 ID キー）が存在することを証明する。
  • 特定の TPM の AIK（認証 ID キー）によって認証された他のキーを証明する。

Windows 10 では、

  • EK（保証キー）証明書が有る場合

    • Microsoft Cloud CA サービスなどのサードパーティサービスと連携して
      AIK（認証 ID キー）証明書をプロビジョニングする。
    • 発行された AIK（認証 ID キー）証明書には、
      EK（保証キー）証明書が使われたことを証明するために特別な OID が追加される。

  • EK（保証キー）証明書が無い場合

    • AIK（認証 ID キー）証明書を発行できる
      （これは、Microsoft Cloud CA サービスによって発行されたものではない）。
    • この証明書は、製造時にデバイスに書き込まれた EK（保証キー）証明書ほどの
      信頼性はないが、TPM がない場合の
      Microsoft Passportなどの高度なシナリオとの
      互換性は確保される。
      • デバイスを拒否するか承諾するかを決めることができる。
      • 価値の高い資産へのアクセスを許可しないこともできる。

PCR（プラットフォーム構成レジスタ）

  • TPM 内で一意のプロパティを格納したメモリ ロケーション
  • システム構成データを含む

補足（PCR の仕組み）: PCR は値を「上書き」できない。
起動過程の各段階が測定値 m を報告すると、TPM は

PCR[n] ← Hash( PCR[n] || m )

という Extend 操作でしか更新できない。
このため、

  • 任意の値に偽装できない（逆算できない）
  • 順序も含めて記録される

という性質が得られる。これが「測定ブート」の基礎である。
電源投入時に初期化される（＝揮発性）ため、
その回の起動構成を表す値になる。

参考

その他の端末のセキュリティ

TEE（Trusted Execution Environment）

SE（Secure Element）

耐タンパ性を持つ独立したチップ（SIM、eSE など）。
スマートフォンでは、TEE と併用して鍵を保護する。

USBドングル

挿さないと PC が動かないハードウエア型の鍵デバイス。

Tags: 移行, インフラストラクチャ, セキュリティ, 認証基盤

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally