WTLS的作用是保證傳輸層的安全，作為WAP 協(xié)議棧的一個層次向上層提供安全傳輸服務(wù)接口。WTLS是以安全協(xié)議TLS1.0標準為基礎(chǔ)發(fā)展而來的，提供通信雙方數(shù)據(jù)的機密性、完整性和通信雙方的鑒權(quán)機制。WTLS在TLS的基礎(chǔ)上，根據(jù)無線環(huán)境、長距離、低帶寬、自身的適用范圍等增加了一些新的特性，如對數(shù)據(jù)報的支持、握手協(xié)議的優(yōu)化和動態(tài)密鑰刷新等。 WTLS能夠提供下列三種類別的安全服務(wù)： i.??????????????第一類服務(wù)：能使用交換的公共密鑰建立安全傳輸，使用對稱算法加密解密數(shù)據(jù)，檢查數(shù)據(jù)完整性，可以建立安全通信的通道，但沒有對通信雙方的身份進行鑒權(quán)。 ii.??????????????第二類服務(wù)：除完成第一類服務(wù)的功能外還可以交換服務(wù)器證書，完成對服務(wù)器的鑒別。 iii.??????????????第三類服務(wù)：除完成第二類服務(wù)的功能外還可以交換客戶證書，在服務(wù)器鑒別的基礎(chǔ)上又增加了客戶鑒別，對惡意的用戶冒充也能進行抗擊。 從第一類服務(wù)到第三類服務(wù)安全級別逐級增高，可以根據(jù)應(yīng)用對安全級別的要求選擇性的實現(xiàn)某一級別的安全服務(wù)。通常應(yīng)該對這三種類別的服務(wù)都能支持，在握手協(xié)商的過程中由客戶端與服務(wù)端共同協(xié)商選定一個類別。 一?WTLS安全問題解決方法 1.????加密 WTLS的保密性依靠加密通信通道來實現(xiàn)，所使用的加密方法和計算共享密鑰所需的值在握手時進行交換。首先，客戶端和服務(wù)器交換Hello消息，此后，客戶端和服務(wù)器交換預(yù)主密鑰（Pre master Secret），這個值用來計算主密鑰（Master Secret），計算所使用的加密算法在服務(wù)器的Hello消息中進行選擇。在這條消息中，服務(wù)器通知客戶端已經(jīng)選擇了一個密碼組，客戶端向服務(wù)器提供一個密碼組列表。如果服務(wù)器未發(fā)現(xiàn)合適的密碼組，則握手失敗，連接關(guān)閉。當前常用的大批量加密算法有：支持40、56和128位密鑰的RC5，支持40和56位密鑰的DES，支持40、56和128位密鑰的3DES和IDEA。所有的算法都是分組加密算法，加密密鑰在密鑰分組的基礎(chǔ)上進行操作，密鑰分組根據(jù)協(xié)商的密鑰刷新頻率在一段時間后重新運算。 2.????密鑰交換 為了保證安全的聯(lián)系通道，加密密鑰或計算密鑰的初始值必須以安全方式進行交換。WTLS的密鑰交換機制提供了一種匿名交換密鑰的方法。在密鑰交換過程中，服務(wù)器發(fā)送包含服務(wù)器公鑰的服務(wù)器密鑰交換消息。密鑰交換算法可能是RSA、Diffie-Hellman或Elliptic Curve Diffie-Hellman。在RSA和匿名RSA中，客戶端用服務(wù)器的公鑰加密預(yù)主密鑰，并在客戶密鑰交換消息中將其返回給服務(wù)器。在基于Diffie-Hellman的算法中，客戶端和服務(wù)器在一個私鑰和相應(yīng)的公鑰基礎(chǔ)上計算預(yù)主密鑰。 如果客戶端列出了它所支持的用密碼寫的密鑰交換方法，服務(wù)器可以選擇是使用基于客戶請求的方法，還是定義另一種方法。如果客戶端并未提出任何方法，則服務(wù)器必須指明。 3.????鑒別 WTLS的身份鑒別依靠證書實現(xiàn)。身份鑒別可以在客戶端和服務(wù)器之間進行，也可以在服務(wù)器允許的情況下，只由客戶端鑒別服務(wù)器，服務(wù)器還可以要求客戶端向服務(wù)器證明自己。在WTLS規(guī)范中，身份鑒別是可選的。 當前所支持的證書類型包括：X.509v3、X9.68 和 WTLS證書。在客戶端和服務(wù)器之間交換Hello消息之后，鑒別過程隨即開始。當使用鑒別時，服務(wù)器發(fā)送服務(wù)證書消息給客戶端。根據(jù)WTLS規(guī)范，為了優(yōu)化流量和客戶處理，服務(wù)器一次只發(fā)送一個證書。服務(wù)器證書由CA公司獨立分發(fā)的公鑰進行鑒別。服務(wù)器也可以發(fā)送證書請求消息給客戶端以鑒別之。此時，客戶端發(fā)送客戶證書消息返回給服務(wù)器，客戶端證書遵循與服務(wù)證書相同的結(jié)構(gòu)。 4.????完整性 數(shù)據(jù)完整性通過使用消息鑒別編碼(MAC)而得到保證， MAC算法同時也被認為是加密算法?？蛻舳税l(fā)送一列所支持的MAC算法，服務(wù)器在返回的Hello 消息中標出所選的算法。WTLS支持通用的MAC算法，MAC在壓縮的WTLS 數(shù)據(jù)上產(chǎn)生。 5.????安全狀態(tài) 在安全協(xié)商后，會話通信雙方將擁有同樣的安全狀態(tài)。當前狀態(tài)通過安全參數(shù)產(chǎn)生，并持續(xù)更新。 二?WTLS協(xié)議結(jié)構(gòu) WTLS工作在無線數(shù)據(jù)報協(xié)議(WDP)層和無線事務(wù)協(xié)議 (WTP)層之間，它所提供的服務(wù)對這兩層協(xié)議來說是可選的。WTLS由功能協(xié)議層和記錄協(xié)議層構(gòu)成。其中功能協(xié)議層包含了握手協(xié)議、改變密碼標準協(xié)議、 告警協(xié)議；記錄協(xié)議層提供對握手協(xié)議層以及上層應(yīng)用數(shù)據(jù)的封裝結(jié)構(gòu)，在客戶端和服務(wù)端的WTLS對等層之間完成實際的數(shù)據(jù)傳送任務(wù)。WTLS協(xié)議結(jié)構(gòu)如圖3-1所示 1.????記錄協(xié)議(Record Protocol) 本協(xié)議是一個從相鄰層接收原始數(shù)據(jù)的協(xié)議，它僅在連接狀態(tài)下運行。當開始一個安全會話時，連接狀態(tài)初始化為NULL。邏輯上存在兩種狀態(tài)：當前狀態(tài)和未決狀態(tài)，記錄在當前狀態(tài)下處理。它將所接收到的數(shù)據(jù)進行壓縮、加/解密、鑒別和數(shù)據(jù)完整性處理，然后向上層轉(zhuǎn)交或向下層發(fā)送。本協(xié)議進行的有關(guān)處理完全按照在握手協(xié)議中通信雙方所協(xié)商一致的處理流程和算法進行。 2.????握手協(xié)議(Handshake Protocol) 所有與安全相關(guān)的參數(shù)都是在握手階段協(xié)商一致的。這些參數(shù)包括：協(xié)議版本號、使用的加密算法、鑒別的信息和由公開密鑰技術(shù)生成的密鑰素材。握手階段從客戶方與服務(wù)方進行Hello消息應(yīng)答開始，在兩個 Hello消息中，通信雙方商定一致的會話方式。當客戶方發(fā)送Client Hello消息以后，它等待接收Server Hello Done消息。服務(wù)方如果需要鑒別，可以發(fā)一個代表自己的服務(wù)器證書給客戶方，也可以要求客戶方鑒別自己。Server Key Exchange 用于向客戶方提供公開密鑰。 當客戶方收到Server Hello Done消息后，返回Client Certificate 消息以讓服務(wù)方鑒別自己。隨后客戶方發(fā)送一個Client Key Exchange消息，包含由服務(wù)方用公開密鑰加密過的共享主密鑰和其他一些信息，以使雙方完成密鑰交換。最后，客戶方發(fā)送一個包含驗證前面所有數(shù)據(jù)的Finished Message，服務(wù)方也同樣發(fā)送一個Finished Message證實交換和計算的信息來回應(yīng)客戶方。此外，任何一方都可以發(fā)送一個Change Cipher Spec消息來決定雙方使用的密碼參數(shù)。 3.????告警協(xié)議(Alert Protocol) 告警類型是WTLS記錄層支持的內(nèi)容類型之一，告警消息傳送的內(nèi)容為信息錯誤的嚴重程度及告警描述。記錄協(xié)議的告警消息主要有警告、危急、致命三種。告警消息使用當前的安全狀態(tài)發(fā)送，如果告警消息的類型是“致命”，則雙方將結(jié)束安全鏈接。同時，其他使用安全會話的鏈接可以繼續(xù)，但會話標識必須設(shè)成無效，從而使失敗的鏈接不能被用于建立新的安全鏈接。當告警消息的類型為“危急”時，當前的安全鏈接結(jié)束，而其他使用安全會話的鏈接可以繼續(xù)，會話標記可以用于建立新的安全鏈接。 WTLS中的出錯處理是基于告警消息的，當發(fā)現(xiàn)錯誤時，發(fā)現(xiàn)的一方發(fā)送包含出現(xiàn)錯誤的告警消息，進一步的處理依賴于出現(xiàn)錯誤的級別和類型。 告警中采用4字節(jié)校驗和，該值可以通過接收其他對話方的上次記錄計算得出，方法如下： （1）以0填充記錄，使其長度為4的模。 （2）將結(jié)果分割為4字節(jié)的長度塊。 （3）對這些塊進行XOR運算。 告警接收方應(yīng)該檢查校驗和是否與以前所發(fā)送的信息相匹配。 4.????改變密碼標準協(xié)議(Change Cipher Spec Protocol) 此協(xié)議用來在WAP會話的雙方間進行加密策略改變的通知，僅使用一種改變密碼標準消息。消息中包含一個字節(jié)，值為1。此消息在雙方的安全參數(shù)協(xié)商一致后，在握手階段由客戶方或服務(wù)方發(fā)送給對方實體，用于通知對方：以后的數(shù)據(jù)記錄將采用新協(xié)商的密碼規(guī)范和密鑰。當消息到達時， 發(fā)送消息的一方設(shè)定當前的寫狀態(tài)為待決狀態(tài)(Pending State)，接收消息的一方設(shè)定當前的讀狀態(tài)為待決狀態(tài)。 三?WTLS中的握手協(xié)議 3.1??????握手協(xié)議的流程 ?????? ?與安全相關(guān)的參數(shù)均在握手過程中產(chǎn)生，當WTLS的客戶端與服務(wù)端第一次通信時，它們將在握手過程中協(xié)商協(xié)議版本、選擇加密算法、相互驗證并用公鑰加密算法產(chǎn)生一個共享的會話密鑰。 i.??????????????當通信開始時，握手協(xié)議主要實現(xiàn)如下功能： ii.??????????????協(xié)商密鑰交換模式，選擇密碼算法。 iii.??????????????根據(jù)應(yīng)用需要，對通信一方或雙方進行身份認證。 iv.??????????????通信雙方按照協(xié)商的密鑰交換模式建立一個預(yù)先主密鑰。 v.??????????????利用預(yù)先主密鑰和隨機數(shù)生成一個主密鑰。 vi.??????????????將所有密碼安全參數(shù)傳給協(xié)議記錄層。 vii.??????????????用戶和服務(wù)器確認對方已經(jīng)計算出相同的密碼參數(shù)，且握手協(xié)議沒有受到攻擊者阻擾。 完整的握手過程如圖3-2所示。首先客戶端對服務(wù)器端發(fā)出ClientHello消息，告知服務(wù)器客戶端要與它連接。而服務(wù)器端發(fā)出ServerHello消息，如果服務(wù)器端沒有發(fā)出該消息則會出現(xiàn)致命的錯誤而中斷整個安全連接。在兩個Hello消息中通信雙方將協(xié)商下列屬性：協(xié)議版本、密鑰交換組合、壓縮方式、密鑰刷新和順序編碼模式等。除此之外，還會有兩個隨機變量產(chǎn)生出來并進行交換：ClientHello.random和ServerHello.random。 在客戶端發(fā)出Hello消息后，它將開始接收消息直到收到ServerHelloDone消息。如果服務(wù)器端需要驗證的話，服務(wù)器端將發(fā)送服務(wù)器認證消息，而且服務(wù)器端也可能會要求客戶端提供其認證。而服務(wù)器密鑰交換信息則向客戶端提供服務(wù)器公鑰用于產(chǎn)生或管理預(yù)主密鑰。 客戶端在收到ServerHelloDone信息后將繼續(xù)握手過程，如果服務(wù)器要求，客戶端將發(fā)送能夠證明自己身份的認證。緊接著客戶端將發(fā)送密鑰交換信息，該信息包含了用服務(wù)器公鑰加密的預(yù)主密鑰或能夠完成雙方密鑰交換的基本信息。最后客戶端將發(fā)送一個完成消息，其中包含對于先前數(shù)據(jù)和計算數(shù)值的確認。 同樣服務(wù)器端將發(fā)送一個完成消息，而且也包含對于先前數(shù)據(jù)和計算數(shù)值的確認。 此刻，客戶端會送出一個改變密碼規(guī)則消息，并且客戶端會將新的密碼規(guī)則拷貝到現(xiàn)有的書寫密碼規(guī)則中。然后客戶端立即按新的算法、密鑰送出完成信息。當服務(wù)器端收到改變密碼規(guī)則消息后，同樣會將新的密碼規(guī)則拷貝到現(xiàn)有讀取密碼規(guī)則中，并用新的密碼規(guī)則傳送本身完成信息以作為響應(yīng)。此刻整個握手過程已經(jīng)完成，客戶端和服務(wù)器端開始交換應(yīng)用層的數(shù)據(jù)。 當客戶端和服務(wù)器端決定繼續(xù)使用前一次的安全會話參數(shù)時，握手過程將被簡化，其信息流如圖3-3所示。首先客戶端發(fā)送一個包含會話標示符的ClientHello消息，服務(wù)器端將檢測安全會話緩存以尋找一個與客戶端傳來的會話標示符相匹配的會話。如果找不到，則服務(wù)器端將產(chǎn)生一個新的會話標示符，并開始完整握手過程。 3.2??????密鑰交換 WAP規(guī)范規(guī)定了握手協(xié)議中的四種密鑰交換方式： A??????????共享密鑰方法：這是最簡單的方法，客戶與服務(wù)器在通信之前就已經(jīng)共享了一個密鑰，在通信時將其共享密鑰作為預(yù)主密鑰，利用它和雙方新近生成的隨機數(shù)生成保密通信所需要的主密鑰。 B?????????RSA加密傳輸方法：當RSA算法用于認證服務(wù)器并交換密鑰時，客戶生成一個20字節(jié)的秘密數(shù)，用服務(wù)器的公開密鑰加密后傳給服務(wù)器；服務(wù)器利用其秘密密鑰可以解密出上述秘密數(shù)。這種方法生成的主密鑰為上述秘密數(shù)與服務(wù)器公開密鑰的級連。 C????????????DH密鑰交換方法：即傳統(tǒng)的Diffle-Hellman密鑰交換方法，客戶和服務(wù)器先分別生成隨機數(shù)Rk和Rs，并基于一個公共基計算出隨機冪指數(shù)；然后，它們交換計算出來的隨機冪指數(shù)；最后，雙方分別利用對方提供的隨機冪指數(shù)為基，以它們自己選擇的隨機數(shù)為指數(shù)，計算出它們共享的密鑰。這種方法容易遭到中間人攻擊。 D????????????EC-DH密鑰交換方法：橢圓曲線版本的Diffie-Hellman密鑰交換方法，客戶和服務(wù)器先分別隨機數(shù)Rk和Rs，并基于某個橢圓曲線的生成點分別計算出隨機點Pk和Ps；最后，雙方分別利用對方提供的隨機點和自己選擇的隨機數(shù)Rk和Rs，計算出共享密鑰，即RkRsG的坐標x。這種方法也容易遭到中間人攻擊。 3.3??????身份認證以及相應(yīng)的握手協(xié)議的分類 WAP規(guī)范采用基于用戶公開密鑰證書方法進行身份認證。公開密鑰證書的記錄中包含有用戶的身份信息，CA在對用戶的身份信息進行確認后，對用戶的公開密鑰和身份等信息的哈希值進行數(shù)字簽名，從而保證證書不能被更改和偽造。 WAP規(guī)范推薦了兩種數(shù)字簽名算法，即RSA和ECDSA。由此，公開密鑰證書也分為兩種：對用戶RSA公開密鑰進行RSA數(shù)字簽名而產(chǎn)生的證書，和對用戶的ECDH公開密鑰進行ECDSA簽名的證書。證書的格式有多種：X-509、WTLS、X-968等。 WAP規(guī)范規(guī)定數(shù)據(jù)加密和完整性保護是必須提供的安全性服務(wù)，為此握手協(xié)議必須實現(xiàn)密鑰交換功能，而身份認證可以根據(jù)應(yīng)用要求有選擇性的實現(xiàn)。為此，WTLS握手協(xié)議可分為三個安全類： l無認證的握手協(xié)議。 l服務(wù)器認證的握手協(xié)議。 l服務(wù)器和客戶相互認證的握手協(xié)議。 為了提高協(xié)議效率并保證密鑰交換和身份認證功能的安全實現(xiàn)，握手協(xié)議中證書的簽名算法必須與密鑰交換算法一致。下面分別論述這三種安全類中的握手協(xié)議。 1.????無認證的握手協(xié)議 無認證的握手協(xié)議采用共享密鑰方式實現(xiàn)密鑰交換，它的實現(xiàn)方式如圖3-4所示?？蛻舳耸紫劝l(fā)送ClientHello消息給服務(wù)器端，其中包含協(xié)議版本、密鑰交換模式、加密算法和完整性算法，，以及隨機數(shù)等信息?？蛻舳撕头?wù)器端利用共享密鑰作為預(yù)主密鑰，并結(jié)合來自用戶和服務(wù)器的隨機數(shù)，生成真正的主密鑰。 基于共享密鑰的協(xié)議存在一個主要問題就是密鑰的分配問題。由于預(yù)主密鑰不能在無線信道中以明文方式傳送，在實際應(yīng)用中預(yù)主密鑰必須以某種方式分配到用戶手中。例如，GSM網(wǎng)絡(luò)中移動用戶與歸屬局共享的密鑰是以SIM卡方式傳給移動用戶的：在移動用戶個人初始化時，歸屬局生成密鑰，并將它存入SIM卡，再將SIM卡交給移動用戶?；诠蚕砻荑€的握手協(xié)議實現(xiàn)簡單，適合在低功耗、低計算能力的移動終端上實現(xiàn)，因而在實際中得到廣泛應(yīng)用。 2.????服務(wù)器認證的握手協(xié)議 服務(wù)器認證的握手協(xié)議采用基于公鑰證書的方法實現(xiàn)身份認證。其預(yù)主密鑰的分配過程如下：服務(wù)器端將公開密鑰傳給客戶端，用戶生成一個預(yù)主密鑰，并用服務(wù)器的公開密鑰加密后傳給服務(wù)器端，服務(wù)器利用其秘密密鑰解密恢復(fù)預(yù)主密鑰，這就很好的解決了預(yù)主密鑰的分配問題。這種密鑰交換方式不要求通信雙方事先共享任何密鑰，適用于分布式網(wǎng)絡(luò)。服務(wù)器認證的握手協(xié)議的實現(xiàn)方式如圖3-5所示。 3.????用戶和服務(wù)器雙向認證握手協(xié)議 用戶和服務(wù)器雙向認證握手協(xié)議，是在服務(wù)器認證握手協(xié)議的基礎(chǔ)上加上用戶認證功能。在WAP規(guī)范中，用戶身份認證也是基于用戶的公開密鑰證書的。在握手協(xié)議中，服務(wù)器向用戶傳證書請求消息，用戶或者將其公開密鑰證書直接傳給服務(wù)器，或者將一個URL地址傳給服務(wù)器，服務(wù)器根據(jù)URL連接調(diào)用用戶公開密鑰證書，后者不僅可以節(jié)省證書傳送時間，而且也可以降低無線終端的復(fù)雜度。用戶和服務(wù)器雙向認證握手協(xié)議的實現(xiàn)過程如圖3-6所示。 3.4??????主密鑰的生成 上述握手協(xié)議中預(yù)主密鑰的生成方法各不相同，根據(jù)密鑰交換方法來變化。而將預(yù)主密鑰轉(zhuǎn)換成主密鑰的方法則是相同的，即： master_secret = PRF(pre_master_secret,“master secret”,ClientHello.random + ServerHello.random)[0..19] 這里PRF代表偽隨機數(shù)。 主密鑰的長度固定為20字節(jié)，而預(yù)主密鑰的長度則依密鑰交換的方法不同而有所不同。當主密鑰計算出之后，預(yù)主密鑰立即被刪除。 在一個恢復(fù)的會話中，主密鑰與前一次會話中的主密鑰相同。然而，由于握手協(xié)議中雙方重新交換了隨機數(shù)，這樣新的會話將使用不同的密鑰組。所謂密鑰組是指加密算法和MAC算法所需要的加密密鑰、初始矢量和MAC密鑰。 密鑰組以下述方法計算：當握手協(xié)議正常結(jié)束時，握手協(xié)議中生成的主密鑰、選擇的密碼算法等信息均被傳給WTLS層的記錄協(xié)議。記錄協(xié)議生成加密算法所需要的加密密鑰和初始矢量，以及MAC算法所需要的MAC密鑰。而這些密碼參數(shù)則是由主密鑰、客戶隨機數(shù)和服務(wù)器隨機數(shù)等參數(shù)經(jīng)過偽隨機函數(shù)PRF產(chǎn)生： key_block = PRF(SecurityParameters.master_secret,expansion_label, seq_num + SecurityParameters.server_random + SecurityParameters.client_random); 上述計算過程重復(fù)多次，直到生成全部的密碼參數(shù)。其中，expansion_label值在客戶端寫和服務(wù)器端寫中使用不同的值，seq_num則取決于握手協(xié)議中所選用的密鑰刷新頻率。 一個新的密鑰組的生成發(fā)生在序列號的間隔處，與密鑰刷新頻率一致。計算中使用的序列號是要求密鑰刷新的第一個號。 不同的擴展標志值用于客戶端寫密鑰和服務(wù)器端寫密鑰，所以，密鑰組生成“client expansion”作為擴展標志值，分割為以下各項： client_write_MAC_secret[SecurityParameters.hash_size] client_write?encryption_key[SecurityParameters.key_material] client_write?IV[SecurityParameters.IV_size] 密鑰組生成“server expansion”作為擴展標志值，分割為以下各項： server_write_MAC_secret[SecurityParameters.hash_size] server_write?encryption_key[SecurityParameters.key_material] server_write?IV[SecurityParameters.IV_size] 在WTLS協(xié)議中，許多連接狀態(tài)參數(shù)可以在安全連接期間被重新計算，這一特點被稱為密鑰刷新，它是為了減小新的密鑰過程而被執(zhí)行。在密鑰刷新中，MAC密文值、加密密鑰和IV矢量將根據(jù)序列號而變化。刷新頻率根據(jù)密鑰刷新參數(shù)。上述計算中所用的序列號參數(shù)是觸發(fā)密鑰刷新的記錄序號。如果序列號根本不用，則在所有的計算中序列號為0。 3.5????? HMAC和偽隨機函數(shù) WAP規(guī)范利用哈希函數(shù)（如MD5或SHA）保護數(shù)據(jù)的完整性。WTLS規(guī)范采用哈希函數(shù)H（SHA-1或MD-5）構(gòu)造MAC，其具體構(gòu)造可以表示如下： HMAC(K,data) = H(K XOR opad + H(K XOR ipad + data) 哈希函數(shù)以H表示，K是由上述密鑰組生成方法產(chǎn)生的MAC密鑰，opad和ipad是兩個固定字符串，它們?nèi)缦聵?gòu)造： ipad = the byte 0x36 repeated B times opad = the byte 0x5c repeated B times B=64表示數(shù)據(jù)分組的字節(jié)長度，L表示哈希輸出的字節(jié)長度（L=16 MD5,L=20 SHA-1）。密鑰K取決于B，使用密鑰長度超過B的應(yīng)用首先用H計算密鑰的哈希值，然后取L個字節(jié)作為HMAC的實際密鑰。在任何情況下，推薦給K的最小長度是L個字節(jié)（哈希輸出長度）。 哈希函數(shù)除了用于構(gòu)造HMAC外，還用來構(gòu)造偽隨機函數(shù)PRF。在TLS規(guī)范中PRF由兩個不同的哈希函數(shù)構(gòu)成，而WTLS為節(jié)省資源僅采用了一個哈希函數(shù)形成PRF。 首先我們定義一個數(shù)據(jù)擴展函數(shù)P_hash(secret,data),它可以利用HMAC通過多次迭代將密鑰和種子擴展為任意長度的輸出。 P_hash(secret,data) = HMAC_hash(secret,A(1) + seed) + HMAC_hash(secret,A(2) + seed) + HMAC_hash(secret,A(3) + seed) +?…… 其中，A(0)=seed,A(i)=HMAC_hash(secret,A(i-1))。這樣，偽隨機函數(shù)PRF可以構(gòu)造如下： PRF(secret,label,seed) = P_hash(secret,label + seed)。

????????上述所有公式中的“＋”都表示字符串的級連。?

?

轉(zhuǎn)自：http://blog.csdn.net/purpleforest/article/details/1353412

轉(zhuǎn)載于:https://www.cnblogs.com/viviancc/archive/2012/04/16/2451867.html

總結(jié)

以上是生活随笔為你收集整理的无线传输层安全协议WTLS安全机制详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。