【可信计算】第十次课：TPM密码资源管理（二）

这一部分相对一第九次课，老师的PPT中多了密钥相关的部分

• TPM的一个最强大的功能就是：应用程序可以把密钥安全地保存在硬件设备中。TPM可以生成密钥，也可以导入在外部生成的密钥，它支持对称和非对称密钥，因为TPM设备的存储资源有限，应用程序经常需要安全地将密钥换入换出TPM，这时TPM可以被认为是一个密钥缓存。
• 密钥可以被看作TPM中的一种实体，也可以看作是被专门定义的TPM对象。它通常作为组织架构中的核心组成部分出现，很多时候我们也可以称上次课讲到的三种组织架构为密钥**组织架构。
• 包含密钥的组织架构在访问时会遇到相应的安全控制方式：包括口令、增强的授权策略、密钥复制限制和密钥用途限制。

密钥使用命令

• TPM2_Create和TPM2_CreatePrimary可以通过模板创建所有类型的密钥。
• TPM2_Load(用于加密的私钥)和TPM2_LoadExternal(用于公钥或者明文私钥)可以将密钥加载到TPM中。
• TPM2_ContextSave和TPM2_ContextLoad用于将密钥换入换出TPM缓存。- TPM2_FlushContext用于删除TPM中的密钥。TPM2_EvictControl可以让一个密钥持续存在与TPM中或者删除一个持续存在的密钥。
• TPM2_Unseal，TPM2_RSA_Encrypt，和TPM2_RSA_Decrypt使用加密密钥完成相关操作。
• TPM2_HMAC，TPM2_HMAC_Start，TPM2_SequenceUpdate，和TPM2_SequenceCompete使用对称签名密钥和HMAC算法完成相关操作。
  TPM2_Sign是一个通用的签名命令，TPM2_VerifySignature用于验证数字签名。
• TPM2_Certify，TPM2_Quote，TPM2_GetSessionAuditDigest，TPM_GetTime是用于对认证数据签名的特殊命令。具体来讲，TPM2_Certify可以实现一个密钥签名另外一个密钥（密钥的名称）。这样一来，TPM就可以作为一个证书授权机构，使用自己的密钥认证证书相关密钥的属性。

密钥生成器

TPM最强大的能力是，它能产生密钥并将相关的秘密信息安全地保存在硬件中。密钥生成器基于TPM自己的随机数发生器，它不依赖任何外部的随机源。因此它消除了由较弱的软件随机数生成器或者不充足的熵值带来的弱点。

为了保护对称密钥，TPM内部会形成一个天然的层次化组织架构，这也TPM可信计算中组织架构名称的由来。在组织架构中，存在一个顶层父密钥，即主密钥，它们没有父节点。

主密钥和种子

主密钥的创建命令使用易于理解的命名方式TPM2_CreatePrimary。TPM1.2中有一个和TPM2.0主密钥相同的密钥：根存储密钥（SRK），这个密钥会一直存在于TPM中。TPM2.0中主种子控制主密钥的生成，它允许有无限多个主密钥，虽然这些主密钥并不一定一直存在于 TPM中。这并不是因为TPM的永久性存储空间有限，而是因为只要控制了种子，就可以重新生成主密钥。

TPM1.2在只有一个密钥的情况仍然可以工作的原因有两个。首先，它只有一个密钥算法和一个密钥大小用于加密密钥，那就是RSA-2048。然而TPM2.0中支持多种密钥算法和多种密钥大小。其次，TPM1.2只有一个密钥组织架构：存储组织架构。TPM2.0有三种组织架构，每一种都至少有一个根节点。

主密钥种子

TPM利用主密钥种子实现有限的非易失性存储空间支持数量不限的根密钥。

三个组织架构的每一个都和一个主密钥种子关联，分别是：背书主密钥种子，平台主密钥种子，和存储主密钥种子。这些种子一直存在于TPM设备中。它们就是密钥生成函数输入的秘密信息。当TPM创建一个主密钥时，它使用主密钥种子和一个公共模板来生成密钥。密钥模板包含了所有的密钥配置信息：密码算法和密钥长度，密钥的policy，密钥的类型（签名，加密等等）。调用者还可以在模板中添加自己的独有数据。该独特数据在模板的公钥区域中添加。

密钥生成函数KDF

密钥生成函数是固定的，相同的输入可以生成相同的输出。对于相同的种子，相同的密钥模板总是会产生相同的密钥。用户通过改变密钥模板中的独特数据，可以创建无限多个主密钥。

当TPM创建好一个主密钥后，密钥就存储在TPM的易失性内存中。这时候用户有两种选择。通过TPM2_EvictControl将有限数量的主密钥转到非易失性的内存空间。剩下的主密钥继续保存在易失性内存中。

如果所需的主密钥数量多于TPM可以保存到持续性存储空间和易失性存储空间中的密钥数量，可以选择性地将密钥从易失性内存中清除，或者先将非易失性存储空间中的密钥移动到易失性存储空间，然后再清除。因为密钥种子是永久性的，所以密钥永远不会丢失。

如果调用者知道完全公开的密钥模板，TPM就可以在需要的时候重新创建一个完全一样的密钥。进一步讲，如果重新创建的密钥是RSA密钥，那这个过程可能需要很长时间。如果重新创建的密钥是椭圆曲线，AES，或者HMAC密钥，创建的过程就会非常快。

在TPM1.2中，有一个背书密钥和与这个密钥相关的TPM厂商签名过的证书。他们被存储在非易失性内存中，在最终的用户使用包含TPM设备的系统时，它们也就同样拥有了这个背书密钥的证书，证书和密钥通常被存储在TPM的NVRAM中。在TPM2.0中，用户可以拥有多个密钥/证书对。如果不想浪费持续性存储空间，那应该怎么办呢？

一个可能的同时也是TPM厂商期望的解决方法是：让TPM生产商使用背书密钥种子生成几个背书主密钥和相应的证书，密钥使用标准算法集和广为人知的模板。其中的一种密钥及其证书，比如流行的RSA-2048被存储到持续性内存中。厂商可以将剩下的密钥清除，但是保存相应的证书。

TCG的基础设施工作组已经定义了一些背书主密钥的模板。RSA模板使用RSA-2048，SHA-256，和AES-128。ECC模板使用NIST-P256曲线，SHA-256，和AES-128。这两种模板使用相同的授权策略，这个授权策略要求知道背书组织架构的口令。

模板的独有数据部分是空的。密钥属性fixedTPM和fixedParent都为真，也就是背书密钥被期望的那样，不能被复制。userWithAuth和adminWithPolicy被设定固定值。密钥的类型是restricted decryptkey：

假设用户想要一个不同的主密钥。他可以将TPM厂商预置在TPM中的密钥清除，然后自己选择算法重新生成一个主密钥。因为密钥的种子没有变化，并且用户重新生成密钥的时候使用的模板与TPM厂商使用的相同，所以用户得到的密钥和TPM厂商之前生成的密钥相同。用户可以把密钥的公钥部分当作TPM厂商证书列表的索引。这个证书可以存储在一个公共的服务器上。这样用户就可以方便的访问证书并开始使用。这种可重复的密钥生成方式允许TPM厂商在生产TPM时就预先生成许多密钥及其证书，但是不用将所有的密钥都存储到非易失性内存中。可在最终的用户需要的时候重新生成。

一旦种子被修改，主密钥就永远不能再重新生成了，TPM中所有基于这个种子的密钥都被认为是无效的。种子被修改也意味着所有厂商生成的所有证书都将没有意义。TPM厂商为一个新的TPM背书密钥生成证书非常困难，所以修改背书组织架构的种子将受控于平台组织架构，这里的平台组织架构通常是指OEM厂商。这也就意味着最终的用户很难修改这个种子。

从另一方面讲，只要用户在密钥模板中的随便输入一些独有数据，他就可以创建和TPM厂商完全没有关系的，自己独立的背书密钥，可以在特定的场景下使用这个方法。

应用案例：多个主密钥

用户可以拥有多个主存储密钥作为密钥组织架构的根节点。但是这些密钥不能全部存储在非易失性内存中。如果用户使用大家熟知的模板创建密钥，他可以在需要的时候重新创建这些密钥。TPM命令如下：

• TPM2_NV_Read：从TPM的NV区域中读取密钥模板。TPM厂商可能会事先配置几种模板（比如说，一个RSA和一个ECC），这些模板和厂商配置的证书相匹配。用户也有可能有公司级别的模板。
• TPM2_CreatePrimary：需要选择模板。
• TPM2_EvictControl：可以选择性地将密钥配置成持续存在于TPM中。尤其是对于RSA密钥来说，这样就能节省重新生成密钥的时间（重新生成这种密钥很费时间）。当然密钥也可以留在易失性内存种，每次上电以后重新生成它们。

密钥的持续性

用户可以通过TPM2_EvictControl命令将一个密钥有易失性内存转移到非易失性内存中，密钥可以在两个上电周期之间保持加载状态。通常情况下，我们只希望有一小部分主密钥，可能是一个组织架构一个，被转成持续性的，这样就可以省去重新生成密钥的时间，从而提升性能。背书，存储，和平台组织架构下除主密钥以外的其他密钥也可以被设置成持续性的。一个典型的应用案例是，在系统启动初期时硬盘不可用，但是这时候需要一个密钥。另外一个应用场景就是在资源受限的平台上，比如说嵌入式控制器，它可能没有外部的持续性非易失性的存储空间。NULL组织架构下的密钥都不能被设置成持续性的。它们在重启后被清除。虽然只有有限数量的密钥可以被设置成持续性的，但是TPM可以处理理论上无限多的密钥。因为应用程序将TPM当作密钥缓存来使用。

密钥缓存

对于不是主密钥的其他密钥来说，TPM就像是一个密钥缓存。具体来说，TPM2_Create命令创建一个密钥后，使用这个密钥的父密钥加密，然后向调用者返回加密过的密钥。用户会将密钥存储在TPM之外，可能是硬盘中。当用户需要使用这个密钥时，他必须使用TPM2_load密令将密钥加载到它的父密钥下。使用完成以后，用户可以使用TPM2_FlushContext命令将密钥从TPM内存中清除。这个使用过程与主密钥不同，主密钥没有父节点，他被创建以后会暂时保留在TPM中。一个典型的硬件TPM可能会有5-10个密钥位置（槽，key slots）：密钥槽就是密钥可以加载到的TPM内存空间。TPM管理系统负责将密钥换入换出密钥缓存。

密钥的句柄与名称

TPM授权参数中并不包含密钥句柄，授权使用的是名称。原因来自于密钥缓存和密钥换入换出操作。一个平台可能有大量的应用软件相关的密钥存储在磁盘上，它们可能通过用户的句柄来识别。但是这样会导致句柄的数量远远超过TPM密钥槽的数量。当管理系统重新加载一个密钥后，它可能会得到一个不同的handle，这个handle可能是和TPM密钥槽的空闲状态相关的，而不是用户初始的handle。因此，中间件必须替换用户handle。如果授权数据中包含了handle信息，那中间件替换handle将会导致授权失败。

TPM2.0通过将名称添加到授权数据中来解决这个问题，名称就是密钥公钥部分的摘要值。TPM管理系统可以修改密钥的handle，但是不能改变密钥的名称。

密钥授权访问控制

TPM对密钥做了硬件保护，相对于软件生成的密钥，在安全性上有很大的提高，但是它仍然在此基础上提供更加强大的密钥访问控制功能。一个软件生成的密钥经常通过使用口令做访问控制来保护密钥。比如说，一个密钥可能会用口令来加密。这种保护的强度与口令本身的强度一样，所以这个密钥很容遭受线下的暴力攻击。也就是说，一旦攻击者拿到了加密过的密钥，解密这个密钥就变成了破解用于加密它的口令。密钥的所有者不能阻止一个高频率尝试口令的攻击方法。并且这种攻击可以被并行化，可以利用不同的机器同时使用不同的口令来实施破解。云服务已经让这种攻击变得非常容易了。

密钥访问控制

TPM针对软件生成的密钥做了两方面的改进。

• 当密钥离开TPM时，它会被一个强度很高的父密钥加密。此时攻击者需要破解一个强度很高的密钥而不是一个口令。
• 当密钥被加载到TPM中时，它还会受到字典攻击防护逻辑的保护。每一次攻击者尝试授权密钥失败时，这个行为就会被记录下来。当失败的次数达到一定预置值时，TPM就会阻止密钥授权，并保持一段事先配置好的时间。这将很可能大大降低攻击者实施攻击的频率。这种频率限制机制可以保证即使破解一个很弱的口令也要耗费比破解软件密钥长得多的时间，因为软件的密钥没有尝试频率限制。

密钥销毁

• 密钥的销毁非常困难，因为通过软件生成的密钥可能被复制过多份，存储在不同的地方。但是TPM中的密钥有父密钥或者本身就是主密钥，通过销毁父密钥或者主密钥种子，就可以确保这些密钥被彻底销毁。
• TPM有三种持续性的组织架构（背书，存储，平台）和一个易失性的组织架构（空组织架构）。每一个架构都有它独有的主密钥种子。把主密钥种子擦除后，就可以阻止在相应的阻止架构下重新创建主密钥，当然这是一个影响重大并且很少做的操作。擦除主密钥可以阻止所有它的子密钥被加载到TPM中。这样任何属性配置为必须存在于TPM中的密钥也都被认为是销毁了。

密钥组织架构

一个组织架构可以被想象成由一个父节点密钥和子密钥，或者说是祖先和后代组成的层次化结构。所有的父密钥都是存储密钥，也就是说这些密钥都是用于加密它们的子密钥的。因此这些存储密钥用于保护它们的子密钥，当子密钥被存储到TPM安全的硬件边界之外时，父密钥能够提供保密性和完整性。这些存储密钥的用途因此受到限制，他们不能用于通用的数据解密操作，这样会泄漏子密钥的私密信息。

在组织架构最顶端的终极父密钥就是主密钥。子密钥可以是存储密钥，这种情况下它可以有自己的子密钥。子密钥也可以是非存储密钥，这种情况下它们只能是叶子密钥，而不能拥有自己的子密钥结点。

密钥类型及其属性

每一个密钥在创建时都会设置自己的属性。密钥属性包括以下部分：

• 密钥用途，比如签名或者加密。
• 密钥类型，对称或者非对称，以及相关的算法。
• 和密钥复制相关的限制。
• 和密钥用途相关的限制。

密钥复制属性

密钥复制是指将一个密钥从一个组织架构下拷贝到另外一个地方（组织架构）。这个密钥可以成为另外一个父密钥的子密钥。目的组织架构或者父密钥可以在相同或者不同的TPM中。主密钥不能被复制，它们对于一个TPM的一个组织架构来说是固定的。

密钥复制的初始作用是密钥备份。如果一个密钥被永久地锁定到一个TPM中，但是这个TPM或者TPM所在的主板损坏了，这个密钥也就永远的丢失了。
第二种应用案例就是在多个设备之间共享密钥。一个用户的签名密钥可以在他的笔记本，平板和手机之前复制。

TPM1.2有一个和密钥复制类似的过程叫做密钥迁移。从字面意义上看，迁移的言外之意就是一个密钥经过迁移之后只存在于目的为止，而原来的位置已经没有这个密钥了。但是实际上并不是这样的。密钥迁移完成之后，密钥仍然存在于原来的位置。基于这个原因，TPM2.0将这个名字修改成了更加准确的复制。

TPM2.0的密钥有两个控制复制的属性。在极端情况下，一个密钥可以被锁定到一个TPM的一个父密钥下，永远不能被复制。相反的极端情况是，一个密钥可以随意地被复制到相同或者不同TPM的另外一个父密钥下。

控制密钥复制属性的定义如下：

• fixedTPM：如果密钥的这个属性被设置，这个密钥就不能被复制了。
• fixedParent：如果密钥的这个属性被设置，这个密钥就不能被复制到不同的父密钥下。这相当于密钥被锁定到一个父密钥下。

这两个布尔属性一共有如下四种组合：

• fixedTPM为真，fixedParent为假。TPM不允许这个配置组合存在。因为fixedTPM已经表明密钥不能以任何形式被复制，这样fixedParent为false又暗示密钥可以复制到不同的父密钥下，这就自相矛盾了。
• fixedTPM和fixedParent都为真，表示这个密钥不能以显式或隐式的方式被复制。
• fixedTPM为假，fixedParent为真，表示一个密钥不能显式地被复制。因为它被锁定到一个父密钥下。但是如果它的父密钥被复制了，这个密钥会被隐式地被复制。
• fixedTPM和fixedParent都为假，表示一个密钥可以以复制组或者复制根的方式被复制。如果它是一个父密钥，那它的子密钥也将跟它一起被复制。

受限制的密钥

受限制的签名密钥：受限制的签名密钥主要用于对TPM的认证数据结构签名。这些结构包括平台配置寄存器（PCR）引用，一个正在被认证的TPM对象，一个针对TPM时间的签名，或者是针对一个审计摘要的签名。签名主要作用于摘要上，但是签名验证者想要确保这个摘要不是由外部的伪造数据计算而来，然后发送给TPM来签名。比如说，一个“引用”就是一个针对一组PCR值得签名，但是真正的签名过程实际上是针对这组PCR值的摘要来做的。一个用户可能对任意PCR做摘要，然后使用一个非限制性的密钥来签名这个摘要。之后这个用户还可以声称这个签名值就是一个“引用”。但是，一个可信赖第三方会发现这个密钥不是限制性密钥，所以不会相信这个声明。因此，一个限制性的密钥可以保证这是针对一个由TPM自己产生的摘要产生的签名。

受限制的解密密钥实际上是一个存储密钥。这种密钥只用于解密特定格式的数据，包括用于验证一个数据结构的完整性校验值。只有这样的密钥才可以作为父密钥去创建和加载子密钥对象，或者是去激活一个证书。这些操作为解密的结果增加了一些限制。比如说，加载密钥并不会返回解密的结果（而是一个密钥的handle）[我自己的理解是，加载了密钥，返回特定的handle，所以才会只能有特定的功能]。

一个不受限制的密钥可以用于通用的解密操作，给它提供相关的加密数据它就会返回解密后的结果（作为一个加解密模块来用）。如果这个密钥被允许用作存储密钥，它就可以解密一个子密钥的私钥并返回给调用者。如果这个密钥可以被用于隐藏数据，它不需要检查unseal授权就可以返回被隐藏的（sealed）数据。

上下文管理和加载

加载密钥需要向TPM提供一个加密过的密钥和一个已经加载的父密钥。TPM使用父密钥解密子密钥并将解密后的密钥存储在易失性的密钥槽中。

上下文管理包含将一个已经加载的密钥的上下文保存到TPM之外，然后将保存的上下文加载到TPM中。当一个密钥被保存时，它会被一个由组织架构秘密信息派生的对称密钥加密，这个对称密钥叫做组织架构证据。当密钥被加载时，TPM使用这个对称密钥来解密。