宋 敏，譚 良

1(四川師范大學 計算機學院，成都 610068)2(中國科學院 計算技術(shù)研究所，北京 100190)

1 引 言

可信計算技術(shù)的基本思想是：在通用計算平臺上嵌入一個防篡改的硬件可信安全芯片，利用芯片的安全特性保證系統(tǒng)按照預(yù)期的行為執(zhí)行，從根本上提高終端的安全性[1].TPM (Trusted Platform Module，簡稱TPM)[2，3]是國際廣泛使用的、是符合可信平臺模塊標準的安全芯片，具有密碼學功能和受保護的存儲空間，能夠為可信計算平臺提供密鑰管理、平臺數(shù)據(jù)保護、完整性存儲與報告、身份標識等功能[4-6].

TPM密鑰管理是其非常重要的功能[7，8]，它是TPM能夠有效地提供其他各項功能的前提和基礎(chǔ).為了滿足密鑰的安全存儲、分發(fā)和備份，TPM采用層次型的存儲保護體系，并提供密鑰遷移(復(fù)制)接口.TPM2.0[9]拋棄了TPM1.1、TPM1.2的密鑰遷移接口而采用密鑰復(fù)制接口，其密鑰復(fù)制接口包括TPM2_Duplicate()和TPM2_Import()兩個.通常，用戶或上層應(yīng)用可以通過以上接口設(shè)計密鑰遷移協(xié)議，將源TPM中的密鑰遷移到目的TPM中，以實現(xiàn)TPM芯片間密鑰的共享.為了保證整個遷移過程中密鑰的安全，需要保證其機密性、完整性和認證性.

目前，已有密鑰遷移協(xié)議主要采用的是TPM1.1和TPM1.2的遷移接口，如文獻[10-12]等，而基于TPM2.0密鑰復(fù)制接口的密鑰遷移協(xié)議還很少.但對研究基于TPM2.0密鑰復(fù)制接口的密鑰遷移協(xié)議仍然很有必要，因為這樣的研究會發(fā)現(xiàn)TPM2.0密鑰復(fù)制接口存在的問題，促進《TPM-Rev-2.0-Part-1-Architecture-01.38》規(guī)范的進一步完善.

2 相關(guān)工作

在TPM1.1和TPM 1.2密鑰遷移機制的分析方面，文獻[10]用一階邏輯語言建立TPM API的形式化模型，并對TPM API進行了全面的邏輯推理分析，其中對密鑰遷移API的分析指出TPM1.1的弱點在于遷移目標由源TPM的owner指定，目標TPM并不參與遷移，目標TPM在接收可遷移密鑰時，可遷移密鑰有可能已經(jīng)泄漏.因此具有較大的安全隱患.文獻[11]應(yīng)用π演算對TPM進行形式化建模，并使用自動定理證明工具ProVerif驗證其安全屬性.作者分析了TPM CMK(certifiable migratable key)的RESTRICT_ MIGRATE遷移模式，分析結(jié)果表明：若作為第三方的遷移權(quán)威(migration authority，簡稱MA)用軟件處理遷移數(shù)據(jù)，則敵手能獲得被遷移密鑰的私鑰.作者建議TPM規(guī)范強制要求MA使用TPM代替軟件處理遷移數(shù)據(jù).文獻[12]對TPM可遷移密鑰的安全性進行了分析，指出TPM提供密鑰遷移機制的同時，降低了可遷移密鑰的安全保護強度，敵手能夠利用TPM的密鑰遷移類接口和密鑰加載接口破壞TPM可遷移密鑰的安全性.文中給出的針對密鑰遷移類接口的攻擊與本文5.3節(jié)中的兩種攻擊類似，導(dǎo)致該類攻擊的原因同樣是由于缺少源TPM和目標TPM間的身份認證.但是由于TPM缺少具有身份標識作用的加解密密鑰，因此目前該類攻擊在TPM密鑰遷移過程中難以避免.

在TPM2.0密鑰遷移機制的分析方面，文獻[13]建立了TPM2.0保護存儲API的抽象模型，并利用類型系統(tǒng)證明了TPM2.0保護存儲的安全性.證明結(jié)果表明，TPM2.0保護存儲中的密鑰復(fù)制類接口是安全的.但沒有證明采用TPM2.0密鑰復(fù)制接口來實現(xiàn)密鑰遷移協(xié)議是安全的.文獻[14]對TPM2.0密鑰管理API的安全性進行了形式化分析，證明了密鑰存儲和使用類接口能夠保證TPM不可復(fù)制密鑰的安全性，并發(fā)現(xiàn)了針對密鑰復(fù)制類接口的兩種攻擊.作者提出了該類接口的改進方案，并證明了利用改進的接口實施密鑰復(fù)制能夠保證被復(fù)制密鑰的安全性.文獻[15]分析了可信平臺模塊(TPM)2.0密鑰復(fù)制的相關(guān)流程，對于其中存在的密鑰隱私泄露安全問題進行了改進.在用戶不安全復(fù)制傳輸情形下，從TPM管理者的角度出發(fā)提出了一套基于TPM自身的加密傳輸協(xié)議.通過利用TPM自身產(chǎn)生安全密鑰，對未受保護的用戶敏感數(shù)據(jù)進行加密，并通過簽名的方式保障傳輸?shù)目煽啃?但文獻[14,15]并沒考慮到當新父密鑰是對稱密鑰時，innerwrap中的對稱加密密鑰以及outerwrap中的密鑰種子如何在源TPM與目標TPM之間安全交換的問題.

另外，對于我國TCM芯片，其密鑰遷移模塊目前并不支持密鑰復(fù)制接口，而只支持“創(chuàng)建遷移授權(quán)”、“創(chuàng)建遷移密鑰數(shù)據(jù)塊”和“導(dǎo)入遷移密鑰數(shù)據(jù)塊”三個接口.文獻[16]指出由該芯片的密鑰遷移模塊實現(xiàn)的密鑰遷移協(xié)議存在兩個問題：其一是對稱密鑰不能作為被遷移密鑰的新父密鑰，違背了TCM的初始設(shè)計思想；其二缺少交互雙方TCM的相互認證，導(dǎo)致源TCM的被遷移密鑰可以被外部敵手獲得，并且敵手可以將其控制的密鑰遷移到目標TCM中.針對上述問題，作者提出兩個新的密鑰遷移協(xié)議：協(xié)議1遵循TCM目前的接口規(guī)范，以目標TCM的PEK(platform encryption key)作為遷移保護密鑰，能夠認證目標TCM，并允許對稱密鑰作為新父密鑰;協(xié)議2簡單改動了TCM接口，以源TCM和目標TCM進行SM2密鑰協(xié)商，得到的會話密鑰作為遷移保護密鑰，解決了上述兩個問題，并且獲得了前向安全屬性.最后，使用形式化分析方法對上述協(xié)議進行安全性分析，分析結(jié)果顯示，協(xié)議滿足正確性和預(yù)期的安全屬性.

從以上分析可以看出，早期協(xié)議TPM1.1、TPM1.2以及TCM的密鑰遷移并不是采用密鑰復(fù)制方式，并不支持密鑰復(fù)制接口，而采用TPM2.0復(fù)制接口來實現(xiàn)密鑰遷移的已有工作還存在不足.

3 TPM2.0密鑰復(fù)制接口的相關(guān)分析

本節(jié)從TPM2.0密鑰類型和結(jié)構(gòu)、密鑰存儲保護體系、密鑰復(fù)制類接口和innerwrap，outerwrap這4個方面對TPM2.0密鑰對象復(fù)制機制進行分析.

3.1 TPM2.0密鑰類型

按照不同的分類方式有不同的分類結(jié)果，這里我們僅介紹與本文有關(guān)的分類方式——根據(jù)密鑰屬性分類.

表1 密鑰可復(fù)制分類表Table1 Classification table of Key which can be copied

TPM2.0中密鑰對象除了基本屬性外，還包括一些其他屬性，如fixedTPM和fixedParent、stclear、sensitiveDataOrigin、userWithAuth、adminWithPolicy、noDA和encryptedDuplication.根據(jù)fixedTPM和fixedParent的屬性組合，可以將密鑰對象分為可復(fù)制密鑰和不可復(fù)制密鑰.如表1所示.本文所指的可復(fù)制密鑰，就是指fixedTPM=0和fixedParent=0的密鑰.

3.2 TPM2.0密鑰對象保護體系

TPM2.0所有的密鑰對象形成一顆密鑰樹，其中種子密鑰對象一般作為根密鑰保護所在層次的子密鑰，如圖1所示.

圖1 TPM2.0的密鑰樹Fig.1 TPM2.0 key tree

在圖1所示的密鑰樹中，TPM2.0將密鑰對象分為可復(fù)制密鑰對象、可跟隨父密鑰復(fù)制密鑰對象以及不可復(fù)制密鑰對象.不可復(fù)制密鑰對象只能與原TPM芯片綁定，不能被復(fù)制；而可復(fù)制密鑰對象可以復(fù)制到其他TPM中使用，而可跟隨父密鑰復(fù)制密鑰對象的存在使得在密鑰樹中一次能復(fù)制一顆子樹，比TPM1.2中的密鑰遷移更靈活，效率更高.

圖2 TPM2.0的密鑰層次保護模型Fig.2 TPM2.0 key hierarchy protection model

如圖2所示，在TPM2.0密鑰樹中，存儲父密鑰采用對稱加密方法保護孩子密鑰，加密密鑰由父密鑰的密鑰種子seedValue產(chǎn)生，加密算法由父密鑰的nameAlg指定.這一點與TPM1.2中用非對稱密鑰的私鑰對孩子的私鑰進行加密保護不同.因此，在TPM2.0的密鑰樹中，無論是對稱密鑰還是非對稱密鑰，只要是存儲密鑰，都可以作為父節(jié)點.

3.3 TPM2.0復(fù)制接口

接口1.復(fù)制數(shù)據(jù)生成接口：TPM2_Duplication(objectHandle，newParentHandle，encrptionKeyIn，symmetricAlg).其中objectHandle為復(fù)制密鑰的句柄，newParentHandle是新父密鑰句柄，encryptionKeyIn是innerwrap加密密鑰，該密鑰或由caller傳入，或是由TPM重新產(chǎn)生，symmetricAlg是對稱加密算法.該函數(shù)執(zhí)行后返回三個值，其一是encryptionKeyOut，encryptionKeyOut返回的是由TPM產(chǎn)生的內(nèi)部加密密鑰，如果TPM沒產(chǎn)生內(nèi)部加密密鑰，該值返回null，其二是duplicate，duplicate是復(fù)制數(shù)據(jù)，封裝了被復(fù)制密鑰的SensitiveArea；最后是outSymSeed，outSymSeed是outerwrap密鑰種子，由它可以產(chǎn)生外部對稱加密的密鑰.

該接口的執(zhí)行過程包括如下過程：

1)檢查復(fù)制密鑰的屬性fixedTPM和fixedParent如果設(shè)置不是(0，0)就結(jié)束復(fù)制過程；

2)檢查復(fù)制密鑰的屬性encryptedDuplication，如果設(shè)置為1，則判斷newParentHandle是否為TPM_RH_NULL，如果為TPM_RH_NULL，則結(jié)束復(fù)制過程，否則轉(zhuǎn)到(3)；如果設(shè)置為0，則轉(zhuǎn)到(4)；

3)執(zhí)行innerwrap，用encrptionKeyIn對遷移密鑰的sensitiveArea進行加密和Hash運算，生成encSensitive；

4)執(zhí)行outerwrap，用密鑰種子seed生成加密密鑰和HMAC密鑰，對encSensitive進行加密和HAMC運算，得到dupSensitive和outerHMAC；

接口2.復(fù)制數(shù)據(jù)導(dǎo)入接口：TPM2_Import(newparentHandle，encryptionKey，duplicate，inSymSeed).其中newparentHandle是新父密鑰句柄，encryptionKey是源TPM內(nèi)的innerwrap密鑰，其值由TPM2_Duplicate的返回值encryptionKeyOut提供，duplicate是復(fù)制數(shù)據(jù)，此值由TPM2_Duplicate的返回值duplicate提供，inSymSeed是源TPM內(nèi)的outerwrap密鑰種子，此值由PM2_Duplicate的返回值outSymSeed提供.

該接口的執(zhí)行過程包括如下過程：

1)檢查遷移密鑰的屬性fixedTPM和fixedParent，如果設(shè)置不是(0，0)就結(jié)束導(dǎo)入過程；

2)檢查新父密鑰是否為存儲密鑰，如果不是，結(jié)束導(dǎo)入過程；

3)檢查innerwrap的加密密鑰encryptionKey是否正確，如果不正確，結(jié)束導(dǎo)入過程；

4)檢查outerwrap的密鑰種子inSymSeed是否正確，如果不正確，結(jié)束導(dǎo)入過程；

5)由inSymSeed和newparentHandle恢復(fù)出源TPM的outerwrap的HAMC密鑰，通過outerHAMC驗證dupsensitive及name的真實性和完整性；然后再恢復(fù)出outerwrap的對稱密鑰，對dupsensitive解密得到encsensitive；

6)用encryptionKey對encsensitive進行解密得到被復(fù)制密鑰的sensitive；并對sensitive及name進行完整性校驗.

3.4 innerwrap和outerwrap分析

由3.3節(jié)可以看出，在利用TPM2_Duplication接口和TPM2_Import接口進行密鑰遷移時，復(fù)制過程的安全性不僅依賴于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》分析發(fā)現(xiàn)，密鑰復(fù)制過程中是否進行innerwrap是由復(fù)制密鑰的屬性encryptedDuplication和新父密鑰的密鑰句柄類型決定，只有當encryptedDuplication=1且newParentHandle！=TPM_RH_NULL時，innerwrap才能發(fā)生.innerwrap過程中需要的對稱加密密鑰由caller決定，caller可以選擇輸入，也可以選擇由TPM自行產(chǎn)生.

innerwrap可以在復(fù)制過程中為復(fù)制密鑰提供完整性和機密性，包括兩個步驟，首先是用復(fù)制密鑰的Hash算法計算復(fù)制密鑰sensitive和name的哈希值innerIntegrity，保證復(fù)制密鑰的完整性.然后用某對稱加密算法的CBF模式對innerIntegrity||sensitive進行加密得到encSensitive.其中需要的對稱加密算法和密鑰由caller將其作為參數(shù)傳入TPM2_Duplication；

從以上過程可以看出，源TPM要完成innerwrap，需要確保加密密鑰安全地傳遞到目的TPM.因此，如何將此加密密鑰安全地傳遞到目的TPM是需要考慮的重要問題.需要考慮如下3種情況：

1)如果新父密鑰是非對稱密鑰，無論復(fù)制密鑰是對稱密鑰還是非對稱密鑰，innerwrap中需要的密鑰都可以由源TPM產(chǎn)生或由caller輸入，且可以采用《TPM-Rev-2.0-Part-1-Architecture-01.38》中B.10.3 或C.6.3中規(guī)定的算法進行保護交換.

2)如果新父密鑰是對稱密鑰，且復(fù)制密鑰是非對稱密鑰，則innerwrap中需要的密鑰可以由目的TPM產(chǎn)生，且可以采用《TPM-Rev-2.0-Part-1-Architec -ture-01.38》中B.10.3 或C.6.3中規(guī)定的算法進行保護交換.

3)如果新父密鑰是對稱密鑰，且復(fù)制密鑰也是對稱密鑰，則innerwrap中需要的密鑰無論是由源TPM產(chǎn)生或目的TPM產(chǎn)生，《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》分析發(fā)現(xiàn)，密鑰復(fù)制過程中是否進行outerwrap是由新父密鑰的密鑰句柄類型決定，當newParentHandle！=TPM_RH_NULL時，outerwrap就會發(fā)生，當newParentHandle=TPM_RH_NULL時，outerwrap不會發(fā)生.究其原因是outerwrap過程主要由新父密鑰控制，如果新父密鑰的句柄為TPM_RH_NULL，則新父密鑰不能為outerwrap提供需要的算法及參數(shù).

outerwrap可以在復(fù)制過程中為復(fù)制密鑰提供機密性、完整性以及和對新父密鑰的認證性.包括兩個步驟，第一是對encSensitive進行加密.具體過程為：首先獲得一密鑰種子seed，然后將此密鑰種子、新父密鑰的npNameAlg和復(fù)制密鑰的Name作為KDFa()的參數(shù)產(chǎn)生對稱加密密鑰，最后采用新父密鑰的對稱加密算法對encSensitive進行加密得到dupSensitive；第二是對dupSensitive和Name進行HAMC運算，產(chǎn)生消息碼outerHMAC.具體過程為：首先用Seed，和新父密鑰的npNameAlg作為KDFa()的參數(shù)產(chǎn)生HAMC密鑰，然后采用新父密鑰的HMAC算法進行運算獲得消息碼outerHMAC.

從以上過程可以看出，源TPM要完成outerwrap，不僅需要獲得新父密鑰的相關(guān)參數(shù)，而且需要確保密鑰種子seed能在源TPM和目的TPM之間安全地交換.需要考慮的3種情況與innerwrap過程一致.

4 基于復(fù)制接口的密鑰遷移協(xié)議

通過對TPM2_Duplication接口和TPM2_Import接口的分析可知，采用TPM2.0的密鑰復(fù)制接口來設(shè)計密鑰遷移協(xié)議，需要將新父密鑰從目標TPM傳遞到源TPM，源TPM調(diào)用TPM2_Duplication接口得到被復(fù)制密鑰的復(fù)制數(shù)據(jù)，目標TPM調(diào)用TPM2_Import將復(fù)制數(shù)據(jù)載入.基本的流程如下：

1)目標TPM將新父密鑰傳遞給源TPM

2)源TPM調(diào)用TPM2_Duplication接口，根據(jù)復(fù)制密鑰的復(fù)制屬性(fixedTPM，fixedParen，encryptedDuplication)和新父密鑰的newParentHandle類型實施innerwrap和outerwrap，得到復(fù)制數(shù)據(jù)；

3)將復(fù)制數(shù)據(jù)傳遞給目標TPM，目標TPM調(diào)用TPM2_Import將被復(fù)制密鑰加載到新父密鑰下我們將在4.1節(jié)給出詳細的密鑰遷移協(xié)議流程，4.2節(jié)對該協(xié)議進行分析.

4.1 基于復(fù)制接口的密鑰遷移協(xié)議

基于密鑰復(fù)制接口來設(shè)計密鑰遷移協(xié)議通常包括6個參與實體：源TPM、源TPM的所有者、目標TPM、目標TPM的所有者、源TPM所在的主機、目標TPM所在的主機，其中，前4個實體是可信的，而源和目標TPM所在的主機被認為是不可信的.表2為協(xié)議相關(guān)符號及函數(shù)說明.

根據(jù)第3節(jié)的分析和規(guī)范要求，我們設(shè)計出基于復(fù)制接口的密鑰遷移協(xié)議，其流程如下：

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

2.OS：調(diào)用復(fù)制接口

(1)獲得objectHandle，newparentHandle

(2)決定encryptionKeyin的產(chǎn)生方式，可以輸入，可以由TPM內(nèi)部產(chǎn)生RNG；

(3)調(diào)用接口TPM2_Duplication(objectHandle，newParentHandle，encrptionKeyIn，symmetricAlg)；

表2 協(xié)議相關(guān)符號及函數(shù)說明Table2 Protocol related symbols and function description

3.TS：執(zhí)行復(fù)制過程

(1)檢查新父密鑰是否為存儲密鑰，如不是，結(jié)束復(fù)制過程，轉(zhuǎn)到6；

(2)檢查復(fù)制密鑰的屬性fixedTPM和fixedParent，如果設(shè)置不是(0，0)就結(jié)束復(fù)制過程，轉(zhuǎn)到6；

(3)檢查復(fù)制密鑰的屬性encryptedDuplication，如果設(shè)置為1，則判斷newParentHandle是否為TPM_RH_NULL，如果為TPM_RH_NULL，則結(jié)束復(fù)制過程，轉(zhuǎn)到6；否則轉(zhuǎn)到(4)；如果設(shè)置為0，newParentHandle不為TPM_RH_NULL則轉(zhuǎn)到(6)，否則轉(zhuǎn)向(8)；

(4)執(zhí)行innerwrap，由caller輸入或TPM產(chǎn)生encrptionKeyIn，并用encrptionKeyIn對復(fù)制密鑰的sensitiveArea進行加密，生成encSensitive；

(5)對encrptionKeyIn進行保護，分為兩種情況：

?如果新父密鑰是非對稱密鑰，如RSA或ECC密鑰，則用新父密鑰的公鑰加密encrptionKeyIn，即CencrptionKeyIn=RSA_OAEP(newParentHandle，encrptionKeyIn)或ECC_ECDH(newParentHandle，encrptionKeyIn)，并將sysmetrickey=CencrptionKeyIn；

?如果新父密鑰是對稱密鑰，則直接sysmetrickey=encrptionKeyIn.

(6)執(zhí)行outerwrap，由TPM產(chǎn)生密鑰種子Seed，用密鑰種子Seed生成加密密鑰和HMAC密鑰，對encSensitive進行加密和HAMC運算，得到dupSensitive和outerHMAC；

(7)對Seed進行保護，分兩種種情況：

?如果新父密鑰是非對稱密鑰，與(5)中情況一致；

?如果新父密鑰是對稱密鑰，則直接sysmetricSeed=Seed；

結(jié)束復(fù)制過程，轉(zhuǎn)到4；

(8) 對復(fù)制密鑰既不進行innerwrap，也不進行outerwrap，則dupSensitive=sensitiveArea，sysmetrickey=NULL，sysmetricSeed=NULL；

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

5.TD：執(zhí)行導(dǎo)入過程

(1)根據(jù)sysmetricSeed參數(shù)是否為NULL來判斷是否進行了outerwrap，如果為NULL，轉(zhuǎn)到下一步；否則直接得到seed或用私鑰解密sysmetricSeed得到seed，按照symmetricAlg算法生成HMAC密鑰HMACkey并對dupSensitive||name進行HAMC運行，得到的值與outerHMAC比較，如果不相等，終止導(dǎo)入過程，轉(zhuǎn)到6；如果相等，則用seed生成對稱加密密鑰symkey并解密dupSensitive得到encSensitive；

(2)根據(jù)sysmetrickey參數(shù)是否為NULL來判斷是否進行了innerwrap.如果為NULL，則轉(zhuǎn)到6；否則直接得到encrptionKeyIn或用新父密鑰的私鑰解密sysmetrickey得到encrptionKeyIn，用symmetricAlg算法對encSensitive進行解密得到Sensitive和name，用Hash算法對Sensitive||name進行完整性驗證，驗證通過，則表明遷移成功，轉(zhuǎn)到6，；驗證不通過，則表明遷移不成功，轉(zhuǎn)到6；

6.結(jié)束遷移過程

4.2 存在的問題

一方面，從4.1節(jié)可以看出，此密鑰遷移協(xié)議存在如下安全問題：

問題1.該協(xié)議缺少源TPM和目標TPM間的身份認證，導(dǎo)致密鑰能夠在敵手和TPM間遷移.存在著如下兩種情況：(1)源TPM不能認證newParent是不是目標TPM的密鑰，導(dǎo)致敵手可以用其控制的密鑰遷移源TPM的密鑰，并獲得密鑰明文；(2)目標TPM不能認證遷移數(shù)據(jù)是否來自源TPM，使敵手可以將其控制的密鑰遷移到目標TPM中.

問題2.當復(fù)制密鑰的屬性encryptedDuplication=0且新父密鑰的句柄newParentHandle= TPM_RH_NULL時，復(fù)制接口不能實施innerwrap和outerwrap，遷移密鑰將以明文傳輸而造成泄露.

問題3.當新父密鑰是對稱密鑰時，innerwrap中的對稱加密密鑰以及outerwrap中的密鑰種子如何在源TPM與目標TPM之間安全交換，《TPM-Rev-2.0- Part-1- Architecture-01.38》并沒有給出具體的解決辦法.

另一方面，4.1節(jié)的密鑰遷移協(xié)議中復(fù)制流程比較復(fù)雜，其中有幾個關(guān)鍵的屬性決定復(fù)制流程.首先，密鑰能否復(fù)制是由復(fù)制密鑰的屬性(fixedTPM，fixedParent)決定；其次，復(fù)制過程中是否實施innerwrap由復(fù)制密鑰的encryptedDuplication決定；第三，復(fù)制過程中是否實施outerwrap由新父密鑰的句柄類型決定；第四，innerwrap中對稱密鑰和outerwrap中密鑰種子的保護交換還依賴新父密鑰的密鑰類型.不同的屬性值決定了復(fù)制過程的不同流程，在所有的流程中，部分流程的輸出結(jié)果是存在安全隱患的.由于所有的判斷均在TPM內(nèi)部進行，在執(zhí)行完成之前外界無法知道TPM2_Duplication()的輸出結(jié)果，也就無法提前掌握輸出結(jié)果的保護情況.為了保證復(fù)制過程的安全，需要提前掌握復(fù)制流程.因此，外界需要一個控制中心，提前獲知復(fù)制密鑰屬性和新父密鑰類型和句柄類型，從而提前掌握復(fù)制流程并對復(fù)制過程的輸出結(jié)果采取合理的保護措施.

5 實驗驗證與評價

5.1 實驗環(huán)境

本節(jié)所有實驗均利用OpenSSL進行模擬仿真實現(xiàn).本實驗共使用3臺計算機，分別稱為source TPM(源TPM)，target TPM(目的TPM)，adversary TPM(敵手，中間人).具體環(huán)境配置如表3所示.

表3 實驗環(huán)境相關(guān)配置表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，最后得到的加密數(shù)據(jù)塊為encSensitive；在outerwrap階段所用的加密種子為seed，由seed產(chǎn)生的對稱加密密鑰和HMAC密鑰分別為ks，hmackey得到的加密數(shù)據(jù)塊為dupSensitive和outerHMAC.

首先，我們用OpenSSL技術(shù)在源TPM和目標TPM所在主機上構(gòu)建TPM2.0密鑰對象保護層次體系，結(jié)果如圖3、圖4所示.

圖3 源TPM的密鑰層次結(jié)構(gòu)Fig.3 Key hierarchy of the source TPM

然后，我們根據(jù)4.1中設(shè)計的密鑰遷移協(xié)議發(fā)現(xiàn)不存在只進行innerwrap的情況，同時根據(jù)4.2節(jié)提到的關(guān)鍵屬性，我們一共梳理出13種情況.為了節(jié)約篇幅，各種情況對應(yīng)的屬性取值如表4所示.其中newParentHandle取值為1代表newParentHandle=!TPM_RH_NULL，為0反之.新父密鑰或遷移密鑰取值為1表示對稱密鑰，為0表示非對稱密鑰，S表示源TPM，T表示目的TPM.

圖4 目的TPM的密鑰層次結(jié)構(gòu)Fig.4 Key hierarchy of the target TPM

表4 屬性取值情況表Table 4 Experimental environment related configuration table

可以看出其中情況1不能進行復(fù)制操作.情況5，8，11與情況2類似，情況6與情況3類似，情況7與情況4類似，且復(fù)制流程也基本一致.因此，后續(xù)篇章對于相同的情況不再一一敘述.

情況2具體的執(zhí)行流程如圖5、圖6所示.

圖5 情況2中源TPM的執(zhí)行流程圖Fig.5 In case 2 source TPM implementation flow chart

圖6 情況2中目的TPM的執(zhí)行流程圖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協(xié)議的執(zhí)行過程由源TPM發(fā)起，seed在源TPM方產(chǎn)生.遷移過程中僅執(zhí)行outerwrap，具體的執(zhí)行流程如圖8、圖9所示.

圖8 情況3中源TPM的執(zhí)行流程圖Fig.8 In case 3 source TPM implementation flow chart

圖9 情況3中目的TPM的執(zhí)行流程圖Fig.9 In case 3 target TPM implementation flow chart

情況4遷移過程中既要執(zhí)行innerwrap，又要執(zhí)行outerwrap，具體的執(zhí)行流程如圖10、圖11所示.

圖10 情況4中源TPM的執(zhí)行流程圖Fig.10 In case 4 source TPM implementation flow chart

圖11 情況4中目標TPM的執(zhí)行流程圖Fig.11 In case 4 target TPM implementation flow chart

情況9協(xié)議的執(zhí)行過程由目的TPM發(fā)起，seed在目的TPM方產(chǎn)生，因此需要先在目的TPM方用遷移密鑰的公鑰對seed加密，然后傳輸給源TPM進而解密得到seed.后續(xù)過程與情況3基本一致.

情況10協(xié)議的執(zhí)行過程由目的TPM發(fā)起，seed和encryptionKeyin在目的TPM方產(chǎn)生.因此需要先在目的TPM方用遷移密鑰的公鑰對seed和encryptionKeyin加密，然后傳輸給源TPM進而解密得到seed和encryptionKeyin.后續(xù)過程與情況4基本一致.

情況12協(xié)議的執(zhí)行過程可由目的TPM或源TPM發(fā)起，seed亦可在目的TPM或源TPM方產(chǎn)生，但不管由哪一方發(fā)起，seed都將以明文傳輸.具體的執(zhí)行流程如圖12、圖13所示.

圖12 情況12中源TPM的執(zhí)行流程圖Fig.12 In case 12 source TPM implementation flow chart

圖13 情況12中目的TPM的執(zhí)行流程圖Fig.13 In case 12 target TPM implementation flow chart

情況13，協(xié)議的執(zhí)行過程可由目的TPM或源TPM發(fā)起，seed和encryptionKeyin亦可在目的TPM或源TPM方產(chǎn)生，但不管由哪一方發(fā)起，seed和encryptionKeyin都將以明文傳輸.具體的執(zhí)行流程圖14、圖15所示.

圖14 情況13中源TPM的執(zhí)行流程圖Fig.14 In case 13 source TPM implementation flow chart

5.3 實驗評價

5.3.1 安全性評價

從5.2節(jié)的實驗可以看出，TPM2.0的密鑰復(fù)制只能在某些條件下保證遷移密鑰的完整性，機密性，但在另一些情況下仍然存在安全威脅.5.2節(jié)的實驗結(jié)果完全驗證了我們在4.2節(jié)中的理論分析.下面我們做一一說明.

圖15 情況13中目的TPM的執(zhí)行流程圖Fig.15 In case 13 target TPM implementation flow chart

1.針對4.2節(jié)中的問題1指出：協(xié)議缺少目的TPM和源TPM間的相互認證，導(dǎo)致密鑰可在敵手與TPM之間遷移.我們以5.1節(jié)的實驗環(huán)境為基礎(chǔ)，給出具體的攻擊方法：敵手使用自己可控的密鑰做為新父密鑰進行密鑰復(fù)制，然后用可控密鑰進行解密得到復(fù)制密鑰的sensitiveArea，從而實現(xiàn)將密鑰復(fù)制到敵手可控的密鑰下.

2.4.2中的問題2指出，當復(fù)制接口不能實施innerwrap和outerwrap，遷移密鑰將以明文傳輸而造成泄露.具體情況見5.2節(jié)中的情況2.

3.4.2節(jié)中問題3指出：當新父密鑰是對稱密鑰時，innerwrap中的對稱加密密鑰以及outerwrap中的密鑰種子如何在源TPM與目標TPM之間安全交換，《TPM-Rev-2.0-Part-1-Architecture-01.38》并沒有給出具體的解決辦法.我們在5.2節(jié)中將此問題分為兩種情況：(1)當復(fù)制密鑰是非對稱密鑰時，我們將協(xié)議的執(zhí)行過程改由目的TPM發(fā)起，seed或encryptionKeyin改在目的TPM方產(chǎn)生，這樣就可以按規(guī)范在源TPM與目標TPM之間安全交換seed或encryptionKeyin，如情況9，情況10.(2)當復(fù)制密鑰也是對稱密鑰時，無論是在源TPM方或目的TPM方產(chǎn)生seed或encryptionKeyin，都無法采用規(guī)范中的辦法在源TPM與目標TPM之間安全交換.此時，seed或encryptionKeyin將以明文傳送，安全隱患很大.如情況12、情況13等.

5.3.2 性能評價

密鑰遷移性能我們主要考查遷移時間.對于密鑰遷移的每一種情況，我們忽略密鑰層次結(jié)構(gòu)的建立、實驗過程中人工輸入運行選項的延遲以及服務(wù)器與客戶端建立連接的等待時間，只計算密鑰復(fù)制遷移過程的時間.例如，在情況3中源TPM所用時間為27128us，目的TPM所用時間為74394us，共計時間27128+74394=0.101522s.圖16為上述13種情況的密鑰復(fù)制遷移耗時圖.

圖16 密鑰遷移耗時圖Fig.16 Times of key migration

6 結(jié)束語

結(jié)合TCG制定的相關(guān)規(guī)范標準，本文首先總結(jié)了TPM1.1-2.0密鑰遷移的現(xiàn)有研究成果，對現(xiàn)有TPM2.0的密鑰復(fù)制接口進行了分析和研究.然后基于復(fù)制接口設(shè)計了密鑰遷移協(xié)議，指出現(xiàn)有TPM2.0中基于密鑰復(fù)制接口的密鑰遷移協(xié)議存在的三個問題.最后通過模擬實驗驗證上述三個問題確實存在.

本文的研究可以增強TPM2.0密鑰的互操作性，有助于下一代TPM芯片的設(shè)計.同時TPM2.0的密鑰遷移研究工作還未完結(jié)，我們下一步的工作是設(shè)計更安全的密鑰遷移協(xié)議來解決以上三個問題，提出完善TPM2.0規(guī)范的改進意見.