Skip to content

Latest commit

 

History

History
273 lines (182 loc) · 26.8 KB

第09章-组织架构.md

File metadata and controls

273 lines (182 loc) · 26.8 KB

组织架构

一个组织架构由一组相关的实体构成,它们被作为一个组来管理。这些实体包括永久对象(组织架构的handle),作为一个树根节点的主要对象,和其他对象比如密钥等。NV索引隶属于一个组织架构,但是不在树型组织中。除去永久性实体,其他实体可以作为一个组被整体删除。

一个组织架构的密码学根节点是一个种子,这个种子是有TPM生成的一个很大的随机数,并且TPM不会将它暴露在TPM安全边界之外。TPM使用这个种子来生成主要的对象比如根存储密钥。这些作为组织架构根节点的密钥用于加密它们的子节点密钥。第15章更加详细地介绍了密钥相关的内容。

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

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

三种持续性组织架构

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

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

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

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

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

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

平台组织架构

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

应用案例:UEFI

当开启UEFI的安全启动特性时,平台固件需要验证一个RSA数字签名来验证软件的真实性。平台OEM会事先在TPM NV索引中存储一个公钥或者是一个可信公钥的哈希值列表。这个NV索引被设置成只有平台OEM可以更新它的内容。在启动过程中,平台固件会使用这个可信的公钥来验证签名。

TPM在这个应用中有两个优点。首先,它提供了安全的公钥存储空间。其次,它提供RSA算法,所以不用软件实现。以上操作的步骤如下:
* TPM_NV_READ
* TPM2_LoadExternal
* TPM2_verifySignature

平台组织架构在三个可持续性组织架构中的独有特性是,它在平台启动时就被使能了,授权值被设置成空,policy也不能被满足。这样做的目的是让平台固件生成一个自己的授权值(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。进一步讲,证书链表明这个密钥是固定在一个特定的TPM设备中。正因为如此,背书组织架构下的主密钥通常是一个加密密钥而不是签名密钥。

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

激活证书

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

  • 证书提供者可以确信它认证密钥的属性。
  • TPM密钥证书的接收者 不能 确定多个密钥来自同一个TPM。

理论上说证书授权机构有可能做非法关联,但是通常情况下我们认为这个私有的CA是可信的,不会这样做的。

在TPM1.2中,一个可以被激活的密钥被限制为一定是不可以迁移的身份认证密钥,并且只能用于对TPM产生的数据签名,而且一定是SRK的子密钥。TPM2.0规范在满足前面提到的两个设计目标的基础上,删除了这些限制。

在继续本节内容之前,我们先在这里回忆如下的知识点,TPM2.0密钥的名称是密钥公共数据的摘要。名称完全可以做为密钥的身份。摘要包括公钥和密钥的属性。

简单来说,在背书组织架构中的主密钥是解密密钥,不是签名密钥。CA会构建一个证书并用主密钥的公钥加密。因此只有拥有主密钥私钥的TPM可以解密恢复证书。具体过程参考图9-1.

图9-1

如下是证书提供者的操作:

  1. 证书提供者首先接收一个公钥和公钥的证书作为一个加密密钥。这个加密密钥通常来说是背书组织架构下的主密钥,这个主密钥的证书通常石头TPM或者平台厂商颁发的。
  2. 证书提供者回溯主密钥证书直到它的根证书。通常情况下,证书提供者会验证这个加密密钥是与一个已知兼容的硬件TPM绑定。
  3. 证书提供者检查公钥并决定是否要颁发证书,以及所颁发的证书中应该写什么内容。在一个典型的应用案例中,证书提供者会办法颁发一个固定在TPM中的限制性密钥。
  4. 证书申请者可能试图修改公钥的属性。这种攻击是不可能成功的。具体的原因看TPM操作的第5步。
  5. 证书提供者会为密钥生成一个证书。
  6. 证书提供者生成一个秘密信息用于保护证书。通常情况下这个秘密是一个对称加密密钥,但是也可以是一个可用于生成加密或者完整性密钥的秘密信息。TCG并没有强制规定这个秘密信息的格式。
  7. 证书提供者为KDF生成一个种子。如果第一步的加密密钥是RSA密钥,那种子就是一个简单的随机数,因为RSA密钥可以直接用于加密和解密。如果密钥是基于椭圆曲线的密钥,需要使用一个更加复杂的Diffie-Hellman协议。
  8. 证书提供者使用TPM提供的公钥加密种子,只有TPM可以解密这个种子。
  9. 种子用于使用TCG指定的KDF生成一个对称加密密钥和HMAC密钥。对称加密密钥用于加密第6步的秘密信息,HMAC密钥用于提供秘密信息的完整性。隐秘但是很重要的一点是,KDF也会使用第1步中加密密钥的名称。后面解释原因。
  10. 加密过的秘密消息和它的完整性校验值将以证书数据块的方式发送到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是永远不能满足的空值。并且它们不能被改变。
  • 它不能被关闭。
  • 它有一个可以生成密钥和数据对象的种子。这个种子不是持续性的,它会在每次重启后由不同的值重新生成。

一个一般用户不会注意到的隐蔽使用案例是,会话,保存的上下文对象,以及对象序列(摘要和HMAC状态)都是在空组织架构下的。因为在每次启动后种子的值就会变化,这就阻止了这些值在重启后被清空。一个用户通常情况下不会改变背书阻止架构的种子(因为这样会让证书失效),存储组织架构的种子(因为这样会让密钥失效),或者平台阻止架构的种子(因为用户可能根本没有这个权限)。

临时性密钥是重启后将会被擦出的密钥。在空组织架构下可以构建一个完整的密钥链,如主密钥,存储密钥,子密钥等。系统重启以后,因为空组织架构的种子已经发生变化了,所以整个密钥组织架构在密码学上已经被擦出了。也就是说,架构中被加密过的相关子密钥可能还存储在硬盘中,但是他们已经不能加载到TPM中了。

TPM可以被当作一个密码协处理器,这时它可以使用TPM外部生成的密钥来完成密码学操作。因为密钥的公共和私有部分可能不是持续性阻止架构的中一部分,所以他们会被加载到空阻止架构下。

密码学基本操作

TPM2.0可以仅仅作为一个密码协处理器存在。尽管可以在任何组织架构下做密码协处理器相关的操作,但是最好是在NULL组织架构下。这是因为它一直是被使能的并且授权值一直都是空,所以永远是可用的。

但是我们不能把TPM当作的一个密码运算加速器,因为它大概率地比纯软件实现的算法还要慢。尽管如此,还是有一小部分合适的应用能够有效的使用这些功能:

  • 在资源受限的环境下,比如说启动初期的软件,开发人员可能不想实现复杂的密码学数学运算功能。
  • 在性能要求不高的应用中,开发者使用TPM可能比购买商业软件或者审查开源授权协议更简单。
  • 在一些认为硬件比软件更优的应用中。
  • 一些需要认证的应用中,可以假设TPM是经过认证的。

接下来介绍随机数,摘要,HMAC,和对称与非对称密钥操作。

随机数生成器

TPM提供了一个简单的接口用于访问硬件随机数生成器。当另外的熵源不能使用时它将很有用。案例就是在嵌入式系统应用以及平台启动初期环境。

我们可以认为TPM是比软件更可信的随机数生成源。参考文章“Ron was wrong, Whit is right”来了解不好的软件随机数生成器带来的问题。

摘要基本操作

TPM2.0提供两种密码学摘要基本操作API。它们都有算法灵活性,允许在调用函数的时候选择哈希算法。

相对简单但是灵活性稍差的方法是TPM2_Hash。调用者输入消息,TPM返回相应的摘要。消息的长度受限于TPM输入缓冲区的大小,通常情况下是1-2KB。另外一种API实现了一种常用的start/update/complete/模式,API分别为TPM2_HashSequenceStart, TPM2_SequenceUpdate, 和TPM2_SequenceComplete。

应用案例:对大文件做哈希

在这个应用案例中,我们假设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函数可以返回一个凭据,这个凭据可以用于对一个限制性密钥签名。参考关于TPM_GENERATED的讨论来了解更多。
应用案例:可信启动

CRTM(Core Root of Trusted Measurement)软件想要验证一个经过签名的软件更新。因为启动阶段的资源有限,CRTM会使用TPM做摘要计算,这样就避免了在CRTM中用软件实现摘要计算算法。

TPM2.0提供了 TPM2_EventSequenceComplete函数来代替 TPM2_SequenceComplete。这个命令只有在没有选择哈希算法时停止摘要过程。因此这个空的算法将触发TPM以支持的所有哈希算法来计算消息的摘要。

这个命令作为TPM1.2中TPM_SHA1CompleteExtend函数的扩展,有以下两方面的增强:
* 它允许将摘要的结果扩展到PCR中。选中一个PCR索引之后,所有在这个索引下的PCR都将根据bank配置的哈希算法来被扩展。最终还会返回每一种哈希算法的哈希值。

* 强度更高的SHA-256算法优先于SHA-1算法。因为这个命令可以支持多种算法同时操作,所以可以返回多种哈希值并对多个PCR bank做扩展操作,因此它允许逐步淘汰SHA-1算法。
应用案例:可信启动

TPM2_EventSequenceComplete命令可以用TPM帮助软件去测量(摘要和扩展)软件/固件。它同样避免了测量软件实现摘要算法。
应用案例:多算法并行哈希操作

总结来说就是,软件可以使用多种算法测量软件并扩展到PCR中。一个TPM很可能不支持一个bank多种哈希算法。当前的PC客户端TPM还不需要这个功能。但是一旦需要,TPM的API可以保证是支持这个功能的。

HMAC基本操作

TPM2.0支持将HMAC作为一个基本操作,然而TPM1.2仅仅支持相关的摘要API。HMAC密钥是加载到TPM中的keyedhash对象(???)。对于一个限制性的密钥,必须使用该密钥的算法。对于一个非限制性算法,调用者可以修改密钥的哈希算法。对于任何密钥来说,有完整的相辅相成的授权方法可用。

对于摘要操作来说,有简单和完全灵活的两种API。TPM2_HMAC是更简单一点的方法。你需要输入一个密钥的handle,一个摘要算法,一个消息,TPM直接返回HMAC值。另外一种又是实现了常用的start/update/complete模式,分别使用函数TPM2_HMAC_Start, TPM2_SequenceUpdate, 和TPM2_SequenceComplete。

应用案例:存储登陆口令

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

在这个应用案例中,我们使用一个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算法,对称和非对称加密操作。