【可信计算】第九次课：TPM密码资源管理

TPM密码资源管理

TSS为上层应用调用TPM密码资源提供了多层接口，开发者可以根据自己的需要，按照规范要求调用这些接口来构建可信应用。但是，TSS作为一个控制TPM密码资源的微型操作系统，它需要通过对各种密码资源进行命名、定位、控制和调度，经过多年的演化，形成了一系列可信计算中独特的概念：实体（Entity）、命名（Name）、组织架构（Hierarchy）、索引（Index）、授权（Authorization）、会话（Session）、上下文（Context）。这些概念本质上都是从安全和效率的角度出发，以密钥为基础构建的一个复杂安全系统。

TPM资源实体（Entity）

一个TPM资源实体是在TPM内部可以通过句柄（handle）直接引用的内容。实体这个概念范围比较广，它更像是对TPM中出现的各种抽象概念的一个定义，比如TPM中的安全机制和业务会话都可被定义成实体。常见的资源实体类型包括：

• 非易失性实体：NVRAM索引；
  对象：密钥和数据；
  易变的实体：会话。TPM中的会话指为完成一次对资源的授权访问所需要的全部中介的总称。

永久实体

组织架构，字典攻击锁定机制，和PCR

永久实体指其句柄由TPM规范定义好，而且这些句柄不能被创建和删除。在TPM1.2中，PCR及其所有者是唯一的永久实体；根存储密钥（SRK）有固定的handle，但是它不是永久实体。在TPM2.0中，有更多的永久实体类型：三个固定的组织架构，一个临时组织架构，字典攻击锁定复位，保留的句柄，明文口令授权会话，和平台组织架构的NV开关等。

永久实体-固定组织架构

固定的组织架构。TPM2.0有三个固定的组织架构（平台，存储，背书），每一个架构都通过固定的handle来访问
TPM_RH_PLATFORM (0x4000000C)
TPM_RH_OWNER（0x40000001）
TPM_RH_ENDORSEMENT（0x4000000B）

访问固定组织架构需要被授权，它们每一个都有一个授权和访问策略。经过各自管理员的授权以后就可改变相应的组织架构（管理员被定义为知道相应组织架构）。组织架构的授权值和访问策略可以改变，但是不论我们如何引用一个组织架构，都是指向的同一个TPM资源实体。

固定的组织架构永远不能被删除，但是它们可以被自己的管理员或者平台管理员关闭。这三种组织架构可以包含相关的密钥链和数据，清除组织架构就能清除其中的密钥和 数据。

永久实体-临时组织架构

TPM2.0有一个叫做NULL的临时组织架构，它通过一个固定的handle来引用：TPM_RH_NULL（0x40000007）。这是一个非常特殊的组织架构，当TPM被用作密码协处理器时（向主机提供高效的密码运算服务，但是并不是可信服务），会利用到这个临时组织架构。临时组织的授权值和policy都是空的。

与固定组织架构类似，临时组织架构本身也是永久存在的，它不能被删除，但是和固定组织架构不同的是，它在TPM的每个加电周期里会被自动清除。有点类似于计算机内存中的固定系统数据。

永久实体-字典攻击锁定复位机制

字典攻击锁定机制有一个固定的句柄：TPM_RH_LOCKOUT（0x4000000A）。它同样有一个授权和policy。和之前介绍的三个固定组织架构一样，它的授权可以被自身的管理员修改。但是它是一个不包含密钥和对象的组织架构。当字典攻击触发锁定时，这个机制用于复位。它还可以用于清除TPM_RM_OWNER组织架构。通常情况下这个复位机制充当TPM存储组织架构的IT管理员。

示例：TPM可以被配置成输入口令失败5次之后将锁定这个用户24小时。锁定期间所有受到字典攻击保护的资源都不能被授权。用户需要让IT管理员相信这个锁定不是因为攻击，仅仅是因为密码输入错误。管理可以使用锁定授权复位失败计数器，这样一来用户就不需要等待24小时。

永久实体-平台配置寄存器（PCR）

TPM拥有大量的PCR，这些PCR可以通过索引来访问。根据特定平台可信计算规范的要求，PCR可能和一个或多种哈希算法相关。PCR也拥有授权值和策略。根据这些授权值和策略，可以改写PCR中存储的值。

授权值和策略可以用于通过PCR扩展（extend）来改变PCR的值。读取PCR的值不需要任何授权。PC客户端平台规定至少要有24个PCR。但是强制规定需要有一个PCR库（bank），PCR库指的是拥有相同哈希算法的一组PCR。这个PCR库可以在系统启动时被配置为使用SHA-1或者SHA-256算法。

由于PCR是永久实体，所以不存在删除和创建PCR的命令，用户只能改变PCR的值和属性。

口令授权会话：
TPM有一个会话也是永久性的，它就是口令授权会话，其句柄为TPM_RS_PW（0x40000009），用户可以使用这个句柄来进行对明文口令的访问授权。

平台NV访问开关：

• 句柄（0x4000000D）TPM_RH_PLATFORM_NV控制着平台组织架构的NV访问开关。当清除开关位后，对所有平台组织架构下的NV索引的访问都将被拒绝。
• 通常情况下，NV索引可以隶属于平台组织架构，也可以隶属于存储组织架构。存储组织架构自己就可以控制NV索引的开关，并不需要设置额外的开关来控制，但是在平台组织架构中，由于包含了更多的内容，所以需要设置独立的NV索引访问开关。平台组织架构常包含了如密钥、数据和NV索引等多项内容。很多情况下，我们需要独立的控制对这些内容的访问。
• 例如：
  平台的固件可以很方便地使用TPM作为存储启动参数的NV空间。即使是在TPM平台组织架构关闭的情况下，这个空间也必须保持可读。这样一来，独立控制就显现它的作用了。

NV索引：

• NVRAM就是TPM内部的非易失性存储空间。而NV索引则是访问这些空间的地址。用户可以对这些非易失性存储空间进行配置以便进行相关数据的存储。当配置完成后，这个空间就具备一个索引和一组属性，用户可以设置索引和属性的取值。
• 因为NVRAM索引具有更多的属性，TPM规范没有把它视为一种对象。读写NVRAM可以被单独控制。它们可以被配置成类似PCR，计数器或者位域。同时也可以配置成只能写一次的实体。第11章会详细介绍他们的属性和应用。
• NVRAM索引同时具有授权值和授权策略。NV索引的拥有者可以改变授权值，但是不能改变授权策略，授权策略一旦被创建就不能再修改。如果NVRAM与某个平台组织架构绑定，那么当平台组织架构被清除时相关的NVRAM索引也将被删除。

对象:

• 一个TPM对象就是指密钥或者和加密相关的数据。对象有一个公共的部分，并且“可能”还有一个私密的部分，比如一个非对称密钥对的私钥，一个对称密钥，或者是加密的数据。所有的对象都隶属于一个组织架构。TPM对象也都有相关的授权数据和授权策略。与NV索引相同的一点是，一个对象的访问策略一旦被创建后就不能再修改。
• 当创建TPM对象时，用户可以决定在使用这个对象的命令中，哪一些命令可以通过授权数据来使用，哪一些只能使用策略。但是需要特别提醒的是：对于有些命令来说，不管密钥创建的时候配置什么样的属性，它们都只能通过策略来授权执行。跟NVRAM索引相似，所有的TPM对象都隶属于以下四中组织架构中的一种：平台，存储，背书，或者NULL。当一个组织架构被清除时，它所有的对象也都将被删除。

非持续的实体:
一个非持续的实体会在TPM一个上电周期内清除。尽管可以通过TPM2_ContextSave来保存一个持续实体，但是TPM的密码学机制不允许重新上电之后加载之前保存的内容，这样就保证了它不断变化的特点。这种非持续的实体同样也被分类：

• 1、用于授权的会话，比如HMAC和策略会话。它们用于TPM实体的授权，命令和命令响应参数加密，和命令审计。
  2、哈希和HMAC事件序列实体。在完成对大数据块加密的时候，可能需要建立大量中间缓冲区。

与非持续实体相对应的是持续性实体，持续性实体会在TPM的上电周期之间保存。

持续性的实体:
一个持续性的实体就是一个组织架构的所有者要求TPM在上电周期之间保留在TPM中的对象。它与永久实体的不同之处是相关组织架构的拥有者可以清除持续性实体。因为TPM的持续性内存空间有限，所以我们应该节约使用持续性实体。

应用案例1：VPN密钥访问，在系统启动的早期阶段访问VPN时需要一个签名密钥。然而这个时候硬盘并不可用。如果应用将密钥保存在TPM的持续性存储空间内，系统在早期启动阶段可以立即使用密钥做密码学操作。

应用案例2：主密钥优化 一个主存储密钥通常作为一个密钥架构的根节点。密钥生成是密码运算中最为耗时的操作。当创建一个密钥之后把它存储到TPM的持续性空间中，这样就可以避免每次启动都重新生成密钥。主板制造企业通常会为TPM配置一个受限制的签名密钥。这个密钥用于标识这个平台的身份。如果主板损坏，然后TPM被替换到其他主板上，那么密钥将不能被加载使用（因为这里认为默认情况下密钥存储在与主板连接的磁盘上）。同时，一个企业的IT部门也希望给备用主板配置新的签名密钥。但是因为一个单纯的主板并没有硬盘，所以也没有办法存储密钥。这时IT部门可以将生成的密钥存储在TPM的持续性空间里，这要以来即使主板损坏了，TPM持续性空间存储的密钥仍然可以在替换的主板上使用。通常情况下，主存储密钥比如SRK，受限的主签名密钥比如身份认证密钥AIK，以及背书密钥是TPM中仅有的可持续性实体。

实体名称:
实体的名称是TPM2.0的一个新概念，它主要用于解决TPM1.2规范中出现的问题。极端严苛的安全分析表明，攻击者有可能在数据被传送到TPM的过程中截获这些数据。TPM需要阻止通过这种攻击篡改数据。但是TPM的存储资源有限，所以它允许一个密钥管理器在必要的时候将密钥加载到TPM或者由TPM导出。当密钥被加载到TPM之后，密钥就可以通过句柄来访问，这个句柄就是密钥所加载到的内存的速记符。因为应用软件可能不知道密钥管理器为了腾出额外空间将密钥的位置改变，所以密钥的handle也就没有防止修改的保护机制，并且恶意软件可以修改发送到TPM的数据来非法访问一个句柄指向的位置。

实体名称的作用：
通常情况下，上面描述的问题并不严重。但是如果用户将两个以上的密钥设置相同的口令，那么有可能通过修改句柄来非法访问另外一个具有相同口令的密钥。虽然在实际中很难实现，但是存在理论上的可能，为安全起见，TPM规范的制定者决定给每一个TPM实体赋予一个全局唯一的名字，比如当使用某个实体的进行HMAC授权计算时，就可以把实体的名称传给HMAC计算命令。这样一来，即使句柄发生变化也没有问题，因为实体的名称唯一而且不会变化。

有了实体名称后，在使用TPM命令进行HMAC授权时，会对TPM命令参数进行哈希，然后还会在计算中隐式地加上句柄相关的实体名称，即使命令参数中不包含实体的名称也是如此。在这种情况下，攻击者只能修改实体的句柄，但是不能修改实体的名称，因为修改会导致HMAC授权失败。

名称是一个TPM实体唯一的身份标示。对于永久性的实体来说（如PCR和组织架构），因为他们的句柄永远不会变，所以句柄就可以作为它们的名称。但是对于其他的实体（如NV索引和加载的对象）来说，它们的名称实际上是他们各自的公开数据的哈希值。TPM设备本身和API调用者在授权时会独立地计算实体的名称。

安全使用实体名称规则：
基于安全的考虑，在创建一个实体时就计算它的名称并合理存储是非常重要的。一种非常容易受到攻击的实现是提供一个由handle产生名称的函数，这个函数用handle作为输入，然后通过handle引用相关实体的公开数据并计算名称。这种做法将完全破坏使用名称来做HMAC运算的初衷。因为handle有可能被篡改，这样一来计算出的名称就有可能不是授权者预期的名称。

防止攻击者读取秘密信息：
用户可能定义一个普通的索引用于存储秘密信息。索引的policy保证只有用户自己可以读取秘密信息。然而在写入秘密信息之前，攻击者可能删除并使用不同的policy重新创建这个索引，这个policy允许攻击者可以读取索引位置的秘密信息。由于索引名称是通过索引公开部分的哈希计算出来的，所以攻击者最终会因为索引名称改变而授权失败。当用户试图去向新创建的索引位置写入秘密信息时也会授权失败，因为“事先通过哈希计算好的名称”将会用于写入命令的参数哈希值计算。暂时性和持续性实体的名称同样也是由其公共区域的摘要计算而来。实体的公共区域因类型不同而不同。

方便TPM密钥的安全管理：
当用户加载一个密钥时会收到TPM返回的handle。用户申请这个密钥的授权时会计算命令参数的HMAC值，HMAC值会隐式地包含密钥的名称（前文已经说过）。资源管理器可能在用户不知情的情况下将密钥导出，然后又重新加载到TPM中。需要知道的是，密钥重新加载到TPM后handle就会发生变化。资源管理器会将用户的handle替换成新的handle。这时授权仍然能够成功的原因是授权计算时并没有包含handle，而是名称。

防止攻击者通过handle替换密钥：
用户重新加载一个密钥后会收到一个handle。尽管攻击者可能通过使用相同的handle来替换用户的密钥，但是因为密钥的授权需要正确的名称，显然攻击者的密钥计算出的名称和原始的密钥不相同，所以攻击会因为HMAC授权不通过而失败。

总结：
TPM中的实体就是可以通过handle引用的TPM资源。永久实体在TPM的规范中具有固定的handle值，不但其handle不能被修改，而且自身也不能被删除或者重新创建。持续性实体可以通过用户选定的handle删除或者创建，它们能够在TPM上电周期之间保持，而非持续性实体则在TPM上电周期中被清除。对象是隶属于某一个组织架构下得实体，它们可能有一个私有区域，它们可以是易变的也可以被设置成持续性的。当对象被设置成可持续性时，它们就称作持续性实体。

一个实体的名称是实体唯一的身份标识。因为资源管理器在将实体换入换出TPM时，实体的handle会发生变化，所以实体的授权使用名称而非handle。

组织架构（hierarchy）

一个组织架构由一组相关的实体构成，它们被当作一个组来管理。这些实体包括永久对象（组织架构的handle），树根节点密钥。NV索引隶属于一个组织架构，但是不在树型组织中。除了其中的永久性实体，其他实体可以作为一个组被整体删除。

一个组织架构的密码学根节点是一个密钥种子，这个密钥种子是在TPM内部生成的一个很大的随机数，并且不会暴露在TPM安全边界之外。TPM使用这个种子来生成主要的密钥比如根存储密钥。作为组织架构根节点的密钥用于加密保护它们的子节点密钥。

三种持续性组织架构

TPM1.2只有一个组织架构，它代表所有者授权和根存储密钥。1.2版本的规范中只允许有一个SRK，它一直是一个存储密钥，并且是这个唯一组织架构的根节点。SRK是TPM在内部随机产生的，它一旦被擦除后就不能被重新产生。SRK也不能被换出TPM之外。子密钥可以被创建并使用SRK加密，这些SRK的子密钥可以用于加密它们自己的子密钥。但是总体上来说，整个密钥的组织架构都在所有者的控制下。这最终的导致TPM1.2只能有一个管理员。

• TPM2.0对持续性组织架构进行了扩充，以支持以下应用场景：
  将TPM用作一个密码协处理器。
  开关TPM的部分功能。
  隔离隐私敏感和隐私不敏感的应用。

• 这三种组织架构有如下的共同特性：
  每一个组织架构都有一个授权值和policy。
  每一个组织架构都有一个开关标志。
  每一个组织架构都有一个用于派生密钥和数据对象的种子。
  每一个组织架构都有可以包含子密钥的主要密钥。

TPM2.0规范增加了更多的灵活性。首先，组织架构主密钥不仅仅用于存储。它们还可以用作签名密钥。其次，主密钥不仅限于一个（理论上是无限多个），并且密钥使用的算法也多种多样（RSA，ECC，SHA-1，SHA-256）。第三，因为可以存在多个主密钥，所以不可能将它们全部存储在TPM内部。因此，与TPM1.2的SRK不同的是，主密钥是由秘密种子派生而来的。派生的过程是可重复的：也即相同的种子和密钥属性总是产生相同的密钥。除了将所有的主密钥存储起来，还可以选择需要的时候重新生成。所以本质上来说，种子是密码学的根。一个主密钥可以被换出TPM，保存上下文，并且还可以在一个上电周期内被重新加载，这样一来就可以省去重新生成密钥的时间。

各个组织架构有自己独立的授权控制（口令和policy），所以它们自然就可以有不同的管理员。TCG选择这三种组织架构，以及它们略有不同的操作是为了满足不同的应用场景，这个场景在组织架构的名字上也有所体现。

平台组织架构

平台组织架构被设计成由平台厂商控制，平台厂商的控制体现在平台上的系统启动早期运行的代码。平台组织架构是TPM2.0中的新概念。在TPM1.2中，平台固件不能确保TPM已经被打开了，平台固件开发者就不能借助TPM来完成一些安全相关的任务。

• 平台组织架构应用：UEFI安全启动
  当开启UEFI的安全启动特性时，平台固件需要验证一个RSA数字签名来验证软件的真实性。平台OEM会事先在TPM NV索引中存储一个公钥或者是一个可信公钥的哈希值列表。这个NV索引被设置成只有平台OEM可以更新它的内容。在启动过程中，平台固件会使用这个可信的公钥来验证签名。
  TPM在这个应用中有两个优点。首先，它提供了安全的公钥存储空间。其次，它提供RSA算法，所以不用软件实现。

平台组织架构在三个可持续性组织架构中的独有特性是，它在平台启动时就可以使用了，授权值被设置成空，让平台固件生成一个自己的授权值（policy可选）。与其他组织架构要求用户输入授权值不同的是，平台授权值是平台固件自己设置的。因此不需要将授权值存储到一个地方，代码本身就是授权值。

因为平台组织架构有它自己的使能开关标志，所以平台固件可以决定何时使能和失能这个组织架构。这样以来就可以满足平台固件和操作系统的独特的使用需求。

存储组织架构

存储组织架构被设计用于平台的所有者：企业IT组织或者个人终端用户。这个存储组织架构与TPM1.2中的是相同的。它有一个所有者policy和授权值，这两者是持续性的。这样设计的原因是它们被设置之后很少发生变化。

平台所有者可以关闭这个组织架构，并且不影响平台组织架构。这样一来即使平台所有者关闭了这个组织架构，平台固件仍可以照常使用TPM。但在TPM1.2中只有一个组织架构，关闭它就等于关掉整个TPM。与之类似的是，这个组织架构可以在不影响其他组织架构的情况下被清除（修改种子，删除持续性对象），存储组织架构主要用于非隐私相关的操作。

背书组织架构

背书组织架构是一个隐私树，用户在处理与隐私相关的任务时应该使用它。TPM和平台厂商可以认证这个组织架构下的主密钥是否受控于一个真实平台上的一个真实TPM设备。在TPM1.2中，一个主密钥可以是一个加密密钥，并且证书可以通过TPM2_ActivateCredential创建，TPM2.0有与之相同的身份激活命令。与TPM1.2不同的是，一个主密钥也可以当作一个签名密钥。创建和认证签名密钥是隐私相关的操作，因为它允许和一个独立唯一的TPM中的密钥相关。因为背书组织架构的目的是用于隐私相关的操作，它的使能开关位，policy，授权值也是独立于其他的组织架构的。它们受控于隐私管理员，当然这个管理员也有可能是终端用户。一个终端用户可以关闭背书组织架构，同时不影响TPM应用使用存储组织架构，平台软件也可以继续使用TPM。

隐私：

• TPM中的隐私保护是指远程组织或个人不能把收到的TPM数字签名信息同具体的TPM关联起来。为保护用户隐私，用户可以在不同的应用使用不同的签名密钥签名，攻击者很难把这多个签名同用户的身份关联起来。
• 隐私敏感主要应用于完全拥有并控制平台的家庭终端用户。在公司中，IT部门可能完全控制计算机，所以TPM的隐私保护特性显得没有那么重要。我们讨论的大部分情况是和远程（非法）关联相关，不涉及攻击者可以物理接触平台的情况。

确定平台的真实身份：

• 关联操作的要求是判定签名密钥来自一个唯一的，真实的TPM。如果密钥可以在另外的TPM中复制或者是用软件生成的，那相应的签名就不能被回溯到一个唯一的设备（对应一个唯一的平台拥有者）。
• TPM厂商可以生成一个背书原始种子，还会用这个种子产生一个或多个主密钥，同时还生成主密钥的证书。证书用于厂商证明密钥来自一个真实的TPM设备。平台的厂商也可能生成一个类似的证书。其他密钥则通过这个认证过的主密钥来认证。

激活证书：
TPM并不强制使用某一个证书格式，但是应该使用类似于X.509证书格式，证书包含证书提供者和密钥属性相关的信息。但是TCG的这个认证的过程有以下多个目标：

• 证书提供者可以确信它认证密钥的属性。
• TPM密钥证书的接收者不能确定多个密钥来自同一个TPM。
• 理论上证书授权机构有可能做非法关联，但是通常情况下我们认为这个私有的CA是可信的，不会这样做。在TPM1.2中，一个可以被激活的密钥被限制为一定是不可以迁移的身份认证密钥，并且只能用于对TPM产生的数据签名，而且一定是SRK的子密钥。TPM2.0规范在满足前面提到的两个设计目标的基础上，删除了这些限制。TPM2.0密钥的名称是密钥公共数据的摘要。名称完全可以做为密钥的身份。摘要包括公钥和密钥的属性。

主密钥是一个签名密钥：
如果一个主密钥是一个签名密钥，并且直接用于认证其他签名密钥，前面提到的关联操作就很简单，因为所有的签名都聚合到了一个证书上。可以看证书链的认证者就可以证明这个认证来自一个真实的TPM。证书链表明这个密钥是固定在一个特定的TPM设备中。正因为如此，背书组织架构下的主密钥通常是一个加密密钥而不是签名密钥。

主密钥是一个加密密钥：
如果主密钥是一个加密密钥，那生成子密钥证书过程就相对比较复杂，这个过程叫做证书激活。证书授权中心又被称作隐私保护CA，因为它是受信任的，它不会泄露任何跟它所认证密钥相关的信息。

证书提供者生成证书：

1. 证书提供者首先接收一个公钥和公钥的证书作为一个加密密钥。这个加密密钥通常来说是背书组织架构下的主密钥，这个主密钥的证书通常由TPM或者平台厂商颁发。
2. 证书提供者回溯主密钥证书直到它的根证书。通常情况下，证书提供者会验证这个加密密钥的确与一个已知兼容的硬件TPM绑定。
3. 证书提供者检查公钥并决定是否要颁发证书，以及所颁发的证书中应该写什么内容。在一个典型的应用案例中，证书提供者会办法颁发一个固定在TPM中的限制性密钥。
4. 证书申请者可能会试图修改公钥的属性。这种攻击是不可能成功的。
5. 证书提供者为密钥生成一个证书。

证书提供者安全发送证书：

6. 证书提供者生成一个秘密信息用于保护证书。通常情况下这个秘密信息是一个对称加密密钥，但是也可以是一个可用于生成加密或者完整性密钥的秘密信息。TCG并没有强制规定这个秘密信息的格式。
7. 证书提供者为KDF生成一个种子。如果第一步的加密密钥是RSA密钥，那种子就是一个简单的随机数，因为RSA密钥可以直接用于加密和解密。如果密钥是基于椭圆曲线的密钥，需要使用一个更加复杂的Diffie-Hellman协议。
8. 证书提供者使用TPM提供的公钥加密种子，只有TPM可以解密这个种子。
9. 种子用于TCG指定的KDF生成一个对称加密密钥和HMAC密钥。对称加密密钥用于加密第6步的秘密信息，HMAC密钥用于提供秘密信息的完整性。隐秘但是很重要的一点是，KDF也会使用第1步中加密密钥的名称。
10. 加密过的秘密消息和它的完整性校验值将以证书数据块的方式发送到TPM中。同时，加密过的种子也将被发送。

• TPM收到的信息：
  用秘密消息保护的证书。
  一个用密钥加密过的秘密消息，加密密钥是由种子和加密密钥的名称生成的。
  一个用TPM的加密密钥加密过的种子。

TPM解密证书：

1. 因为种子是通过TPM的加密密钥来加密的，所以TPM会解密，并且保证种子保留在TPM中。
2. TPM计算加密密钥的名称。
3. TPM使用和之前相同的TCG KDF结合名称和种子生成对称加密密钥和HMAC密钥。
4. 上述生成的两个密钥用于验证秘密信息的完整性，然后解密。
5. 此时如果攻击者修改了公钥属性就会被检测到。因为如果攻击者向证书颁发机构提供了不同于TPM的密钥，相应的名称就会不同，因此对称密钥和HMAC密钥就会不同，这一步也就会失败。
6. TPM返回秘密消息。

在TPM之外，用户可以使用这个秘密信息按照协商好的方法解密证书。最简单的情况是，把秘密消息当作一个对称解密密钥直接解密证书。

以上的协议使证书提供者相信只有满足以下条件时才能恢复证书：

• TPM拥有与加密密钥证书相对应的私钥。
• TPM的密钥与提供给证书颁发机构的密钥是同一个密钥。
• 隐私管理员应该控制背书密钥的使用，不管是作为签名密钥还是用于上述的激活证书的协议中。这样也就有效控制了它与其他TPM密钥的关联。

TPM隐私保护的设计要点：

• 平台拥有者控制着背书组织架构。平台的拥有者通常不能修改背书的种子，因为一旦修改种子，现有的TPM证书将失效，并且没有办法恢复。
• 用户可以使用模板中的随机数在背书组织架构生成其他的主密钥。用户通过以下方法彻底删除密钥：将密钥换出TPM，然后删除外部的副本并清除掉随机数。
• 当密钥用于签名（认证）一些数据时，认证命令响应数据中将包含一些隐私敏感的数据如：resetCount（TPM已经复位的次数），restartCount（TPM重启或者恢复的次数），以及固件版本。尽管这些值不直接映射到TPM，但是它们可以帮助攻击者实现非法关联。

隐私保护案例：检测两次可信声明之间的重启
一个认证服务器每隔一段时间就会轮询可信平台机器，用于验证PCR没有变化，或者验证新的PCR值是否可信。当可信平台重启时，这种认证可能会存在问题。在TPM1.2中，当可信平台已经进入到一个不可信的状态然后又重新启动，这时认证服务器没办法检测到重启，也就无法准确判断平台的可信性。在TPM2.0中，认证需要的数据中包含了启动次数信息。在这个过程中，需要混淆敏感信息，同时还要确保能够检测到重启次数，从而确定是否发生了重启。

• 检测步骤：

1. 周期性地执行TPM2_Quote命令。
2. 每一次Quote命令都返回一个TPM2B_ATTEST结构体。
3. quote包含TPM2B->TPMS_CLOCK_INFO->resetCount。
4. resetCount通过一个基于密钥名称的对称密钥来混淆。
5. 对于相同的密钥来说，如果resetCount值不变，那么混淆后的resetCount值也不变。
6. 对于不同的密钥，混淆后的值不会相同，这样就阻止了攻击者进行的非法关联。

空组织架构

与三个持续性的组织架构相对应的是易变组织架构，叫做空组织架构。空组织架构与三个持续性的组织架构类似。它也可以拥有主密钥，并由主密钥派生子密钥。
它的几个不同的属性如下：

• 授权值是空口令，policy是永远不能满足的空值。并且它们不能被改变。
• 不能被关闭。
• 有一个可以生成密钥和数据对象的种子。这个种子不是持续性的，它会在每次重启后由不同的值重新生成。

空组织架构下的基本密码运算：
在空组织架构下，TPM可以用作一个秘密协处理器。此时，TPM主要使用外部生成的密钥或者不需要秘密信息的算法进行密码运算。作为密码协处理器的主要功能包括随机数生成器，摘要和HMAC算法，对称和非对称加密操作。

摘要基本操作：
TPM2.0提供两种密码学摘要基本操作API。它们都具备算法灵活性，允许在调用函数的时候选择哈希算法。相对简单但是灵活性稍差的方法是TPM2_Hash。调用者输入消息，TPM返回相应的摘要。消息的长度受限于TPM输入缓冲区的大小，通常情况下是1-2KB。另外一种API可以实现对大文件的哈希。API分别为TPM2_HashSequenceStart, TPM2_SequenceUpdate, 和TPM2_SequenceComplete。

应用案例1：对大文件做哈希
在这个应用案例中，我们假设TPM的输入缓冲区大小为2KB。用户希望使用SHA-256算法对一个4KB的文件做哈希。用户使用TPM做哈希是因为在软件层面没有实现SHA-256哈希算法。用户使用后一种序列式的操作命令是因为文件大于2KB。步骤如下：

1. 执行TPM2_HashSequenceStart并选择SHA-256算法。
2. 执行两次TPM2_SequenceUpdate，每一次输入2KB。
3. 执行TPM2_SequenceComplete来返回最终的结果。

这种API和TPM1.2中的类似，但是它有如下几方面的加强：

• 支持多种哈希算法。
• start函数返回一个handle。可以并发执行多个哈希操作。
• update函数不再限制输入大小是64的倍数。
• complete函数可以大于64字节。
• complete函数可以返回一个凭据，这个凭据可以用在限制性密钥进行的签名中。

应用案例2：存储登陆口令
什么是加盐操作
一个典型的口令文件存储经过加盐的口令哈希值。验证操作主要是对输入的口令进行加盐操作并作哈希，然后与存储的值相比较。因为上述的计算中没有包含秘密信息，这种方法经常会遭受针对口令文件的线下攻击。

在这个应用案例中，我们使用一个TPM生成的HMAC密钥。口令文件存储加盐口令的HMAC值。验证的过程主要是对输入的口令进行加盐操作并做HMAC计算，然后将结果与存储值比较。因为线下攻击者没有HMAC密钥，所以他们无法实施攻击。

安全存储登录口令：

1. 执行TPM2_Create，选择一个可以使用大家熟知的空口令的HMAC密钥（也叫做keyedhash对象）。
2. 执行TPM2_Load来加载HMAC密钥，或者也可以执行加载之后再通过TPM2_EvictControl来让密钥对象持续存在于TPM中。
3. 执行TPM2_HAMC来计算加盐的口令的HMAC值。

RSA基本操作：
有两个命令可以支持基本的RSA操作：TPM2_RSA_Encrypt和TPM2_RSA_Decrypt。这两个操作都需要一个已经加载的RSA密钥。它们都允许以下几种填充机制：PKCS#1，OAEP，和无填充。加载到TPM中的密钥的填充配置信息不能被覆盖。但是如果密钥的填充机制是空的话，调用者可以制定一种有效的填充方法。

TPM2_RSA_Decrypt是一个私钥操作。TPM在返回明文之前会验证授权信息，验证填充并去掉填充信息。

TPM2_RSA_Encrypt是一个公钥操作。必须制定一个消息和公钥，但是因为是公钥操作，所以不需要授权。TPM在加密操作之前会对明文做填充。

CRTM签名验证：

• 一个平台可能实现了CRTM更新机制。这个机制要求更新签名，因为一旦攻破CRTM之后整个平台就会不安全。但是通常情况下CRTM的代码和数据空间都有限。因此CRTM很愿意使用TPM来做签名验证。
• CRTM会使用一个可以直接加载到TPM的硬编码公钥数据块。密钥的填充机制为空。CRTM可以使用TPM2_RSA_Encrypt命令使用公钥来验证签名，填充机制设置为空。最终，CRTM只需要把命令的结果和更新的摘要做一些简单的对比就完成验证工作。

对称密钥基本操作：

• 使用TPM2_EncryptDecrypt命令可以实现对称加密解密操作。这个函数只能处理较小的数据块，这同样也是因为TPM的输入缓冲区大小有限。但是，这个API包含一个初始化向量输入，同时输出一个可以链接的值，所以大的数据块可被分部处理。
• 对于HMAC密钥来说，一个限制性的密钥有固定的模式。但是调用者可以指定对于非限制性的密钥的模式。
• 相关密钥必须是一个对称密码对象。它必须是经过授权的，并且所有的授权方式都是可用的。
• 对称密钥加密是一个敏感的话题。尽管TPM的运算速度不快，但是它由硬件保护的密钥远远比软件中的密钥安全。所以这个功能也有可能导致TPM受到进口管制，还可能引起相关政府机构的关注。正因为如此，PC客户端平台将这个命令列为了可选命令。

总结：
TPM有三个持续性的组织架构和一个空组织架构。平台组织架构被平台OEM使用，表现为启动初期的代码。即使用户关闭了其他的组织架构，平台OEM仍然可以依赖这个组织架构完成一些功能。存储组织架构受控于用户，它应用于隐私不敏感的场景。背书组织架构应用于隐私相关的操作。隐私相关的证书激活操作通常在背书组织架构下完成。空组织架构是易变的。会话，上下文，和序列对象都会使用这种组织架构。同时，在这个空组织架构下也可以创建一个完整的密钥树，它们在重新上电后会被清除。除去TPM的安全存储特性，它还可以用作一个秘密协处理器。它主要是使用TPM外部生成的密钥或者不需要秘密信息的算法做密码学操作。作为密码协处理器的主要功能包括随机数生成器，摘要和HMAC算法，对称和非对称加密操作。