原文地址：
http://www.vonwei.com/?mod=pad&act=view&id=11
TPM 1.2规范主要面向PC平台，其103版本在2009年被接受为ISO标准（ISO/IEC 11889），而且国际上上亿的终端机器和laptop都配备了TPM安全芯片，到目前为止，虽然有声称TPM 2.0的芯片制造出来，不过占据主要市场的还是TPM 1.2芯片。由于TPM 2.0与TPM 1.2芯片并不兼容，在上层软件链成熟前，基于TPM 1.2的芯片还会持续一段时间。不过，由于TPM 2.0的灵活性，解决了TPM 1.2存在的很多安全问题，且满足更多场景的应用，其代替TPM 1.2芯片将是一个必然趋势。
本文简单总结下从TPM 1.2到TPM 2.0的变化。
-
在密码算法上的变化
SHA1算法的安全强度已经被证明无法满足需求，已经被弃用。
不同的国度使用的密码算法不一定相同，主要源于不相信别人的密码算法，如在国内主要使用商密的SM系列算法。
RSA虽然是最经典的非对称加密算法，不过对ECC的使用增加也是一个趋势，在相同的安全强度下，ECC的密钥长度比RSA要短很多，国内SM2也是一种ECC算法。特别是对于直接匿名认证机制DAA，基于ECC算法的效率明显高于RSA。2009年的美密上，有一篇关于768比特RSA密钥的因式分解，在密码领域TPM 1.2使用2048bit的RSA强度也存在争议。
因此，TPM 2.0相对于TPM 1.2在密码算法上的改变主要参考以上几点。
TPM 1.2密码算法：RSA加密、RSA签名、RSA-DAA、SHA1、HMAC，并没有要求支持对称算法。
TPM 2.0算法支持：RSA加密和签名、ECC加密和签名、ECC-DAA、ECDH、SHA1、SHA256、HMAC、AES，而且厂商可以随意使用TCG IDs来增加新的算法，如在国内实现必须增加SM2、SM3和SM4算法，拥有一定的灵活性。
-
不能只面向PC平台，应该扩展到更加广阔的平台
TPM 1.2主要面向PC平台设计，而类似的安全思维其实可以扩展到网络、服务器、云环境、移动设备和嵌入式产品等。TPM安全芯片本身是以安全芯片的形式在主机上隔离出一个拥有独立处理能力和存储能力的区域，在这个程度上，虚拟技术、TrustZone、智能卡等本质上是一致的，不过安全性可能并不在一个层次。
TPM 1.2的owner只有一个就是用户，而计算平台本身可能也需要使用TPM。TPM 1.2中，所有安全和隐私都在该owner的控制下。TPM 2.0将这种控制功能进行了隔离，给出了三个控制域：安全域或者存储域（owner为用户，用户正常的安全功能）；隐私域（owner为平台或者用户，平台身份认证）；平台域（owner为平台，保护平台固件的完整性）。
关于TPM 2.0的三个控制域，以后的文章中会进行详细的分析。
如果TPM使用太困难，成本价格太高，又有谁会想去用呢？TPM 1.2在这方面做的并不是很好。一个安全芯片嵌入到服务器上，体现不了多少成本；但是如果在空间有限的移动设备或者嵌入式设备上配备一个安全芯片，基本没太大的价值。因此，TPM 2.0规范主要提供一个参考，以及可能实现的方式，但是并没有限制必须以安全芯片的形式存在，如可以基于虚拟技术或者ARM TrustZone、Intel TXT等进行构建，只要能提供一个可信执行环境（TEE），就可以进行构建。
-
密钥
TPM 1.2的背书密钥只有一个，就是EK，出厂时厂商就预置在芯片内，更换都很困难。takeowner后可以生成属主和唯一的存储根密钥SRK，从而可以构建密钥的存储体系。
在TPM 2.0中，EK属于隐私域，可以有多个，而且可以支持不同的非对称算法；SRK属于安全域，也可以有多个和支持不同的算法。实际上TPM 2.0的三个控制域中，都支持多密钥和多算法。
TPM 2.0的主密钥都是通过主种子，使用密钥派生算法KDF来生成。存储种子的空间比存储密钥的空间要小很多。TPM 2.0中密钥的存储通常是通过对称加密，父密钥的强度不能低于子密钥吧，要不子密钥的安全强度也无法达到其声称的size。
-
平台配置寄存器PCRs
PCRs主要用来存储系统启动和运行过程中的度量值，防止度量日志被篡改。PCRs值不只保证每次系统启动时执行相同的代码，其保证以相同的顺序执行相同的代码。
微软在win8中就使用PCR来恢复unsealing Bitlocker的密钥。如果系统启动过程中有任何微小的变化，都需要用户干预才能恢复，因此这个过程比较脆弱。
TPM 2.0规范运行其有多个PCRs banks，一个bank内所有PCR使用相同的算法进行扩展操作。而且不同的banks可以分配不同的PCRs。对于不同的bank，扩展操作是相互独立的，互不干扰。
-
签名
TPM 2.0的签名方法支持多种算法，和各种复杂的签名机制，包含DAA和U-Prove。
不过，TPM 2.0的签名原语设计的很灵活高效。在一个复杂的签名机制中，直接使用签名私钥的部分只是整个签名计算的很小一部分，而且是一个自包含的操作。基于这些考虑，TPM 2.0设计了灵活的签名机制，其它复杂的签名算法可以很容易使用其签名原语进行构造。
Liqun Chen在CCS 2013上的论文“Flexible and scalable digital signatures in TPM 2.0”对签名机制和实现进行了详细的描述，可以参考。
-
授权
授权即是否允许软件进程访问TPM内部的资源（密钥、计数器、NV存储空间等）。
TPM 1.2拥有不同的机制来授权客体（objects）的使用、委托使用和迁移等。而TPM 2.0提供了一个统一的框架来使用授权功能，授权功能可以通过各种独特的方式进行组合来增加灵活性。
TPM 2.0允许使用明文密码和HMAC的授权，也允许使用多个授权限定符来构造任意复杂的授权策略。增强的授权机制是TPM 2.0的一个特色。
TPM 1.2的授权比较受限制，唯一的授权访问方式是基于passwords和PCR值。例如，为了使用TPM内部的一个密钥，软件需要证明其拥有某个password的知识（通过hash的方式嵌入在可信命令中）；而且可以将该密钥与特定的PCR状态seal在一起。这使得TPM1.2的授权机制缺乏灵活性。通常一个计算机平台拥有多个用户，如何共享TPM密钥和数据是比较困难的。不同用户由于password不一样，他们知道的密钥集合也是相互独立的。系统管理员如何授权这些密钥的使用是一个难点。
TPM 1.2中，软件通过授权会话证明其拥有password（消息验证码），在命令需要授权前通常通过一个独立的命令来开启会话。TPM 2.0提出了增强的授权机制（Enhanced Authorization，EA）。
TPM 2.0对密钥和数据的授权使用方式进行了扩展，授权会话变成了策略会话，多个授权方式可以通过布尔逻辑的形式进行组合。例如，在一个场景中，Alice和Bob两个用户拥有不同的passwords，现在想要让他们可以访问同一个密钥，可以创建一个策略“当且仅当Password(Alice) or Password(Bob),允许访问密钥”。软件进程可以先创建策略，在生成TPM密钥或者数据时指定该策略的哈希值即可，TPM不需要知道策略的详情，hash值足够。
-
TPM 2.0的授权方式总结
Passwords：与TPM 1.2类似
PCR值：与TPM 1.2一样，不过布尔逻辑加法表示可以使用多个PCR状态
TPM counter or NVRAM value：需要计数器或者NV空间拥有某个特定值
Physical presence：需要用户在计算机平台的物理现场
Commands：客体只能被给定的一组命名使用
Digital signature from a public key：允许使用外部智能卡来作为授权条件
-
TPM芯片的使用
影响TPM 1.2使用的最大一个障碍是，PC厂商将TPM默认置为关闭状态。为了激活TPM的使用，用户必须进入固件（PC上通常为BIOS），找到管理TPM安全芯片的目录，将其激活。之所以有这个决定，主要是因为TCG早期受到了外面质疑的影响。质疑者认为使用TPM可能导致PC平台绑定特定的软件，而影响其他软件的使用，特别是厂商可以借此推广自己的软件。TCG因此推荐默认情况下关闭TPM。这实际上是一个资源的浪费，既然不用TPM，为啥要在上亿的PC平台上配备安全芯片呢？老百姓用不到，可以只在面向特定安全领域的终端上安装此芯片。国内TCM在这方面做得还好，只是一些特定型号的安全主机才会配备TCM芯片，并不是每个PC平台都装。
既然要在BIOS中对TPM的使用进行激活，而实际上大部分用户都没有用过BIOS，这样势必导致大部分TPM永远沉睡在主板上。即便激活了TPM 1.2，其状态是没有属主的（unowned），需要通过一个特定的命令来建立属主，往往第一个建立属主的人才是TPM的实际拥有者。在非属主状态，能使用的TPM很有限，没有SRK，密钥也无法创建或者加载，PCR状态也无法进行验证。在TPM 1.2中，固件（BIOS）无法验证启动状态（boot state），固件可以哈希代码并扩展PCRs，但是检查具体的度量值只能靠更上层的操作系统或者应用程序。
在TPM 2.0中对这些情况进行了修复。首先，TPM默认状态应该是开启的。其次，增加了平台域，保证平台固件也可以操作完整的TPM资源，即固件可以创建密钥、加密数据、验证PCR值等。这意味着，平台固件和平台用户可以同时成为TPM的属主（owner）。固件开发者可以使用这种能力来保证一个安全的预引导环境，类似操作系统使用TPM的能力来保护其操作以及上层应用。
TPM 2.0规范
TPM 1.2规范对功能的描述采用伪代码的形式，虽然更加正式，但是厂商实现时在细节上还是会存在一定的误解。TPM 2.0规范采用C语言的形式进行了描述，为不同厂商实现时提供了标准的指导。吐槽一下，说实话，TPM2.0的标准看起来也很费劲，对于一个不懂可信计算的开发人来说，让其根据规范实现芯片，绝对是一种煎熬。就算懂点可信计算，根据其规范理解其意思也是一个煎熬的过程，part 1写的不太详细，而后面C代码的关联性又没那么强。不管怎么，对于搞可信计算的人来说，认真研读TPM2.0规范，还是很有收获的，在后面的博客中，将不断总结对TPM 2.0规范的研读，下面给出TPM 2.0四部分概述：
-
Part1是比较系统的介绍，要了解可信平台模块的基本思想和原理，主要参考Part1吧
-
Part2给出TPM接口的变量、数据类型、数据结构和常量
-
Part3总结TPM能执行的所有命令，对于每个命令给出命令请求和响应的格式，并且通过C代码形式分析了每个命令的执行流程
-
Part4给出了Part3中命令代码用到的算法和方法
实际使用可信计算是很多命令的组合，因此，就算了解每个命令的意思，具体使用时还必须从整体上思考，才能组合出实际的应用。
参考
[1] Trusted Computing Group, TPM Library Specification, http://www.trustedcomputinggroup.org/resources/tpm_library_specification
[2] Justin D. Osborn and David C. Challener. Trusted Platform Module Evolution, http://www.jhuapl.edu/techdigest/TD/td3202/32_02-Osborn.pdf
[3] Liqun Chen. From TPM 1.2 to TPM 2.0, http://www.iaik.tugraz.at/content/about_iaik/events/ETISS_INTRUST_2013/ETISS/
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
