專利名稱：一種基于802.1x認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法
技術領域：
本發(fā)明屬于計算機信息安全領域，尤其涉及一種基于802. Ix認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法。
背景技術：
IEEE 802. Ili是IEEE 802. 11工作組提出的一個安全標準，用于解決IEEE 802. 11 無線局域網(wǎng)(Wireless LocalAreaNetwork，簡稱 WLAN)的安全問題。IEEE802. Ix 協(xié)議是IEEE 802. Ili標準中的一個認證協(xié)議，其體系結構包括三部分客戶端、認證者和認證服務器，主要作用是對WLAN接入用戶進行認證。802. Ix認證協(xié)議運行結束后，客戶端和認證服務器端會協(xié)商出主會話密鑰PMK(Pairwise Master Key)，并由認證服務器端傳給認證者，用于在客戶端和認證者之間計算對等臨時密鑰，繼而得到數(shù)據(jù)加密時所需的各種密鑰。IEEE 802. Ix 協(xié)議使用了可擴展認證協(xié)議 EAP (Extensible Authentication Protocol)。圖1是EAP數(shù)據(jù)包的格式。其中，Code字段用于指出EAP數(shù)據(jù)包的類型，該字段有四個取值，分別對應Request (請求)、Response (回復),Success (成功)和Failure (失敗)四種EAP數(shù)據(jù)包類型。Type字段表明了 Request類型或Response類型的EAP數(shù)據(jù)包所包含的數(shù)據(jù)類型。IEEE 802. Ix協(xié)議中已定義的Type值如下(1) Identity，用于傳用戶名； (2)Notification，用于認證者向客戶端傳遞一些可以顯示的消息；(3)Nak，只在Response 類型的EAP數(shù)據(jù)包中有效；在認證機制協(xié)商過程中，如果有一方不同意另一方提出的認證機制時就用Nak進行否決，而另一方收到Nak消息后則重新選擇認證機制直到雙方都同意為止，從而完成協(xié)商過程；(4)MD5-Challenge ； (5)One-time Password(OPT) ； (6)Genetic Token Card ； (7) EAP-TLS。其中，(4)、(5)、(6)、(7)是認證機制。圖2是IEEE 802. Ix認證協(xié)議的認證流程。首先由認證者向客戶端發(fā)送 EAP-Request/Identity，從而開始整個認證過程。客戶端收到該數(shù)據(jù)包后，發(fā)送包含其身份信息的EAP-Response/Identity給認證者。認證者收到該數(shù)據(jù)包后，將其轉發(fā)給認證服務器端。認證服務器端收到該數(shù)據(jù)包后，便同客戶端開始整個認證消息交互過程。如果認證服務器端通過了對客戶端的認證，那么認證服務器端向認證者發(fā)送EAP-Success，認證者收到該消息后，則認為認證成功，并將該消息轉發(fā)給客戶端，此后客戶端就可以進行授權的正常通信過程；否則，認證服務器端向客戶端發(fā)送EAP-Failure，認證者收到該消息后，則認為認證失敗，并將該消息轉發(fā)給客戶端，中斷與客戶端的通信。雖然802. Ix認證協(xié)議允許通信雙方進行身份認證，并能夠建立安全信道，但是 802. Ix認證協(xié)議沒有考慮通信終端平臺的安全性，對運行在終端上的軟件不提供保護也不做驗證，也就是說802. Ix認證協(xié)議僅能提供一個安全傳輸信道，沒有實現(xiàn)可信信道?？尚判诺朗且粋€與終端的平臺狀態(tài)安全綁定的安全通信信道。將可信計算的遠程證明技術與現(xiàn)有的安全信道技術結合，可以建立可信信道。可信計算遠程證明技術的核心思想是計算平臺以可信芯片TPM(Trusted Platform Module)為信任根，借助可信度量模塊，對系統(tǒng)平臺狀態(tài)信息進行度量，度量結果一方面記錄在TPM 芯片中的平臺配置寄存器PCR(Program Control Register)中，同時在系統(tǒng)保存代表了被驗證的平臺的完整性度量歷史的度量存儲日志SMUStorage Measurement Log)；遠程用戶根據(jù)SML和相關PCR中的數(shù)據(jù)來判斷該運行環(huán)境是否可信、某些環(huán)節(jié)是否出現(xiàn)安全問題。^ TCG(Trusted Computing Group)規(guī)范中，TPM 使用身份證明密鑰 AIK(Attestation Identity Key)來證明自己的身份，凡是經(jīng)過AIK簽名的實體，都表明已經(jīng)經(jīng)過TPM的處理。為了防止重放、篡改、假冒等攻擊，遠程證明要求被驗證的一方要使用AIK對數(shù)據(jù)進行簽名。圖3是美國IBM公司的研究人員設計的遠程證明協(xié)議的流程圖。在這個遠程證明過程中，首先驗證請求者生成一個160bit隨機數(shù)并記為nonce，發(fā)送給被驗證者；被驗證者在收到nonce后，請求內置TPM用AIK的私鑰對指定的PCR值和nonce進行簽名，簽名結果記為Quote，然后將Quote、SML和AIK公鑰證書Cert (AIK)發(fā)送給驗證請求者；最后驗證請求者對接收的內容進行驗證，確定遠程計算平臺身份及其所報告內容的真實性。安全信道技術的核心是密鑰交換協(xié)議，基于現(xiàn)有安全信道技術來建立可信信道的實質就是將遠程證明技術融入到安全信道技術的密鑰交換協(xié)議中，即在密鑰協(xié)商過程中對通信終端的平臺狀態(tài)進行驗證。EAP協(xié)議支持多種認證機制，并允許定義額外新的認證機制。目前還沒有關于將可信計算的遠程證明技術透明地應用于802. Ix認證協(xié)議來建立可信信道的研究報告或軟件，透明性是指在將遠程證明技術融入到安全信道技術的密鑰交換協(xié)議時，不需修改具體的認證機制。

發(fā)明內容
本發(fā)明的目的是，提供一種基于802. Ix認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法，在實現(xiàn)可信傳輸?shù)耐瑫r充分考慮系統(tǒng)的可擴展性。本發(fā)明的又一目的是，提供一種基于802. Ix認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法，有效地提高WLAN的安全性。本發(fā)明的又一目的是，提供一種基于802. Ix認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法，實現(xiàn)遠程證明過程對802. Ix認證機制的透明性。為達到上述目的，本發(fā)明采用如下的技術手段一種基于802. Ix認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法，包括以下步驟(1)客戶端和認證服務器端完成認證消息交互過程，并分別計算出主會話密鑰 PMK ；(2)認證服務器端向認證者發(fā)送EAP-Request/TPM，該數(shù)據(jù)包中Type字段的值為 TPM, TypeData字段的值為所要驗證的平臺狀態(tài)信息的類型，認證者收到該數(shù)據(jù)包后將其轉發(fā)給客戶端；(3)客戶端收到EAP-Request/TPM后，若根據(jù)Type字段的值判斷需要向認證服務器端發(fā)送客戶端的驗證信息，則根據(jù)客戶端的主會話密鑰和客戶端的平臺信息生成客戶端的驗證信息，封裝成EAP-Response/TPM發(fā)送給認證者，認證者收到該數(shù)據(jù)包后將其轉發(fā)給認證服務器端；(4)認證服務器端收到EAP-Response/TPM后，若根據(jù)Type字段的值判斷 TypeData字段的內容為客戶端發(fā)送來的驗證信息，則根據(jù)接收到的客戶端的驗證信息和認證服務器端的主會話密鑰對客戶端進行驗證，驗證通過后向認證者發(fā)送EAP-Success，認證者再將該數(shù)據(jù)包轉發(fā)給客戶端；還包括以下步驟(5)客戶端收到EAP-Request/TPM后，若根據(jù)Type字段的值判斷需要向認證服務器端發(fā)送客戶端的驗證信息，但客戶端并不支持遠程證明機制，則客戶端向認證者發(fā)送 ΕΑΡ-Response，該數(shù)據(jù)包中Type字段的值為Nak，TypeData字段的值為客戶端不支持遠程證明機制這一事實，認證者收到該數(shù)據(jù)包后將其轉發(fā)給認證服務器端；(6)認證服務器端收到ΕΑΡ-Response后，若根據(jù)Type字段和TypeData字段的值判斷客戶端不支持遠程證明機制，則向認證者發(fā)送EAP-Failure，認證者再將該數(shù)據(jù)包轉發(fā)給客戶端。生成客戶端的驗證信息包括以下步驟(1)對客戶端的主會話密鑰進行哈希運算，結果記為HS_Key ；(2)利用可信安全芯片TPM中的AIK私鑰對字符串PCRs | | HS_Key進行簽名，簽名結果記作signs，其中PCRs是客戶端安全芯片TPM中代表客戶端平臺狀態(tài)信息的PCR內容， ‘ I I，代表將兩個字符串連接起來；(3)用客戶端的主會話密鑰作為對稱加密密鑰，對客戶端的平臺度量存儲日志 SMLs加密，結果記為encs ；(4)利用signs、encs及客戶端AIK的公鑰證書生成驗證信息。認證服務器端對客戶端平臺信息的驗證包括以下步驟認證服務器端利用所述客戶端AIK的公鑰證書從Signs中獲得HS_Key和PCRs ；對認證服務器端的主會話密鑰進行哈希運算，結果記為HR_Key ；判斷HR_Key和HS_Key是否匹配，如果不匹配，則終止認證過程；如果匹配，則認證服務器端利用主會話密鑰解密encs得到客戶端的平臺度量存儲日志SMLs ；根據(jù)SMLs重新計算客戶端TPM平臺配置寄存器存儲的內容，計算結果記為PCR_ tmpS ；判斷PCR_tmpS與PCRs是否匹配，如果不匹配，則終止認證過程；如果匹配，則認證通過。本發(fā)明的有益效果在于(1)本發(fā)明將可信計算的遠程證明技術緊密地融入802. Ix認證協(xié)議，確?？蛻舳似脚_狀態(tài)信息和安全信道的真實連接；(2)本發(fā)明的方法實現(xiàn)了客戶端的平臺信息在網(wǎng)絡上的秘密傳輸；(3)本發(fā)明的方法不需要修改標準802. Ix認證協(xié)議中涉及到的認證機制，實現(xiàn)了遠程證明過程對802. Ix認證機制的透明性。


圖1是EAP數(shù)據(jù)包的格式；圖2是IEEE 802. Ix認證協(xié)議的認證流程；圖3是美國IBM公司的研究人員設計的遠程證明協(xié)議的流程圖；圖4是實現(xiàn)了本發(fā)明所提供的方法的802. Ix認證協(xié)議的認證流程。
具體實施例方式本發(fā)明一種基于802. Ix認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法，在硬件上要求客戶端配有可信安全芯片TPM，而且它的BIOS支持TPM ；在軟件上要求客戶端安裝度量模塊。 客戶端擁有自己的AIK公私鑰。本發(fā)明提供的方法需要對802. Ix認證協(xié)議做如下修改(1)為EAP數(shù)據(jù)包中的Type字段定義一個新值，記作TPM，用于說明認證服務器端要驗證客戶端的平臺狀態(tài)信息。當Type字段的值為TPM時，對應的TypeData 字段的值用于說明所要驗證的平臺信息的類型。本發(fā)明中將Type字段值為TPM的 ΕΑΡ-Request (Response)記作 ΕΑΡ-Request (Response) /TPM0本發(fā)明中用ΕΑΡ-Request 表示 Request 類型的 EAP 數(shù)據(jù)包，EAP-Request/ Identity表示Type字段值為Identity的Request類型的EAP數(shù)據(jù)包，其他類似符號的含義依此類推。TypeData字段的值隨ΕΑΡ-Request和ΕΑΡ-Response中Type值的不同而不同。(2)當客戶端接收到EAP-Request/TPM時，如果客戶端支持遠程證明機制，則回復 EAP-Response/TPM，該數(shù)據(jù)包中Type字段的值也置為TPM，TypeData字段則用于存放客戶端的驗證信息。如果客戶端不支持遠程證明機制，則回復Type字段值為Nak的Response 類型數(shù)據(jù)包，TypeData字段則用于說明客戶端不支持遠程證明機制這一事實。圖4是實現(xiàn)了本發(fā)明所提供的方法的802. Ix認證協(xié)議的認證流程。具體步驟如下步驟1，認證者向客戶端發(fā)送EAP-Request/Identity，從而發(fā)起整個認證過程；步驟2，客戶端收到認證者發(fā)送的EAP-Request/Identity后，將其用戶名等身份信息封裝在EAP-Response/Identity中，發(fā)送給認證者；步驟3，認證者收到EAP-Response/Identity后，將該數(shù)據(jù)包轉發(fā)給認證服務器端；步驟4，認證服務器端收到EAP-Response/Identity后，便同客戶端開始整個認證消息交互過程。認證過程結束后，客戶端和認證服務器端分別計算出主會話密鑰PMK，進入步驟5 ；步驟5，認證服務器端構造EAP-Request/TPM，其中Type字段的值為TPM，TypeData 字段的值為所要驗證的平臺狀態(tài)信息的類型，然后將EAP-Request/TPM發(fā)送給認證者；步驟6，認證者收到EAP-Request/TPM后，將該數(shù)據(jù)包轉發(fā)給客戶端；步驟7，客戶端收到認證者轉發(fā)的EAP-Request/TPM后，首先檢查Type字段的值， 如果值為TPM，則客戶端對主會話密鑰進行哈希運算，并將其哈希值記作HS_Key?？蛻舳耸褂肨PM中AIK的私鑰(記作AIKphv)對字符串PCRsI | HS_Key進行簽名，并將簽名結果記作 Signs0其中，PCRs是客戶端安全芯片TPM中代表客戶端平臺狀態(tài)信息的PCR內容，‘ | | ’代表將兩個字符串連接起來。然后客戶端用主會話密鑰作為對稱加密密鑰，對SMLs加密，結果記為encs。最后客戶端構造EAP-Response/TPM，Type字段的值為TPM，并將signs、encs和 CertsAIK放入TypeData字段。其中，CertsAIK為客戶端AIK的公鑰證書，SMLs表示客戶端的平臺度量存儲日志。最后將EAP-Response/TPM發(fā)送給認證者，進入步驟8。如果客戶端檢查到Type字段的值為TPM但其本身并不支持遠程證明機制，則客戶端構造EAP-Response，其中Type字段的值為Nak，TypeData字段值為客戶端不支持遠程證明機制這一事實，進入步驟8 ；步驟8，認證者收到EAP-Response/TPM或ΕΑΡ-Response后，將該數(shù)據(jù)包轉發(fā)給認證服務器端；步驟9，認證服務器端收到認證者轉發(fā)的Response數(shù)據(jù)包后，提取其中Type字段的值，如果值為TPM，則再提取TypeData字段的內容，驗證其中的CertsAIK的有效性和合法性。如果驗證沒通過，則終止認證過程并向認證者發(fā)送ΕΑΡ-Failure ；如果驗證通過，則利用CertsAIK的公鑰從Signs中獲得步驟7中的HS_Key和PCRS。然后認證服務器端對主會話密鑰進行哈希運算，將哈希值記作HR_Key，判斷HR_Key和HS_Key是否匹配。如果不匹配， 則終止認證過程并向認證者發(fā)送ΕΑΡ-Failure ；如果匹配，則認證服務器端用主會話密鑰解密encs得到步驟7中的SMLs，然后根據(jù)SMLs重新計算客戶端TPM平臺配置寄存器存儲的內容，計算結果記為PCR_tmpS，然后判斷PCR_tmpS與PCRs是否匹配。如果不匹配，則終止認證過程并向認證者發(fā)送ΕΑΡ-Failure ；如果匹配，則說明認證服務器通過了對客戶端的認證，并向認證者發(fā)送EAP-Access，然后認證服務器端再通過安全信道將PMK傳送給認證者，進入步驟10。如果認證服務器端檢查到接收到的Response數(shù)據(jù)包中Type字段的值為 Nak，則提取TypeData字段的內容，當認證服務器端知道客戶端不支持遠程證明機制時，則向認證者發(fā)送EAP-Failure，進入步驟10 ；步驟10，如果認證者收到了認證服務器端發(fā)送的EAP-Access消息，則認為認證成功，并向客戶端轉發(fā)EAP-Success，此后客戶端可以進行授權的正常通信過程；如果認證者收到了認證服務器端發(fā)送的EAP-Failure，則認為認證失敗，并向客戶端轉發(fā) EAP-Failure，此時客戶端不能夠進行授權的通信過程。通過上述方法，實現(xiàn)了 WLAN中的可信傳輸，該可信傳輸具有以下兩個特性，一個是遠程證明過程對認證機制的透明性，另一個是客戶端的平臺信息在網(wǎng)絡傳輸過程中的秘密性。
權利要求
1.一種基于802. Ix認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法，其特征在于，包括以下步驟客戶端和認證服務器端完成認證消息交互過程，并分別計算出主會話密鑰PMK ； 認證服務器端向認證者發(fā)送EAP-Request/TPM，該數(shù)據(jù)包中Type字段的值為TPM， TypeData字段的值為所要驗證的平臺狀態(tài)信息的類型，認證者收到該數(shù)據(jù)包后將其轉發(fā)給客戶端；客戶端收到EAP-Request/TPM后，若根據(jù)Type字段的值判斷需要向認證服務器端發(fā)送客戶端的驗證信息，則根據(jù)客戶端的主會話密鑰和客戶端的平臺信息生成客戶端的驗證信息，封裝成EAP-Response/TPM發(fā)送給認證者，認證者收到該數(shù)據(jù)包后將其轉發(fā)給認證服務器端；認證服務器端收到EAP-Response/TPM后，若根據(jù)Type字段的值判斷TypeData字段的內容為客戶端發(fā)送來的驗證信息，則根據(jù)接收到的客戶端的驗證信息和認證服務器端的主會話密鑰對客戶端進行驗證，驗證通過后向認證者發(fā)送EAP-Success，認證者再將該數(shù)據(jù)包轉發(fā)給客戶端。
2.根據(jù)權利要求1所述的方法，其特征在于，還包括以下步驟客戶端收到EAP-Request/TPM后，若根據(jù)Type字段的值判斷需要向認證服務器端發(fā)送客戶端的驗證信息，但客戶端并不支持遠程證明機制，則客戶端向認證者發(fā)送 ΕΑΡ-Response，該數(shù)據(jù)包中Type字段的值為Nak，TypeData字段的值為客戶端不支持遠程證明機制這一事實，認證者收到該數(shù)據(jù)包后將其轉發(fā)給認證服務器端；認證服務器端收到ΕΑΡ-Response后，若根據(jù)Type字段和TypeData字段的值判斷客戶端不支持遠程證明機制，則向認證者發(fā)送EAP-Failure，認證者再將該數(shù)據(jù)包轉發(fā)給客戶端。
3.根據(jù)權利要求1所述的方法，其特征在于，所述的生成客戶端的驗證信息包括以下步驟對客戶端的主會話密鑰進行哈希運算，結果記為HS_Key ；利用可信安全芯片TPM中的AIK私鑰對字符串PCRs I I HS_Key進行簽名，簽名結果記作 signs，其中PCRs是客戶端安全芯片TPM中代表客戶端平臺狀態(tài)信息的PCR內容，‘ | |，代表將兩個字符串連接起來；用客戶端的主會話密鑰作為對稱加密密鑰，對客戶端的平臺度量存儲日志SMLs加密， 結果記為encs ；利用signs、encs及客戶端AIK的公鑰證書生成驗證信息。
4.根據(jù)權利要求1所述的方法，其特征在于，認證服務器端對客戶端平臺信息的驗證包括以下步驟認證服務器端利用所述客戶端AIK的公鑰證書從Signs中獲得HS_Key和 PCRs;對認證服務器端的主會話密鑰進行哈希運算，結果記為HR_Key ； 判斷HR_Key和HS_Key是否匹配，如果不匹配，則終止認證過程；如果匹配，則認證服務器端利用主會話密鑰解密encs得到客戶端的平臺度量存儲日志SMLs ；根據(jù)SMLs重新計算客戶端TPM平臺配置寄存器存儲的內容，計算得到PCR_tmpS ； 判斷PCR_tmpS與PCRs是否匹配，如果不匹配，則終止認證過程；如果匹配，則認證通過。
全文摘要
本發(fā)明涉及一種基于802.1x認證協(xié)議的WLAN可信傳輸?shù)膶崿F(xiàn)方法，該方法包括當客戶端和認證服務器端完成認證消息交互過程并分別計算出主會話密鑰后，認證服務器端封裝一個Request類型的EAP數(shù)據(jù)包，發(fā)送給認證者，其中Type字段的值為TPM，表示認證服務器端要對客戶端進行遠程證明，TypeData字段的值為所要驗證的平臺狀態(tài)信息的類型。然后認證者將該Request包轉發(fā)給客戶端。客戶端接收到該包后，根據(jù)Type字段的值和客戶端的主會話密鑰和客戶端的平臺信息生成客戶端平臺驗證信息，并發(fā)送給認證者；再由認證者轉發(fā)給認證服務器端。認證服務器端收到客戶端平臺驗證信息后，根據(jù)認證服務器端的主會話密鑰對客戶端平臺驗證信息進行驗證，驗證通過后向客戶端發(fā)送Success類型的EAP數(shù)據(jù)包。
文檔編號H04W80/00GK102223635SQ20111019013
公開日2011年10月19日 申請日期2011年7月7日 優(yōu)先權日2011年7月7日
發(fā)明者劉吉強, 常曉林, 秦英, 韓臻 申請人:北京交通大學