可信計算中的遠程認證體系

彭新光，王曉陽

（太原理工大學 計算機科學與技術學院，太原 030024)

遠程認證是可信計算研究中的一項重要分支，它要求當用戶平臺向信息供應商發送服務請求時，必須證明其達到信息供應商要求的安全等級。其中基于屬性的遠程認證在各種認證方案中具有明顯的優點，它克服了基于配置的遠程認證中認證時間長，認證信息量大，平臺信息泄露等缺陷，實現了精簡、瘦身的認證過程［1-2］。基于屬性的遠程認證體系首先由Poritz提出，之后Chen提出了基于屬性的遠程認證協議PBA（Property-based attestation)，Qin提出了基于組件屬性的遠程認證CPBA（component property-based attestation)，這些研究成果促進了基于屬性的遠程認證的快速發展［3-5］。

當前的基于屬性的遠程認證體系存在以下不足：

1)證書權威發布機構（Certificate Authorization)是整個證明過程中的“最重要機密攜帶者”，若CA被攻陷，則整個遠程證明系統的安全性都將得不到保證。

2)證明過程中實現匿名傳輸的方式多采用零知識證明方式，零知識證明方式證明繁瑣，計算量大，效率較低。

本文在原有屬性遠程認證體系的基礎上，提出了一種新的屬性遠程證明體系。該體系具有以下特點：

1)通過引入盲簽名，降低了證書權威發布機構的被攻陷風險，提高了整個證明方案的安全性。

2)通過實現虛擬子群簽名來實現證明過程中的匿名傳輸，在安全性沒有降低的同時減少了計算量，提高了證明效率。

1 遠程認證體系

一個元件的“屬性”是描述該元件安全等級的唯一標志。當用戶計算機向信息供應商提出請求時，供應商對主機安全性的證明可以由證明整個主機系統的安全性縮小到證明主機中與此次服務相關的模塊的安全性。元件的屬性證書由證書權威發布機構發布，信息供應商可以通過驗證中心驗證元件的屬性證書是否真實，具體結構如圖1所示。

遠程認證體系包括模塊生產廠商、用戶平臺、信息供應商、證書發布權威機構和驗證中心這5個角色。這5個角色都參與模塊屬性證明過程。我們用下列符號來表示系統中的各個參與者。

MF（Module Factory)：模塊生產商，負責模塊的生產，它要向證書發布權威機構申請獲取模塊屬性證書。

CA（Certificate Authorization)：證書權威發布機構，發布，撤銷組件證書。

U（User)：包 含 有 TPM（Trusted Platform Module)的用戶平臺，向各服務商提出服務請求。

SP（Service Provider)：信息供應商，為各用戶平臺提供服務，驗證各用戶平臺是否可信。

VC（Verification Center)：驗證中心，驗證證書是否被篡改，是否被撤銷。

圖1 遠程認證體系

如圖所示：可將遠程認證的過程分為三步。

1)申請過程：模塊生產商MF向CA申請模塊證書，CA為各模塊頒發模塊證書，同時向VC傳遞一些必要的參數，以便驗證屬性證書時使用。模塊證書隨模塊傳遞給用戶U。

2)證明過程：用戶平臺U向SP發起數據請求，SP要求驗證用戶平臺的模塊屬性證書，用戶U與服務提供商SP進行交互式的遠程證明。

3)驗證過程：服務提供商SP和驗證中心VC共同合作驗證TPM簽名、模塊屬性簽名，并檢查簽名是否被撤銷。

2 遠程認證協議

2.1 遠程認證所需的安全等級

假設某子公司信息系統向總公司服務器請求傳輸某些重要資料，這就要求子公司的信息系統的文件傳輸程序滿足母公司所要求的安全等級。設傳輸模塊E1可傳輸格式為為dat，dll，exe的文件，傳輸模塊E2可傳輸格式為jsp，xml，dat的文件，傳輸模塊E3可傳輸格式為jar，rar，dat的文件。E1，E2，E3的標準配置分別為。

傳輸元件E1，E2，E3都能達到文件傳輸的安全屬性。同時要求該信息系統必須安裝有K1和K2兩個安全補丁。K1的配置滿足屬性，K2的配置滿足屬性。因此傳輸文件所需的屬性p＝，則該信息系統傳輸文件的屬性認證可表示為：

2.2 遠程認證協議

在TCG的TNC規范中，每個生產商的軟件產品都被定義了一個ID，長度為32bit。前24bit代表生產商的ID，是生產商向TCG申請得到的，后8位表示生產商生產的具體軟件產品的子信息。模塊屬性證書中的id采用TCG的模塊ID，lid（32)表示模塊ID長度。

設模塊Ei的配置為（di，χi，pi)，di是模塊Ei的ID值，χi為組件Ei的度量值，長度為lx（160)。pi為組件滿足的安全屬性，長度為lp（160)。

2.2.1 申請過程

屬性證書的生成與加密（現采用Nybery-Rueppel簽名［6］及RSA加密)：在證書發布權威機構CA中，設pca，qca為兩個大素數，其中qca｜（pca-1)，g為Zp＊的qca階元。設整數k1＜k2滿足k1＋k2＝［log2pca］。設 H1：｛0，1｝k1→｛0，1｝k2，H2：Zpca→Zqca為兩個hash函數。屬性證書的的私鑰為x∈Zpca，對應公鑰為y＝gx（mod pca)，假設組件Ei配置（di，χi，pi)，設待簽消息M＝（di‖χi‖pi)∈Z2k1。

簽名步驟如下：

1)CA隨機選取k∈RZq，計算r＝gk（mod pca)并發送r給元件制造商。

2)元件制造商隨機選取t2，t3∈RZq，計算 M′＝M‖H1（M)，R＝M'rgt2yt3（mod pca)，r′＝H2（R)＋t3（mod qca)發送r'給CA。

3)CA計算s＝r'x＋k（mod qca)，發送s給元件制造商。

4)元件制造商驗證等式是否成立gs＝yr'r（mod pca)如果成立，則計算S＝s＋t2（mod qca)并確定（R，S)為對消息 M 的簽名。否則，輸出“False”。

CA將（H2，g，pca)傳送給 VC，以便驗證屬性簽名時用。VC進行以下步驟：

1)選取兩個保密的大素數pvc和qvc.

2)計算nvc＝pvc＊qvcΦ（nvc)＝（pvc-1)（qvc-1)，其中Φ（nvc)是nvc的歐拉函數的值。

3)選一整數e，滿足1＜e＜Φ（nvc)，且gcd（Φ（nvc)，e)＝1

4)計算d，滿足de≡1mod（nvc)，即d是e在下的乘法逆元，因e與Φ（nvc)互素，由模運算可知它的乘法逆元一定存在。以｛e，nvc｝為加密公鑰，｛d，nvc｝為加密私鑰。

VC提前將公鑰｛e，nvc｝傳送給CA，公鑰只有CA知道。CA對屬性簽名（R，S)中的R和S分別進行RSA加密。r'≡Remod nvc，s'≡Semod nvc，CA發布組件加密后的證書（r‘，s’)。

2.2.2 證明過程

配有元件的用戶U請求服務商SP提供請求服務，SP將證明屬性請求和挑戰隨機數N發送給U，要求U證明計算平臺達到安全屬性。

接下來TPM將進行度量和簽名，步驟如下：

1)TPM進行系統元件度量，執行系統元件度量算法，組件ei的度量值為χi，TPM選擇e1到en的元件進行度量，得到度量值χ1到χn。

2)TPM選擇hash函數Ht，對元件e1到en的各id和個度量值求摘要。l＝Ht（d1‖χ1‖…dn‖χn)，si＝lx（mod n)。

TPM將要被驗證的元件夠成一個動態虛擬群［7］，TPM將做以下動作：選擇一個RSA模ng＝pgqg，其中p1與q1是兩個大素數。選擇整數e＞1，使得（e｜Φ（ng))＝1，計算d，使ed≡1（modΦ（ng))。將（ng，e，c)作為系統公鑰。然后，將各個元件加入虛擬群，設組件E1先加入群，成為第1個群成員：

1)TPM 首先隨機選擇x1∈zN，由x1y1≡1（modφ（ng))可以求出y1；

2)TPM選擇一個大于y1的素數m1，M＝m1由 MiNi≡1（mod mi)，得出 Ni；

3)計算c≡y1M1N1，此時，E1的密鑰為（x1，m1)。

接著，剩下的元件也陸續加入虛擬群，若Ei想加入群，成為第k＋1個群成員，則TPM首先隨機選擇xk＋1∈zN，由xk＋1yk＋1≡1（modφ（n))可以求出yk＋1；然后 TPM 選擇一個大于yk＋1的素數mk＋1，使gcd（mk＋1，mi)＝1，i＝1，…，k。

重新計算c≡y1M1N1＋y2M2N2＋…＋ykMkNk＋yk＋1Mk＋1Nk＋1（mod M)，其中新的 M，Mi，Ni都通過原來的M，Mi，Ni得出，即：M＝Mmk＋1；Mi＝Mimk＋1；Ni＝Nimk＋1（mod mi)；其中i＝1，2…k；最后生成簽名協議，設群組成員U1…Um組成子群，他們的秘密鑰分別為（x1，m1)…（xm，mm)。U1…Um分別對摘要簽名，計算si＝lx（mod n)i＝1…m，得子群簽名為（N，（s1，m1)…（sm，mm))，子群通知GC子群簽名完畢，GC對于簽名成員Ui，i＝1…m，重新選擇大于yi素數mi，使gcd（mi，mj)＝1，j＝1，…，（i-1)，GC重新計算：

最后TPM利用skTPM進行簽名：

2.2.3 驗證過程

SP首先驗證AIK證書的正確性，然后驗證元件屬性簽名的正確性：

1)由yi＝c（mod mi)，分別計算出yi（i＝1，…，m)；

VC對密文的解密運算為：

若驗證正確，說明各元件屬性證書正確。

3 協議原型模型

為在實踐中驗證協議方案的可行性，本文在Red Flag 6.0系統下實現了協議方案原型。實驗時序圖如圖2所示。

圖2 原型模型時序圖

試驗中的組件為Java開源類庫文件（.jar文件)，組件中附有屬性證書類，類中包含有組件的ID號、度量值、屬性值、屬性證書值。在向CA申請證書前，屬性證書值為NULL，在申請證書后，組件的ID號、度量值和屬性值被設置為NULL，只保留屬性證書值。

initializePropertyParameter（)對屬性證書的參數進行初始化。初始化256bit的pca，qca及其他參數的平均時間為94ms，512bit的pca和qca初始化平均時間為338ms，其中生成pca，qca，x三個大素數的時間占到整個時間的40%～45%。request-ForMessage（)和vertifyMessage（)完成屬性信息的簽名過程。對于352bit的代簽屬性信息（32bit id值，160bit度量值，160bit屬性值)，在初始化參數為512bit的情況下，生成屬性簽名的平均時間分別為563ms。生成的屬性簽名（r，s)中，r為256bit，s為512bit。

encrySignature（)對屬性簽名（r，s)進行 RSA加密，采用1024bit的RSA加密算法分別對r和s進行加密，生成加密后的屬性簽名（R，S)。加密一對屬性簽名的平均時間為375ms。

sendParameterToVC（)將屬性簽名和RSA加密算法的參數發送給VC，供驗證時使用。

各組件的子群簽名在createProperty（)生成，其中TPM度量摘要值l通過SHA1函數生成（160 bit)。在大素數pg，qg為256bit的情況下，l的元件子群簽名生成時間分布圖如圖3所示。

圖3 子群簽名生成時間分布圖

從圖3中可以看出，兩條曲線的軌跡很接近。即在子群簽名的整個生成過程中，構建子群占用了整個過程的絕大部分時間。在子群構建好后，子群簽名在極短的時間內就能構建好。例如：生成包含20個組件的子群簽名，構建子群需要1735ms，簽名過程需31ms；生成包含60個組件的子群簽名，構建子群需要5344ms，簽名過程需93ms。單個模塊生成時間如表1所示。

表1 單個模塊平均生成時間

從表1中可以看到，隨著元件數的增加，單個元件子群簽名生成的平均時間保持在0.08～0.1s的范圍內，達到實際應用的要求。

4 結束語

本文給出了一種安全性較強、效率較高的遠程認證體系。當前方案中，CA對元件的屬性值處理方式為兩步，第一步是簽名，第二步是加密。下一步研究將集中在將簽名和加密合并為一個步驟，簽名的同時進行加密。利用“簽密”簡化計算步驟，以提高CA的計算效率。

［1］Chen L Q，Landfermann R，Lohr H，et al.A protocol for property-based attestation［C］∥Proceedings of the first ACM-work-shop on Scalable trusted computing.NewYork：ACMPress，2006：7-16.

［2］Jan Camenisch，Anna Lysyanskaya.A signature scheme with efficient protocols［C］∥Security in CommunicationNetworks 02.Springer Verlag，2002：268-289.

［3］李尚杰，賀也平.基于屬性的遠程證明的隱私性分析［J］.通信學報，2009（11)：146-152.

［4］于愛民，馮登國.基于屬性的遠程證明模型［J］.通信學報，2010（8)：1-8.

［5］秦宇，馮登國.基于組件屬性的遠程證明［J］.軟件學報，2009（6)：1621-1641.

［6］黃振杰，王育民.Nybery-Rueppel消息恢復盲簽名的一般化和改進［J］.通信學報，2005（12)：131-135.

［7］施榮華，周玉.一種前向安全的動態子群簽名方案［J］.計算機工程與應用，2006（3)：130-134.