可信環(huán)境下的密鑰撤銷機制研究

摘 要:針對TPM只作為對密鑰的訪問控制設(shè)備，而不能銷毀被攻破密鑰的問題，提出了兩種利用密鑰列表實施撤銷的機制。通過對TPM命令集的少量修改，利用密鑰列表對加載的密鑰進(jìn)行有效性檢查，從而保證被TPM使用的密鑰都是未撤銷的，并且兩種機制都能實現(xiàn)與當(dāng)前TCG規(guī)范的向后兼容，也不會增加其他操作的負(fù)載。最后，提出將兩種機制結(jié)合以保證密鑰撤銷和加載操作的效率，增強撤銷機制的可實施性。

關(guān)鍵詞:可信計算; 可信平臺模塊; 密鑰撤銷; 密鑰列表

中圖分類號:TP309

文獻(xiàn)標(biāo)志碼:A

文章編號:1001-3695(2010)02-0714-04

doi:10.3969/j.issn.1001-3695.2010.02.086

Research on revocation of keys in trusted environment

LI Chao-ling1， GENG Yu-ying2， ZHOU Yan-zhou1， LI Fu-lin1， LI Li-xin1

(1.Institute of Electronic Technology， PLA Information Engineering University， Zhengzhou

450004， China; 2. Office of Huarong Asset Management Corporation， Zhengzhou 450004， China)

Abstract:TPM is not able to destroy collapsed keys， because keys (except for SRK and EK) are stored outside of it. To solve this problem， this paper proposed two mechanisms of revoking TPM keys. Without major changes to the TPM command set， checked the validities of loaded keys by using key lists. While realizing revocation checking effectively， preserved backwards compatibility with the current TCG specifications， and introducted no overhead for normal operation. At last， to improve the efficiency of revoking and loading operations and enhance the practicability of revocation mechanism， proposed the combination of both mechanisms.

Key words:trusted computing; TPM; key revocation; key list

0 引言

可信計算平臺的主要特征是在主板上嵌入可信平臺模塊(trusted platform module， TPM)，它是構(gòu)建信任根的核心硬件模塊，是提高整個平臺安全性的基礎(chǔ)部件[1]。TPM的主要功能之一就是對加密和簽名密鑰的安全存儲，但TPM的實現(xiàn)只是擁有有限存儲空間的小型片上系統(tǒng)(system on chip， SOC)，所以TCG(trusted computing group)規(guī)范中只有存儲根密鑰(storage root key， SRK)和簽注密鑰(endorsement key， EK)永久性地存儲在TPM內(nèi)部，其他密鑰都由SRK加密后存儲在外部非可信的設(shè)備上，而TPM只作為對外部存儲密鑰的訪問控制設(shè)備[2]，如圖1所示。這種方法能提供與所有密鑰都存儲在TPM內(nèi)部一樣的安全性，并能降低TPM的生產(chǎn)成本，但卻導(dǎo)致外部密鑰被攻破時TPM不能可靠地銷毀它們。因此，一旦攻擊者得到對某個TPM密鑰的訪問權(quán)限和加密密文，他就能通過TPM訪問該密鑰。

一種防止被攻破密鑰再被使用的簡單方法是刪除SRK，但會導(dǎo)致TPM的所有不可遷移密鑰不可用。因而這種方法不具有可行性，因為在某些應(yīng)用環(huán)境中TPM可能管理著大量密鑰，刪除SRK很可能導(dǎo)致系統(tǒng)癱瘓。TCG規(guī)范給出了TPM的撤銷方法[3]以及對TPM密鑰的管理，如密鑰遷移[4]，但并未給出對單個TPM密鑰撤銷的機制。

本文提出了兩種撤銷TPM密鑰的機制，它們分別采用記錄被撤銷密鑰的黑名單和記錄未撤銷密鑰的白名單，通過對TPM命令集的少量修改，實現(xiàn)加載密鑰時檢查其有效性，并根據(jù)密鑰的有效性繼續(xù)或終止操作。它們適用于所有TPM密鑰的撤銷，但撤銷操作主要用于請求外部服務(wù)時的認(rèn)證密鑰，所以本文主要分析對這類密鑰的撤銷。效率上，黑名單機制能提供高效的密鑰撤銷操作，但加載密鑰到TPM的性能較低;白名單機制能提供對密鑰的快速訪問，但撤銷密鑰的開銷很大。因此，最后提出將黑白名單結(jié)合以最大化撤銷和加載操作的效率。

1 黑名單撤銷機制

黑名單機制中，將被撤銷密鑰的列表存儲在外部存儲器上，并以哈希鏈的形式保存，以方便認(rèn)證、順序訪問和添加新撤銷密鑰。只將哈希鏈的最后一個元素TPM.lastHash存儲在TPM內(nèi)部，因此只占用很小的永久性存儲空間。必須保證外部存儲列表的安全性，因為惡意的修改(如改變完整性或刪除)將使整個列表無效和導(dǎo)致拒絕服務(wù)(denial of service， DoS)攻擊。因此，黑名單由一個軟件棧管理，但只有TPM能操作它。

為保證效率和兼容性，假設(shè)并非每個密鑰都默認(rèn)為可撤銷的，而是在生成時由用戶指定是否可撤銷。這樣，舊的應(yīng)用就能無須任何修改地使用TPM，同時不可撤銷密鑰也無須表示撤銷信息的數(shù)據(jù)結(jié)構(gòu)。為每個由TPM生成的密鑰增加一個特殊字段revocable，加載密鑰時TPM檢查該標(biāo)志位，如果密鑰被標(biāo)志為non-revocable則只執(zhí)行標(biāo)準(zhǔn)的加載操作。目前TCG規(guī)范并未利用TPM_KEY_FLAGS[5]所有可能的掩碼值，所以可通過添加新的掩碼值實現(xiàn)revocable標(biāo)志。由于TPM_KEY_FLAGS并不受加密保護(hù)，revocable標(biāo)志位也需要添加到TPM_STORE_ASYMKEY[5]結(jié)構(gòu)中以保證一致性和完整性。

另外，再添加一個新的標(biāo)志位checked到TPM_STORE_ASYMKEY中，它表示一個可撤銷密鑰是否已經(jīng)利用黑名單驗證過有效性。它用于在加載密鑰的命令TPM_LoadKey和一個新添加的、驗證密鑰有效性的命令TPM_ShowRevListElement間傳遞狀態(tài)信息。

1.1 數(shù)據(jù)結(jié)構(gòu)和初始化

哈希鏈中的每個撤銷密鑰都經(jīng)過TPM的認(rèn)證，認(rèn)證采用SRK或SRK的直接子密鑰，后者要求SRK和其直接子密鑰都加載到TPM。但由于TPM的密鑰空間有限，它對TPM密鑰空間的占用可能制約加載其他密鑰的能力。哈希鏈的元素rev_element結(jié)構(gòu)如下:

〈key，hash(REVOC_LABEL||key||SRK||prevHash)〉

其中:key表示被撤銷密鑰的公鑰，SRK表示存儲根密鑰，REVOC_LABEL標(biāo)簽表示哈希值只用于構(gòu)建撤銷列表，prevHash指撤銷列表中前一個元素的哈希值(列表首元素的prevHash值設(shè)為0k)。SRK使哈希值被標(biāo)記:只有擁有該SRK的TPM能生成并驗證哈希值。引入一個新的TPM數(shù)據(jù)結(jié)構(gòu)TPM_REV_ELEMETN來存儲哈希鏈的元素:

Typedef struct tdTPM_REV_ELEMENT {

TPM_STRUCT_VER ver;

TPM_STORE_PUBKEY pubKey;

TPM_REV_ELEMENT_HASH Hash;

}TPM_REV_ELEMENT;

初始化撤銷機制時，TPM.lastHash置為0k，表示不存在撤銷列表。每生成一個新的SRK都需要進(jìn)行初始化操作，它是TPM_TakeOwnership命令的一部分。另外，必須修改密鑰生成命令TPM_CreateWrapKey以便初始化revocable和checked字段。其中checked默認(rèn)為1。

1.2 密鑰的撤銷

添加命令TPM_RevokeKey來撤銷密鑰，它獲取密鑰句柄keyHandle和SRK的句柄srkHandle。TPM_RevokeKey命令利用TPM.lastHash生成新的條目，更新TPM中的TPM.lastHash值并返回新生成的列表條目，如算法1所示。為保證執(zhí)行效率，該算法并不檢查當(dāng)前哈希鏈的完整性，也不檢查密鑰是否已經(jīng)包含在列表中。為描述簡單，本文的算法只列出了需要的輸入/輸出參數(shù)。其他參數(shù)可參考TPM規(guī)范[6]。

算法1 TPM_RevokeKey算法

輸入:srkHandle，keyHandle

輸出:returnCode，revElement

newHash:=hash(REVOC_LABEL||keyHandle.pubKey||SRK|| TPM.lastHash)

TPM.lastHash:=newHash

return RET_REVOKE_KEY_ACK，newHash

1.3 密鑰的使用

每個被使用的TPM密鑰都需要利用TPM_LoadKey命令加載，如果加載的密鑰是可撤銷的(key.revocable置為true)則它不能直接使用:TPM必須檢查該密鑰是否在撤銷列表中。因此，TPM要求應(yīng)用程序或TSS(trusted software stack)反復(fù)調(diào)用TPM_ShowRevListElement命令將撤銷列表的條目順序地讀取到TPM，該命令檢查哈希鏈的完整性和密鑰是否在列表中。如果哈希鏈無效或匹配成功則返回RET_FAIL并終止執(zhí)行，匹配不成功則返回RET_REVOC要求調(diào)入下一個條目繼續(xù)檢查，直到哈希鏈末尾時返回RET_OK并設(shè)置一個標(biāo)志位表示密鑰可用。最后，為終止密鑰加載操作，需要再次調(diào)用TPM_LoadKey命令，它為應(yīng)用程序返回密鑰句柄。

因為撤銷檢查只在將密鑰加載到TPM時進(jìn)行，并非每次使用密鑰時都需要，從而可能導(dǎo)致密鑰被撤銷后仍以可用的形式存在于TPM中。解決的方法是不斷刷新TPM緩存中的密鑰。當(dāng)然，這會降低系統(tǒng)性能。

算法2描述了修改后的TPM_LoadKey命令。如果inKey指向一個可撤銷密鑰，則首先確定是否已經(jīng)利用撤銷列表檢查過密鑰的有效性(inKeyPlain.Keyflags.checked置為true)。如果是，則按加載密鑰的正常操作進(jìn)行，否則返回加密后的inKey數(shù)據(jù)結(jié)構(gòu)和RET_REVOC，表示需要利用TPM_ShowRevListElement命令對密鑰作進(jìn)一步處理。

算法2 黑名單機制中的TPM_LoadKey算法

輸入:parentHandle，inKey，Nonce

輸出:returnCode，inKeyHandle，inKey

inKeyPlain:=Decrypt(inKey， parentHandle)

if inKeyPlain.Keyflags.revocable=TRUE then

if inKeyPlain.Keyflags.checked=(TRUE||Nonce) then

Continue as denoted in TPM specification

return TPM_SUCCESS，inKeyHandle

else

inKeyPlain.Keyflags.checked:=(FALSE||Nonce)

inKey:=Encrypt(inKeyPlain，parentHandle)

return RET_REVOC，inKey

else

Continue as denoted in TPM specification

return TPM_SUCCESS，inKeyHandle

算法3給出了命令TPM_ShowRevListElement的實現(xiàn)，它驗證哈希鏈，確定對該公鑰的所有后續(xù)調(diào)用被執(zhí)行和該密鑰不在撤銷列表中。它獲取SRK的句柄、TPM_LoadKey命令返回的inKey、撤銷列表的一個元素、父密鑰的句柄和授權(quán)會話的信息(parentHandle的授權(quán)會話的Nonce)。這里需要利用授權(quán)會話的信息來保證對黑名單的檢查是最新的。因此，為成功加載一個可撤銷密鑰，TPM_LoadKey命令必須使用TPM_ShowRevListElement的部分授權(quán)數(shù)據(jù)。算法3的執(zhí)行需要TPM內(nèi)部存儲兩個值:經(jīng)過驗證的前一個列表元素的哈希值prevHash和該公鑰的哈希值previnKey，它們都可以作為TPM_STANY_DATA結(jié)構(gòu)的附加字段。當(dāng)TPM.lastHash等于撤銷列表的當(dāng)前元素時，表示已經(jīng)到達(dá)列表的末尾，TPM檢查給定的公鑰是否與inKey中的私鑰相對應(yīng)，如果是，則改變標(biāo)簽inKeyPlain.Keyflags.checked的值并返回inKey。

算法3 TPM_ShowRevListElement算法

輸入:srkHandle，revElement，parentHandle，inKey，Nonce

輸出:returnCode，inKey

if undefined(prevHash) then

prevHash:=0k

curHash:=Hash(REVOC_LABEL||revElement.pubKey||SRK||prevHash)

if(curHash!=revElement.Hash)||(revElement.pubKey= inKey.pubKey) then

Return RET_FAIL

if not(undefined(previnKey)) then

Return RET_FAIL

previnKey:=Hash(inKey.pubKey)

prevHash:=curHash

if curHash=TPM.lastHash then

inKeyPlain:=Decrypt(inKey，parentHandle)

if inKeyPlain.Keyflags.checked=(FALSE||Nonce) then

if inKeyPlain contains public key corresponding to previnKey then

inKeyPlain.Keyflags.checked:=(TRUE||Nonce)

inKey:=Encrypt(inKeyPlain，parentHandle)

Return RET_OK，inKey

else

Return RET_FAIL

else

return RET_REVOC

1.4 清理協(xié)議

加載可撤銷密鑰的開銷隨黑名單的大小線性增長，當(dāng)名單過長時加載操作的開銷將難以接受。因此需要一個清除黑名單的清理協(xié)議:清理協(xié)議生成一個與舊SRK并列的新SRK，復(fù)制所有未撤銷密鑰到新SRK下的密鑰樹中，然后刪除舊的SRK。因為在沒有舊SRK的條件下所有舊的密鑰塊都不可用，而且只有未撤銷密鑰被遷移，從而可以刪除黑名單并將TPM恢復(fù)到空黑名單的狀態(tài)。

然而，清理協(xié)議的實現(xiàn)面臨許多實際問題。首先，TPM以樹型結(jié)構(gòu)存儲密鑰，因此存在不可撤銷密鑰加密保護(hù)可撤銷密鑰的情況[2]。這種情況下，需要修改不可撤銷密鑰以防止在清除黑名單后再利用它解密舊的、被撤銷的密鑰。其次，密鑰可能擁有不同的訪問權(quán)限，而對于密鑰使用的授權(quán)其所有者可能不可用，從而清理協(xié)議需要避免所有的訪問控制機制，導(dǎo)致協(xié)議實現(xiàn)的難度增加。最后，密鑰樹需要以正確的順序加載到TPM，父密鑰要先于子密鑰被加載。盡管可能實現(xiàn)這樣的清理協(xié)議，但會相當(dāng)復(fù)雜。在密鑰撤銷頻繁的情況下，采用白名單更高效。

2 白名單撤銷機制

白名單機制中，TPM為每個可撤銷密鑰生成一個單獨的白名單塊。白名單塊包含密鑰和一個計數(shù)器的哈希值，該計數(shù)器表示白名單當(dāng)前的版本，即撤銷操作執(zhí)行的次數(shù)。TPM維護(hù)一個安全的計數(shù)器TPM.revCounter存儲最新的計數(shù)值。只有當(dāng)密鑰的計數(shù)器值與TPM.revCounter的值相等時，密鑰才有效。撤銷一個密鑰時，除被撤銷密鑰外的所有密鑰的計數(shù)器值都必須加1以保持最新。

與密鑰自身不同，白名單塊不是密鑰體系的一部分;相反，它們由白名單根密鑰(WRK，whitelist root key)加密和認(rèn)證。其中WRK由SRK直接保護(hù)。這就避免了更新白名單時遇到與黑名單的清理協(xié)議同樣的訪問控制問題，因為對白名單的更新操作，包括密鑰撤銷或生成新的白名單塊，只要求對WRK的訪問權(quán)限。WRK也允許在外部更新白名單:WRK可以被遷移到一個可信的外部設(shè)備，它能計算新的白名單塊而不需要TPM的參與，TPM只需要更新內(nèi)部的計數(shù)器值。

2.1 密鑰的生成

執(zhí)行密鑰生成命令要求WRK被加載到TPM，它同時返回密鑰和白名單塊。TPM_CreateWrapKey命令的實現(xiàn)如算法4所示。

算法4 白名單機制中的TPM_CreateWrapKey算法

輸入:parentHandle，wrkHandle，keyInfo

輸出:returnCode，wrappedKey，whitelistBlob

Set wrappedKey.Keyflags.revocable according to keyInfo

Generate key as denoted in specification

if keyInfo.Keyflags.revocable=TRUE then

whitelistblob:=Hash(REVOC_LABEL||keyInfo.pubKey|| WRK||TPM.revCounter)

return TPM_SUCCESS，wrappedKey，whitelistblob

2.2 密鑰的撤銷

撤銷密鑰時，需要更新除被撤銷密鑰外的所有密鑰的白名單塊，它由TPM_WhitelistTransformKey命令完成，如算法5所示。在適當(dāng)?shù)氖跈?quán)后，該命令獲取一個密鑰塊，增加它的計數(shù)器值并返回一個新的密鑰塊。白名單的所有元素都完成更新后，必須執(zhí)行TPM_WhitelistCommit命令更新TPM的計數(shù)值，如算法6所示。對TPM_WhitelistCommit命令的調(diào)用十分關(guān)鍵，錯誤的調(diào)用將使所有的密鑰無效并可能導(dǎo)致DoS攻擊，因此對它的調(diào)用要求TPM所有者授權(quán)。

算法5 白名單機制中的TPM_WhitelistTransformKey算法

輸入:parentHandle，wrkHandle，revokedHandle，whitelistblob

輸出:returnCode，whitelistBlob

hashval:=Hash(REVOC_LABEL||revokedHandle.pubKey||WRK||TPM.revCounter)

if hashval!=whitelistblob then

Whitelistblob:=Hash(REVOC_LABEL||

revokedHandle.pubKey ||WRK||TPM.revCounter+1)

return TPM_SUCCESS， whitelistblob

else

return RET_FAIL

算法6 白名單機制中的TPM_WhitelistCommit算法

輸入:wrkHandle

輸出:returnCode

TPM.revCounter++

return TPM_SUCCESS

2.3 密鑰的使用

加載一個密鑰時，它的白名單塊也必須載入TPM。TPM計算公鑰、WRK以及TPM.revCounter的哈希值，并與白名單塊比較。僅當(dāng)兩者相等時，算法按TCG規(guī)范定義的操作執(zhí)行，如算法7所示。

算法7 白名單機制中的TPM_LoadKey算法

輸入:parentHandle，wrkHandle，keyInfo

輸出:returnCode，wrappedKey，whitelistBlob

inKeyPlain:=Decrypt(inKey，parentHandle)

if inKeyPlain.Keyflags.revocable=TRUE then

hashval:=Hash(REVOC_LABEL||inKey.pubKey||WRK ||TPM.revCounter)

if hashval!=whitelistblob then Return RET_FAIL

Continue as in the specification

return TPM_SUCCESS，keyHandle

3 黑白名單相結(jié)合的撤銷機制

為簡化對黑白名單機制中各操作的效率比較，假設(shè)一個TPM的所有可撤銷密鑰數(shù)量為M，已撤銷密鑰數(shù)量為N，哈希運算hash(REVOC_LABEL||keyHandle.pubKey||SRK|| TPM.lastHash)和hash(REVOC_LABEL||keyInfo.pubKey|| WRK||TPM.revCounter)的運算時間相同(設(shè)為TH)，并忽略數(shù)據(jù)傳輸?shù)耐ㄐ砰_銷。這樣，黑名單機制中密鑰撤銷的開銷為TH，加載一個可撤銷密鑰的開銷為NTH;白名單機制中加載一個可撤銷密鑰的開銷為TH，撤銷密鑰的開銷為(M-1)TH。可見，黑名單機制中密鑰撤銷是常量時間，但加載密鑰的開銷與已撤銷密鑰的數(shù)量呈線性。雖然可以通過清理協(xié)議清除黑名單，但協(xié)議的實現(xiàn)十分復(fù)雜。而白名單機制中密鑰的加載十分高效，但密鑰撤銷的開銷較大，它與系統(tǒng)中可撤銷密鑰的數(shù)量呈線性。黑白名單機制中各操作效率對比如圖2所示。

將黑白名單結(jié)合可以提高密鑰撤銷和加載的效率。利用黑名單完成通常的密鑰撤銷操作，另外再維護(hù)一個白名單來有效地清理黑名單。如果一個密鑰被撤銷，它首先被添加到黑名單中，TPM將拒絕加載黑名單中的任何密鑰;當(dāng)生成一個新的可撤銷密鑰時，同時為它生成一個白名單塊，TPM也將拒絕加載任何不在白名單中的可撤銷密鑰。當(dāng)黑名單太大時，TPM所有者可以通過為所有不在黑名單中的密鑰生成一個新的白名單來清除黑名單。

結(jié)合后的機制要求修改TPM_WhitelistTransformKey命令，并添加一個測試密鑰是否在黑名單中的操作，如算法8所示。如果密鑰在黑名單中，則不為它生成白名單塊，遷移命令返回一個錯誤。此外，還需要修改TPM_WhitelistCommit命令，使它將TPM內(nèi)部的哈希值置為0k。將黑白名單結(jié)合，可以得到兩方面的最高效率:撤銷密鑰可以在常量時間內(nèi)完成，并且可以維護(hù)很短的黑名單以實現(xiàn)高效的密鑰使用。雖然更新白名單的開銷很大，但它并不需要頻繁更新。

算法8 結(jié)合機制中的TPM_WhitelistTransformKey算法

輸入:srkHandle，parentHandle，wrkHandle，revokedHandle，

revElement，inKey，Nonce

輸出:returnCode，whitelistBlob

Switch(TPM_ShowRevListElement(srkHandle，revElement， parentHandle，inKey，Nonce))

Case: RET_FAIL

return RET_FAIL

Case: RET_OK

whitelistBlob:=Hash(REVOC_LABEL||inKey.pubKey||WRK|| TPM.revCounter+1)

return TPM_SUCCESS，whitelistBlob

Case: RET_ REVOC

Continue to compare with next blacklist item

4 結(jié)束語

受TPM存儲能力的限制，密鑰并不直接存儲在TPM中，而是加密后保存在外部設(shè)備上。這種方式導(dǎo)致密鑰存儲事實上并不受TPM的控制，它只作為對密鑰的訪問控制設(shè)備，因而TPM不能銷毀被攻破的外部存儲密鑰。針對這個問題，本文提出了利用黑白名單撤銷TPM密鑰的機制，它們都只需要對TPM的命令集作少量修改，并能保證與現(xiàn)有規(guī)范的向后兼容。為最大化密鑰撤銷和加載操作的效率，增強撤銷機制的可實施性，最后提出將黑白名單相結(jié)合的撤銷機制。

參考文獻(xiàn):

[1]Trusted Computing Group. Trusted platform module (TPM) specifications[R/OL].(2008-06-15). https://www.trustedcompu- tinggroup.org/specs/TPM.

[2]Trusted Computing Group.TCG specification architecture overview revision 1.2[R/OL]. (2004-04-28). https://www.tru-stedcompu-tinggroup.org.

[3]BRICKELL E， CAMENISCH J， CHEN Li-qun. Direct anonymous attestation[C]//Proc of the 11th ACM Conference on Computer and Communications Security. New York: ACM Press， 2004:132-145.

[4]KHN U， KURSAWE K， LUCKS S， et al. Secure data management in trusted computing[C]//Proc of Workshop on Crypographic Hardware and Embedded Systems. Heidelberg: Springer，2005:324-338.

[5]Trusted Computing Group.TCG TPM specification version 1.2 revision 103，TPM main part 2 TPM structures[R/OL]. (2006-10-26). https://www.trustedcomputinggroup.org.

[6]Trusted Computing Group.TCG TPM specification version 1.2 revision 103，TPM main part 3 command[R/OL]. (2006-10-26). https://www.trustedcomputinggroup.org.