接上文TPM分析笔记（九）TPM资源实体-句柄

一、TPM组织架构

上文阐述一个TPM2.0资源实体是TPM内部可以通过handle直接引用。

本质上TPM组织架构也是由一组相关的资源实体构成，它们被作为一个组来管理。这些实体包括永久对象（组织架构的handle），它将被作为一个树根节点的主要对象，树节点还有其它对象，如密钥。另外NV索引隶属于一个组织架构，但是它不在树型组织中。除去永久性实体，其他实体可以作为一个组被整体删除。

每个hierarchy的密码学根节点是一个种子，这个种子是由TPM生成的一个很长的随机数（如果是非对称密钥，由TPM筛选素数），并且TPM不会将它暴露在TPM安全边界之外。TPM使用这个种子来生成主要的对象，比如根存储密钥。这些作为组织架构根节点的密钥用于加密它们的子节点密钥。

每一个组织架构都有一个相关的校验值（proof value），这个校验值可以被独立生成或者由种子派生。TPM使用这个校验值来确保一个向TPM提供的值是之前由TPM产生的。通常情况下，TPM会用校验值派生出一个HMAC密钥，然后用对TPM内部产生的数据做HMAC。之后数据会被送到TPM之外，当这些数据再次被送到TPM时，TPM会验证HMAC来保证数据真实性，这个就是TPM Ticket功能。

一个组织架构可以是持续性（TPM上电周期之间保持）的或者易变的（重启后消失）。每一个组织架构都有不同的应用场景：用于平台厂商，用户，隐私相关的应用，以及临时性的需求。

1.1 三种持续性组织架构

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

TPM2.0将持续性组织架构扩展到三个来支持以下应用场景：

• 将TPM用作一个密码协处理器。
• 使能或者失能TPM的一部分功能。
• 隔离隐私敏感和隐私不敏感的应用。 这三种组织架构有如下的共同特性：
  1、每一个组织架构都有一个授权值和policy。
  2、每一个组织架构都有一个使能标志。
  3、每一个组织架构都有一个用于派生密钥和数据对象的种子。
  4、每一个组织架构都有可以包含子密钥的主要密钥。

主密钥在某种程度上类似于TPM1.2中SRK。你可以创建一个使用SHA-1算法的RSA-2048主密钥用作存储密钥，它就相当于SRK。

但是，TPM2.0规范增加了更多的灵活性：

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

因为各个组织架构有自己独立的授权控制（口令和policy），所以它们自然就可以有不同的管理员。TCG选择这三种组织架构，以及它们略有不同的操作是为了满足不同的应用场景，这个场景在组织架构的名字上也有所体现。接下来我们将结合一些预期的应用案例来详细介绍。

1.1.1 平台hierarchy

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

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

平台组织架构在三个可持续性组织架构是最独特的。平台hierarchy意在处于平台制造商的控制之下，平台hierarchy在重启时是使能的，平台授权值被设定为一个零长度的口令，策略被设定为一个不可满足的策略，这在hierarchy中是独特的。

它在平台启动时就被使能了，授权值被设置成空，policy也不能被满足。这样做的目的是让平台固件生成一个自己的授权值（policy可选）。与其他组织架构要求用户输入授权值不同的是，平台授权值是平台固件自己设置的。因此不需要讲授权值存储到一个地方，代码本身就是授权值。

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

1.1.2 存储hierarchy

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

平台所有者可以关闭这个组织架构，并且不影响平台组织架构。这样一来即使平台所有者关闭了这个组织架构，平台固件仍可以照常使用TPM。但在TPM1.2中只有一个组织架构，关闭它就等于关掉整个TPM（个人想法：什么情况下会有这样的需求？关闭存储阻止架构，使用平台组织架构）。与之类似的是，这个组织架构可以在不影响其他组织架构的情况下被清除（修改种子，删除持续性对象）。

存储组织架构主要用于非隐私相关的操作，接下来要介绍的具有独立控制的隐私组织架构负责隐私相关的操作。

1.1.3 背书hierarchy

背书组织架构是一个隐私树，用户需要考虑隐私时应该使用它。TPM和平台厂商可以认证这个组织架构下的主密钥受控于一个真实平台上的一个真实TPM设备。在TPM1.2中，一个主密钥可以是一个加密密钥，并且证书可以通过TPM2_ActivateCredential创建，TPM2.0有与之相同的身份激活命令。与TPM1.2不同的是，一个主秘钥也可以当作一个签名密钥。创建和认证签名密钥是隐私相关的操作，因为它允许和一个独立唯一的TPM中的密钥相关。

因为背书组织架构目的是用于隐私相关的操作，它的使能位，policy，授权值也是独立于其他的组织架构的。它们受控于隐私管理员，当然这个管理员也有可能是终端用户。一个终端用户可以关闭背书组织架构，同时不影响TPM应用使用存储组织架构，平台软件也可以继续使用TPM。

1.2 非持久性组织架构

1.2.1 空hierarchy

空hierarchy与三种持久性hierarchy类似，可以有主密钥，基于主密钥可以创建子密钥。不同点如下：

• 授权值是一个零长度的口令，策略为空（不能被满足）。这些不能被改变
• 它不能被禁用
• 它有一个种子，密钥和数据对象都来源于它。这个种子不是持久性的，在每次重启时，它和proof会被重新生成不同的值

会话、保存的上下文对象和序列对象（摘要和HMAC状态）都是空hierarchy。这使得他们在系统每次重启后都为空，因为种子和proof值改变了。用户通常不会修改背书hierarchy种子（因为这会使证书无效）、存储hierarchy种子（因为它会让具有长生命周期的密钥无效）和平台hierarchy种子（因为用户可能没有这个权限）。

临时性密钥在系统重启后就会被擦除，TPM可以被用作一个密码协处理器，利用外部生成的密钥，执行密码算法。

空的hierarchy每次重启时，都会被清除。

最后

以上就是善良灰狼为你收集整理的TPM分析笔记（十）TPM 组织架构（TPM hierarchy）一、TPM组织架构的全部内容，希望文章能够帮你解决TPM分析笔记（十）TPM 组织架构（TPM hierarchy）一、TPM组织架构所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。