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

「沒辦法升級到 Windows 11」「更新 BIOS 之後被要求輸入 BitLocker 回復金鑰」「不想讓應用程式的私密金鑰被帶出這台電腦」。這些看起來各自獨立的諮詢，只要弄清楚 TPM 扮演的角色，就能一併理清。

TPM 是專責產生、保管與使用加密金鑰的安全處理器。它既不是讓加密變快的零件，也不是會自動攔下病毒的零件。本文先給出確認與處理的步驟，之後再說明金鑰保護與測量啟動的機制。¹

1. 先講結論：把 TPM 的兩項工作分開

前者的「不讓金鑰外流」，意思是不把無法匯出的私密金鑰本身交出去。後者的「釋放金鑰」，意思是讓被封印的機密資訊只在條件相符時才能使用。把「用金鑰進行運算」和「解除封印」分開來看，後半段的圖就比較容易讀懂。²³

量測到的開機狀態也會用於健康狀態證明。不過這與金鑰的封印、釋放是不同的處理。TPM 會產生一份對目前量測值簽章過的報告（quote），再由服務與 MDM 評估其內容。詳細內容在 8.3 節說明。³

PCR 是把開機時載入的程式碼與設定的雜湊值逐層累加起來的記錄。BitLocker 會把金鑰綁在這份記錄上，因此韌體或開機設定一旦改變，就可能要求輸入回復金鑰。另一方面，清除 TPM 或更換主機板時，問題不在量測值，而在於原本那顆 TPM 裡的金鑰再也用不到了。⁴⁵

變更 TPM 設定之前，請先確認回復金鑰放在哪裡，以及有哪些復原手段。清除 TPM 不是一般的例行檢查，而是可能失去金鑰與受保護資料的操作。包含暫停 BitLocker、變更後重新啟用保護在內的完整步驟，整理在第 3 章。⁵

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 34 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 先確認狀態：把存在、就緒與規格版本分開

要確認的有三件事：有沒有 TPM、Windows 能不能使用它、規格版本是不是 2.0。請把「查看狀態」與「變更設定或清除」分開。首先要掌握的是，Windows 10/11 會自動初始化 TPM 並取得所有權。因此通常不需要在 TPM 管理主控台（tpm.msc）裡動設定，Microsoft 也表示「在大多數情況下，建議避免用 tpm.msc 進行組態設定」。例外大概只有與電腦重設或全新安裝相關的場合。¹ 順帶一提，TPM 管理主控台自 Windows Server 2019 / Windows 10 1809 版起已結束積極開發。¹

2.1. 從圖形介面查看

• Win + R → 輸入 tpm.msc 就會開啟 TPM 的管理主控台，可以看到有沒有 TPM、狀態、規格版本與製造商。畫面分成「狀態」欄（是否處於可用狀態）與「TPM 製造商資訊」欄（製造商名稱、製造商版本、規格版本），而規格版本是不是 2.0，就是判斷 Windows 11 的 TPM 要求時的依據。在沒有裝 TPM 或 TPM 被停用的電腦上，畫面會顯示找不到相容的 TPM（這種情況下的確認順序在 2.4 節）。
• 在 Windows 安全性的 裝置安全性 → 安全性處理器詳細資料 也能看到相同的資訊。從這個畫面可以進入 安全性處理器疑難排解 → 清除 TPM（第 3 章會談到，但請不要隨手按下去）。⁵

2.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

請不要把範例輸出的數值直接當成自己電腦的設定，而要逐項閱讀下列項目。⁷

如果想用程式化的方式判斷規格版本是不是 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 可以查看背書金鑰與憑證的資訊，Get-TpmSupportedFeature 可以確認特定功能的支援狀況。解除鎖定用 Unblock-Tpm，重設 TPM 用 Clear-Tpm。⁶

2.3. 用命令列工具查看

tpmtool 是取得 TPM 資訊與進行診斷的標準工具。⁹

:: 顯示 TPM 的基本資訊
tpmtool getdeviceinformation

:: 收集 TPM 的記錄並放到目前的目錄
tpmtool gatherlogs

如果要連同 BitLocker 的狀態一起看，可以搭配 manage-bde -status 或 Get-BitLockerVolume。事件記錄這一側的調查步驟，整理在「使用 Get-WinEvent 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間」。

2.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 的切換設定。這種情況符合 3.2 節的「切換多個 TPM 會讓 BitLocker 進入回復模式」，所以一旦決定就不要再改。⁵
• 確認是否啟用了傳統／CSM 模式。TPM 2.0 在 CSM 模式下無法運作。如果原因出在這裡，切換到 UEFI 之前需要先執行 MBR2GPT（第 4 章）。¹⁰
• 在 UEFI 這一側變更 TPM 設定之前，要先確認回復金鑰的位置並暫停 BitLocker。這是會改變量測前提的操作，和第 3 章開頭因果表的處理方式相同。請把它歸在變更前的準備，而不是變更後的補救。

3. 故障處理：把回復金鑰、清除 TPM、鎖定分開

回復金鑰畫面、清除 TPM、PIN 鎖定，是三件不同的問題。請不要因為被要求輸入回復金鑰就去清除 TPM。清除是會失去金鑰的操作，要和一般的狀態確認、從鎖定中回復區分開來。

如果接下來要進行變更作業，請先確認回復金鑰的保存位置，再暫停 BitLocker。適用對象是 UEFI 更新、變更安全開機設定、清除 TPM、更換主機板。保存位置在組織裡是 Active Directory Domain Services 或 Microsoft Entra ID，個人則是 Microsoft 帳戶等。組織可以設定成把回復金鑰保存到 AD DS。³

如果回復金鑰畫面已經出現，就從前一個操作來區分原因。PCR 是開機狀態的記錄。請把「記錄變了」和「用不到原本那顆 TPM 所保護的金鑰」當成兩種不同的原因，再閱讀下表。⁴¹¹⁵

上面五列是量測值、或索要金鑰的開機階段與條件不符的情況。最後一列則是用不到與原本那顆 TPM 綁在一起的金鑰。一般變更所造成的回復模式，只要把組態改回去或用回復金鑰解除即可。最後一列則是在沒有事先暫停、也沒有回復金鑰的情況下就無法復原。攻擊者試圖解除金鑰的那一列，表達的不是復原步驟，而是設計上的防護。

系統磁碟的搬移之所以歸在最後一列，是因為被封印的金鑰在原本那台電腦的 TPM 裡。就算把磁碟插到另一台電腦，金鑰也不會跟著過去。即使打算只換磁碟，實質上也等同於更換主機板。如果預計要搬移，請在作業前暫停 BitLocker，或先把回復金鑰準備在手邊。

3.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

圖 1：被要求輸入 BitLocker 回復金鑰時的原因釐清

韌體更新是進入回復模式最常見的觸發原因。Microsoft 也建議，設定了包含 PCR 0 的設定檔時，要在韌體更新前暫停 BitLocker。⁴ 反過來說，在安全開機設定正確、綁定到 PCR 7 的電腦上，因韌體更新而掉進回復模式的頻率會下降。⁴ 支援 Modern Standby 的機種把 PCR 7 的量測列為標誌認證的必要項目，只要 TPM 與安全開機設定正確，預設就會綁定到 PCR 7 與 PCR 11。⁴

有沒有先暫停，後續的工夫會完全不同。暫停 BitLocker 之後，磁碟區上會留下明鑰這個保護裝置，所以就算清除 TPM 或換上新的 TPM，也能不輸入回復金鑰直接開機（開機後重新啟用保護，就會針對新的 TPM 重新封印）。圖 1 之所以寫「回復金鑰是唯一的手段」，講的是沒有暫停就直接清除或更換的情況。反過來說，只要多做一個事前準備，就能避開這個分支。

3.2. 想清除 TPM／已經清除了 TPM

清除 TPM 會導致資料遺失。官方文件的警告非常明確。一旦清除，與 TPM 綁在一起建立的金鑰，以及用那些金鑰保護的資料（虛擬智慧卡、登入 PIN 等）都會全部失去。對於用 TPM 保護、加密的資料，請務必準備好備份與復原手段。⁵

即使確實需要清除，也請遵守下列條件。⁵

• 不要在沒有管理員指示的情況下，清除不屬於自己的電腦（公司或學校的電腦）上的 TPM。
• 清除務必透過作業系統的功能（tpm.msc 或 Windows 安全性）進行，不要直接從 UEFI 清除。
• 如果只是想暫時停止 TPM 運作，請使用「關閉 TPM」而不是清除。

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

清除 TPM 與廢棄時的磁碟清除是兩回事

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

要把電腦交給第三方時，主體是儲存裝置的清除步驟：Windows 的「重設此電腦（同時清除資料）」、專用的清除工具、加密清除、實體破壞等。清除 TPM 只是最後的收尾。廢棄、轉讓的完整步驟，整理在「廢棄 Windows PC 前該做的事 ── 資料清除、帳戶解除、備份的實務檢查清單」。

不要隨意切換多個 TPM

有些系統搭載多顆 TPM 並可在 UEFI 中切換，但 Windows 並不支援這種組態。切換 TPM 之後，Windows 有可能無法正確偵測新的 TPM，BitLocker 就會進入回復模式。如果要切換，切換後必須清除並重新安裝 Windows。Microsoft 強烈建議，在有兩顆 TPM 的系統上，一旦選定其中一顆就不要再改。⁵

3.3. TPM 被鎖定了

PIN 連續輸入錯誤，TPM 就會鎖定。在 Windows 的預設組態下，TPM 2.0 會在驗證失敗 32 次時鎖定，並且每 10 分鐘忘記一次失敗。即使處於鎖定狀態，只要在回復間隔內保持開機等待，就能脫離鎖定。² 10 分鐘只是 Windows 的預設值，實際間隔請用該台電腦的 Get-Tpm 所回傳的 LockoutHealTime 確認（第 2 章）。與其慌張地反覆重新開機，放著不動反而可能比較快。

想立刻解除的話，就送出重設鎖定的命令。不過，擁有者密碼與鎖定授權並不是同一個東西。自 Windows 10 1607 版起，Windows 在佈建 TPM 時不會保留擁有者密碼（會設定一個隨機的高熵值之後丟棄）。¹² 如果依照「管理員手上有擁有者密碼」的前提來安排步驟，到了現場就會卡住。

取而代之的是鎖定授權（lockout authorization）。OSManagedAuthLevel 的預設值 5，在 TPM 2.0 中代表「只保留鎖定授權」。¹² 也就是說，預設狀態是「完整的擁有者密碼已經失去，但解除鎖定所需的授權還留著」，tpm.msc 的重設鎖定時間與 Unblock-Tpm 通常就是靠這個授權運作。雖然也有保留擁有者密碼本身的設定（在登錄檔把 OSManagedAuthLevel 設成 4），但 Microsoft 強烈不建議這麼做。¹²

另外，即使沒有擁有者密碼，仍保留了透過 UEFI 的實體存在確認來執行啟用、停用、清除 TPM 等管理操作的途徑。¹² 但這並不是能夠非破壞性地立刻解除鎖定的替代手段。在無法使用鎖定授權時，基本上是等待隨時間回復（每 10 分鐘回復一次），而清除是會失去所有金鑰的最後手段（3.2 節）。

另外，如果是必須明確輸入授權值才能重設的組態，一旦用錯誤的值嘗試重設，TPM 在 24 小時內都不會允許再次重設。² 請不要盲目地亂試。

另外，TPM 2.0 中也有不需要驗證值就能建立的金鑰，這些金鑰即使 TPM 被鎖定也能使用。BitLocker 預設的「僅 TPM」組態，即使 TPM 被鎖定也能啟動 Windows。²

4. Windows 11 的要求：把 TPM 2.0 與 UEFI、IoT 的條件分開

4.1. TPM 1.2 與 2.0 差在哪裡

處理老電腦時，還是會遇到 TPM 1.2。兩者的差距不只是「版本變高了」而已。¹⁰

其中影響最大的是 SHA-1。NIST 在 2014 年就要求多數聯邦機關遷移到 SHA-256，Microsoft 與 Google 也在 2017 年終止了對 SHA-1 簽章與憑證的支援。TPM 1.2 的規格只能使用 SHA-1，因此跟不上這股趨勢。¹⁰

4.2. 安全開機的「支援」與「啟用」是兩回事

一般電腦用 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，比較不容易掉進回復模式（第 7 章）。光是啟用並不會自動變成這樣，所以實際綁定在哪些 PCR 上，請用 manage-bde -protectors -get C: 的 PCR 驗證設定檔確認。不是因為它是要求，而是為了這個實際好處才去啟用，這樣的整理才正確。

4.3. 從傳統／CSM 轉到 UEFI，不要只改設定

另一個容易被忽略的，是 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 的裝置上也無法如預期運作。¹

4.4. IoT Enterprise 的例外：依版本類型與版本號判定

到目前為止的「Windows 11 就必須有 TPM 2.0」，講的是一般電腦用的版本。Windows 11 IoT Enterprise 另外定義了給專用裝置的放寬版最低要求，在 IoT Enterprise LTSC（以及非 LTSC 的 24H2 以後）中，TPM 與安全開機都是選用（Optional）。¹⁴ 在工業用電腦與設備內嵌的現場，知不知道這一點，會讓「這塊主機板裝不了 Windows 11」的結論整個翻轉。

官方的要求表由 PREFERRED（建議）與 OPTIONAL（給專用裝置的最低要求）兩欄組成。¹⁴

有三個注意事項。

• 並不是「只要是 LTSC 就不需要 TPM」。定義了放寬要求的是 IoT Enterprise，而 Windows 11 Enterprise LTSC（不含 IoT）與一般電腦用版本同等對待。因為名稱相似而常被混淆，但採購的授權是哪一種，結論就會不同。
• 非 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 實戰指南」。

5. 金鑰保護：不交出私密金鑰，只回傳處理結果

5.1. 和純軟體的金鑰保護差在哪裡

先想像一個沒有 TPM 的世界。如果只靠軟體保護私密金鑰，金鑰最後一定會在某個時點變成記憶體中的明文。因為要進行簽章或解密的運算，CPU 就必須讀取金鑰的值。也就是說，面對已經打進核心的惡意軟體，或是能實體讀出記憶體的攻擊者，原理上就藏不住。官方文件也明確指出，軟體式的金鑰保護「會遭受逆向工程攻擊，被分析出使用期間金鑰在記憶體中如何保存、又如何產生副本」。³

如果用 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

圖 2：只用軟體保護金鑰，與把金鑰交給 TPM 保管的差別

5.2. TPM 本身並不會監視病毒

這裡重要的一點是，TPM 是被動的（passive）。TPM 不會主動監視什麼，也不會攔下病毒。它只是一個接收命令、回傳回應的零件。¹⁰ 正因如此，要發揮 TPM 的價值，就需要 OEM（電腦廠商）細心地整合硬體與韌體，而 Windows 則是以此為前提來組建功能，形成這樣的架構。

5.3. 在 TPM 這一側限制 PIN 的猜測次數

另一根支柱是字典攻擊防護。TPM 所保護的金鑰可以設定 PIN 這類的驗證值。當驗證值的猜測失敗達到一定次數，TPM 就會拒絕後續嘗試並鎖定。在 TPM 2.0 中，這個行為由 Windows 設定。具體來說是驗證失敗 32 次就鎖定，每經過 10 分鐘忘記一次失敗。如果 320 分鐘內完全沒有失敗，記住的失敗次數就會歸零。²

「次數限制在硬體這一側」這個事實會發揮作用。如果失敗次數是由軟體計算，只要重新開機、把系統時鐘往回撥，或是把記錄次數的檔案還原到先前狀態，就能讓它失效。TPM 就辦不到這些。³ Windows Hello 的 PIN 即使只有 4 位數也能說比密碼安全，根據正是在這裡。

6. 內部各部件的職責：身分證明、金鑰保護、開機記錄

不需要一次記住所有縮寫。請依職責分開來讀：EK 與 AIK 負責身分證明，SRK 負責金鑰保護，PCR 負責開機記錄，NVRAM 是非揮發性的儲存區域。先用圖看過全貌，再說明各自的關係。

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

圖 3：TPM 的主要構成要素，以及金鑰的父子關係

6.1. EK 與 AIK：證明是真的 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 對外公開，就能唯一識別出這台電腦，造成隱私問題。因此在實際情境中會使用 AIK（Attestation Identity Key／證明用金鑰）。憑證授權單位會用 EK 與其憑證來證明「這把 AIK 確實存在於真正的 TPM 內」，並核發 AIK 憑證。由於可以對不同對象使用不同的 AIK，就能防止多個驗證者串通起來追蹤同一台裝置。³

6.2. SRK：加密後的金鑰也能放在外部儲存裝置

SRK（Storage Root Key／儲存根金鑰）是用來包覆（wrap）其他金鑰的父金鑰。TPM 可以把自己產生的金鑰加密後送出，而那把金鑰只有同一顆 TPM 才能解密。這個處理稱為「包覆（wrap）」或「綁定（bind）」。² 也就是說，並不需要只用 TPM 內部那一小塊儲存區域存放所有金鑰。把加密後的金鑰放到外部儲存裝置，只在原本那顆 TPM 上使用，就能處理大量的金鑰。「取不出私密金鑰」與「加密後的金鑰資料可以存到外部」兩者並不矛盾。

6.3. PCR 與 NVRAM：開機記錄與非揮發性儲存區域

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 各方面都有改善。¹⁰

7. 測量啟動：記錄雜湊值，在期望的開機狀態下釋放金鑰

就算能安全保管金鑰，要做到「不讓別的作業系統使用那把金鑰」，還需要使用條件。BitLocker 是靠把金鑰封印在測量啟動（Measured Boot）的記錄上來建立這個條件。以下依照「計算雜湊 → 記錄到 PCR → 釋放金鑰」的順序說明。³

7.1. 所謂「量測」到底是在做什麼

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

• 同樣的內容，不論何時由誰計算，都一定得到相同的值
• 內容只要差一個位元組，就會變成完全不同的值
• 實質上無法從數值還原出原本的內容

舉例來說，用 SHA-256 這種雜湊計算，abc 會得到

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

而只有最後一個字元不同的 abd 則會得到

a52d159f262b2c6ddb724a61840befc36eb30c88877a4030b65cbe86298449c9

即使只差一個字元，數值也會全面改變，把兩個值擺在一起比對，連「內容相近」這樣的線索都留不下來。PowerShell 的 Get-FileHash 可以計算任意檔案的 SHA-256，這種「指紋」的感覺可以自己動手試試。

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

7.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

圖 4：測量啟動與 BitLocker 釋放金鑰的流程

圖中之所以是「解密之後才量測核心」的順序，是因為依照測量啟動的原則，要載入的東西一律在執行前量測。Windows 開機載入程式會先驗證核心的數位簽章再載入，核心接著再驗證開機驅動程式、啟動檔案與 ELAM，形成這樣的鏈條。¹⁵ 如果等核心啟動之後才量測自己，量測就可以被略過，那就沒有意義了。

BitLocker 會在 TPM 內建立一把只有在量測值符合期望時才能使用的金鑰。期望值是以「從系統磁碟的作業系統磁碟區啟動 Windows 開機管理程式」這個時點來計算的。一旦從別的作業系統啟動或組態被改變，TPM 內的量測值就會不同，TPM 不會允許使用金鑰，加密過的作業系統磁碟區也就無法解密。³

7.3. BitLocker 使用的 PCR：0、2、4、11 與 7、11 的差別

那麼實際上會看哪些 PCR 呢？原生 UEFI 組態下的預設平台驗證設定檔如下。⁴

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

7.4. PCR 11：不允許在開機管理程式之後的階段索要金鑰

PCR 11 即使在使用同一台電腦的 TPM 時，也會限制能夠索要金鑰的開機階段。設想的情境是：攻擊者讓被害者的電腦維持原狀（保留硬體與韌體），只把系統磁碟換成自己準備的那一顆。由於金鑰封印在原本那顆 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 的金鑰。¹¹

8. Windows 中的用途：BitLocker、Hello、健康狀態證明的差別

Windows 的各項功能各自使用了 TPM 的不同性質。核心分別是：BitLocker 是依開機狀態釋放金鑰，Hello 是用裝置專屬的金鑰進行驗證，健康狀態證明則是回報量測值。請先看過用途的全貌，再讀需要的功能說明。

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 主要安全功能

8.1. BitLocker 與裝置加密

BitLocker／裝置加密。如第 7 章所見。解鎖方式有僅 TPM、TPM+PIN、TPM+啟動金鑰、TPM+PIN+啟動金鑰四種，官方的整理是：僅 TPM 便利性最高，但安全性比要求額外驗證因素的方式低。¹¹

另外，裝置加密（自動啟用 BitLocker 的機制）的前提條件在這幾年變了。過去的條件是必須滿足 Modern Standby 或 HSTI 的要求，且不能有可進行 DMA 存取的外部連接埠，但自 Windows 11 24H2 版起這些前提已經取消，適用的電腦變多了。¹⁶ 舊文章裡寫的「不是支援 Modern Standby 的機種就不能用」，在 24H2 以後並不適用。手邊的電腦是否適用，可以用 msinfo32.exe（系統資訊）的「裝置加密支援」確認。¹⁶

8.2. Windows Hello 與 Credential Guard

Windows Hello／Windows Hello for Business。以每台裝置各自佈建的金鑰，搭配 PIN 或生物特徵進行驗證。有 TPM 時由 TPM 保護金鑰，沒有時則用軟體保護。生物特徵只會在該台裝置上用於存取已佈建的金鑰，不會在裝置之間共用。³ 在有 TPM 的裝置上無法把金鑰複製到別處，因此可以得到即使認證資訊外洩，在其他裝置上也用不了的性質。

Credential Guard。這是把認證資訊的雜湊處理放到核心無法存取的隔離記憶體區域中進行的功能。這塊隔離區域會在開機過程中初始化並受到保護，Credential Guard 則使用 TPM，以量測值保護該區域的金鑰。金鑰只有在「隔離區域被初始化的那個開機階段」才能存取，一般的核心無法使用。³

8.3. 健康狀態證明、憑證、虛擬智慧卡

測量啟動與遠端證明。TPM 可以使用 AIK，針對目前量測值的狀態產生一份經過密碼學簽章的陳述（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 安全金鑰。² 作為既有資產它仍然留著，但如果是現在才要設計，方向上不會選它。

9. 實作與採購：比較 dTPM、整合式 TPM、fTPM 與 Pluton

9.1. 不要把實作的差異直接當成保護能力的高下

由於「TPM 晶片」這種說法很普遍，常讓人以為 TPM 一定是獨立的零件，但實作有三種。¹⁰

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"]

圖 6：TPM 的三種實作形態，以及其延伸的 Pluton

• 獨立式 TPM（dTPM）是獨立半導體封裝的專用晶片。它安裝在主機板上，優點是 OEM 可以和系統本體分開進行評估與認證。¹⁰
• 整合式 TPM 與其他元件放在同一個封裝內，但在邏輯上是以分離的專用硬體實作。¹⁰
• 韌體 TPM（fTPM）是在通用運算單元的信任執行環境（TEE）中，以韌體的形式執行 TPM。¹⁰ 適合小型、低耗電裝置上專用晶片不切實際的情況。

只要是相容的 TPM，Windows 都以相同方式使用。Microsoft 不對 TPM 該用哪種方式實作表態，並表示廣泛的生態系能回應各種需求。¹⁰ 換句話說，並不會因為是 fTPM 就低人一等。

9.2. Pluton：CPU 整合與韌體的更新途徑

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 的韌體漏洞被發現時，有機會不必等電腦廠商提供 BIOS 更新就先發布出來，這在實務上是很值得慶幸的性質。

採購時不要用「因為是專用晶片所以好」「因為是 fTPM 所以差」來決定，而要確認廠商的維護方針與韌體更新的提供狀況。判斷的軸線不只是實作方式，而是在持續使用那台裝置的期間內能不能更新。

10. 給開發者：用 CNG 保護金鑰，並設計重複使用、權限與復原

當自家應用程式出現「想把授權金鑰綁定到這台裝置」「想用裝置專屬的用戶端憑證連線到伺服器」「想讓設定檔中的機密值只能在這台裝置上解密」這類需求時，TPM 會是很有力的選項。

10.1. 使用 CNG，而不是 TBS

Windows 有一組低階 API 叫做 TBS（TPM Base Services）。它是跨應用程式集中管理 TPM 存取的系統服務，以透過 RPC 的 API 形式提供，並依照呼叫端指定的優先權協調地排程 TPM 存取。¹⁸

如果目的是金鑰的保管、簽章、加密與持久化，Microsoft 建議使用比 TBS 更高階的金鑰儲存 API。請先區分你是想直接操作 TPM，還是想保護應用程式的金鑰；若是後者，就從 CNG 使用。¹⁸

應該使用的是 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. 最小範例，以及重新開啟既有金鑰的實用範例

在 .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);
}

10.3. 程式碼的三個重點：禁止匯出、範圍、競爭處理

ExportPolicy = CngExportPolicies.None 是關鍵。這裡若維持預設值，就算用了 TPM，也可能變成金鑰可以被取出的設定。使用 TPM 的理由就是「金鑰不會外流」，所以請明確指定不可匯出。

另一個陷阱是搞混以使用者為單位的金鑰與以電腦為單位的金鑰。CngKey.Exists / CngKey.Open 的雙引數版本只會尋找以使用者為單位的金鑰。如果只把建立端改成 CngKeyCreationOptions.MachineKey，參照端卻維持原狀，就會找不到既有的電腦金鑰，每次都以「想用同一個名稱重新建立卻失敗」的方式壞掉。請像上面的程式碼一樣，在建立、存在確認、開啟這三個地方使用相同的範圍（CngKeyCreationOptions.MachineKey 與 CngKeyOpenOptions.MachineKey）。

把 OpenOrCreateKey 抽成函式並加上 try/catch 也有理由。因為「先確認存在再建立」很禁不起競爭。在應用程式被重複啟動等情況下，兩個處理程序都看到 Exists == false 之後才進入 Create，先建立成功的一方勝出，落敗的一方就會以「已經有同名的金鑰」失敗。這只會在第一次啟動時發生，而且機率很低，測試時幾乎踩不到。請從一開始就加上「落敗的一方重新開啟勝出者所建立的金鑰」這個收尾處理。

不過，可以重新開啟的只有失敗原因是「已經有同名的金鑰」（NTE_EXISTS）的時候。如果把 TPM 不可用、權限不足這類其他失敗也導向同一條路徑，真正的原因就會被 Open 的「找不到金鑰」這個不同的例外掉包，調查就會走偏。上面的程式碼之所以用例外篩選器限定 HResult，就是為了這個。

10.4. 維運設計：速度、金鑰遺失、ACL、沒有 TPM 的裝置

程式碼跑得起來，維運還沒完成。特別是，放置金鑰的範圍，與能使用金鑰的帳戶權限，是兩回事。請把速度與執行緒、送修後的重新註冊、存取權，以及未搭載 TPM 的裝置該怎麼處理都先決定好。

• TPM 並不快。它是專用的微控制器，或是在 CPU 保護模式下運作的小型處理器。² 產生金鑰花上數秒也不罕見。不要把 TPM 的金鑰直接用來加密大量資料。資料請用 AES 等對稱金鑰加密，再用 TPM 的金鑰保護那把對稱金鑰，做成兩層結構。
• 不要在 UI 執行緒上執行金鑰產生與簽章。上述的慢會直接表現成畫面凍結。
• 清除 TPM 金鑰就會消失。請以「送修、更換主機板、重新安裝作業系統時會失去金鑰」為前提，把重新註冊的動線（例如在伺服器端重新註冊裝置的步驟）納入設計。「金鑰一沒就沒救了」的設計，在現場一定會出問題。
• 決定要以使用者為單位還是以電腦為單位。以使用者為單位的金鑰會綁在設定檔上。如果要從服務或排程工作使用，就需要以電腦為單位（CngKeyCreationOptions.MachineKey），而建立需要系統管理員權限。也別忘了在參照端傳入 CngKeyOpenOptions.MachineKey。資料放置位置的思考方式，可以參考「Windows應用程式資料儲存位置怎麼選 ── SQLite / JSON / 登錄檔 / Access 判斷表」。
• 光是改成以電腦為單位，服務的帳戶仍然無法使用那把金鑰。MachineKey 決定的只有金鑰存放區的位置，誰能使用則由金鑰上的 ACL（安全性描述元）決定。用非系統管理員的服務帳戶去開啟系統管理員建立的金鑰，卡在「存取被拒絕」，是很常見的狀況。處理方式是：用實際要使用金鑰的身分（服務的帳戶）的權限去建立，或是在建立時把服務的 SID 以允許的形式設定到安全性描述元（CNG 的 Security Descr 屬性）。不論選哪一種，都請務必用實際的執行帳戶做過動作確認。
• 決定沒有 TPM 的環境要怎麼處理。是把它當成不符合要求而擋下，還是回退到 Microsoft Software Key Storage Provider 並接受「保護等級下降」。在混用環境中，實際上會採取「憑證範本優先使用 Platform Crypto Provider，同時也允許軟體提供者」這樣的做法。³
• 要不要幫金鑰加上 PIN，請慎重考慮。字典攻擊防護有效是優點，但 TPM 的鎖定是全域的。由於針對每一把金鑰分別管理失敗次數在技術上不切實際，驗證失敗一多，整顆 TPM 就會被鎖住。² 也就是說，自家應用程式的輸入錯誤，有可能連累同一台裝置上的 Windows Hello。
• 認證資訊本身該怎麼處理仍是另一個問題。不把它以明文放在腳本或設定檔中的設計，整理在「PowerShell 中安全處理認證資訊 ── 把明文密碼逐出腳本」。

11. 實務定石（判斷表）

12. 總結

理解 TPM 的出發點，是區分不交出私密金鑰卻能讓人使用與把開機的量測值當成金鑰的使用條件這兩件事。TPM 是被動的零件，由作業系統與韌體來使用它的功能。測量啟動會在執行前量測，而 BitLocker 所使用的靜態 PCR 在重新開機之前都無法把記錄改回去。³¹⁰

確認狀態時，要把 TPM 的存在、就緒狀態與規格版本分開。不要只憑 TPM 2.0 就判斷可以遷移到 Windows 11，請連 UEFI 與 CPU 等一併確認。安全開機的最低要求是「支援」，與啟用是兩回事。滿足綁定 PCR 7 條件的組態，有減少因韌體更新而觸發 BitLocker 回復的優點。¹³⁴

一般電腦用的 Windows 11 與 IoT Enterprise 的放寬要求要分開思考。TPM 為選用的只有 IoT Enterprise LTSC 與非 LTSC 的 24H2 以後，非 LTSC 的 21H2〜23H2 以及不是 IoT 的 Enterprise LTSC 並不同等對待。不要只憑實作方式的名稱決定高下，而要依需要的保護，以及更新與維護的提供狀況來選。¹⁴¹⁰

在維運上，請把變更前確認回復金鑰與暫停 BitLocker、變更後重新啟用保護串成一整套動作。清除 TPM 不是磁碟清除。開發時請使用 CNG 的 Platform Crypto Provider，除了禁止匯出之外，也要把金鑰的範圍、ACL、建立時的競爭，以及金鑰遺失後的重新註冊都設計進去。⁵¹⁸¹⁹

相關文章

• 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。