WindowsのTPMとは何か ── 図解でわかる「鍵を外に出さない金庫」と測定起動

「Windows 11にできないPCがあります。TPMがないと言われました」──ここ数年、法人のPC入れ替えの相談で必ず出てくる言葉です。「なんだかセキュリティのチップらしい」ところまでは知られているものの、それが何をしていて、なぜ必須なのか、そしてなぜBIOSを更新しただけでBitLockerの回復キーを聞かれるのかまで説明できる人は多くありません。

TPMは「暗号化を速くするチップ」ではありませんし、「ウイルスを防ぐチップ」でもありません。やっていることは、乱暴に言えば次の2つだけです。

1. 秘密鍵を自分の中から出さないまま、使わせてくれる
2. 起動時に何が読み込まれたかを記録し、その記録が期待どおりのときだけ鍵を出す

この2つが分かると、BitLocker、Windows Hello、Credential Guard、デバイスの正常性証明といったWindowsのセキュリティ機能が同じ土台の上に乗っていることも、実務で遭遇するトラブルの理由も、きれいに説明がつきます。

この記事では、TPMの仕組みを図で押さえたうえで、Windowsのどこで使われているのか、自分のPCの状態をどう確認するのか、回復キー画面やTPMクリアといった現場のトラブルをどう扱うのか、そして開発者が自分のアプリからTPMを使うにはどうするのかまでを、公式ドキュメントの裏付けつきで整理します。

1. まず結論

TPM(Trusted Platform Module)は、暗号鍵の生成・保管・利用を担うセキュリティ専用のプロセッサです。¹ やっていることは、冒頭で挙げた2つに集約されます。

• 秘密鍵をチップの外に出さないまま使わせる(金庫)。エクスポート不可と指定した鍵の秘密部分は、他のソフトウェア・プロセス・ユーザーに一切公開されません。²
• 起動時に何が読み込まれたかを記録する(台帳)。ファームウェアやブートローダーは、次に実行するコードのハッシュをPCRという領域に記録してから制御を渡します。この記録が期待どおりのときだけ鍵を取り出せる「封印」ができ、BitLockerがその代表例です。³²

この2つから、実務で効く結論が導けます。詳細は各章で説明します。

• Windows HelloのPINが4桁でも安全に成立するのは、辞書攻撃対策(認証失敗32回でロックアウト)がハードウェア側にあるからです(2章)。²
• Windows 11の最小要件は「UEFI、セキュアブート対応」のファームウェアとTPM 2.0です。ただしWindows 11 IoT Enterpriseには専用機向けの緩和要件があり、TPMが任意になる構成もあります(6章)。⁴⁵
• TPMの実装は3種類(専用チップ/統合/ファームウェア)ありますが、Windowsはどれも同じように使います(5章)。⁶
• Windows 10/11はTPMを自動的に初期化して所有権を取得するので、通常 tpm.msc で設定をいじる必要はありません(8章)。¹
• TPMのクリアはデータ消失につながります。実行前にバックアップと復旧手段の確認が必須です(9章)。⁷
• 開発者は、TPMを直接叩くのではなくCNGの「Microsoft Platform Crypto Provider」を使います(10章)。⁸

2. TPMとは何か ── 「鍵を外に出さない金庫」

まず、TPMがない世界を考えます。ソフトウェアだけで秘密鍵を守ろうとすると、鍵は最終的にどこかのタイミングでメモリ上の平文になります。署名や復号の計算をするには、CPUが鍵の値を読む必要があるからです。つまり、カーネルまで到達したマルウェアや、メモリを物理的に読み出せる攻撃者からは、原理的に隠しきれません。公式ドキュメントも、ソフトウェアによる鍵保護は「使用中にメモリ上でどう鍵を保管しているか、どうコピーを作っているかを解析されるリバースエンジニアリング攻撃を受ける」と明言しています。³

TPMはこの前提をひっくり返します。鍵はTPMの中で生成され、TPMの中に留まります。アプリやOSは鍵をもらうのではなく、TPMに仕事を依頼して結果だけを受け取るのです。

flowchart TB
    subgraph SW["A. ソフトウェアだけで鍵を守る場合"]
        A1["アプリ / OS"] -->|"鍵を読み込んで計算する"| A2["メモリ上の秘密鍵<br/>平文になる瞬間がある"]
        A2 -.->|"読み出せてしまう"| A3["カーネルまで到達したマルウェア<br/>メモリ解析・物理攻撃"]
    end
    subgraph HW["B. TPMに鍵を預ける場合"]
        B1["アプリ / OS"] -->|"署名して / 復号して<br/>という依頼だけを送る"| B2["TPM"]
        B2 --> B3["TPMの中の秘密鍵で計算する<br/>鍵はチップの外へ出ない"]
        B3 -->|"結果だけを返す"| B4["アプリ / OS が受け取るのは<br/>署名や復号の結果だけ"]
        B5["カーネルまで到達したマルウェア<br/>メモリ解析・物理攻撃"] -.->|"鍵そのものは取り出せない"| B2
    end
    SW ~~~ HW

図1: ソフトウェアだけで鍵を守る場合と、TPMに鍵を預ける場合の違い

ここで重要なのは、TPMは受動的(passive)だという点です。TPMは自分から何かを監視したり、ウイルスを止めたりしません。コマンドを受け取って応答を返すだけの部品です。⁶ だからこそ、TPMの価値を引き出すにはOEM(PCメーカー)がハードウェアとファームウェアを丁寧に統合する必要があり、Windowsがそれを前提に機能を組み立てている、という構図になります。

もう1つの柱が辞書攻撃対策です。TPMが守る鍵には、PINのような認証値を設定できます。認証値の推測が一定回数失敗すると、TPMは追加の試行を拒否してロックアウトします。TPM 2.0では、この挙動をWindowsが構成します。具体的には認証失敗32回でロックアウトし、10分経過ごとに1回分の失敗を忘れるという設定です。320分間まったく失敗がなければ、記憶している失敗回数はゼロに戻ります。²

この「回数制限がハードウェア側にある」という事実が効いてきます。ソフトウェアで失敗回数を数えていると、再起動されたり、システムクロックを巻き戻されたり、カウントを記録したファイルをロールバックされたりすれば無効化できます。TPMならそれができません。³ Windows HelloのPINが4桁でもパスワードより安全と言える根拠は、まさにここにあります。

3. TPMの中身 ── EK・SRK・PCR・NVRAM

TPMの内部には、役割の違う要素がいくつか入っています。名前が似ていて混乱しやすいので、図で位置関係を押さえておきます。

flowchart TB
    TPM["TPM 2.0"]
    TPM --> EK["EK / 保証鍵<br/>製造時の種から導出される<br/>製造元の証明書が付く"]
    TPM --> SRK["SRK / ストレージルート鍵<br/>ほかの鍵を包む親の鍵"]
    TPM --> PCR["PCR 0〜23<br/>起動の測定値を積み上げる"]
    TPM --> NV["NVRAM<br/>電源を切っても消えない小領域"]
    EK --> AIK["AIK / 証明用の鍵<br/>EKの代わりに外へ出す身分証"]
    SRK --> K1["BitLockerの鍵"]
    SRK --> K2["Windows Helloの鍵"]
    SRK --> K3["証明書の秘密鍵"]
    PCR -.->|"この値のときだけ<br/>取り出せる、と縛る"| K1

図2: TPMの主要な構成要素と、鍵の親子関係

EK(Endorsement Key / 保証鍵)は、そのTPM固有の非対称鍵ペアです。秘密側はTPMの中に保持され、外部に公開されることも、外部からアクセスされることも一切ありません。² 製造元が署名したEK証明書が付いており、「この鍵は確かに当社が製造したTPMの中にある」ことを示します。これによって、本物のTPMなのか、TPMのふりをしたマルウェアなのかを区別できます。³

なお、マイクロソフトのドキュメントはEKをRSA鍵ペアと説明していますが²、これはTPM 1.2時代からの記述です。TPM 2.0で製造時にチップへ書き込まれる不変の秘密は、正確には「エンドースメント・プライマリ・シード」という種で、EKはこの種から決まった手順(テンプレート)で導出されます。同じ種から導出すれば必ず同じ鍵になるので、EKは作り直せても事実上そのTPM固有の鍵であり続けます。RSAとECCのどちらのEKも導出でき、実機に両方が用意されていることも珍しくありません。

ただし、EKをそのまま外部に見せるとPCを一意に識別できてしまい、プライバシー上の問題になります。そこで実際のシナリオではAIK(Attestation Identity Key / 証明用の鍵)を使います。認証局がEKとその証明書を使って「このAIKは本物のTPMの中に存在する」ことを証明し、AIK証明書を発行します。相手ごとに別のAIKを使えるので、複数の検証者が結託して同じ端末を追跡することを防げます。³

SRK(Storage Root Key / ストレージルート鍵)は、他の鍵を包む(ラップする)ための親鍵です。TPMは作った鍵を暗号化して外に出すことができ、その鍵はそのTPMでしか復号できません。この処理を「ラップ」または「バインド」と呼びます。² つまり、TPMの中の記憶領域は小さくても、外部ストレージに暗号化して置いておけば、実質的に何本でも鍵を持てるということです。

PCR(Platform Configuration Register)は、起動時の測定値を積み上げる特殊なレジスタです。0番から23番まであり、それぞれ何を測るかが決まっています。⁹ 重要な性質は、任意の値を直接書き込めず、Extend という操作でしか値を進められないことです。Extend は「現在の値と新しい測定値を連結してハッシュを取った結果を新しい値にする」という一方向の操作なので、「途中で都合の悪い記録だけを消す」ことが原理的にできません。値は再起動でリセットされます。³

なお、TPM 2.0にはリセット可能属性を持つPCRもあります(DRTMやアプリケーション用途)。ただしBitLockerが封印に使うPCR(0・2・4・7・11)は静的な測定起動用のPCRで、再起動までリセットできません。本記事の説明はこちらを前提にしています。

NVRAMは不揮発の小さな領域で、証明書などを保持するのに使われます。TPM 2.0はTPM 1.2に比べ、アルゴリズム、暗号、階層、ルート鍵、認可、NVRAMの各面で改善されています。⁶

4. 測定起動とPCR ── なぜ「起動が変わると開かない」のか

TPMのもう1つの柱が測定起動(Measured Boot)です。ここがBitLockerの動作を理解する鍵になります。

4.1. そもそも「測定」とは何をすることか

先に進む前に、「測定」という言葉を具体的にしておきます。ここでの測定は、重さや温度のような物理量を測ることではありません。次に実行するプログラムや設定データのバイト列全体から、ハッシュ値を計算することです。ハッシュ値は「内容の指紋」のような固定長の値で、次の性質を持ちます。

• 同じ内容からは、いつ誰が計算しても必ず同じ値が出る
• 内容が1バイトでも違えば、まったく別の値になる
• 値から元の内容を復元することは実質的にできない

たとえばSHA-256というハッシュで計算すると、abc は

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

になり、最後の1文字だけ違う abd は

a52d159f262b2c6ddb724a61840befc36eb30c88877a4030b65cbe86298449c9

になります。1文字の違いでも値は全面的に変わり、2つの値を見比べても「似た内容だった」という手がかりすら残りません。PowerShellの Get-FileHash で任意のファイルのSHA-256を計算できるので、この「指紋」の感覚は手元でも試せます。

つまり「起動の測定値」とは、起動の過程で実行されるファームウェア・ブートローダー・設定それぞれのハッシュ値のことです。測定値が前回とすべて同じなら「起動に関わったソフトウェアと構成は前回とまったく同じだった」と言い切れます。逆に、ブートローダーが改ざんされていたり、別のOSから起動されたりすれば、対応する測定値が必ず変わります。これが測定起動の土台です。

4.2. 測定の連鎖 ── 読み込むものを、実行する前に測る

仕組みは単純です。システムファームウェアの中にはCRTM(Core Root of Trust for Measurement)という、無条件に信頼される起点があります。CRTMは次に実行するソフトウェアコンポーネントを無条件にハッシュ化し、その測定値をTPMへ記録します。以降のコンポーネントも同じことを繰り返します──読み込むものを、実行する前に測るのです。実行前に測定値が送られるため、あるコンポーネントが自分の測定値をTPMから消すことはできません。³

sequenceDiagram
    autonumber
    participant FW as UEFIファームウェア CRTM
    participant BM as Windows ブートマネージャー
    participant OS as Windows カーネル
    participant T as TPM

    FW->>T: 次に実行するコードのハッシュを Extend
    Note over T: PCR 0 / 2 / 4 / 7 が更新される
    FW->>BM: 制御を渡す
    BM->>T: 封印された BitLocker の鍵の解除を依頼
    alt PCR が封印時と同じ値
        T-->>BM: 鍵を返す
        BM->>BM: OSボリュームを復号する
        BM->>T: カーネル・ELAM・ブートドライバーを Extend
        Note over BM,T: 実行前に測ってから制御を渡す
        BM->>OS: 制御を渡して Windows を起動
    else PCR が違う値
        T-->>BM: 鍵を返さない
        BM->>BM: 回復キー入力画面へ
    end

図3: 測定起動とBitLockerの鍵解放の流れ

図で「復号したあとにカーネルを測る」順序になっているのは、測定起動の原則どおり、読み込むものは実行前に測るからです。Windowsブートローダーがカーネルのデジタル署名を検証してから読み込み、カーネルがさらにブートドライバー・スタートアップファイル・ELAMを検証する、という連鎖になっています。¹⁰ カーネルが起動してから自分を測るのでは、測定を省略できてしまい意味がありません。

BitLockerは、この測定値が期待した値のときだけ使える鍵をTPMの中に作ります。期待値は、システムディスクのOSボリュームからWindowsブートマネージャーが動く時点のものとして計算されます。別のOSで起動されたり構成が変えられたりすれば、TPM内の測定値が変わり、TPMは鍵の使用を許可せず、暗号化されたOSボリュームは復号できません。³

では、実際にどのPCRが見られているのでしょうか。ネイティブUEFI構成での既定のプラットフォーム検証プロファイルは次のとおりです。⁹

既定では PCR 0・2・4・11 が封印の対象です。ただしセキュアブート状態(PCR 7)がサポートされている場合は、PCR 7とPCR 11で封印されます。⁹ これは重要な違いです。PCR 0/2/4はファームウェアやブートマネージャーのイメージそのもののハッシュなので、ファームウェアを更新するたびに値が変わり、回復モードに落ちます。一方PCR 7は「セキュアブートが有効か、どの鍵を信頼しているか」を測るので、署名者が同じであればイメージが更新されても値が変わりません。マイクロソフトも、PCR 7に紐づけることでファームウェア更新やイメージ更新による回復モード突入の可能性が減ると説明しています。⁹

PCR 11の使われ方は少し変わっていて、面白い工夫です。想定されているのは、攻撃者が被害者の端末はそのまま(ハードウェアとファームウェアを保ったまま)で、OSディスクだけを自分の用意したものに差し替えるという攻撃です。鍵は元のTPMに封印されているので端末ごと変えては意味がなく、被害者のTPMを使い続けるのがポイントです。攻撃者は被害者のOSパーティションのメタデータから封印済みのBitLocker鍵blobを取り出し、自分の支配下のOSを起動してからTPM APIを呼び、その鍵blobの解除(unseal)を試みます。

これが成立しないのは、Windowsが鍵を封印するときPCR 11の値を0として封印し、ブートマネージャーが次のブートローダー(正規のものであれ不正なものであれ)へ制御を渡すときに必ずPCR 11を1に変えるからです。攻撃者のOSが動いている時点でブートマネージャーはすでに制御を手放しており、PCR 11は確実に0ではなくなっています。したがって同じ端末・同じTPMの上でも、ブートマネージャーより後の段階から鍵を要求することはできません。¹¹

なお、セキュアブートそのものもBitLockerの守りの一部です。既定でBitLockerはPCR 7の測定によってセキュアブートの完全性保護を利用し、許可されていないEFIファームウェア・EFIブートアプリケーション・ブートローダーが起動してBitLockerの鍵を取得することを防ぎます。¹¹

5. dTPM・fTPM・Pluton ── 実装形態の違い

「TPMチップ」という言い方が広まっているせいで、TPMは必ず独立した部品だと思われがちですが、実装は3種類あります。⁶

flowchart LR
    C1["CPU"] ---|"LPC / SPI バス"| T1["専用のTPMチップ<br/>= ディスクリート dTPM"]
    C2["CPU / チップセットの<br/>パッケージ"] --> T2["同じパッケージ内の専用ハードウェア<br/>論理的には分離<br/>= 統合 integrated"]
    C3["汎用CPU"] --> T3["信頼実行環境 TEE の上で動く<br/>ファームウェア実装<br/>= ファームウェア fTPM"]
    C4["SoC"] --> T4["マイクロソフト設計の<br/>セキュリティプロセッサ<br/>= Pluton"]

図4: TPMの3つの実装形態と、その延長にあるPluton

• ディスクリートTPM(dTPM)は、独立した半導体パッケージの専用チップです。マザーボードに実装され、OEMがシステム本体とは別に評価・認証できるという利点があります。⁶
• 統合TPMは、他のコンポーネントと同じパッケージに入りつつ、論理的には分離された専用ハードウェアとして実装されます。⁶
• ファームウェアTPM(fTPM)は、汎用の演算ユニットの信頼実行環境(TEE)でTPMをファームウェアとして動かします。⁶ 小型・低消費電力のデバイスで専用チップが現実的でないケースに向きます。

Windowsは互換性のあるTPMであればどれも同じように使います。マイクロソフトはTPMをどの方式で実装すべきかについて立場を取らず、幅広いエコシステムがあらゆるニーズに応えるとしています。⁶ つまり「fTPMだから格下」ということはありません。

そのうえでMicrosoft Plutonは、統合形態をさらに進めたものです。マイクロソフトが設計しシリコンパートナーが製造する、CPUに組み込まれたセキュアな暗号プロセッサで、TPMの機能を提供しつつ、TPM 2.0仕様の範囲を超えたセキュリティ機能も提供することを狙って設計されています。¹² 2026年時点でPlutonが利用できるのは、Windows 11が動作する次のチップセット搭載機です。¹²

• AMD: Ryzen 6000 / 7000 / 8000 / 9000 シリーズ、Ryzen AI シリーズ
• Intel: Core Ultra 200V シリーズ、Core Ultra Series 3 および Series 3 プロセッサ
• Qualcomm: Snapdragon 8cx Gen 3、Snapdragon X シリーズ

運用面でPlutonが持つ特徴は、ファームウェアの更新経路が2系統あることです。従来どおりUEFIカプセル更新でマザーボードのSPIフラッシュ上のファームウェアを更新できるほか、OSの更新を通じて新しいPlutonファームウェアを動的に読み込めます。システム起動時にはSPIフラッシュ上のファームウェアで初期化され、Windowsの起動中に(あれば)Windows Update経由で取得した最新版が読み込まれる、という流れです。¹² TPMのファームウェア脆弱性が見つかったときに、PCメーカーのBIOS更新提供を待たずに配られる可能性がある、というのは実務上ありがたい性質です。

6. TPM 1.2 と 2.0 の違い、そしてWindows 11の要件

古いPCを扱っていると、まだTPM 1.2に出会うことがあります。両者の差は「バージョンが上がった」という以上のものです。⁶

とくに効くのがSHA-1です。NISTは2014年時点で多くの連邦機関にSHA-256への移行を求め、マイクロソフトやグーグルも2017年にSHA-1ベースの署名・証明書のサポートを廃止しました。TPM 1.2の仕様はSHA-1しか使えないため、この流れに追随できません。⁶

そしてWindows 11です。最小要件は、互換性リストに載った64bit CPU、メモリ4GB、ストレージ64GB、DirectX 12以上に対応しWDDM 2.0ドライバーを持つグラフィックス、720p以上で9インチ超・8ビット/チャネルのディスプレイ、「UEFI、セキュアブート対応(Secure Boot capable)」のシステムファームウェア、そしてTPM 2.0です。⁴

ここは正確に読んでください。最小要件が求めているのはセキュアブートに対応していることであって、有効になっていることではありません。⁴ 無効のままでも要件自体は満たせるので、Windows 11に上げるためだけにUEFI設定をいじる必要はありません。もっとも、セキュアブートを有効化し、かつプラットフォームがPCR 7の紐づけ要件を満たしていれば、BitLockerがPCR 7に紐づいて回復モードに落ちにくくなります(4章)。有効化だけで自動的にそうなるわけではないので、実際にどのPCRに紐づいているかは manage-bde -protectors -get C: のPCR検証プロファイルで確認してください。要件だからではなく、この実利のために有効化するのが正しい整理です。

もう1つ見落とされがちなのが、TPM 2.0はレガシーモードやCSM(Compatibility Support Module)モードのBIOSではサポートされないという点です。TPM 2.0搭載デバイスはBIOSモードを「ネイティブUEFIのみ」に構成する必要があり、レガシー/CSMオプションは無効化しなければなりません。⁶

これは実務で厄介な状況を生みます。レガシーモードでインストールされたOSは、BIOSモードをUEFIに変えると起動しなくなるからです。BIOSモードを変更する前に MBR2GPT ツールを使い、OSとディスクをUEFI対応の状態にしておく必要があります。⁶ 「TPMは載っているのにWindows 11に上げられない」という機体は、この状態であることが少なくありません。Windows 10からの移行判断の全体像は「Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断表」に整理しています。

なお、デバイスの正常性証明(Device Health Attestation)についても、WindowsがサポートするのはTPM 2.0であり、TPM 2.0を積んでいてもレガシーBIOSのデバイスでは期待どおりに動作しません。¹

6.1. 例外 ── Windows 11 IoT EnterpriseではTPMは任意

ここまでの「Windows 11ならTPM 2.0必須」は、一般PC向けエディションの話です。Windows 11 IoT Enterprise には、専用機向けの緩和された最小要件が別に定義されていて、IoT Enterprise LTSC(および非LTSCの24H2以降)ではTPMもセキュアブートも任意(Optional)です。⁵ 産業用PCや装置組み込みの現場では、ここを知っているかどうかで「この基板ではWindows 11にできない」という結論がひっくり返ります。

公式の要件表は、PREFERRED(推奨)とOPTIONAL(専用機向けの最小)の2列構成になっています。⁵

注意点が3つあります。

• 「LTSCならTPM不要」ではありません。緩和要件が定義されているのは IoT Enterprise で、Windows 11 Enterprise LTSC(IoTなし)は一般PC向けと同じ扱いです。名前が似ているので混同されがちですが、調達するライセンスがどちらなのかで結論が変わります。
• 非LTSCのIoT Enterpriseはバージョンで違います。21H2〜23H2のOPTIONAL要件ではTPM 2.0は依然として必須(任意になっているのはセキュアブートだけ)で、TPMが任意になるのは24H2以降です。⁵
• プロセッサ要件は別建てです。TPMとセキュアブートが任意でも、対応プロセッサの一覧は別途定義されているので、そちらは必ず確認してください。⁵

そしてマイクロソフト自身が、緩和要件を選ぶことの意味に釘を刺しています。エンドユーザーがあとからソフトウェアを追加できるデバイスで要件を下げるときは慎重に検討すべきで、TPMを載せないことはエンドユーザーが必要とするソフトウェアに影響しうる、という趣旨です。⁵ TPMがなければBitLockerは鍵を起動状態に封印できず、Windows Helloの鍵もソフトウェア保護に落ちます。「要件を満たすために載せる」のではなく「その端末に必要な保護を得るために載せる」という判断に切り替えてください。

IoT Enterprise / LTSCの選び方とライセンス調達の全体像は「産業用PCにはどのWindowsを入れるべきか ── Windows IoT Enterprise / LTSC 実践ガイド」に整理しています。

7. WindowsのどこでTPMが使われているか

「TPMが必須です」と言われても、それが日々のどの機能に効いているのかが見えないと納得しにくいものです。地図を描いておきます。

flowchart LR
    TPM["TPM 2.0"]
    TPM --> BL["BitLocker / デバイス暗号化<br/>鍵を起動状態に封印する"]
    TPM --> WH["Windows Hello<br/>PINや生体情報に紐づく鍵を保護<br/>辞書攻撃対策で短いPINでも安全"]
    TPM --> CG["Credential Guard<br/>分離環境の鍵を測定値で保護"]
    TPM --> MB["測定起動 / リモート証明<br/>起動状態に署名した quote を発行"]
    TPM --> HA["デバイスの正常性証明<br/>MDMの条件付きアクセスの判断材料"]
    TPM --> PCP["Platform Crypto Provider<br/>証明書の秘密鍵を持ち出し不可に"]

図5: TPMを土台にしているWindowsの主なセキュリティ機能

BitLocker / デバイス暗号化。4章で見たとおりです。解除方式はTPMのみ、TPM+PIN、TPM+スタートアップキー、TPM+PIN+スタートアップキーの4通りで、TPMのみは利便性が最も高いぶん、追加の認証要素を求める方式より安全性は低い、と整理されています。¹¹

なお、デバイス暗号化(BitLockerを自動で有効化する仕組み)の前提条件はここ数年で変わりました。かつてはModern StandbyまたはHSTIの要件を満たし、DMAアクセス可能な外部ポートを持たないことが条件でしたが、Windows 11 バージョン24H2以降この前提は撤廃され、より多くの端末が対象になっています。¹³ 古い解説にある「Modern Standby対応機でないと使えない」は、24H2以降には当てはまりません。手元の端末が対象かどうかは、msinfo32.exe(システム情報)の「デバイス暗号化のサポート」で確認できます。¹³

Windows Hello / Windows Hello for Business。デバイスごとにプロビジョニングされた鍵と、PINや生体情報を組み合わせて認証します。TPMがあれば鍵はTPMが保護し、なければソフトウェアで保護します。生体情報はプロビジョニング済みの鍵にアクセスするためだけにその端末上で使われ、端末間で共有されません。³ TPMがある端末では鍵を他の場所へコピーできないため、認証情報が漏れても他の端末では使えないという性質が得られます。

Credential Guard。資格情報のハッシュ処理をカーネルからアクセスできない分離メモリ領域で行う機能です。この分離領域は起動プロセス中に初期化・保護され、Credential GuardはTPMを使ってその鍵を測定値で保護します。鍵は「分離領域が初期化される起動プロセスの段階」でのみアクセス可能で、通常のカーネルからは利用できません。³

測定起動とリモート証明。AIKを使って、TPMは現在の測定値の状態に暗号署名した文(quote)を生成できます。これをリモートへ送ることで、「どのソフトウェアと構成で起動し、OSを初期化したか」を証明できます。³ 測定はWindowsの初期状態で止まるので、どのアプリを使っているかといったプライバシー情報は含まれません。³

デバイスの正常性証明。マイクロソフトの正常性証明サービスが、複数メーカーのTPM向けにAIK証明書を発行し、測定起動の情報を解析して「BitLockerがオンか」「セキュアブートがオンか」「DEPが有効か」といった単純な表明に変換します。MDM(Intuneなど)は複雑な quote を自前で解析せずに、この表明を使って端末を隔離したりクラウドサービスへのアクセスを止めたりできます。¹³

Platform Crypto Provider。証明書の秘密鍵をTPMで保護します。証明書テンプレートで「TPMのPlatform Crypto Providerを使う」と指定でき、エクスポート不可に設定された証明書の秘密鍵はTPMから取り出せません。PINを要求する証明書なら、TPMの辞書攻撃対策が自動的に適用されます。³ これが10章で扱う開発者視点の入口です。

仮想スマートカード。TPMを「常に挿さっているスマートカード」として振る舞わせる機能で、物理カードとリーダーの購入・配布コストを不要にします。³ ただしマイクロソフトは現在、仮想スマートカードの利用者にWindows Hello for BusinessやFIDO2セキュリティキーへの移行を推奨しています。² 既存資産としては残っていますが、これから設計するなら選ばない方向です。

8. 自分のPCのTPMを確認する

ここからは手を動かす話です。まず押さえておきたいのは、Windows 10/11はTPMを自動的に初期化して所有権を取得するということです。したがってTPM管理コンソール(tpm.msc)で設定をいじる必要は通常なく、マイクロソフトも「ほとんどの場合、tpm.mscでの構成は避けることを推奨する」としています。例外は、PCのリセットやクリーンインストールに関わる場面くらいです。¹ ちなみにTPM管理コンソールは、Windows Server 2019 / Windows 10 バージョン1809以降、積極的な開発が終了しています。¹

8.1. GUIで見る

• Win + R → tpm.msc でTPMの管理コンソールが開きます。TPMの有無、状態、仕様バージョン、メーカーが分かります。
• Windowsセキュリティの デバイス セキュリティ → セキュリティ プロセッサの詳細 でも同じ情報が見られます。この画面から セキュリティ プロセッサのトラブルシューティング → TPM をクリア に進めます(9章で扱いますが、安易に押してはいけません)。⁷

8.2. PowerShellで見る

複数台を調べるならPowerShellが確実です。TrustedPlatformModule モジュールに一通りのコマンドレットがあります。¹⁴

# TPMの状態をまとめて確認する(管理者権限で実行)
Get-Tpm

出力は次のような形です。¹⁵

TpmPresent                : True
TpmReady                  : True
TpmEnabled                : True
TpmActivated              : True
TpmOwned                  : True
ManufacturerIdTxt         : INTC
ManufacturerVersion       : 402.1.0.0
ManagedAuthLevel          : Full
OwnerClearDisabled        : False
AutoProvisioning          : Enabled
LockedOut                 : False
LockoutHealTime           : 10 minutes
LockoutCount              : 0
LockoutMax                : 31

読み方のポイントは次のとおりです。¹⁵

• TpmPresent: TPMが存在するか。ここが False ならハードウェアかUEFI設定の問題です。
• TpmReady: Windowsが使える状態か。TpmPresent が True でも TpmReady が False なら、初期化や所有権取得でつまずいています。
• LockedOut / LockoutCount / LockoutMax / LockoutHealTime: 辞書攻撃対策の状態です。LockedOut が True なら、PINの入力ミスなどで一時的に締め出されています。
• OwnerClearDisabled: True だとOSから所有者認証値によるリセット(クリア)ができません。
• AutoProvisioning: Windowsによる自動プロビジョニングの有効/無効です。

仕様バージョンが2.0かどうかを機械的に判定したい場合は、WMIから見るのが手軽です。

# 仕様バージョン・メーカー・有効状態を取得する
Get-CimInstance -Namespace 'root/CIMv2/Security/MicrosoftTpm' -ClassName Win32_Tpm |
    Select-Object SpecVersion, ManufacturerId, ManufacturerVersion,
                  IsEnabled_InitialValue, IsActivated_InitialValue, IsOwned_InitialValue

ここで注意したいのが ManufacturerId です。Get-Tpm が返す ManufacturerIdTxt(INTC のような文字列)は Get-Tpm 側にしかないプロパティで、Win32_Tpm クラスにはありません。¹⁶ うっかり Select-Object ManufacturerIdTxt と書くと、その列は黙って空になります。

Win32_Tpm にあるのは uint32 の ManufacturerId で、各バイトをASCII文字として解釈すると文字列になります(例: 1414548736 → 0x54 0x50 0x4D 0x00 → TPM)。¹⁶ 文字列で欲しいなら、次のように自分で復号するか、素直に Get-Tpm を使ってください。

# ManufacturerId(uint32)をASCII文字列に直して一覧にする
Get-CimInstance -Namespace 'root/CIMv2/Security/MicrosoftTpm' -ClassName Win32_Tpm |
    Select-Object SpecVersion, ManufacturerVersion,
        @{ Name = 'ManufacturerText'; Expression = {
            $bytes = [System.BitConverter]::GetBytes([uint32]$_.ManufacturerId)
            # uint32を上位バイトから読む(例: 1229870147 → 0x49 0x4E 0x54 0x43 → INTC)
            if ([System.BitConverter]::IsLittleEndian) { [array]::Reverse($bytes) }
            -join ($bytes | Where-Object { $_ -ne 0 } | ForEach-Object { [char]$_ })
        } }

SpecVersion は 2.0, 0, 1.16 のように「仕様バージョン, リビジョン, エラッタ」の形で返ります。¹⁶ 先頭が 2.0 かどうかを見れば、Windows 11のTPM要件を満たすかの判定に使えます(CPU・メモリ・ストレージなど他の要件は別途の確認が必要です。11章参照)。複数台に対してリモートで実行する方法は「PowerShell Remoting(WinRM)入門」を参照してください。

そのほか、Get-TpmEndorsementKeyInfo でEKと証明書の情報を、Get-TpmSupportedFeature で特定機能のサポート状況を確認できます。ロックアウトの解除は Unblock-Tpm、TPMのリセットは Clear-Tpm です。¹⁴

8.3. コマンドラインツールで見る

tpmtool はTPMの情報取得と診断に使う標準ツールです。¹⁷

:: TPMの基本情報を表示する
tpmtool getdeviceinformation

:: TPMのログを収集してカレントディレクトリに置く
tpmtool gatherlogs

BitLockerの状態とあわせて見るなら、manage-bde -status や Get-BitLockerVolume を併用します。イベントログ側の調査手順は「Get-WinEventでイベントログを実務的に調べる」にまとめています。

9. 実務のトラブル ── 回復キー画面・TPMクリア・ロックアウト

現場でTPMが話題になるのは、たいてい何かがうまくいかないときです。よくある3つを扱います。

9.1. BitLockerの回復キーを求められた

いちばん多い相談です。原因の切り分けは、実は単純です。

flowchart TD
    S["起動時に回復キー画面が出た"] --> Q1{"直前に何かを変えたか"}
    Q1 -->|"UEFI/BIOSを更新した"| A1["PCR 0 などの測定値が変わった<br/>次回以降は再封印されるので<br/>回復キーで解除して継続"]
    Q1 -->|"セキュアブート設定を変えた<br/>CSMを有効にした"| A2["PCR 7 の測定値が変わった<br/>設定を戻すか回復キーで解除"]
    Q1 -->|"TPMをクリアした<br/>マザーボードを交換した"| A3["封印した鍵そのものが消えた<br/>事前にBitLockerを一時停止していなければ<br/>回復キーが唯一の手段"]
    Q1 -->|"USBから別OSを起動した<br/>ブート順を変えた"| A4["ブート構成の測定値が変わった<br/>元に戻して再起動"]
    Q1 -->|"心当たりがない"| A5["攻撃の可能性も含めて調査<br/>ログ収集後に回復キーで解除"]
    A1 --> R["回復キーの保管場所を確認<br/>AD DS / Entra ID / Microsoftアカウント"]
    A2 --> R
    A3 --> R
    A4 --> R
    A5 --> R

図6: BitLockerの回復キーを求められたときの切り分け

ファームウェア更新は回復モードの定番の引き金です。マイクロソフトも、PCR 0を含むプロファイルを設定している場合はファームウェア更新の前にBitLockerを一時停止するよう案内しています。⁹ 逆に言えば、セキュアブートが正しく構成されPCR 7に紐づいている端末では、ファームウェア更新で回復モードに落ちる頻度が下がります。⁹ Modern Standby対応機ではPCR 7の測定がロゴ要件であり、TPMとセキュアブートが正しく構成されていれば既定でPCR 7とPCR 11に紐づきます。⁹

運用としての結論はシンプルです。UEFI更新・セキュアブート設定変更・TPMクリア・マザーボード交換の前には、必ずBitLockerを一時停止する。そして、その前に回復キーの保管場所(Active Directory Domain Services、Microsoft Entra ID、個人ならMicrosoftアカウント)を確認しておくことです。組織ではBitLockerを構成して回復キーをAD DSに保管できます。³

一時停止を挟んでいたかどうかで、その後の手間はまったく変わります。BitLockerを一時停止するとクリアキーの保護機能がボリュームに残るので、TPMをクリアしても新しいTPMに載せ替えても、回復キーを入力せずにそのまま起動できます(起動後に保護を再開すると、新しいTPMに対して封印し直されます)。図6で「回復キーが唯一の手段」としているのは、一時停止せずにクリア・交換してしまった場合の話です。逆に言えば、事前準備を1つ入れるだけで、この分岐は回避できます。

9.2. TPMをクリアしたい / クリアしてしまった

TPMのクリアはデータ消失を招きます。公式ドキュメントの警告は明確です。クリアすると、TPMに紐づいて作られた鍵と、その鍵で保護されたデータ(仮想スマートカードやサインインPINなど)がすべて失われます。TPMで保護・暗号化しているデータについて、バックアップと復旧手段を必ず用意してください。⁷

加えて、実務で効く注意点が3つあります。⁷

• 自分の所有物でない端末(会社や学校のPC)のTPMを、管理者の指示なしにクリアしない。
• クリアは必ずOSの機能(tpm.msc やWindowsセキュリティ)から行い、UEFIから直接クリアしない。
• 一時的にTPMの動作を止めたいだけなら、クリアではなく「TPMをオフにする」を使う。

クリア後、Windowsは自動的にTPMを再初期化して所有権を取得し直します。⁷

ここで強調しておきたいのは、TPMのクリアはデータ消去(サニタイズ)ではないということです。クリアで失われるのはTPMの中の鍵であって、ディスク上のデータそのものは1バイトも消えません。BitLockerの回復キーはAD DSやMicrosoft Entra ID、Microsoftアカウントに退避されているのが普通なので、それを持つ人はTPMをクリアした後でもボリュームを復号できます。

端末を第三者に渡すときの本体は、Windowsの「このPCを初期状態に戻す(データも消去する)」、専用の消去ツール、暗号化消去、物理破壊といったストレージの消去手順です。TPMのクリアはその仕上げに過ぎません。廃棄・譲渡の手順全体は「Windows PCの廃棄・譲渡チェックリスト」に整理しています。

もう1つ、意外に知られていない落とし穴があります。一部のシステムには複数のTPMが載っていてUEFIで切り替えられることがありますが、Windowsはこの構成をサポートしていません。TPMを切り替えるとWindowsが新しいTPMを正しく検出できないことがあり、BitLockerは回復モードに入ります。切り替えるなら、切り替えたうえでクリアし、Windowsを再インストールする必要があります。マイクロソフトは、TPMが2つあるシステムでは片方を選んだら変更しないことを強く推奨しています。⁷

9.3. TPMがロックアウトされた

PINの入力ミスが続くと、TPMがロックアウトします。Windowsの既定構成では、TPM 2.0は認証失敗32回でロックし、10分ごとに1回分の失敗を忘れます。ロック状態でも、回復間隔のあいだ電源を入れたまま待てばロックアウトから抜けられます。² 10分はあくまでWindowsの既定値なので、実際の間隔はその端末の Get-Tpm が返す LockoutHealTime で確認してください(8章)。慌てて再起動を繰り返すより、放置するほうが早いことがあります。

即時解除したい場合は、ロックアウトリセットのコマンドを送ります。ここで誤解しやすいのがTPM所有者パスワードです。Windows 10 バージョン1607以降、WindowsはTPMのプロビジョニング時に所有者パスワードを保持しません(ランダムな高エントロピー値を設定したうえで破棄します)。¹⁸ 「管理者が所有者パスワードを持っている前提」で手順を組むと、現場で止まります。

代わりに使われるのがロックアウト認可(lockout authorization)です。OSManagedAuthLevel の既定値5は、TPM 2.0では「ロックアウト認可だけを保持する」ことを意味します。¹⁸ つまり「フルの所有者パスワードは失われているが、ロックアウトを解除するための認可は残っている」のが既定の状態で、tpm.msc のロックアウト時間リセットや Unblock-Tpm は通常この認可で動きます。所有者パスワードそのものを残す設定(レジストリで OSManagedAuthLevel を4にする)もありますが、マイクロソフトは強く非推奨としています。¹⁸

なお、所有者パスワードがなくても、UEFIでの物理的存在の確認によってTPMの有効化・無効化・クリアといった管理操作を行う経路は残されています。¹⁸ ただしこれは、ロックアウトを非破壊で即時解除する代替手段ではありません。ロックアウト認可が使えない場合は、時間経過による回復(10分ごとに1回分)を待つのが基本で、クリアは鍵をすべて失う最終手段です(9.2節)。

なお、認可値を明示的に入力してリセットする構成の場合、間違った値でリセットを試みると、TPMは24時間リセットの再試行を許可しません。² 手当たりしだいに試さないでください。

なお、TPM 2.0では認証値なしで作れる鍵もあり、それらはTPMがロックされていても使えます。BitLockerの既定のTPMのみ構成は、TPMがロックされていてもWindowsを起動できます。²

10. 開発者から見たTPM ── Platform Crypto ProviderとCNG

自社アプリで「ライセンス鍵を端末に紐づけたい」「サーバーへの接続に端末固有のクライアント証明書を使いたい」「設定ファイルの機密値をこの端末でしか復号できないようにしたい」という要件が出たとき、TPMは有力な選択肢になります。

10.1. TBSではなくCNGを使う

Windowsには低レベルのAPIとしてTBS(TPM Base Services)があります。アプリケーション横断でTPMアクセスを集中管理するシステムサービスで、RPC経由のAPIとして提供され、呼び出し側が指定した優先度に基づいてTPMアクセスを協調的にスケジュールします。¹⁹

ただし、TBSのドキュメント自身がこう書いています。「TPMは鍵保管の用途にも使えるが、開発者にはこれらのシナリオではキーストレージAPIの使用を推奨する。キーストレージAPIは鍵の作成・署名・暗号化・永続化の機能を提供し、TBSよりも高水準で扱いやすい」。¹⁹ つまり、鍵を守りたいだけならTBSを触る理由はありません。

使うべきなのは、CNG(Cryptography API: Next Generation)のキーストレージプロバイダー 「Microsoft Platform Crypto Provider」 です。CNGは暗号プロバイダーとキーストレージプロバイダーを分離しており、Platform Crypto ProviderはTPMを利用するKSPとして、秘密鍵を安全に保管し取り出せないようにします。⁸

Platform Crypto Providerが提供する、ソフトウェアだけのCNGプロバイダーでは実現できない(あるいは同等に実現できない)特性は2つです。³

• 鍵の保護: TPMの中に利用制限付きの鍵を作れる。OSは鍵をシステムメモリにコピーせずにTPM内で読み込んで使える。持ち出し不可に設定できる。TPMが作った鍵はそのTPMにしか存在せず、そのTPMは鍵のコピーを作る源にはならない。
• 辞書攻撃対策: 鍵にPINなどの認証値を要求でき、推測が多すぎればTPMが一定時間の拒否を返す。

10.2. C#での書き方

.NETからは System.Security.Cryptography の CNG系クラスで扱えます。

using System;
using System.Security.Cryptography;

const string KeyName = "KomuraSoft.DeviceKey";

// NTE_EXISTS: 「オブジェクトは既に存在します」(同名の鍵がすでにある)
const int NTE_EXISTS = unchecked((int)0x8009000F);

// TPMを使うキーストレージプロバイダー
var provider = new CngProvider("Microsoft Platform Crypto Provider");

// ユーザー単位の鍵にするか、マシン単位(サービスやタスクから使う)にするか。
// 作成側と参照側で必ず揃える ── ここがずれると「作ったはずの鍵が見つからない」になる。
const bool UseMachineKey = false;
var openOptions = UseMachineKey ? CngKeyOpenOptions.MachineKey : CngKeyOpenOptions.None;
var creationOptions = UseMachineKey
    ? CngKeyCreationOptions.MachineKey   // 作成には管理者権限が必要
    : CngKeyCreationOptions.None;

CngKey OpenOrCreateKey()
{
    if (CngKey.Exists(KeyName, provider, openOptions))
    {
        // 2回目以降は既存の鍵を開く(鍵はTPMに永続化されている)
        return CngKey.Open(KeyName, provider, openOptions);
    }

    var creationParameters = new CngKeyCreationParameters
    {
        Provider = provider,
        KeyCreationOptions = creationOptions,
        // 秘密鍵の持ち出しを一切許可しない ── ここがTPMを使う意味の中心
        ExportPolicy = CngExportPolicies.None,
    };
    creationParameters.Parameters.Add(
        new CngProperty("Length", BitConverter.GetBytes(2048), CngPropertyOptions.None));

    try
    {
        return CngKey.Create(CngAlgorithm.Rsa, KeyName, creationParameters);
    }
    catch (CryptographicException ex) when (ex.HResult == NTE_EXISTS)
    {
        // Exists と Create の間に別プロセスが同名の鍵を作ると、Create は
        // NTE_EXISTS で失敗する。その場合だけ、勝った側が作った鍵を開き直す。
        // それ以外の失敗(TPMが使えない・権限不足など)はそのまま呼び出し元へ投げる。
        return CngKey.Open(KeyName, provider, openOptions);
    }
}

using (var key = OpenOrCreateKey())
using (var rsa = new RSACng(key))
{
    byte[] payload = System.Text.Encoding.UTF8.GetBytes("device-attestation-challenge");
    // 署名はTPMの中で行われる。秘密鍵はプロセスのメモリに現れない
    byte[] signature = rsa.SignData(payload, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

ExportPolicy = CngExportPolicies.None が肝です。ここを既定のままにすると、せっかくTPMを使っても鍵を取り出せる設定になりかねません。「鍵が外に出ない」ことがTPMを使う理由なので、明示的に持ち出し不可を指定してください。

もう1つの落とし穴が、ユーザー単位の鍵とマシン単位の鍵の取り違えです。CngKey.Exists / CngKey.Open の2引数版はユーザー単位の鍵しか探しません。作成側だけを CngKeyCreationOptions.MachineKey に変えて参照側をそのままにすると、既存のマシン鍵が見つからず、毎回「同じ名前で作り直そうとして失敗する」という壊れ方をします。上のコードのように、作成・存在確認・オープンの3か所で同じスコープ(CngKeyCreationOptions.MachineKey と CngKeyOpenOptions.MachineKey)を使うよう揃えてください。

OpenOrCreateKey を関数に切り出して try/catch を入れているのにも理由があります。「存在を確認してから作る」は競合に弱いからです。アプリの多重起動などで2つのプロセスがともに Exists == false を見てから Create に進むと、先に作れたほうが勝ち、負けたほうは「同名の鍵がすでにある」で失敗します。初回起動時にだけ、しかも稀にしか起きないので、テストではまず踏みません。負けた側は勝者が作った鍵を開き直す、という後始末を最初から入れておいてください。

ただし、開き直してよいのは失敗の理由が「同名の鍵がすでにある」(NTE_EXISTS)のときだけです。TPMが使えない・権限が足りないといった別の失敗まで同じ経路に流すと、本来の原因が Open の「鍵が見つからない」という別の例外にすり替わり、調査が迷走します。上のコードが例外フィルターで HResult を絞っているのはそのためです。

10.3. 設計時に織り込むべき現実

公式ドキュメントの記述とTPMの性質から、実装前に決めておくべきことがいくつかあります。

• TPMは速くない。専用のマイクロコントローラーや、CPUの保護モードで動く小さなプロセッサです。² 鍵生成に数秒かかることも珍しくありません。大量データの暗号化にTPMの鍵を直接使ってはいけません。データはAESなどの対称鍵で暗号化し、その対称鍵をTPMの鍵で保護する二段構えにします。
• 鍵生成・署名はUIスレッドで走らせない。上記の遅さがそのままフリーズとして見えます。
• TPMをクリアすると鍵は消える。修理・マザーボード交換・OS再インストールで失われる前提で、再登録の導線(サーバー側で端末を再登録する手順など)を設計に入れてください。「鍵が消えたら詰み」という設計は現場で必ず事故ります。
• ユーザー単位かマシン単位かを決める。ユーザー単位の鍵はプロファイルに紐づきます。サービスやスケジュールタスクから使うならマシン単位(CngKeyCreationOptions.MachineKey)が必要で、作成には管理者権限が要ります。参照側にも CngKeyOpenOptions.MachineKey を渡すのを忘れないでください。データの置き場所の考え方は「Windowsアプリのデータ保存先の選び方」も参考になります。
• マシン単位にしただけでは、サービスのアカウントはその鍵を使えません。MachineKey が決めるのは鍵ストアの場所だけで、誰が使えるかは鍵に付いたACL(セキュリティ記述子)で決まります。管理者が作った鍵を非管理者のサービスアカウントで開こうとして「アクセスが拒否されました」で止まるのは定番の事故です。対処は、鍵を使う本人(サービスのアカウント)の権限で作るか、作成時にセキュリティ記述子(CNGの Security Descr プロパティ)へサービスのSIDを許可として設定するか。どちらにせよ、必ず実際の実行アカウントで動作確認してください。
• TPMがない環境をどう扱うか決める。要件として弾くのか、Microsoft Software Key Storage Provider にフォールバックして「保護レベルが下がる」ことを受け入れるのか。混在環境では、証明書テンプレートでPlatform Crypto Providerを優先しつつソフトウェアプロバイダーも許す、という運用が実際に取られています。³
• 鍵にPINを付けるかどうかは慎重に。辞書攻撃対策が効くのは利点ですが、TPMのロックアウトはグローバルです。個々の鍵ごとに失敗回数を管理するのは技術的に現実的でないため、認証失敗が増えすぎるとTPM全体がロックされます。² 自社アプリの入力ミスが、同じ端末のWindows Helloを巻き込む可能性があるということです。
• 資格情報そのものの扱いは別問題として残ります。スクリプトや設定ファイルに平文で置かない設計は「PowerShellでの資格情報の安全な扱い」に整理しています。

11. 実務の定石(判断表)

12. まとめ

• TPMは「秘密鍵をチップの外に出さないまま使わせる金庫」と「起動時に読み込まれたものを記録する台帳」を兼ねた、受動的なセキュリティプロセッサです。
• 測定起動用の静的なPCRは Extend でしか値を進められず、しかも実行前に測定するため、途中のコンポーネントが自分の痕跡を消せません。BitLockerはこの測定値に鍵を封印しています(TPM 2.0にはリセット可能なPCRもありますが、封印に使うPCRは対象外です)。
• ネイティブUEFIの既定ではPCR 0/2/4/11、セキュアブートが使える環境ではPCR 7/11に封印されます。PCR 7に紐づくほうが、ファームウェア更新で回復モードに落ちにくくなります。
• 実装はディスクリート/統合/ファームウェアの3種類で、Windowsはどれも同じように扱います。PlutonはCPU統合型で、ファームウェアをWindows Update経由でも更新できる点が運用上の特徴です。
• Windows 11の要件はTPM 2.0と「UEFI、セキュアブート対応」のファームウェア。要件は対応であって有効化ではありませんが、有効化するとBitLockerがPCR 7に紐づくという実利があります。TPMを積んでいてもCSMモードでは要件を満たさないので、MBR2GPT を挟んでからBIOSモードを変えてください。
• 例外はWindows 11 IoT Enterpriseで、専用機向けの緩和要件ではTPMもセキュアブートも任意です。ただし対象はIoT Enterprise LTSCと非LTSCの24H2以降で、非LTSCの21H2〜23H2はTPM 2.0必須、IoTなしのWindows 11 Enterprise LTSCは緩和対象外です。そもそもTPMを載せない選択は、BitLockerやWindows Helloの保護を手放すことでもあります。
• ファームウェア更新・セキュアブート設定変更・TPMクリア・マザーボード交換の前には、BitLockerの一時停止と回復キーの所在確認をセットで行います。
• 自社アプリからは、TBSではなくCNGの Microsoft Platform Crypto Provider を使います。持ち出し不可を明示し、TPMの遅さとクリア時の消失を設計に織り込んでください。

関連記事

• Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断表
• 産業用PCにはどのWindowsを入れるべきか ── Windows IoT Enterprise / LTSC 実践ガイド
• Windows PCの廃棄・譲渡チェックリスト
• PowerShell Remoting(WinRM)入門 ── 複数台のWindowsを一括管理する
• Get-WinEventでイベントログを実務的に調べる ── 絞り込みの速さが調査時間を決める
• PowerShellでの資格情報の安全な扱い ── 平文パスワードをスクリプトから追放する
• Windowsアプリのデータ保存先の選び方

関連する相談領域

合同会社小村ソフトでは、Windows 11移行にともなうハードウェア要件の棚卸しやBitLocker運用設計の相談、TPMを使った端末固有の鍵管理を含むWindows業務アプリの受託開発を扱っています。

• Windowsアプリ開発
• 不具合調査・原因解析
• 既存資産活用・移行支援
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

TPMは結局のところ何をしているのですか？

ひとことで言えば「秘密鍵を外に出さないまま使わせてくれる小さな金庫」です。TPMの中で作られた秘密鍵は、設定しだいでチップの外へ一切出ません。アプリやOSは鍵そのものを受け取るのではなく、TPMに対して「このデータに署名して」「この鍵で復号して」と依頼し、結果だけを受け取ります。これに加えて、起動時に読み込まれたファームウェアやブートローダーのハッシュをPCRという領域に積み上げて記録し、その値が期待どおりのときだけ鍵を取り出せるようにする「封印」ができます。BitLockerが「PCの中身をすり替えると解除できない」のはこの仕組みによるものです。

Windows 11がTPM 2.0を必須にしたのはなぜですか？

BitLocker・Windows Hello・Credential Guard・デバイス正常性の証明といった機能が、ハードウェアに根ざした信頼の起点を前提に設計されているためです。TPM 1.2はRSAとSHA-1しか使えず、ロックアウトの挙動もメーカーごとにばらついていましたが、TPM 2.0では新しいアルゴリズムが使え、辞書攻撃対策もWindowsが一貫して構成します。なお、TPM 2.0はレガシーBIOS互換モード(CSM)では動作しないため、ネイティブUEFI構成が前提になります。例外はWindows 11 IoT Enterpriseで、IoT Enterprise LTSCと非LTSCの24H2以降ではTPMもセキュアブートも任意です(非LTSCの21H2〜23H2ではTPM 2.0は必須。名前の似たWindows 11 Enterprise LTSC(IoTなし)は緩和対象外)。

dTPM、fTPM、Plutonは何が違うのですか？どれを選ぶべきですか？

実装形態の違いです。dTPM(ディスクリートTPM)はマザーボード上の専用チップ、fTPM(ファームウェアTPM)はCPUの信頼実行環境で動くソフトウェア実装、PlutonはCPUに統合されたマイクロソフト設計のセキュリティプロセッサです。Windowsから見た使い方はどれも同じで、マイクロソフトはどの実装を選ぶべきかについて立場を取らないと明記しています。実務上の違いは、専用チップはCPUとの間のバスが物理攻撃の対象になりうること、fTPMはCPUのファームウェア更新に挙動が左右されること、PlutonはファームウェアをWindows Update経由で更新できることなどです。調達で選べる場合は、業務端末ではメーカーの保守方針とファームウェア更新の提供状況を基準にするのが現実的です。

BIOSを更新したらBitLockerの回復キーを求められました。なぜですか？

BitLockerの鍵は起動時の測定値(PCR)に封印されているため、その測定対象が変わると鍵が解放されず回復モードに入ります。ファームウェア更新はまさにPCR 0などの測定値を変える操作です。マイクロソフトも、PCR 0を含む構成ではファームウェア更新前にBitLockerを一時停止するよう案内しています。回復キーで解除すれば、次回以降は新しい測定値で再封印されるので同じことは起きません。運用としては、UEFI更新・セキュアブート設定変更・TPMのクリア・マザーボード交換の前には必ずBitLockerを一時停止し、回復キーの保管場所(Active Directory、Microsoft Entra ID、Microsoftアカウント)を先に確認してください。

自分のアプリからTPMで鍵を守るにはどうしますか？

TPMのコマンドを直接叩くのではなく、CNG(Cryptography API: Next Generation)のキーストレージプロバイダー「Microsoft Platform Crypto Provider」を使います。.NETならCngKey.CreateにこのプロバイダーとExportPolicies.Noneを指定するだけで、秘密鍵がTPMの中に作られ、持ち出せない状態になります。低レベルのTPM Base Services(TBS)も公開されていますが、マイクロソフト自身が鍵の保管・署名・暗号化の用途にはより高水準なキーストレージAPIを使うよう推奨しています。実装上は、TPMの処理が遅いこと、TPMをクリアすると鍵が消えること、TPMのない環境へのフォールバックをどうするかを設計に織り込んでください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。