TPM 2.0密钥迁移协议研究

2018-10-26宋敏，谭良

小型微型计算机系统 2018年9期

宋敏，谭良

1(四川师范大学计算机学院，成都 610068)2(中国科学院计算技术研究所，北京 100190)

1 引言

可信计算技术的基本思想是：在通用计算平台上嵌入一个防篡改的硬件可信安全芯片，利用芯片的安全特性保证系统按照预期的行为执行，从根本上提高终端的安全性[1].TPM (Trusted Platform Module，简称TPM)[2，3]是国际广泛使用的、是符合可信平台模块标准的安全芯片，具有密码学功能和受保护的存储空间，能够为可信计算平台提供密钥管理、平台数据保护、完整性存储与报告、身份标识等功能[4-6].

TPM密钥管理是其非常重要的功能[7，8]，它是TPM能够有效地提供其他各项功能的前提和基础.为了满足密钥的安全存储、分发和备份，TPM采用层次型的存储保护体系，并提供密钥迁移(复制)接口.TPM2.0[9]抛弃了TPM1.1、TPM1.2的密钥迁移接口而采用密钥复制接口，其密钥复制接口包括TPM2_Duplicate()和TPM2_Import()两个.通常，用户或上层应用可以通过以上接口设计密钥迁移协议，将源TPM中的密钥迁移到目的TPM中，以实现TPM芯片间密钥的共享.为了保证整个迁移过程中密钥的安全，需要保证其机密性、完整性和认证性.

目前，已有密钥迁移协议主要采用的是TPM1.1和TPM1.2的迁移接口，如文献[10-12]等，而基于TPM2.0密钥复制接口的密钥迁移协议还很少.但对研究基于TPM2.0密钥复制接口的密钥迁移协议仍然很有必要，因为这样的研究会发现TPM2.0密钥复制接口存在的问题，促进《TPM-Rev-2.0-Part-1-Architecture-01.38》规范的进一步完善.

2 相关工作

在TPM1.1和TPM 1.2密钥迁移机制的分析方面，文献[10]用一阶逻辑语言建立TPM API的形式化模型，并对TPM API进行了全面的逻辑推理分析，其中对密钥迁移API的分析指出TPM1.1的弱点在于迁移目标由源TPM的owner指定，目标TPM并不参与迁移，目标TPM在接收可迁移密钥时，可迁移密钥有可能已经泄漏.因此具有较大的安全隐患.文献[11]应用π演算对TPM进行形式化建模，并使用自动定理证明工具ProVerif验证其安全属性.作者分析了TPM CMK(certifiable migratable key)的RESTRICT_ MIGRATE迁移模式，分析结果表明：若作为第三方的迁移权威(migration authority，简称MA)用软件处理迁移数据，则敌手能获得被迁移密钥的私钥.作者建议TPM规范强制要求MA使用TPM代替软件处理迁移数据.文献[12]对TPM可迁移密钥的安全性进行了分析，指出TPM提供密钥迁移机制的同时，降低了可迁移密钥的安全保护强度，敌手能够利用TPM的密钥迁移类接口和密钥加载接口破坏TPM可迁移密钥的安全性.文中给出的针对密钥迁移类接口的攻击与本文5.3节中的两种攻击类似，导致该类攻击的原因同样是由于缺少源TPM和目标TPM间的身份认证.但是由于TPM缺少具有身份标识作用的加解密密钥，因此目前该类攻击在TPM密钥迁移过程中难以避免.

在TPM2.0密钥迁移机制的分析方面，文献[13]建立了TPM2.0保护存储API的抽象模型，并利用类型系统证明了TPM2.0保护存储的安全性.证明结果表明，TPM2.0保护存储中的密钥复制类接口是安全的.但没有证明采用TPM2.0密钥复制接口来实现密钥迁移协议是安全的.文献[14]对TPM2.0密钥管理API的安全性进行了形式化分析，证明了密钥存储和使用类接口能够保证TPM不可复制密钥的安全性，并发现了针对密钥复制类接口的两种攻击.作者提出了该类接口的改进方案，并证明了利用改进的接口实施密钥复制能够保证被复制密钥的安全性.文献[15]分析了可信平台模块(TPM)2.0密钥复制的相关流程，对于其中存在的密钥隐私泄露安全问题进行了改进.在用户不安全复制传输情形下，从TPM管理者的角度出发提出了一套基于TPM自身的加密传输协议.通过利用TPM自身产生安全密钥，对未受保护的用户敏感数据进行加密，并通过签名的方式保障传输的可靠性.但文献[14,15]并没考虑到当新父密钥是对称密钥时，innerwrap中的对称加密密钥以及outerwrap中的密钥种子如何在源TPM与目标TPM之间安全交换的问题.

另外，对于我国TCM芯片，其密钥迁移模块目前并不支持密钥复制接口，而只支持“创建迁移授权”、“创建迁移密钥数据块”和“导入迁移密钥数据块”三个接口.文献[16]指出由该芯片的密钥迁移模块实现的密钥迁移协议存在两个问题：其一是对称密钥不能作为被迁移密钥的新父密钥，违背了TCM的初始设计思想；其二缺少交互双方TCM的相互认证，导致源TCM的被迁移密钥可以被外部敌手获得，并且敌手可以将其控制的密钥迁移到目标TCM中.针对上述问题，作者提出两个新的密钥迁移协议：协议1遵循TCM目前的接口规范，以目标TCM的PEK(platform encryption key)作为迁移保护密钥，能够认证目标TCM，并允许对称密钥作为新父密钥;协议2简单改动了TCM接口，以源TCM和目标TCM进行SM2密钥协商，得到的会话密钥作为迁移保护密钥，解决了上述两个问题，并且获得了前向安全属性.最后，使用形式化分析方法对上述协议进行安全性分析，分析结果显示，协议满足正确性和预期的安全属性.

从以上分析可以看出，早期协议TPM1.1、TPM1.2以及TCM的密钥迁移并不是采用密钥复制方式，并不支持密钥复制接口，而采用TPM2.0复制接口来实现密钥迁移的已有工作还存在不足.

3 TPM2.0密钥复制接口的相关分析

本节从TPM2.0密钥类型和结构、密钥存储保护体系、密钥复制类接口和innerwrap，outerwrap这4个方面对TPM2.0密钥对象复制机制进行分析.

3.1 TPM2.0密钥类型

按照不同的分类方式有不同的分类结果，这里我们仅介绍与本文有关的分类方式——根据密钥属性分类.

表1 密钥可复制分类表Table1 Classification table of Key which can be copied

TPM2.0中密钥对象除了基本属性外，还包括一些其他属性，如fixedTPM和fixedParent、stclear、sensitiveDataOrigin、userWithAuth、adminWithPolicy、noDA和encryptedDuplication.根据fixedTPM和fixedParent的属性组合，可以将密钥对象分为可复制密钥和不可复制密钥.如表1所示.本文所指的可复制密钥，就是指fixedTPM=0和fixedParent=0的密钥.

3.2 TPM2.0密钥对象保护体系

TPM2.0所有的密钥对象形成一颗密钥树，其中种子密钥对象一般作为根密钥保护所在层次的子密钥，如图1所示.

图1 TPM2.0的密钥树Fig.1 TPM2.0 key tree

在图1所示的密钥树中，TPM2.0将密钥对象分为可复制密钥对象、可跟随父密钥复制密钥对象以及不可复制密钥对象.不可复制密钥对象只能与原TPM芯片绑定，不能被复制；而可复制密钥对象可以复制到其他TPM中使用，而可跟随父密钥复制密钥对象的存在使得在密钥树中一次能复制一颗子树，比TPM1.2中的密钥迁移更灵活，效率更高.

图2 TPM2.0的密钥层次保护模型Fig.2 TPM2.0 key hierarchy protection model

如图2所示，在TPM2.0密钥树中，存储父密钥采用对称加密方法保护孩子密钥，加密密钥由父密钥的密钥种子seedValue产生，加密算法由父密钥的nameAlg指定.这一点与TPM1.2中用非对称密钥的私钥对孩子的私钥进行加密保护不同.因此，在TPM2.0的密钥树中，无论是对称密钥还是非对称密钥，只要是存储密钥，都可以作为父节点.

3.3 TPM2.0复制接口

接口1.复制数据生成接口：TPM2_Duplication(objectHandle，newParentHandle，encrptionKeyIn，symmetricAlg).其中objectHandle为复制密钥的句柄，newParentHandle是新父密钥句柄，encryptionKeyIn是innerwrap加密密钥，该密钥或由caller传入，或是由TPM重新产生，symmetricAlg是对称加密算法.该函数执行后返回三个值，其一是encryptionKeyOut，encryptionKeyOut返回的是由TPM产生的内部加密密钥，如果TPM没产生内部加密密钥，该值返回null，其二是duplicate，duplicate是复制数据，封装了被复制密钥的SensitiveArea；最后是outSymSeed，outSymSeed是outerwrap密钥种子，由它可以产生外部对称加密的密钥.

该接口的执行过程包括如下过程：

1)检查复制密钥的属性fixedTPM和fixedParent如果设置不是(0，0)就结束复制过程；

2)检查复制密钥的属性encryptedDuplication，如果设置为1，则判断newParentHandle是否为TPM_RH_NULL，如果为TPM_RH_NULL，则结束复制过程，否则转到(3)；如果设置为0，则转到(4)；

3)执行innerwrap，用encrptionKeyIn对迁移密钥的sensitiveArea进行加密和Hash运算，生成encSensitive；

4)执行outerwrap，用密钥种子seed生成加密密钥和HMAC密钥，对encSensitive进行加密和HAMC运算，得到dupSensitive和outerHMAC；

接口2.复制数据导入接口：TPM2_Import(newparentHandle，encryptionKey，duplicate，inSymSeed).其中newparentHandle是新父密钥句柄，encryptionKey是源TPM内的innerwrap密钥，其值由TPM2_Duplicate的返回值encryptionKeyOut提供，duplicate是复制数据，此值由TPM2_Duplicate的返回值duplicate提供，inSymSeed是源TPM内的outerwrap密钥种子，此值由PM2_Duplicate的返回值outSymSeed提供.

该接口的执行过程包括如下过程：

1)检查迁移密钥的属性fixedTPM和fixedParent，如果设置不是(0，0)就结束导入过程；

2)检查新父密钥是否为存储密钥，如果不是，结束导入过程；

3)检查innerwrap的加密密钥encryptionKey是否正确，如果不正确，结束导入过程；

4)检查outerwrap的密钥种子inSymSeed是否正确，如果不正确，结束导入过程；

5)由inSymSeed和newparentHandle恢复出源TPM的outerwrap的HAMC密钥，通过outerHAMC验证dupsensitive及name的真实性和完整性；然后再恢复出outerwrap的对称密钥，对dupsensitive解密得到encsensitive；

6)用encryptionKey对encsensitive进行解密得到被复制密钥的sensitive；并对sensitive及name进行完整性校验.

3.4 innerwrap和outerwrap分析

由3.3节可以看出，在利用TPM2_Duplication接口和TPM2_Import接口进行密钥迁移时，复制过程的安全性不仅依赖于innnerwrap，而且依赖于outerwrap，下面我们分别对innnerwrap和outerwrap进行分析.

3.4.1 innerwrap过程

通过对《TPM-Rev-2.0-Part-1-Architecture-01.38》和《TPM-Rev-2.0-Part-3-Commands-01.38-code》分析发现，密钥复制过程中是否进行innerwrap是由复制密钥的属性encryptedDuplication和新父密钥的密钥句柄类型决定，只有当encryptedDuplication=1且newParentHandle！=TPM_RH_NULL时，innerwrap才能发生.innerwrap过程中需要的对称加密密钥由caller决定，caller可以选择输入，也可以选择由TPM自行产生.

innerwrap可以在复制过程中为复制密钥提供完整性和机密性，包括两个步骤，首先是用复制密钥的Hash算法计算复制密钥sensitive和name的哈希值innerIntegrity，保证复制密钥的完整性.然后用某对称加密算法的CBF模式对innerIntegrity||sensitive进行加密得到encSensitive.其中需要的对称加密算法和密钥由caller将其作为参数传入TPM2_Duplication；

从以上过程可以看出，源TPM要完成innerwrap，需要确保加密密钥安全地传递到目的TPM.因此，如何将此加密密钥安全地传递到目的TPM是需要考虑的重要问题.需要考虑如下3种情况：

1)如果新父密钥是非对称密钥，无论复制密钥是对称密钥还是非对称密钥，innerwrap中需要的密钥都可以由源TPM产生或由caller输入，且可以采用《TPM-Rev-2.0-Part-1-Architecture-01.38》中B.10.3 或C.6.3中规定的算法进行保护交换.

2)如果新父密钥是对称密钥，且复制密钥是非对称密钥，则innerwrap中需要的密钥可以由目的TPM产生，且可以采用《TPM-Rev-2.0-Part-1-Architec -ture-01.38》中B.10.3 或C.6.3中规定的算法进行保护交换.

3)如果新父密钥是对称密钥，且复制密钥也是对称密钥，则innerwrap中需要的密钥无论是由源TPM产生或目的TPM产生，《TPM-Rev-2.0-Part-1-Architecture-01.38》中都未给出此密钥的保护交换办法.

3.4.2 outer wrap过程

通过对《TPM-Rev-2.0-Part-1-Architecture-01.38》和《TPM-Rev-2.0-Part-3-Commands-01.38-code》分析发现，密钥复制过程中是否进行outerwrap是由新父密钥的密钥句柄类型决定，当newParentHandle！=TPM_RH_NULL时，outerwrap就会发生，当newParentHandle=TPM_RH_NULL时，outerwrap不会发生.究其原因是outerwrap过程主要由新父密钥控制，如果新父密钥的句柄为TPM_RH_NULL，则新父密钥不能为outerwrap提供需要的算法及参数.

outerwrap可以在复制过程中为复制密钥提供机密性、完整性以及和对新父密钥的认证性.包括两个步骤，第一是对encSensitive进行加密.具体过程为：首先获得一密钥种子seed，然后将此密钥种子、新父密钥的npNameAlg和复制密钥的Name作为KDFa()的参数产生对称加密密钥，最后采用新父密钥的对称加密算法对encSensitive进行加密得到dupSensitive；第二是对dupSensitive和Name进行HAMC运算，产生消息码outerHMAC.具体过程为：首先用Seed，和新父密钥的npNameAlg作为KDFa()的参数产生HAMC密钥，然后采用新父密钥的HMAC算法进行运算获得消息码outerHMAC.

从以上过程可以看出，源TPM要完成outerwrap，不仅需要获得新父密钥的相关参数，而且需要确保密钥种子seed能在源TPM和目的TPM之间安全地交换.需要考虑的3种情况与innerwrap过程一致.

4 基于复制接口的密钥迁移协议

通过对TPM2_Duplication接口和TPM2_Import接口的分析可知，采用TPM2.0的密钥复制接口来设计密钥迁移协议，需要将新父密钥从目标TPM传递到源TPM，源TPM调用TPM2_Duplication接口得到被复制密钥的复制数据，目标TPM调用TPM2_Import将复制数据载入.基本的流程如下：

1)目标TPM将新父密钥传递给源TPM

2)源TPM调用TPM2_Duplication接口，根据复制密钥的复制属性(fixedTPM，fixedParen，encryptedDuplication)和新父密钥的newParentHandle类型实施innerwrap和outerwrap，得到复制数据；

3)将复制数据传递给目标TPM，目标TPM调用TPM2_Import将被复制密钥加载到新父密钥下我们将在4.1节给出详细的密钥迁移协议流程，4.2节对该协议进行分析.

4.1 基于复制接口的密钥迁移协议

基于密钥复制接口来设计密钥迁移协议通常包括6个参与实体：源TPM、源TPM的所有者、目标TPM、目标TPM的所有者、源TPM所在的主机、目标TPM所在的主机，其中，前4个实体是可信的，而源和目标TPM所在的主机被认为是不可信的.表2为协议相关符号及函数说明.

根据第3节的分析和规范要求，我们设计出基于复制接口的密钥迁移协议，其流程如下：

1.HD→HS：newParent.publicAera，newparentHandle，symmetricAlg；

2.OS：调用复制接口

(1)获得objectHandle，newparentHandle

(2)决定encryptionKeyin的产生方式，可以输入，可以由TPM内部产生RNG；

(3)调用接口TPM2_Duplication(objectHandle，newParentHandle，encrptionKeyIn，symmetricAlg)；

表2 协议相关符号及函数说明Table2 Protocol related symbols and function description

3.TS：执行复制过程

(1)检查新父密钥是否为存储密钥，如不是，结束复制过程，转到6；

(2)检查复制密钥的属性fixedTPM和fixedParent，如果设置不是(0，0)就结束复制过程，转到6；

(3)检查复制密钥的属性encryptedDuplication，如果设置为1，则判断newParentHandle是否为TPM_RH_NULL，如果为TPM_RH_NULL，则结束复制过程，转到6；否则转到(4)；如果设置为0，newParentHandle不为TPM_RH_NULL则转到(6)，否则转向(8)；

(4)执行innerwrap，由caller输入或TPM产生encrptionKeyIn，并用encrptionKeyIn对复制密钥的sensitiveArea进行加密，生成encSensitive；

(5)对encrptionKeyIn进行保护，分为两种情况：

•如果新父密钥是非对称密钥，如RSA或ECC密钥，则用新父密钥的公钥加密encrptionKeyIn，即CencrptionKeyIn=RSA_OAEP(newParentHandle，encrptionKeyIn)或ECC_ECDH(newParentHandle，encrptionKeyIn)，并将sysmetrickey=CencrptionKeyIn；

•如果新父密钥是对称密钥，则直接sysmetrickey=encrptionKeyIn.

(6)执行outerwrap，由TPM产生密钥种子Seed，用密钥种子Seed生成加密密钥和HMAC密钥，对encSensitive进行加密和HAMC运算，得到dupSensitive和outerHMAC；

(7)对Seed进行保护，分两种种情况：

•如果新父密钥是非对称密钥，与(5)中情况一致；

•如果新父密钥是对称密钥，则直接sysmetricSeed=Seed；

结束复制过程，转到4；

(8) 对复制密钥既不进行innerwrap，也不进行outerwrap，则dupSensitive=sensitiveArea，sysmetrickey=NULL，sysmetricSeed=NULL；

4.HS→HD：dupSensitive，outerHMAC，sysmetrickey，sysmetricSeed；

5.TD：执行导入过程

(1)根据sysmetricSeed参数是否为NULL来判断是否进行了outerwrap，如果为NULL，转到下一步；否则直接得到seed或用私钥解密sysmetricSeed得到seed，按照symmetricAlg算法生成HMAC密钥HMACkey并对dupSensitive||name进行HAMC运行，得到的值与outerHMAC比较，如果不相等，终止导入过程，转到6；如果相等，则用seed生成对称加密密钥symkey并解密dupSensitive得到encSensitive；

(2)根据sysmetrickey参数是否为NULL来判断是否进行了innerwrap.如果为NULL，则转到6；否则直接得到encrptionKeyIn或用新父密钥的私钥解密sysmetrickey得到encrptionKeyIn，用symmetricAlg算法对encSensitive进行解密得到Sensitive和name，用Hash算法对Sensitive||name进行完整性验证，验证通过，则表明迁移成功，转到6，；验证不通过，则表明迁移不成功，转到6；

6.结束迁移过程

4.2 存在的问题

一方面，从4.1节可以看出，此密钥迁移协议存在如下安全问题：

问题1.该协议缺少源TPM和目标TPM间的身份认证，导致密钥能够在敌手和TPM间迁移.存在着如下两种情况：(1)源TPM不能认证newParent是不是目标TPM的密钥，导致敌手可以用其控制的密钥迁移源TPM的密钥，并获得密钥明文；(2)目标TPM不能认证迁移数据是否来自源TPM，使敌手可以将其控制的密钥迁移到目标TPM中.

问题2.当复制密钥的属性encryptedDuplication=0且新父密钥的句柄newParentHandle= TPM_RH_NULL时，复制接口不能实施innerwrap和outerwrap，迁移密钥将以明文传输而造成泄露.

问题3.当新父密钥是对称密钥时，innerwrap中的对称加密密钥以及outerwrap中的密钥种子如何在源TPM与目标TPM之间安全交换，《TPM-Rev-2.0- Part-1- Architecture-01.38》并没有给出具体的解决办法.

另一方面，4.1节的密钥迁移协议中复制流程比较复杂，其中有几个关键的属性决定复制流程.首先，密钥能否复制是由复制密钥的属性(fixedTPM，fixedParent)决定；其次，复制过程中是否实施innerwrap由复制密钥的encryptedDuplication决定；第三，复制过程中是否实施outerwrap由新父密钥的句柄类型决定；第四，innerwrap中对称密钥和outerwrap中密钥种子的保护交换还依赖新父密钥的密钥类型.不同的属性值决定了复制过程的不同流程，在所有的流程中，部分流程的输出结果是存在安全隐患的.由于所有的判断均在TPM内部进行，在执行完成之前外界无法知道TPM2_Duplication()的输出结果，也就无法提前掌握输出结果的保护情况.为了保证复制过程的安全，需要提前掌握复制流程.因此，外界需要一个控制中心，提前获知复制密钥属性和新父密钥类型和句柄类型，从而提前掌握复制流程并对复制过程的输出结果采取合理的保护措施.

5 实验验证与评价

5.1 实验环境

本节所有实验均利用OpenSSL进行模拟仿真实现.本实验共使用3台计算机，分别称为source TPM(源TPM)，target TPM(目的TPM)，adversary TPM(敌手，中间人).具体环境配置如表3所示.

表3 实验环境相关配置表Table 3 Experimental environment related configuration table

5.2 实验过程

为了表述方便首先假定一个场景：密钥migratekey需要从源平台source TPM迁移到目的平台target TPM，在source TPM端保护migratekey的父密钥是parentkey，而target TPM端选定的将要保护migratekey的父密钥是Newparentkey简称nparentkey.在innerwrap阶段所用的加密密钥为encryptionKeyin，加密encryptionKeyin后得到encryptionKeyout，最后得到的加密数据块为encSensitive；在outerwrap阶段所用的加密种子为seed，由seed产生的对称加密密钥和HMAC密钥分别为ks，hmackey得到的加密数据块为dupSensitive和outerHMAC.

首先，我们用OpenSSL技术在源TPM和目标TPM所在主机上构建TPM2.0密钥对象保护层次体系，结果如图3、图4所示.

图3 源TPM的密钥层次结构Fig.3 Key hierarchy of the source TPM

然后，我们根据4.1中设计的密钥迁移协议发现不存在只进行innerwrap的情况，同时根据4.2节提到的关键属性，我们一共梳理出13种情况.为了节约篇幅，各种情况对应的属性取值如表4所示.其中newParentHandle取值为1代表newParentHandle=!TPM_RH_NULL，为0反之.新父密钥或迁移密钥取值为1表示对称密钥，为0表示非对称密钥，S表示源TPM，T表示目的TPM.

图4 目的TPM的密钥层次结构Fig.4 Key hierarchy of the target TPM

表4 属性取值情况表Table 4 Experimental environment related configuration table

可以看出其中情况1不能进行复制操作.情况5，8，11与情况2类似，情况6与情况3类似，情况7与情况4类似，且复制流程也基本一致.因此，后续篇章对于相同的情况不再一一叙述.

情况2具体的执行流程如图5、图6所示.

图5 情况2中源TPM的执行流程图Fig.5 In case 2 source TPM implementation flow chart

图6 情况2中目的TPM的执行流程图Fig.6 In Case 3 target TPM implementation flow chart

由于迁移过程既不进行innerwarp也不进行outerwarp，迁移密钥将以明文传输，其明文信息如图7所示.

图7 情况2中迁移密钥以明文形式传输Fig.7 In case 2，the migration key is transmitted in clear text

情况3协议的执行过程由源TPM发起，seed在源TPM方产生.迁移过程中仅执行outerwrap，具体的执行流程如图8、图9所示.

图8 情况3中源TPM的执行流程图Fig.8 In case 3 source TPM implementation flow chart

图9 情况3中目的TPM的执行流程图Fig.9 In case 3 target TPM implementation flow chart

情况4迁移过程中既要执行innerwrap，又要执行outerwrap，具体的执行流程如图10、图11所示.

图10 情况4中源TPM的执行流程图Fig.10 In case 4 source TPM implementation flow chart

图11 情况4中目标TPM的执行流程图Fig.11 In case 4 target TPM implementation flow chart

情况9协议的执行过程由目的TPM发起，seed在目的TPM方产生，因此需要先在目的TPM方用迁移密钥的公钥对seed加密，然后传输给源TPM进而解密得到seed.后续过程与情况3基本一致.

情况10协议的执行过程由目的TPM发起，seed和encryptionKeyin在目的TPM方产生.因此需要先在目的TPM方用迁移密钥的公钥对seed和encryptionKeyin加密，然后传输给源TPM进而解密得到seed和encryptionKeyin.后续过程与情况4基本一致.

情况12协议的执行过程可由目的TPM或源TPM发起，seed亦可在目的TPM或源TPM方产生，但不管由哪一方发起，seed都将以明文传输.具体的执行流程如图12、图13所示.

图12 情况12中源TPM的执行流程图Fig.12 In case 12 source TPM implementation flow chart

图13 情况12中目的TPM的执行流程图Fig.13 In case 12 target TPM implementation flow chart

情况13，协议的执行过程可由目的TPM或源TPM发起，seed和encryptionKeyin亦可在目的TPM或源TPM方产生，但不管由哪一方发起，seed和encryptionKeyin都将以明文传输.具体的执行流程图14、图15所示.

图14 情况13中源TPM的执行流程图Fig.14 In case 13 source TPM implementation flow chart

5.3 实验评价

5.3.1 安全性评价

从5.2节的实验可以看出，TPM2.0的密钥复制只能在某些条件下保证迁移密钥的完整性，机密性，但在另一些情况下仍然存在安全威胁.5.2节的实验结果完全验证了我们在4.2节中的理论分析.下面我们做一一说明.

图15 情况13中目的TPM的执行流程图Fig.15 In case 13 target TPM implementation flow chart

1.针对4.2节中的问题1指出：协议缺少目的TPM和源TPM间的相互认证，导致密钥可在敌手与TPM之间迁移.我们以5.1节的实验环境为基础，给出具体的攻击方法：敌手使用自己可控的密钥做为新父密钥进行密钥复制，然后用可控密钥进行解密得到复制密钥的sensitiveArea，从而实现将密钥复制到敌手可控的密钥下.

2.4.2中的问题2指出，当复制接口不能实施innerwrap和outerwrap，迁移密钥将以明文传输而造成泄露.具体情况见5.2节中的情况2.

3.4.2节中问题3指出：当新父密钥是对称密钥时，innerwrap中的对称加密密钥以及outerwrap中的密钥种子如何在源TPM与目标TPM之间安全交换，《TPM-Rev-2.0-Part-1-Architecture-01.38》并没有给出具体的解决办法.我们在5.2节中将此问题分为两种情况：(1)当复制密钥是非对称密钥时，我们将协议的执行过程改由目的TPM发起，seed或encryptionKeyin改在目的TPM方产生，这样就可以按规范在源TPM与目标TPM之间安全交换seed或encryptionKeyin，如情况9，情况10.(2)当复制密钥也是对称密钥时，无论是在源TPM方或目的TPM方产生seed或encryptionKeyin，都无法采用规范中的办法在源TPM与目标TPM之间安全交换.此时，seed或encryptionKeyin将以明文传送，安全隐患很大.如情况12、情况13等.

5.3.2 性能评价

密钥迁移性能我们主要考查迁移时间.对于密钥迁移的每一种情况，我们忽略密钥层次结构的建立、实验过程中人工输入运行选项的延迟以及服务器与客户端建立连接的等待时间，只计算密钥复制迁移过程的时间.例如，在情况3中源TPM所用时间为27128us，目的TPM所用时间为74394us，共计时间27128+74394=0.101522s.图16为上述13种情况的密钥复制迁移耗时图.