第03章-快速上手TPM2.0.md

快速上手TPM2.0

这一章主要描述TPM的应用。因为TPM2.0继承了TPM1.2中已有的功能，所以我们首先介绍TPM1.2的相关特性及其应用。然后我们进而介绍TPM2.0中新增加的特性和典型应用场景。

我们在第一章中已经提到，随着互联网的兴起，解决随之而来的安全问题，特别是解决电子商务中的安全问题是设计TPM的主要驱动力。一个基于硬件的标准的安全解决方案是当下迫在眉睫的需求。与此同时，因为没有历史包袱，所以这对安全研究者来说是一个从头到尾设计一个全新安全系统的黄金契机。长期以来，人们都期待一个基础性的安全架构，它能用于支撑新的安全技术的建立，而不是仅仅为了解决安全问题的安全补丁。

TCG在TPM1.2的设计中第一次尝试解决以下工业界中常见的问题：

• 设备身份：在TPM发布之前，设备通常用MAC地址和IP地址作为自己的身份，这并不安全。
• 密钥的安全生成：具备一个硬件随机数生成器对密钥的生成是非常有利的。许多安全解决方案因为密钥生成的质量不高而被破解。
• 密钥的安全存储：TPM能够安全存储高质量的密钥并让它们免于软件攻击，这是TPM带给设备的一个重大安全优势。
• NVRAM存储：当IT组织收到一个全新设备时，它们常常根据自己的标准流程格式化硬盘并重新部署软件。NVRAM可以让TPM一直保存证书而不依赖外部存储。
• 设备健康认证：在TPM出现之前，IT通常使用软件来检测系统的健康（安全）状态。但是，当整个软件系统被攻破的情况下，软件的报告就不可信赖了。

TPM2.0在1.2版本的基础上又增加了更多：

• 算法灵活性：因为有些算法的强度实际上比预期弱，所以未来可能需要修改。TPM2.0可以在不用修改规范前提下修改算法，这一点已经多次提到了。
• 增强的授权模式：这个功能通过增加授权策略的方式统一了TPM实体的授权方式。授权策略可以支持多元素多用户认证。除此之外，还包括策略管理的功能。
• 快速密钥加载：密钥加载是一个很费时的过程，因为密钥常常被加密存储。新的TPM规范使用对称密钥来加密密钥，相对于之前的非对称密钥加密，速度大大提高。
• 更稳定的PCR：过去，将密钥和设备状态绑定（状态常常由PCR存储，这里绑定可以简单理解为只有当某个PCR的值是某一个已知的好的状态时，才允许访问密钥）在一起会引起一些管理上的问题。因为通常情况下，假设一个密钥和存储平台启动过程测量值的PCR绑定，当启动固件因为正常更新影响PCR的值时，相应的密钥就要修改或者重新绑定。这个问题在新版本的TPM中已经不是问题了。
• 灵活的管理功能：各种各样的授权被分门别类，满足了对TPM资源进行灵活管理的需求。
• 通过名称识别资源：TPM1.2中对资源的间接访问产生了安全隐患。这问题在新的规范中通过使用资源名称来解决，名称本身经过基于密码学的安全处理。

已有超过10亿符合TPM1.2规范的TPM被部署在计算机系统中，单从这一点来看，无疑TPM1.2时成功的。而TPM2.0在1.2基础上做了更进一步的扩展。目前许多厂商正在实现满足TPM2.0规范的TPM，并且已经在部署了（2018的现在，新发布的商用机中应该都是TPM2.0了）。除了硬件TPM，一些厂商也在开发软件实现的TPM（来来来，Intel KPT，IMB vTPM，GOOGLE等大厂产品了解一下）。

TPM1.2应用场景

一般来讲，TPM2.0的设计能够胜任所有TPM1.2芯片能做的事情。因此，考虑到当前的应用软件可以在TPM2.0芯片上运行，我们首先来介绍已经应用TPM1.2功能的应用。

身份认证

TPM1.2作为第一代嵌入式安全芯片，第一个得到应用的预期的功能是设备身份功能。首先来介绍一下具有类似功能的智能卡。智能卡的芯片中嵌入了用来标识其身份的私钥。同时还有口令或者PIN码用于验证智能卡用户身份。私钥和口令共同实现了“你拥有什么”，“你知道什么”这两方面的认证。但是只要知道一个智能卡的口令或者PIN码，它就没有办法阻止被多个人使用。也没有一种方法使智能卡和一个特定的设备实现绑定，当然如果这个智能卡是用来代理个人用户身份而不是设备身份的时候，这对智能卡来说是一种优势，因为一个软件的用户很可能会在不同的机器上使用相同的软件服务，这样一来一张卡就可以解决认证问题（后面也有类似的说明）。

通过在个人电脑中植入私钥的方法，可以让设备拥有身份。这对于IT组织来说是是一个巨大的利好，因为这样可以很安全有效地管理软件的加载和实施安全防护（）。但是随着个人电脑变得越来越轻便，它在“你拥有什么”这方面的认证功能已经开始取代智能卡了。在实际的应用中，经常出现一个智能卡完成对一个用户的身份认证后被留在电脑上。这个例子的言外之意就是PC和智能卡经长一块儿被盗。最后的结果就是将这两者分开并没有什么用处（这个译者暂时持保留态度吧，毕竟在安全领域就是个小白。曾经也看到过intel人写关于ME的书中说，TrustZone不好，因为它运行的时候是是AP在跑，没有Intel ME使用的轻量级的独立CPU省电。这个我真是看不懂，呵呵呵。总之，还是要辨证的看问题吧，我就是对这个地方的描述评论一下，并没有任何否定TPM牛X的安全设计理念的意思）。

另一方面，如果一个密钥的授权口令是存储在个人电脑的安全芯片中的，而这个密钥用于个人身份的代理，那么可以肯定的是这个密钥不能仅仅存在于一个电脑上。因为很我们几乎可以肯定的说这个人会使用不同的设备。更进一步说，设备通常经过3-5年后就需要升级，因此需要一个灵活的管理方式把密钥由旧的平台迁移到新平台上。

根据前面的描述，这里引出两个嵌入式安全芯片的两个重要设计目标。那就是它需要一种可以代表设备身份的密钥，并且密钥不能移动到其他设备上。另外，它还需要用于代表个人用户身份的密钥，与前者相反的是，这个密钥必须可以安全复制到不同设备上。当设备不再被使用时，如果密钥继续留在设备上就会有潜在的安全风险。因此它还要有删除这两种密钥的能力（这里补充一点，TPM2.0超级厉害的密钥管理功能都支持以上功能哦，不信我们走着瞧！）。

那么到底身份认证（此时需要脑补一下签名验签的过程和安全属性）有什么用呢？其实它有大量的应用，我们举例来说：

• 用于VPN认证一个设备的身份，决定是否授予设备代理网络的访问权限。这样一来，IT组织可以很确定只有公司拥有的设备可以访问公司的VPN网络资源。（如果设备中有公司的IT组织掌握的私钥，可以通过让设备签名一个消息，IT用公钥来验证签名的方式轻松搞定认证？）
• 用于VPN认证一个用户的身份，决定是否授予一个账户代理网络访问权限。这跟上一个是一样的道理，不再赘述。
• 用户用于签名电子邮件：如果设备中的一个私钥能够代表一个个人的身份，那么用这个私钥完成的签名也就可以被收信人用于认证发信人的身份。
• 用户用于向银行证明自己的身份：关于这一点，嗯，还是google一下银行U盾，双向身份认证来详细了解一下吧。
• 用户用于授权支付：可以阻止别人以自己的名义买东西。
• 用户用于向远程系统证明自己的身份：只有只有经过认证的的用户才能登陆远程系统。

加密

系统的嵌入式安全芯片的第二个应用案例是用于加密密钥，被加密的密钥则用于加密文件或者解密收到的加密文件。出口法规限制常常让安全芯片在实现加解密引擎上止步不前；但是安全芯片用于存储加密密钥是被允许的，所以安全芯片通常会包含这个功能。因为芯片本身已经具备了基于非对称密钥的签名验签功能，在此基础上增加仅仅需要加解密包含密钥的少量数据的功能，这并不需要很高的成本。

正如上文所述，一旦具备基础的运算能力，就可以实现以下应用场景：

• 加密设备上的文件和文件夹。
• 全磁盘加密。
• 为口令管理器提供口令加密功能。
• 加密远程存储的文件。

密钥存储

TPM的设计者常常会问自己一个很基础的问题：用户会在TPM上使用多少密钥呢？如果答案只是一两个，那么芯片将会有足够的片上空间来存储密钥。不幸的是，密钥的数量是大于3的（就差一个？）。这种成本的顾虑使得TPM不可能把所有的密钥都存储在片上，TPM毕竟不是功能相对单一的智能卡。不过需要注意的是，TPM被设计为总是和平台在物理上绑定在一起，而平台上一定有大容量的硬盘，这个理论上可以存储很多很多的密钥。因此，TCG决定把硬盘用起来。

具体的做法就是，TPM可以访问自己内部生成的密钥，它可以用公钥加密其他的密钥，然后将加密结果存储到硬盘上。这样一来TPM就可以使用理论上不受限制数量的密钥，并且不浪费珍贵得内部存储空间。存储在硬盘上的密钥可以被擦出也可以被备份，这个看起来像是设计者能接受的妥协。相对不太重要的密钥一旦与TPM建立联系之后就有了如下的应用场景：

• 因为可利用的密钥数量理论上不受限制，一些隐私保护方案就可以通过使用更多的密钥使隐私保护的粒度更小，实现更细化的保护。这样一来你可以要求用不同的密钥分别保护你的年龄，体重，婚姻状态，健康状态，政治倾向等私密信息。
• 使用不同的密钥来保护不同级别的安全：举例来说，个人，财务，数据等信息的密钥可以被划分成不同的安全等级。
• 使用不同的密钥保护同一台机器上的不同用户：通常来说一台机器上的不用用户可能有不同的资源访问权限。
• 让办公机器“旅店化”：密钥存放在服务器上，当需要的时候再下载使用。

随机数生成器

随机数生成器是生成密钥必需的组件，但是早期的个人电脑通常没有一个质量很好的随机数生成器（随机程度也是有级别的，可以Google一下）。安全协议因为密钥质量不好而被破解的案例时有发生。不开玩笑，这是真的。所以第一代的TPM标准要求必须配备随机数生成器。

Anyone who considers arithmetical methods of producing random digits is, of course, in a state fo sin --Von Neuman

一个高质量的随机数生成器很多应用案例：

• 为操作系统提供随机数种子
• 为安全协议提供nonce（随机数）
• 为文件加密提供临时密钥（一次性使用，用完就删，不过下次需要的时候还能根据相同的输入产生相同的密钥？）
• 产生长期使用的密钥（例如存储密钥）
• 为蒙特卡罗方法提供种子（这个小白表示真的不懂啊）

NVRAM存储

一些具有访问控制属性的NVRAM存储区域对于PC来说是非常有用的。它们可以用来存储密钥，当关机时密钥不可访问，但是访问密钥时，速度比用公私密钥对解密密钥数据的方法快很多，因为它就是直接数据访问。同时它可以用来为一个系统不同部分提供新传递的功能。TPM中NVRAM的读写属性是可以单独控制的，这也就意味着用户不需要担心因为意外或者恶意攻击造成数据被擦除（不可写）。初次之外，系统在启动初期没办法访问硬盘，这时NVRAM就可以用来存储这个时候必须要使用的密钥。一个明显的例子是，系统在启动时在访问自加密硬盘之前必须输入口令才能读写。

具备NVRAM能够提供以下功能：

• 存储证书链的根密钥：一般是每个人都可以访问的公钥，但是必须保证公钥不能被修改。
• 存储背书密钥（EndorsementKey）：背书密钥用于TPM在出厂配置阶段解密证书和传递口令。EK是很隐私的数据，不要相信网络上误导性的宣传。
• 存储机器已知的好的状态（一些列的系统测量（HASH extend）值）：INTELCPU有一个可信计算技术（TXT），其中的启动控制策略（LaunchControlPolicy）就用到了TPM NVRAM的这个作用。与UEFI（现在的BIOS，UnifiedExtensibleFirmwareInterface）的安全启动技术所使用的根公钥类似，这些值用于系统所有者控制系统在启动虚拟机（或者OS）之前应该处于什么样的状态。在TXT中，用户对NVRAM的内容有绝对的控制权，而UEFI的安全启动并非如此。
• 存储硬盘可用之前的解密密钥：刚刚前文也介绍了，自加密硬盘。

平台配置寄存器

相对于智能卡来说，TPM一个独一无二的优势是，可以保证它和主板在物理上绑定，并且在系统开始启动之前就可以使用了。因此，TPM就可以用于保存系统启动过程中系统状态测量值。PCR就用于实现这个功能。PCR中存储了由软件算出的一系列哈希值，TPM可以通过使用一个特定的私钥签名这些测量值，然后向外部报告。本书的后续章节我们会详细描述PCR是怎样工作的，现在我们只需要知道它有一个单向存储的特性可以保证内容不被篡改（HashExtend）。因此，如果PCR中的值与预期的可信值相同，那这些值就被认为是可信的。

PCR的另外一个巧妙的用处是，它们可以被用于认证。正如一个银行账户只能在有效的交易时间段内被打开一样，我们可以在TPM中创建密钥或者其他的状态。创建的同时让它们的授权配置与PCR某一个值绑定，只有PCR的值是某一个预期的状态时才可以使用它们。这样一来就出现了很多有意思的应用场景：

• VPN只有在确认PC已经运行了所有IT允许的软件后才授权设备访问网络，如果是不被允许的软件，PCR值会不同，认证会失败。
• 文件系统服务只有在确认MBR正常以及硬盘确实存在时才会得到解密密钥。

隐私保护

第一代的TPM架构师就已经非常重视用于的隐私保护了。隐私保护对于公司来说尤为重要，因为包含个人身份信息的系统和相关数据的泄露可以导致巨大的经济损失。许多地方法律要求公司及时告知用户的隐私数据泄露；所以，如果一个包含人力资源数据的公司笔记本失窃了，公司必须通知每一个相关的人，告诉他们相关信息可能已经泄露了。重复一下，类似的隐私信息泄露可能会造成巨大的经济损失。在嵌入式安全系统出现以前，在标准PC上加密隐私文件几乎是不可能的，因为没有地方存放密钥。最后的结果就是，大部分的加密方案会把密钥存“藏”在它们自己可以很容易访问到但技术上经过专业分析的地方，或者是通过口令派生密钥。但是口令也有一些基础性的问题：如果人们可以记住它，那计算机也可以猜出它。最有效的保护方式是用硬件记录已经尝试的次数，如果达到一个设定的次数后就要强制停止一段时间，之后再允许尝试（好多手机系统都有这个功能）。TPM规范也要求TPM芯片实现这个功能，这极大地提高了用户隐私保护的级别。

架构师们更加关注的第二个隐私保护问题是：提供一种可以向用户证明一个密钥是由TPM创建并保护的机制，同时这个机制又不能让用户知道是哪一个TPM创建和产生了这个密钥。正如解决计算机领域其他问题一样，TPM使用某种程度的间接方式处理这个问题。如果让EK仅仅应用于解密，而不是签名，那它就可以作为TPM的身份信息。当然TPM的做法并不完全是这样，而是提供另外一种密钥，叫做（特征）身份认证密钥（AIK），可以认为是一种替代身份密钥。EK可以向用户证明AIK是由TPM创建的，并且不用告知用户AIK来自那个TPM，一个隐私证书认证机构应该具有这样的能力。因为AIK的数量不受限制，我们可以创建不同用处的AIK。比方说，用户可以创建三个AIK分别用于证明他是高级市民，他很富裕，他是单身（dog）。这样一来当某一次认证只需要其中一种身份特征时，就可以避免泄露更多的隐私信息。

关于第二个隐私保护问题，我们可能会有疑问，TPM到底怎么做到既可以证明秘钥由TPM创建，同时又不告知创建秘钥的TPM的身份的？来自Intel，IBM，HP的密码学家设计了一个叫做直接匿名认证（DirectAnonymousAttestation）的方法，DAA基于分组签名技术，并且包含了复杂的认证方法。这个方法涉及的认证协议的优点是，它允许AIK的创建者使用可变的认证信息，具体来说用户可以设定一个AIK具有完美的匿名性（这就是我们本段落开头疑问涉及的问题），或者足够多的认证所需信息（隐私CA知道所有的隐私信息），以及这两者之间的隐私配置。这两种配置的不同体现在TPM遭到破坏并且EK的私钥被泄露到网络上的时候。CA如果知道所有的用户隐私信息就可以恢复这个证书，否则如果是第一种完全匿名的配置就不能恢复。

PCR在设计实现以及PC应用等方面对微小变化的敏感性，让它成为TPM中状态最不可逆向的部分。也就是说只是知道一PCR的值对你了解PC如何启动几乎没有价值。当然从另一方面说，这对IT阻止判定系统运行异常导致的PCR值变化带来了不小的难度。总结一下就是虽然给用户带来了隐私保护，但同时在某些方面也造成了额外的难度，事物通常是有两面性的。

TPM2.0新增的应用场景

TPM2.0吸取了TPM1.2在应用中的一些经验教训，做了一系列的改进。尤其需要强调的是关于算法方面的改进，TPM1.2因为广泛应用SHA-1算法曾经面临遭受密码攻击的风险。新版本加强了这方面的设计，即使一个算法已经不再安全整个系统也不至于产生致命的安全隐患。

算法灵活性

我们已经多次提到，TPM2.0规范允许TPM设备使用多种不同的算法。理论上TPM2.0设备可以使用任何哈希算法，而不是像之前仅仅是SHA-1。现在看来SHA-256是早期SHA-256使用最多的一种算法。同时新的规范增加了对称加密算法如AES和非对称加密算法如ECC的支持。

对称算法的引入实现了秘钥片外存储时使用对称加密而不是非对称加密，这一重要的秘钥存储方式的改变使TPM2.0可以使用任何加密算法。所以即使将来有一种密码不再安全也不需要修改规范，替换它就可以了。

理想情况下，不同秘钥算法配合使用时需要有相互匹配的算法强度。下表列出了NIST认可的不同密码算法的强度。

类型	算法	秘钥强度（比特位数）
非对称	RSA1024	80
非对称	RSA2048	112
非对称	RSA3072	128
非对称	RSA16384	256
非对称	ECC224	112
非对称	ECC256	128
非对称	ECC384	192
非对称	ECC521	260
对称	DES	56
对称	3DES（2Keys）	127
对称	3DES（3Keys）	128
对称	AES128	128
对称	AES256	256
哈希	SHA-1	65
哈希	SHA-224	112
哈希	SHA-256	128
哈希	SHA-384	192
哈希	SHA-512	256
哈希	SHA-3	可变

现在对称加密算法通常使用AES。最常用的128位非对称加密算法是RSA2048或者是ECC256，RSA2048在算法强度上不如ECC256，并且速度慢，运行空间需求大。但是因为RSA的专利已经到期，而且兼容现有的大部分软件，所以很多人在使用它。事实上，很多人因为免费和软件兼容性好将RSA2048，SHA-1和AES-128组合在一起使用，尽管它们在算法强度上显然是不匹配的。本书中的大部分例子使用RSA或者ECC做加解密，而哈希算法我们只使用SHA-256。

NIST已经不提倡使用SHA-1，并且2014年之后就将不再应用于数字签名中（尽管大部分使用SHA-1的TPM1.2没有沦陷，但当前的密码分析能力使得攻击是非常有可能的）。因为SHA-1的密码强度要远远低于其他同类算法，所以除非是无法避免的兼容性问题，否则没有任何理由继续使用它。

TCG通过算法标识符列表来发布TPM设备中可以使用的一系列算法。这其中就包括可以在PCR中使用的哈希算法。当然这个列表是可以随着时间推移而变化的。

总结来说，算法灵活性让TPM具备以下非常好的特性：

• 可以使用兼容旧应用的算法。
• 可以使用兼容美国政府的B类机密算法。
• 可以使用兼容美国政府的B类最高机密算法。
• 可以使用兼容其他政府要求的算法。
• 由SHA-1升级到SHA-256。
• 不改变规范的情况下改变使用的算法（要吐了吗？反正我要吐了，不过这也是老外厉害的地方，或者说厉害的人之所以厉害的原因：反复，坚持）。

增强的授权模式

TPM1.2规范经历了多年的多项功能优化，所以最后就导致了规范在管理和认证方面非常复杂。新版的TPM使用“在场证明”或者所有者授权来管理设备。EK的使用就受到TPM所有者的授权控制。秘钥一共有两种授权形式：一种用于秘钥的使用，另外一种用于秘钥的复制（TPM1.2中叫做秘钥迁移）。另外，可以受到Locality（这个实在没有办法翻译，看看PTP spec. 中相关的描述就知道了，本书后面也有描述）和PCR值的控制。

与前述情况类似，TPM1.2中的NVRAM也可以受到Locality和PCR值得控制，并且有两种授权形式：分别用于读写操作。但是这两种授权模式的唯一可能的不同之处就是，是否其中有一个是所有者授权（这里的所有者是指TPM所有者还是NVRAM所有者？）

TPM1.2中，经过认证的可迁移秘钥和其他秘钥的授权形式相同，但是为了完成秘钥迁移，我们需要对一个迁移授权进行签名，TPM会检查这个授权是否有效。这个过程的执行需要所有者授权。

更让人觉得复杂的是，一些需要所有者授权的命令和秘钥的授权可以被第二口令代理。但是所有者的第一授权也知道口令，并且代理会消耗珍贵的NVRAM空间。更加糟糕的是，实际上操作过程让人难以理解，结果就是我们可能根本就不知道这个特性。

TPM2.0规范的授权方式完全不同，它被称作增强的授权。增强的授权使用以下几种类型的授权模式：

• 明文口令：TPM1.2没有这个功能。在某些情况下，比如系统启动以前，BIOS控制TPM的时候，口令比较合适（基于成本和复杂度上考虑，HMAC相关的BIOS实现软件不受担保，所以可能不合适）。
• HMAC秘钥：可能TPM并不信任OS，但是信任直接和它通信的软件（TSS等），这样HMAC带来的安全性就有了担保。TPM用于远程系统就是一个例子。
• 签名（比如通过智能卡）：当IT工作人员需要维护TPM时，使用智能卡认证可以有效地防止IT组织的权限被乱用。当工作人员离开IT阻止的时候可以简单地收回智能卡而不用担心信息泄露，如果是用明文口令的话就会麻烦很多。
• 签名时附加额外的数据：举例来说，额外的数据可以是指纹提取设备读取的指纹。这是EA的一个非常有用的功能。比方说，当额外的数据是指纹或者GPS信息用于签名认证时，TPM不需要直接比对具体的指纹信息或者理解GPS信息的意义。
• PCR代理系统的状态，至少是在系统启动时：全瓷盘加密的例子，PCR不对就不允许使用机密秘钥。
• Locality来指示一个TPM命令来自哪里：目前为止这个功能仅仅用于CPU向TPM发出特殊请求，Intel TXT（HCRTM）和AMD-v有相关的应用。另外，一个来自CMU叫做Flicker的软件也使用了这个方法，只要是在一个小而安全的操作系统中需要安全操作时会使用它。
• 时间：授权策略可以限制秘钥的使用时间，就像银行只允许金库在规定交易时间段内打开一样。
• 内部计数器值：一个对象可以被设置成只能在计数值在某一个特定范围时使用。它可以用来限制一个秘钥的使用次数（这里说的应该是在一个TPM内部系统启动周期内）。
• NV索引对应内存的值：秘钥的使用可以设置成受某一NV索引对应内存的值控制，比如值得某一个比特是0或者1标志这个秘钥能或者不能被使用。这个在撤销秘钥的使用权限时很有用。
• 在场证明：用户需要向TPM证明用户真的拥有TPM所在的平台，具体实施上要体现在用户可以在物理上操作设备。

上述的列表还不完整，但是已经初步让你了解了这个新的策略授权机制。另外，用户还可以用过将不用的策略使用逻辑与，逻辑或组合起来构成更复杂的策略。比如说：

• Mary使用一个HMAC秘钥和智能卡来标识自己的身份，智能卡与一个公钥的使用关联。
• Joe用指纹来标识自己的身份，指纹设备与上述同一个公钥关联。
• 这个秘钥可以被Mary OR Joe使用（如果不是有实际的使用经验，还真是比较难理解，不过一旦理解就觉得好简单，祝你好运）

授权策略可繁可简，TPM中所有的对象和资源实体都可以和一个授权策略相关联。EA这些功能极大地扩展了TPM的应用场景，尤其是在权限管理方面；EA设计的结果也降低了NVRAM的使用，消除了以前版本存在特殊情况。

好的授权策略可以提供理论上任何你能想到的秘钥使用限制。不过尽管有一些限制理论上可行，但在实际上难度呈指数级增长。新的EA可以允许以下几种新的应用场景：

• 资源的授权受到多个因素的控制
• 资源可以被多个用户授权
• 限制资源的使用次数
• 限制资源授权时间段
• 撤销资源的使用权限
• 为不同用户设定同一个资源不同的使用授权方式

快速密钥加载

在TPM1.2规范中，当一个秘钥第一次被加载到TPM时，就需要用私钥执行非常费时的解密操作（秘钥通常加载之前通常被RSA的公钥机密存储）。为了避免在同一个会话（session）期间多次做费时的加解密操作，第一次加载成功后，TPM可以使用对称加密算法加密这个秘钥，然后缓存到硬盘上。当需要再次使用时，只需要使用对称秘钥解密从而实现秘钥重新加载。但是一旦TPM断电，对称秘钥会被擦除，下次启动后TPM仍需要用私钥解密来加载这个秘钥。

在TPM2.0中，除了导入TPM设备之外创建的秘钥需要非对称算法加密之外，其他TPM需要存储的秘钥都是用对称算法来加密的。所以TPM2.0中秘钥的加载过程是很快的。因此也不需要使用向TPM1.2中描述的缓存的方法，因为两者都是使用对称秘钥，速度没有差别。

快速的秘钥加载让用户几乎感觉不到加载时的延迟。这样也使得设计一个多应用不受限制地使用TPM的系统更加容易。

更稳定的PCR

TPM1.0系列的TPM存在一个非常棘手的问题，那就是PCR很脆弱（这里的脆弱主要还是从PCR相关应用的灵活性等方面来分析）。通常来说，PCR的值代表了机器得状态，其中序号小的PCR代表着系统在启动时各个阶段的状态，序号大的CR代表操作系统启动后的状态。秘钥和数据都可以被隐藏、绑定到一个PCR的值上，这样的操作就叫做隐藏（Sealing）。这里需要注意的是如果秘钥或者数据是被隐藏到可以表示BIOS阶段系统状态的PCR上，那升级BIOS就会变成一件棘手的事情，因为BIOS变了PCR就会变。所以最后的处理方法就是，在升级BIOS之前，将所有相关的秘钥和数据进行解绑操作（Unseal），等升级成功后再重新锁定。这种管理方式对于管理员来说简直就是噩梦，另外这也会让用户觉得讨厌，使用体验不好。

在TPM2.0的规范中，你可以将一个事物隐藏到一个PCR的签名上，而不是一个具体的PCR值（当然如果你愿意仍然可以这样做）。这样一来，只要相关的签名能够被验证通过就可以解密，从而不用依赖某一个具体的PCR值（这里会涉及到一个叫做TPM2_Authorize的命令，过程还是稍微有点烦，TPM-software的github 仓库上的某一个issue有讨论，下文也有提到）。

通常情况下，IT会对它接受的不用的BIOS版本对应的PCR值签名，TPM可以实现由原来的只有一个值满足才能恢复数据，到现在只要其中有一个满足就可以。

具体的技术实现上，TPM使用一个叫做TPM2_Authorize命令，这个命令的主要作用就是让授权策略变得灵活。

这种新的技术开启以下新的不同应用场景：

• 将资源隐藏到任意经过OEM签名的BIOS上
• 将资源隐藏到任意经过OEM签名的OS上
• 将资源隐藏到任意经过OEM签名的BIOS上

灵活的管理功能

在1.0系列的TPM规范中，TPM中只有两种认证：所有者的授权认证和根存储秘钥授权（SRK）。因为通常情况下SRK是广为人知的20个字节的0，所以所有者的授权被用于各种各样的目的：

• 复位字典攻击计数器
• 恢复TPM出厂设置
• 授权阻止SRK被修改
• 保护创建AIK的用户的隐私
• 授权NVRAM空间的创建和删除，防止过度损耗

不同角色使用相同授权的问题是角色很难被独立的管理。因为有时候你可能想把其中的某些角色分别交给其他不同人代理。比方说，控制AIK创建和删除的角色与复位字典攻击计数器的角色在隐私保护上的需求是不同的。

在TPM1.2规范中，你可以使用Delegate命令将所有者授权代理给不同的人，但是这种操作给常复杂，并且耗费大量珍贵的NVRAM空间。因此实际上没有应用使用这种功能。

使用TPM1.2的系统还存在另外一个问题，那就是不能保证TPM设备一定被使能了（一般指上电以后）。所以很多OEM厂商不愿意开发基于TPM的应用，比如在系统启动阶段打开VPN和启动OS之前验证BIOS这样的应用，这实际上造成TPM被禁用。但是在TPM2.0中，OEM可以这样做，因为TPM的平台组织架构（Hierarchy）在上电后总是使能的。

在TPM2.0规范中，运用TPM1.2所有者授权的各种角色被独立分开。这主要是因为可以给它们不同的授权和策略，同时被包含在不同的TPM内部组织架构。比如前面提到的字典攻击的例子中，复位操作可以由独立的口令授权。其他的角色也被包含在TPM2.0如下的阻止架构中：

• 标准存储架构：包含TPM1.x中SRK的大部分内容。
• 平台组织架构：主要是被BIOS和系统管理模式使用，用户不可以使用。
• 背书或者隐私架构：阻止非法用户使用TPM做认证。
• 空阻止架构：此时TPM用作密码协处理器。

除了空组织架构，其他每个组织架构都有各自的授权口令和授权策略。字典攻击的逻辑也有一个与之对应的授权策略。事实上，所有需要授权的TPM内部的资源实体也有与之对应的授权策略。

通过名称识别资源

TPM1.2规范中，资源通过handle来标识而不是通过经过密码学处理过的名称。这种方法会有问题，比如说两个资源使用相同的授权，相对底层的软件可以做到修改资源的handle，这样就有可能造成欺骗。具体来说，假设有两个资源R1和R2，它们使用同样的授权。R1和R2分别对应两个软件：没有有底层操作能力的S1，和有底层操作能力的S2，同时假设有一个R1授权用户A，以及未授权用户B。如果B可以破解软件R2的底层操作，他可以把R2的handle修改成R1的值从而得到授权（后半段是我自己想的一个可能的过程，不一定准确）

在TPM2.0中，资源有自己的名字。名字是经过密码学的方法与资源绑定的，所以消除了前文说的攻击。另外你还可以使用TPM的秘钥对一个名称签名，用于证明这个名称是正确的。因为名字包含秘钥的授权策略信息，所以签名也可以用于证明某个方法可以被用于秘钥的授权。在后续增强的授权模式一章将详细介绍这一点。除此之外，如果秘钥可以被复制，这个证书还可以作为“出生证明”来指出哪一个TPM创建了这个秘钥。

小结

这一章我们从较高层次介绍了TPM1.2和TPM2.0的应用案例。TPM1.2具有功能是可信计算的基础。这主要包括秘钥生成，使用，和存储以及PC健康状态认证。TPM2.0增加复杂的管理和授权功能，同时也增加算法灵活度，避免新算法的应用导致规范的修改。

下一章我们将学习一些应用和软件开发包（SDK），它们利用TPM的功能解决了一些现存的问题。这其中包括，利用系统空闲时间加密数据的安全解决方案如BitLcokerhe TrueCrypt；还有用于PC健康认证和设备身份认证的软件如WaveSystem，StrongSwan和JWSecure；最后还有用于构建这些软件应用的SDK。