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）里改设置，微软也表示“在大多数情况下，建议避免用 tpm.msc 进行配置”。例外大概只有涉及重置 PC 或全新安装的场景。¹ 顺带一提，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）入门》。

此外，用 Get-TpmEndorsementKeyInfo 可以查看 EK 和证书的信息，用 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 域服务或 Microsoft Entra ID，个人则是 Microsoft 账户等。在组织中可以配置成把恢复密钥保存到 AD DS。³

如果恢复密钥界面已经出现，就从紧邻之前的操作来区分原因。PCR 是启动状态的记录。请把“记录变了”和“无法使用原来那颗 TPM 保护的密钥”当作两种不同的原因，再读下面的表。⁴¹¹⁵

上面 5 行是度量值或索要密钥的启动阶段与条件不符的情况。最后一行是无法使用绑定在原 TPM 上的密钥的情况。由普通变更导致的恢复模式，要么把配置改回去，要么用恢复密钥解锁。最后一行则是：既没有事先暂停、也没有恢复密钥的话就无法恢复。攻击者解锁密钥那一行说明的不是恢复步骤，而是设计上的防护。

系统盘迁移之所以归入最后一行，是因为被密封的密钥在原来那台 PC 的 TPM 里。把盘插到另一台 PC 上，密钥并不会跟过去。就算只打算换一块盘，实质上和更换主板是一回事。如果计划迁移，请在作业前暂停 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 -->|"从 U 盘启动了别的系统<br/>改了启动顺序"| A4["启动配置的度量值变了<br/>改回去并重启"]
    Q1 -->|"毫无印象"| A5["把攻击的可能性也纳入调查<br/>收集日志后用恢复密钥解锁"]
    A1 --> R["确认恢复密钥的保存位置<br/>AD DS / Entra ID / Microsoft 账户"]
    A2 --> R
    A3 --> R
    A4 --> R
    A5 --> R

图1：被要求输入 BitLocker 恢复密钥时的排查

固件更新是恢复模式的常见诱因。微软也提示，配置了包含 PCR 0 的配置文件时，应在固件更新前暂停 BitLocker。⁴ 反过来说，在安全启动配置正确、绑定到 PCR 7 的终端上，因固件更新掉进恢复模式的频率会降低。⁴ 支持新式待机的机型把 PCR 7 的度量列为徽标要求，只要 TPM 和安全启动配置正确，默认就会绑定到 PCR 7 和 PCR 11。⁴

有没有插入一次暂停，之后的工作量完全不同。暂停 BitLocker 后，卷上会留下明文密钥（clear key）保护程序，所以无论是清除 TPM 还是换成新的 TPM，都可以不输入恢复密钥直接启动（启动后恢复保护，就会针对新的 TPM 重新密封）。图1 中说“恢复密钥是唯一手段”，指的是没有暂停就清除或更换的情况。反过来说，只要多做一步事前准备，就能避开这个分支。

3.2. 想清除 TPM / 已经清除了 TPM

清除 TPM 会导致数据丢失。官方文档的警告非常明确。一旦清除，绑定 TPM 生成的密钥，以及用这些密钥保护的数据（虚拟智能卡、登录 PIN 等）都会全部丢失。对于用 TPM 保护或加密的数据，请务必准备好备份和恢复手段。⁵

即使确实需要清除，也要遵守以下条件。⁵

• 不要在没有管理员指示的情况下，清除不属于自己的终端（公司或学校的 PC）的 TPM。
• 清除一定要通过操作系统的功能（tpm.msc 或 Windows 安全中心）进行，不要从 UEFI 直接清除。
• 如果只是想暂时停止 TPM 工作，用“关闭 TPM”而不是清除。

清除之后，Windows 会自动重新初始化 TPM 并重新取得所有权。⁵

清除 TPM 与报废时的磁盘擦除是两件事

这里要强调的是，清除 TPM 不是数据擦除（sanitize）。清除失去的是 TPM 里的密钥，磁盘上的数据本身一个字节都不会消失。BitLocker 的恢复密钥通常已经备份到 AD DS、Microsoft Entra ID 或 Microsoft 账户，所以持有它的人在清除 TPM 之后照样能解密该卷。

把终端交给第三方时，主体是存储的擦除步骤：Windows 的“重置此电脑（同时删除数据）”、专用擦除工具、加密擦除、物理销毁等。清除 TPM 只是最后的收尾。报废与转让的完整步骤，整理在《Windows PC 报废与转让检查清单》。

不要随意切换多个 TPM

有些系统装有多个 TPM，可以在 UEFI 中切换，但Windows 并不支持这种配置。切换 TPM 后，Windows 可能无法正确检测到新的 TPM，BitLocker 会进入恢复模式。如果要切换，就必须在切换之后清除 TPM 并重新安装 Windows。微软强烈建议，在装有两个 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），但微软强烈不推荐。¹²

另外，即使没有所有者密码，仍然保留着通过 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 差在哪里

打理老 PC 时，还会碰到 TPM 1.2。两者的差别不止是“版本号变高了”。¹⁰

影响最大的是 SHA-1。NIST 在 2014 年就要求许多联邦机构迁移到 SHA-256，微软和谷歌也在 2017 年停止了对基于 SHA-1 的签名和证书的支持。TPM 1.2 的规格只能用 SHA-1，因此跟不上这个趋势。¹⁰

4.2. 安全启动的“支持”和“启用”是两回事

面向普通 PC 的 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”，讲的是面向普通 PC 的版本。Windows 11 IoT Enterprise 另外定义了面向专用设备的放宽最低要求，在 IoT Enterprise LTSC（以及非 LTSC 的 24H2 及以后版本）中，TPM 和安全启动都是可选的（Optional）。¹⁴ 在工业用 PC 和设备嵌入的现场，知不知道这一点，会让“这块主板上不了 Windows 11”的结论完全翻转。

官方的要求表由 PREFERRED（推荐）和 OPTIONAL（面向专用设备的最低）两列构成。¹⁴

有 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 实践指南》。

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（PC 厂商）把硬件和固件仔细整合起来，而 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 不是“烧录进去的密钥”，而是“由种子派生的密钥”

微软的文档把 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，就能防止多个验证方串通起来追踪同一台终端。³

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. 所谓“度量”到底是在做什么

在往下讲之前，先把“度量”这个词具体化。这里的度量不是测量重量或温度那样的物理量，而是对接下来要执行的程序或配置数据的整个字节序列计算哈希值。哈希值是一种像“内容指纹”的定长值，具有以下性质。

• 同样的内容，无论何时由谁计算，都一定得到同样的值
• 内容只要差 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 度量的是“安全启动是否启用、信任哪些密钥”，只要签名者相同，即使映像更新了值也不变。微软也说明，绑定到 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+启动密钥 4 种；官方的梳理是，仅 TPM 便利性最高，相应地安全性比要求附加身份验证要素的方式低。¹¹

另外，设备加密（自动启用 BitLocker 的机制）的前提条件在最近几年发生了变化。过去的条件是满足新式待机或 HSTI 的要求，并且没有可进行 DMA 访问的外部端口；但从 Windows 11 版本 24H2 起这个前提被取消，覆盖的终端更多了。¹⁶ 旧资料里“必须是支持新式待机的机型才能用”，在 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. 运行状况证明、证书、虚拟智能卡

度量启动与远程证明。借助 AIK，TPM 可以生成一份对当前度量值状态做了加密签名的陈述（quote）。把它发送到远端，就能证明“用哪些软件和配置启动并初始化了操作系统”。³ 度量止于 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 安全密钥。² 作为既有资产它还在，但如果是从现在开始做设计，方向上不应再选它。

9. 实现与采购：比较 dTPM、集成 TPM、fTPM 和 Pluton

9.1. 不要把实现的差异直接当成保护能力的高下

由于“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"]

图6：TPM 的三种实现形态，以及作为其延伸的 Pluton

• 分立式 TPM（dTPM）是独立半导体封装的专用芯片。它装在主板上，优点是 OEM 可以把它与系统本体分开评估和认证。¹⁰
• 集成 TPM 与其他组件放在同一封装内，同时作为逻辑上隔离的专用硬件来实现。¹⁰
• 固件 TPM（fTPM）是在通用计算单元的可信执行环境（TEE）中以固件形式运行 TPM。¹⁰ 适合小型、低功耗设备上专用芯片不现实的场景。

只要是兼容的 TPM，Windows 对它们一视同仁。微软对 TPM 该用哪种方式实现不表态，并称广阔的生态系统能满足各种需求。¹⁰ 也就是说，并不存在“因为是 fTPM 所以低一等”这回事。

9.2. Pluton：CPU 集成与固件的更新途径

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 的特点是固件有两条更新途径。既可以照旧用 UEFI 胶囊更新来更新主板 SPI 闪存上的固件，也可以通过操作系统更新动态加载新的 Pluton 固件。流程是：系统启动时用 SPI 闪存上的固件初始化，Windows 启动过程中再加载（如果有的话）通过 Windows Update 获取的最新版。¹⁷ 发现 TPM 固件漏洞时，有可能不必等 PC 厂商发布 BIOS 更新就拿到修复，这在实务上是很值得庆幸的特性。

采购时不要用“专用芯片所以好”“fTPM 所以差”下结论，而要确认厂商的维护方针和固件更新的提供情况。判断轴不只是实现方式，还要看在继续使用该终端的整个期间内能否更新。

10. 面向开发者：用 CNG 保护密钥，并设计复用、权限与恢复

当自研应用出现“想把许可证密钥绑定到终端”“想用终端特有的客户端证书连接服务器”“想让配置文件中的机密值只能在这台终端上解密”这类需求时，TPM 是很有力的选项。

10.1. 用 CNG，而不是 TBS

Windows 提供了底层 API TBS（TPM Base Services）。它是跨应用程序集中管理 TPM 访问的系统服务，以基于 RPC 的 API 形式提供，并根据调用方指定的优先级协作式地调度 TPM 访问。¹⁸

如果目的是密钥的保管、签名、加密和持久化，微软推荐使用比 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 应用的数据保存位置怎么选》。
• 仅仅改成按计算机，服务的账户还是用不了这把密钥。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 恢复的优点。¹³⁴

面向普通 PC 的 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、更换设备的判断表
• 工业用 PC 应该装哪种 Windows——Windows IoT Enterprise / LTSC 实践指南
• Windows PC 报废与转让检查清单
• PowerShell Remoting（WinRM）入门——批量管理多台 Windows
• 用 Get-WinEvent 实务排查事件日志——筛选速度决定调查时间
• PowerShell 中凭据的安全处理方式——把明文密码逐出脚本
• Windows 应用的数据保存位置怎么选

相关的咨询领域

小村软件有限公司承接与 Windows 11 迁移相关的硬件要求盘点、BitLocker 运维设计咨询，以及包含用 TPM 做终端专属密钥管理在内的 Windows 业务应用受托开发。

• Windows 应用程序开发
• 故障排查与原因分析
• 现有资产复用与迁移支持
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

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 中、由微软设计的安全处理器。从 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 的环境下如何回退这几点纳入设计。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。