Windows 的 TPM 是什麼 ── 圖解「不讓金鑰外流的保險箱」與測量啟動

「有一台電腦裝不了 Windows 11，說是沒有 TPM」──這幾年，只要談到法人 PC 汰換，一定會聽到這句話。雖然大家多少都知道「好像是某種安全晶片」，但能說明它到底在做什麼、為什麼是必要條件，以及為什麼光是更新 BIOS 就會被問要求輸入 BitLocker 回復金鑰的人並不多。

TPM 不是「讓加密變快的晶片」，也不是「防毒的晶片」。若說得直白一點，它做的事只有以下兩件：

1. 讓私密金鑰不離開自己內部，卻仍然可以使用
2. 記錄開機時載入了什麼，只有在記錄符合預期時才釋放金鑰

只要理解這兩點，BitLocker、Windows Hello、Credential Guard、裝置健康狀態證明等 Windows 安全功能為何都建立在同一個地基上，以及實務上遇到的各種故障原因，都能得到清楚的解釋。

本文將先以圖解掌握 TPM 的機制，接著整理 Windows 在哪些地方用到它、如何確認自己 PC 的狀態、如何處理回復金鑰畫面與清除 TPM 等現場的疑難雜症，以及開發者該如何從自己的應用程式使用 TPM，並附上官方文件作為依據。

由於涵蓋範圍較廣，先提供本文的閱讀方式。不需要從頭依序讀完。

1. 先講結論

TPM（Trusted Platform Module）是負責產生・保存・使用加密金鑰的安全專用處理器。¹ 它做的事，可以歸納成開頭提到的那兩點。

• 讓私密金鑰不離開晶片外也能使用（保險箱）。指定為不可匯出的金鑰，其私密部分完全不會公開給其他軟體・處理程序・使用者。²
• 記錄開機時載入了什麼（帳本）。韌體與開機載入程式，會先把接下來要執行的程式碼雜湊值記錄到稱為 PCR 的區域，才會把控制權交出去。只有在這份記錄符合預期時才能取出金鑰，這種「封印」機制正是 BitLocker 的代表用法。³²

從這兩點，可以推導出實務上有用的結論。細節將於各章說明。

• 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 內部。應用程式或作業系統拿到的不是金鑰，而是向 TPM 委託工作、只取回結果。

flowchart TB
    subgraph SW["A. 只靠軟體保護金鑰的情況"]
        A1["應用程式／作業系統"] -->|"讀取金鑰並運算"| A2["記憶體中的私密金鑰<br/>存在變成明文的瞬間"]
        A2 -.->|"可以被讀出"| A3["滲透到核心層級的惡意程式<br/>記憶體分析・實體攻擊"]
    end
    subgraph HW["B. 把金鑰交給 TPM 保管的情況"]
        B1["應用程式／作業系統"] -->|"只送出 請簽章／請解密<br/>這樣的委託"| B2["TPM"]
        B2 --> B3["用 TPM 內的私密金鑰運算<br/>金鑰不會離開晶片"]
        B3 -->|"只回傳結果"| B4["應用程式／作業系統<br/>拿到的只有簽章或解密結果"]
        B5["滲透到核心層級的惡意程式<br/>記憶體分析・實體攻擊"] -.->|"無法取出金鑰本身"| B2
    end
    SW ~~~ HW

圖 1：只靠軟體保護金鑰，與把金鑰交給 TPM 保管的差異

這裡重要的一點是，TPM 是被動（passive）的。TPM 不會主動監控什麼，也不會攔截病毒。它只是一個接收命令、回傳應答的元件。⁶ 正因如此，要發揮 TPM 的價值，就需要 OEM（PC 廠商）仔細整合硬體與韌體，而 Windows 正是以此為前提來建構功能。

另一根支柱是字典攻擊防護。TPM 保護的金鑰可以設定類似 PIN 的驗證值。若驗證值猜測連續失敗達一定次數，TPM 就會拒絕額外的嘗試並進入鎖定。在 TPM 2.0 中，這個行為由 Windows 統一設定，具體來說是驗證失敗 32 次即鎖定，每經過 10 分鐘就忘記一次失敗紀錄。若連續 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 的惡意程式。³

補充：TPM 2.0 的 EK 不是「燒錄的金鑰」，而是「由種子導出的金鑰」

Microsoft 的文件把 EK 說明為 RSA 金鑰對，² 但這是延續自 TPM 1.2 時代的描述。TPM 2.0 在製造時寫入晶片、不可變更的秘密，正確來說是稱為「保證主種子（Endorsement Primary Seed）」的種子，EK 是依照固定程序（範本）從這顆種子導出的。只要從同一顆種子導出，就一定會得到相同的金鑰，因此即使重新產生，EK 實質上仍然是該 TPM 特有的金鑰。RSA 與 ECC 兩種 EK 都能導出，實機同時具備兩者也不罕見。這與理解本文主旨無關，可以略過不看。

不過，若直接把 EK 對外揭露，就能唯一識別出該台 PC，會造成隱私問題。因此實際情境中會使用AIK（Attestation Identity Key／證明用金鑰）。認證機構利用 EK 及其憑證，證明「這把 AIK 確實存在於真正的 TPM 之中」，並發行 AIK 憑證。由於可以針對不同對象使用不同的 AIK，因此能防止多個驗證方聯手追蹤同一台終端機。³

SRK（Storage Root Key／儲存根金鑰）是用來包裝（wrap）其他金鑰的父金鑰。TPM 可以把自己建立的金鑰加密後移到外部，而該金鑰只有在這個 TPM 上才能解密。這個處理過程稱為「包裝（wrap）」或「綁定（bind）」。² 也就是說，即使 TPM 內部的儲存空間很小，只要把加密後的金鑰放在外部儲存空間，實質上就能持有無數把金鑰。

PCR（Platform Configuration Register）是用來累加記錄開機時量測值的特殊暫存器。編號從 0 到 23，各自對應要量測的內容。⁹ 其重要特性是，無法直接寫入任意數值，只能透過稱為 Extend 的操作往前推進。Extend 是「把目前的值與新的量測值串接後取雜湊，作為新的值」這種單向操作，因此原理上不可能「事後只刪除不利的記錄」。數值會在重新開機時重置。³

另外，TPM 2.0 中也存在具有可重置屬性的 PCR（用於 DRTM 或應用程式用途）。不過 BitLocker 用於封印的 PCR（0・2・4・7・11）屬於靜態的測量啟動用 PCR，在重新開機之前不會重置。本文的說明皆以此為前提。

NVRAM 是不揮發的小型區域，用來保存憑證等資料。相較於 TPM 1.2，TPM 2.0 在演算法、加密、階層、根金鑰、授權、NVRAM 等各方面都有所改進。⁶

4. 測量啟動與 PCR ── 為什麼「開機狀態一變就打不開」

TPM 的另一根支柱是測量啟動（Measured Boot）。這裡是理解 BitLocker 行為的關鍵。

4.1. 「量測」究竟是在做什麼

在往下說明之前，先把「量測」這個詞具體化。這裡的量測，指的不是測量重量或溫度這類物理量。而是從接下來要執行的程式或設定資料的整段位元組序列，計算出雜湊值。雜湊值是一種「內容的指紋」，具有固定長度，且具備以下性質。

• 相同的內容，無論何時何人計算，一定會得到相同的值
• 只要內容差一個位元組，就會變成完全不同的值
• 幾乎不可能從數值反推出原始內容

舉例來說，用 SHA-256 計算 abc 會得到

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

而只差最後一個字元的 abd 則會得到

a52d159f262b2c6ddb724a61840befc36eb30c88877a4030b65cbe86298449c9

即使只差一個字元，數值也會全面改變，就算把兩個值放在一起比對，也看不出「內容很相似」的線索。用 PowerShell 的 Get-FileHash 就能計算任意檔案的 SHA-256，這種「指紋」的感覺可以親自動手試試看。

也就是說，「開機的量測值」指的是開機過程中執行的韌體・開機載入程式・組態設定各自的雜湊值。如果量測值與上次完全相同，就可以斷言「參與開機的軟體與組態與上次一模一樣」。反過來說，若開機載入程式遭到竄改，或是從別的作業系統開機，對應的量測值就一定會改變。這正是測量啟動的基礎。

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: 解密作業系統磁碟區
        BM->>T: 對核心・ELAM・開機驅動程式執行 Extend
        Note over BM,T: 在交出控制權之前先量測
        BM->>OS: 交出控制權並啟動 Windows
    else PCR 數值不同
        T-->>BM: 不回傳金鑰
        BM->>BM: 進入回復金鑰輸入畫面
    end

圖 3：測量啟動與 BitLocker 金鑰解除的流程

圖中之所以呈現「先解密才量測核心」的順序，是因為依照測量啟動的原則，要載入的東西一定在執行前先量測。整個連鎖是這樣的：Windows 開機載入程式在讀入核心前會先驗證其數位簽章，核心接著再驗證開機驅動程式・啟動檔案・ELAM。¹⁰ 如果等核心啟動之後才量測自己，量測就可以被省略，這樣就沒有意義了。

BitLocker 會在 TPM 內建立一把只有量測值符合預期時才能使用的金鑰。預期值是以系統磁碟的作業系統磁碟區、Windows 開機管理員啟動當下的狀態計算出來的。若從別的作業系統開機，或組態遭到變更，TPM 內的量測值就會改變，TPM 不會允許使用金鑰，加密的作業系統磁碟區也就無法解密。³

那麼，實際上會檢視哪些 PCR 呢？原生 UEFI 組態下，預設的平台驗證設定檔如下所示。⁹

在預設情況下，封印的對象是 PCR 0・2・4・11。不過，若支援安全開機狀態（PCR 7），則會改以 PCR 7 與 PCR 11 封印。⁹ 這是一個重要的差異。PCR 0/2/4 是韌體或開機管理員映像本身的雜湊值，因此每次更新韌體，數值都會改變，進而落入回復模式。相對地，PCR 7 量測的是「安全開機是否啟用、信任哪些金鑰」，只要簽署者相同，即使映像更新，數值也不會改變。Microsoft 也說明，若綁定 PCR 7，因韌體更新或映像更新而落入回復模式的可能性會降低。⁹

PCR 11 的用法有點特別，是一個有意思的巧思。設想的情境是：攻擊者保持被害者終端機原封不動（硬體與韌體都不變），只把作業系統磁碟替換成自己準備的內容。由於金鑰封印在原本的 TPM 上，換掉整台終端機沒有意義，重點在於持續使用被害者的 TPM。攻擊者會從被害者作業系統分割區的中繼資料取出已封印的 BitLocker 金鑰 blob，啟動自己控制的作業系統後呼叫 TPM API，試圖解除（unseal）該金鑰 blob。

之所以無法得逞，是因為Windows 在封印金鑰時，會把 PCR 11 的值設為 0，而開機管理員把控制權交給下一個開機載入程式（無論是合法還是不合法）時，一定會把 PCR 11 改為 1。攻擊者的作業系統開始運作時，開機管理員早已交出控制權，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["Microsoft 設計的<br/>安全處理器<br/>= Pluton"]

圖 4：TPM 的 3 種實作形態，以及其延伸出的 Pluton

• 獨立式 TPM（dTPM）是獨立半導體封裝的專用晶片。安裝在主機板上，優點是 OEM 可以獨立於系統本體進行評估與認證。⁶
• 整合式 TPM與其他元件封裝在一起，但以邏輯上獨立的專用硬體實作。⁶
• 韌體 TPM（fTPM）是在通用運算單元的信任執行環境（TEE）中，把 TPM 當作韌體來運作。⁶ 適合專用晶片不划算的小型・低耗電裝置。

Windows 對相容的 TPM 一律以相同方式使用。Microsoft 對於應該採用哪種實作方式不表態，並表示廣泛的生態系可以滿足各種需求。⁶ 也就是說，「因為是 fTPM 所以比較低階」這種說法並不成立。

在此基礎上，Microsoft Pluton 更進一步推進了整合形態。它是由 Microsoft 設計、矽晶合作夥伴製造、內嵌於 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 具有兩套韌體更新途徑的特色。除了可以像以往一樣透過 UEFI 膠囊更新，更新主機板 SPI 快閃記憶體上的韌體之外，還能透過作業系統更新動態載入新版 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，Microsoft 與 Google 也在 2017 年廢止了對以 SHA-1 為基礎的簽章・憑證的支援。TPM 1.2 的規格只能使用 SHA-1，因此無法跟上這股潮流。⁶

接下來是 Windows 11。最低要求包括：列在相容清單上的 64 位元 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 驗證設定檔確認。啟用安全開機的理由不應該是「因為是要求」，而是為了這項實際效益，這樣的理解才正確。

還有一點容易被忽略：TPM 2.0 不支援傳統模式或 CSM（Compatibility Support Module）模式的 BIOS。搭載 TPM 2.0 的裝置，必須把 BIOS 模式設定為「僅限原生 UEFI」，傳統／CSM 選項必須停用。⁶

這在實務上會造成一個麻煩的狀況：以傳統模式安裝的作業系統，一旦把 BIOS 模式改成 UEFI 就會無法開機。在變更 BIOS 模式之前，必須先用 MBR2GPT 工具，把作業系統與磁碟調整成支援 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（專用機種的最低要求） 兩欄構成。⁵

有 3 點需要注意。

• 並不是「只要是 LTSC 就不需要 TPM」。定義有放寬要求的是 IoT Enterprise，不含 IoT 的 Windows 11 Enterprise LTSC 與一般 PC 適用版本相同。由於名稱相似容易混淆，採購的授權究竟是哪一種，會直接影響結論。
• 非 LTSC 的 IoT Enterprise 依版本而異。21H2〜23H2 的 OPTIONAL 要求中，TPM 2.0 依然是必要條件（選用的只有安全開機），TPM 變成選用是從24H2 以後才開始。⁵
• 處理器要求是另外定義的。即使 TPM 與安全開機是選用，支援的處理器清單仍另有規範，請務必一併確認。⁵

而 Microsoft 自身也對選用放寬要求的意義提出提醒。在終端使用者之後可能自行安裝軟體的裝置上，降低要求時應審慎評估，不搭載 TPM 可能會影響終端使用者所需的軟體，這正是其主旨。⁵ 沒有 TPM，BitLocker 就無法把金鑰封印在開機狀態上，Windows Hello 的金鑰也只能退回軟體保護。請把判斷準則從「為了滿足要求才搭載」切換成「為了讓那台終端機獲得所需的保護才搭載」。

IoT Enterprise／LTSC 的選擇方式與授權採購的整體概觀，整理在「工業用電腦該安裝哪一種 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）。把它送到遠端，就能證明「是以哪種軟體與組態開機、如何初始化作業系統」。³ 量測會停在 Windows 的初始狀態，因此不包含正在使用哪些應用程式之類的隱私資訊。³

裝置健康狀態證明。Microsoft 的健康狀態證明服務，會為多家廠商的 TPM 發行 AIK 憑證，並解析測量啟動的資訊，轉換成「BitLocker 是否開啟」「安全開機是否開啟」「DEP 是否啟用」等單純的聲明。MDM（如 Intune）不需要自行解析複雜的 quote，就能利用這些聲明來隔離終端機或阻擋雲端服務的存取。¹³

Platform Crypto Provider。以 TPM 保護憑證的私密金鑰。可以在憑證範本中指定「使用 TPM 的 Platform Crypto Provider」，設定為不可匯出的憑證私密金鑰，無法從 TPM 中取出。若憑證要求輸入 PIN，TPM 的字典攻擊防護就會自動套用。³ 這正是第 10 章要談的開發者視角入口。

虛擬智慧卡。這項功能讓 TPM 表現得像「一張永遠插著的智慧卡」，省去購買與配發實體卡片與讀卡機的成本。³ 不過，Microsoft 目前建議虛擬智慧卡的使用者遷移至 Windows Hello for Business 或 FIDO2 安全金鑰。² 雖然作為既有資產仍然存在，但若是從現在開始設計，就不建議選用。

8. 確認自己 PC 的 TPM

接下來要開始動手操作。首先要掌握的是，Windows 10/11 會自動初始化 TPM 並取得所有權。因此通常不需要在 TPM 管理主控台（tpm.msc）中動手調整設定，Microsoft 也表示「多數情況下建議避免使用 tpm.msc 進行組態設定」。例外大概只有涉及 PC 重設或全新安裝的場景。¹ 順帶一提，TPM 管理主控台自 Windows Server 2019／Windows 10 版本 1809 起已結束積極開發。¹

8.1. 用 GUI 檢視

• 按 Win + R → 輸入 tpm.msc 即可開啟 TPM 管理主控台。可以看到 TPM 是否存在、狀態、規格版本、製造商。畫面分為「狀態」欄（是否處於可用狀態）與「TPM 製造商資訊」欄（製造商名稱・製造商版本・規格版本），規格版本是否為 2.0 是判斷是否符合 Windows 11 TPM 要求的依據。若終端機沒有搭載 TPM，或 TPM 已停用，畫面會顯示找不到相容 TPM（這種情況下的確認順序請見 8.4 節）。
• 在 Windows 安全性的 裝置安全性 → 安全處理器詳細資料 中，也能看到相同的資訊。從這個畫面可以進入 安全處理器疑難排解 → 清除 TPM（第 9 章會說明，但請勿貿然按下）。⁷

8.2. 用 PowerShell 檢視

若要檢查多台機器，用 PowerShell 較為可靠。TrustedPlatformModule 模組提供了一整套 Cmdlet。¹⁴

# 一次確認 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，就無法從作業系統以擁有者驗證值進行重設（清除）。
• 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)入門 ── 一次管理多台 Windows」。

此外，可以用 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 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間」中。

8.4. 「明明是 TPM 2.0 卻用不了」時的確認順序

光是確認完並無法解決問題，這裡把結果對應到下一步該做的事連接起來。判斷的起點是 Get-Tpm 的 TpmPresent 與 TpmReady。

檢視 UEFI 設定時的確認要點如下。多數機種的韌體 TPM 預設為停用，只要啟用就能解決問題。

• 項目名稱因廠商而異。Intel 平台上多半標示為 PTT（Platform Trust Technology），AMD 平台上多半標示為 fTPM（AMD fTPM / AMD CPU fTPM 等），有些機種畫面上根本不會出現 TPM 這個字。請不要因為「找不到 TPM 項目」就判斷為未搭載。
• 通常位於 Security 或 Advanced 之下。有時也會在 Trusted Computing、PCH-FW Configuration 之類的標題底下。
• 有些機種具備切換專用晶片（dTPM）與韌體 TPM 的設定。這種情況屬於 9.2 節「切換多個 TPM 會讓 BitLocker 進入回復模式」的範疇，一旦決定就不要再變更。⁷
• 確認傳統／CSM 模式是否已啟用。TPM 2.0 在 CSM 模式下無法運作。若原因出在這裡，切換到 UEFI 之前需要先執行 MBR2GPT（第 6 章）。⁶
• 在 UEFI 端啟用 TPM 後，別忘了暫停 BitLocker。這是會改變量測值前提的操作，與第 9 章開頭的因果表屬於同一類。

9. 實務上的疑難雜症 ── 回復金鑰畫面・清除 TPM・鎖定

在現場，TPM 成為話題的時候，大多是出了什麼問題的時候。這裡處理 3 個常見情境。

在此之前，先把本文開頭提出的問題──「為什麼光是更新 BIOS 就會被要求輸入 BitLocker 回復金鑰」──的直接答案，整理成因果表放在前面。這是「哪個操作，改變了哪個 PCR，結果會怎樣」的對應關係。⁹¹¹⁷

這張表的重點在於，上面 5 列與最下面一列是完全不同的事件。上面 5 列屬於「金鑰還在，但量測值對不上」的狀態，用回復金鑰通過後就會恢復原狀。最下面一列屬於「金鑰本身已不在手邊」的狀態，若沒有回復金鑰就無法復原。

作業系統磁碟遷移之所以歸類在最下面一列，是因為封印的金鑰位在原本那台 PC 的 TPM 之中。即使把磁碟插到別台 PC，金鑰也不會跟著過去。就算只是打算更換磁碟，實質上也等同於更換主機板。若有遷移計畫，請在作業前先暫停 BitLocker，或事先準備好回復金鑰。

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 啟動了別的作業系統<br/>變更了開機順序"| A4["開機組態的量測值改變了<br/>改回原狀後重新啟動"]
    Q1 -->|"沒有頭緒"| A5["連同攻擊的可能性一併調查<br/>收集記錄後用回復金鑰解除"]
    A1 --> R["確認回復金鑰的保存位置<br/>AD DS／Entra ID／Microsoft 帳戶"]
    A2 --> R
    A3 --> R
    A4 --> R
    A5 --> R

圖 6：被要求輸入 BitLocker 回復金鑰時的判別方式

韌體更新是進入回復模式的常見觸發因素。Microsoft 也建議，若組態中包含 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 中標示為「回復金鑰是唯一手段」的情境，指的是未經暫停就清除・更換的情況。反過來說，只要事先做好這一項準備，就能避開這個分支。

9.2. 想清除 TPM／不小心清除了 TPM

清除 TPM 會導致資料遺失。官方文件的警告很明確：清除後，與 TPM 綁定建立的金鑰，以及受該金鑰保護的資料（虛擬智慧卡或登入 PIN 等）都會全部遺失。對於由 TPM 保護・加密的資料，請務必事先準備好備份與復原手段。⁷

除此之外，實務上還有 3 個生效的注意事項。⁷

• 不要在未經管理員指示的情況下，清除非自己所有的終端機（公司或學校的 PC）的 TPM。
• 清除務必透過作業系統的功能（tpm.msc 或 Windows 安全性）進行，不要直接從 UEFI 清除。
• 若只是想暫時停止 TPM 運作，請使用「停用 TPM」，而不是清除。

清除後，Windows 會自動重新初始化 TPM 並重新取得所有權。⁷

這裡要強調的是，清除 TPM 並不等於資料清除（消毒）。清除所失去的是 TPM 內部的金鑰，磁碟上的資料本身連一個位元組都不會消失。BitLocker 的回復金鑰通常已經備份到 AD DS、Microsoft Entra ID 或 Microsoft 帳戶，因此持有它的人即使在 TPM 清除之後，仍然能夠解密磁碟區。

把終端機交給第三方時，主要的處理程序是磁碟資料的清除步驟：Windows 的「將此 PC 重設（同時清除資料）」、專用清除工具、加密清除、實體破壞等。清除 TPM 只是收尾動作而已。廢棄・讓渡的完整流程整理在「廢棄 Windows PC 前該做的事 ── 資料清除、帳戶解除、備份的實務檢查清單」中。

還有一個意外不太為人所知的陷阱。部分系統搭載多個 TPM，可以在 UEFI 中切換，但Windows 不支援這種組態。切換 TPM 可能導致 Windows 無法正確偵測新的 TPM，BitLocker 也會進入回復模式。若要切換，必須在切換後執行清除，並重新安裝 Windows。Microsoft 強烈建議，在搭載兩個 TPM 的系統上，一旦選定其中一個就不要再變更。⁷

9.3. TPM 被鎖定了

若持續輸入錯誤的 PIN，TPM 就會進入鎖定。在 Windows 的預設組態中，TPM 2.0 會在驗證失敗 32 次後鎖定，每 10 分鐘忘記一次失敗紀錄。即使處於鎖定狀態，只要在恢復間隔內保持電源開啟等待，就能脫離鎖定。² 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），但 Microsoft 強烈不建議這麼做。¹⁸

另外，即使沒有擁有者密碼，透過在 UEFI 中確認實體存在，仍然保留了執行 TPM 啟用・停用・清除等管理操作的途徑。¹⁸ 不過，這並不是能以非破壞方式立即解除鎖定的替代手段。若無法使用鎖定授權，基本做法是等待隨時間恢復（每 10 分鐘恢復一次），清除則是會失去所有金鑰的最終手段（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 提供者無法實現（或無法以同等程度實現）的特性有兩個。³

• 金鑰保護：可以在 TPM 內建立帶有使用限制的金鑰。作業系統不需要把金鑰複製到系統記憶體，就能在 TPM 內讀取並使用。可以設定為無法取出。TPM 建立的金鑰只存在於該 TPM 之中，該 TPM 也不會成為複製金鑰的來源。
• 字典攻擊防護：可以要求金鑰輸入 PIN 等驗證值，一旦猜測次數過多，TPM 就會回傳一定時間的拒絕。

10.2. 用 C# 撰寫的方式

從 .NET 可以用 System.Security.Cryptography 的 CNG 系列類別處理。首先，在 TPM 內建立金鑰、並設為無法取出的最小範例就是這樣（.NET 8／Windows）。

using System.Security.Cryptography;

var parameters = new CngKeyCreationParameters
{
    // 使用 TPM 的金鑰儲存提供者
    Provider = new CngProvider("Microsoft Platform Crypto Provider"),
    // 完全不允許匯出私密金鑰
    ExportPolicy = CngExportPolicies.None,
};

using var key = CngKey.Create(CngAlgorithm.Rsa, "KomuraSoft.DeviceKey", parameters);
using var rsa = new RSACng(key);

如此一來，私密金鑰就會在 TPM 內建立，不會出現在處理程序的記憶體中。不過，實際運用時還需要處理「第二次以後要開啟既有的金鑰」「以使用者為單位還是以機器為單位」「同時啟動時的競爭」等問題。下面的程式碼把這些都納入了考量。

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))
    {
        // 第二次以後開啟既有的金鑰(金鑰已持久化保存在 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 的理由，因此請務必明確指定為不可匯出。

另一個陷阱是使用者單位金鑰與機器單位金鑰的混淆。CngKey.Exists / CngKey.Open 的雙參數版本只會尋找使用者單位的金鑰。若只把建立端改成 CngKeyCreationOptions.MachineKey，而參照端維持不變，就會找不到既有的機器金鑰，每次都會「試圖以同名重新建立卻失敗」，陷入這種壞掉的狀態。請像上面的程式碼一樣，在建立・確認存在・開啟這 3 處都使用相同的範圍（CngKeyCreationOptions.MachineKey 與 CngKeyOpenOptions.MachineKey）。

之所以把 OpenOrCreateKey 抽成函式並加上 try/catch，也是有原因的。「先確認是否存在，再建立」對競爭情況很脆弱。若因應用程式多重啟動等原因，兩個處理程序同時看到 Exists == false 後都進入 Create，先建立成功的一方會贏，失敗的一方會因為「已有同名金鑰」而失敗。這種情況只會在第一次啟動時、而且很少發生，測試階段幾乎不會踩到。請從一開始就加入「輸的一方重新開啟贏家建立的金鑰」這樣的收尾處理。

不過，只有失敗原因是「已有同名金鑰」（NTE_EXISTS）時，才可以重新開啟。若把 TPM 無法使用、權限不足等其他失敗也導向同一條路徑，原本的原因就會被 Open 的「找不到金鑰」這個不同的例外取代，調查會因此走偏。上面的程式碼之所以在例外過濾器中篩選 HResult，原因就在這裡。

10.3. 設計時應納入考量的現實

根據官方文件的記述以及 TPM 的性質，有幾件事應該在實作前先決定好。

• TPM 並不快。它是專用的微控制器，或是在 CPU 保護模式下運作的小型處理器。² 金鑰產生耗時數秒並不罕見。請勿直接用 TPM 的金鑰加密大量資料。應以 AES 等對稱金鑰加密資料本身,再用 TPM 的金鑰保護該對稱金鑰,採取兩階段的做法。
• 金鑰產生・簽章不要放在 UI 執行緒上執行。上述的緩慢會直接表現成畫面凍結。
• 清除 TPM 後金鑰會消失。請以維修・更換主機板・重新安裝作業系統會導致金鑰遺失為前提,把重新登錄的動線(例如在伺服器端重新註冊終端機的步驟)納入設計。「金鑰消失就完蛋」這種設計,在現場一定會出事。
• 決定要以使用者單位還是機器單位管理。使用者單位的金鑰與設定檔綁定。若要從服務或排程工作使用,就需要機器單位(CngKeyCreationOptions.MachineKey),建立時需要系統管理員權限。別忘了在參照端也傳入 CngKeyOpenOptions.MachineKey。資料存放位置的思考方式,也可以參考「Windows 應用程式資料儲存位置怎麼選」。
• 光是設為機器單位,服務帳戶並不會自動就能使用該金鑰。MachineKey 決定的只是金鑰儲存的位置,誰能使用則是由附加在金鑰上的 ACL(安全性描述元)決定。管理員建立的金鑰,若嘗試用非管理員的服務帳戶開啟而卡在「存取被拒」,是常見的事故。處理方式是,用實際使用金鑰的當事人(服務帳戶)的權限建立,或是在建立時把服務的 SID 設定進安全性描述元(CNG 的 Security Descr 屬性)中允許存取。無論哪一種,都務必用實際的執行帳戶進行動作確認。
• 決定如何處理沒有 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、換機的判斷表
• 工業用電腦該安裝哪一種Windows ── Windows IoT Enterprise / LTSC 實戰指南
• 廢棄 Windows PC 前該做的事 ── 資料清除、帳戶解除、備份的實務檢查清單
• PowerShell Remoting(WinRM)入門 ── 一次管理多台 Windows
• 使用 Get-WinEvent 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間
• PowerShell 中安全處理認證資訊 ── 把明文密碼逐出腳本
• Windows應用程式資料儲存位置怎麼選 ── SQLite / JSON / 登錄檔 / Access 判斷表

相關諮詢領域

合同會社小村軟體承接 Windows 11 遷移所伴隨的硬體要求盤點、BitLocker 運用設計諮詢，以及包含以 TPM 進行終端機專屬金鑰管理在內的 Windows 業務應用程式委外開發。

• Windows應用程式開發
• 不具合調查・原因分析
• 既有資產活用・遷移支援
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

TPM 到底在做什麼？

一句話說，就是「讓私密金鑰在不流出晶片外的情況下也能使用的小保險箱」。在 TPM 內部產生的私密金鑰，只要設定得當，就完全不會離開晶片。應用程式或作業系統不會拿到金鑰本身，而是向 TPM 提出「請為這份資料簽章」「請用這把金鑰解密」的請求，只取回結果。除此之外，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 中、由 Microsoft 設計的安全處理器。從 Windows 的角度來看，三者的用法完全相同，Microsoft 也明確表示不會對該選擇哪一種實作表態。實務上的差異在於：專用晶片與 CPU 之間的匯流排可能成為實體攻擊的目標；fTPM 的行為會受 CPU 韌體更新影響；Pluton 的韌體可透過 Windows Update 更新等。若採購時可以選擇，對業務用終端機而言，以廠商的維護方針與韌體更新的提供情況作為判斷基準較為實際。

更新 BIOS 之後被要求輸入 BitLocker 回復金鑰，這是為什麼？

因為 BitLocker 的金鑰被封印在開機時的量測值（PCR）上，一旦量測對象改變，金鑰就無法解封，進而進入回復模式。韌體更新正是會改變 PCR 0 等量測值的操作。Microsoft 官方也建議，在包含 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），但 Microsoft 自身也建議在金鑰保存・簽章・加密用途上，使用層級更高的金鑰儲存 API。實作上，請把 TPM 處理速度較慢、清除 TPM 後金鑰會消失、以及在沒有 TPM 的環境下該如何回退等問題，一併納入設計考量。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。