Windows的TPM是什么 ── 图解「不外泄密钥的保险柜」与度量启动

「有一台PC装不了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不是「烧录的密钥」，而是「从种子派生的密钥」

微软的文档把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. 「度量」究竟是在做什么

在往下讲之前，先把「度量」这个词具体化。这里的度量，不是测量重量或温度那样的物理量。而是从即将执行的程序或配置数据的整个字节序列中计算出哈希值。哈希值是一种固定长度的「内容指纹」，具有以下性质：

• 相同内容无论何时、由谁计算，都必然得到相同的值
• 内容哪怕只差1字节，得到的值也会完全不同
• 几乎不可能从哈希值反推出原始内容

例如用SHA-256计算，abc会得到

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

而只有最后一个字符不同的abd会得到

a52d159f262b2c6ddb724a61840befc36eb30c88877a4030b65cbe86298449c9

即使只差1个字符，值也会全面改变，就算把两个值放在一起比较，也看不出「内容相似」的任何线索。用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度量的是「安全启动是否启用、信任哪些密钥」，只要签名者相同，即使镜像被更新，值也不会变化。微软也说明，绑定到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["微软设计的<br/>安全处理器<br/>= Pluton"]

图4：TPM的3种实现形态，以及处于其延长线上的Pluton

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

Windows对任何兼容的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具有的特点是固件更新有两条路径。除了照旧可以通过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，微软和谷歌也在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，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章所述。解锁方式有4种：仅TPM、TPM+PIN、TPM+启动密钥、TPM+PIN+启动密钥，其中仅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用度量值来保护其密钥。密钥仅在「隔离区域被初始化的启动过程阶段」可访问，普通内核无法使用它。³

度量启动与远程证明。TPM可以借助AIK，生成一份对当前度量值状态进行加密签名的声明（quote）。把它发送到远程，就能证明「以何种软件与配置启动、并初始化了操作系统」。³ 由于度量在Windows的初始状态就已结束，因此不包含使用了哪些应用之类的隐私信息。³

设备健康证明。微软的健康证明服务会为多家厂商的TPM签发AIK证书，解析度量启动信息，并将其转换为「BitLocker是否开启」「安全启动是否开启」「DEP是否启用」这类简单的声明。MDM（如Intune）无需自行解析复杂的quote，就可以利用这些声明来隔离终端或阻止其访问云服务。¹³

Platform Crypto Provider。用于保护证书的私钥。可以在证书模板中指定「使用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的有无、状态、规范版本、厂商。画面分为「状态」栏（是否处于可用状态）和「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行与最下面1行属于完全不同的事件。上面5行是「密钥还在，但度量值对不上」的状态，用恢复密钥通过后就能恢复原状。最下面1行是「密钥本身不在手边」的状态，没有恢复密钥就无法恢复。

操作系统磁盘迁移之所以属于最下面1行，是因为封印的密钥存在于原来那台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恢复密钥时的排查

固件更新是引发恢复模式的常见诱因。微软也建议：如果配置了包含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后，明钥保护器（clear key protector）会保留在卷上，因此无论是清除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的「将此电脑初始化(同时清除数据)」、专用的擦除工具、加密擦除、物理销毁等存储擦除步骤。清除TPM只是其中的收尾环节。报废・转让的完整流程整理在「Windows PC报废・转让检查清单」中。

还有一个不太为人所知的陷阱。部分系统搭载了多个TPM，可以在UEFI中切换，但Windows不支持这种配置。切换TPM可能导致Windows无法正确识别新的TPM，从而使BitLocker进入恢复模式。如果要切换，就必须在切换之后清除TPM并重新安装Windows。微软强烈建议：在搭载两个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)，但微软强烈不建议这样做。¹⁸

另外，即使没有所有者密码，通过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提供程序无法实现（或无法同等实现）的特性有两个。³

• 密钥保护：可以在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与确认恢复密钥所在位置作为一套操作来执行。
• 自家应用应使用CNG的Microsoft Platform Crypto Provider，而不是TBS。要明确指定不可导出，并把TPM的迟缓和清除时的丢失都纳入设计考虑。

相关文章

• Windows 10 停止支持后的现实解决方案 ── ESU・LTSC・更换设备的判断表
• 工业用PC应该安装哪种Windows ── Windows IoT Enterprise / LTSC 实践指南
• 报废 Windows 电脑前应该做的事 —— 数据清除、账户解绑、备份的实务检查清单
• PowerShell Remoting(WinRM)入门 ── 批量管理多台 Windows
• 用 Get-WinEvent 实务排查事件日志 ── 筛选速度决定调查时间
• PowerShell 中凭据的安全处理方式 ── 把明文密码逐出脚本
• Windows应用的数据存储位置怎么选 ── SQLite / JSON / 注册表 / Access 判断表

相关咨询领域

合同会社小村软件承接与Windows 11迁移相关的硬件要求盘点、BitLocker运维设计咨询，以及包括利用TPM进行设备专属密钥管理在内的Windows业务应用受托开发。

• Windows应用开发
• 故障调查・原因分析
• 既有资产利用・迁移支持
• 联系我们

参考链接

</content>

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

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