專(zhuān)利名稱(chēng)：憑證的受保護(hù)動(dòng)態(tài)提供的制作方法
背景技術(shù)：
隨著無(wú)線(xiàn)電信的出現(xiàn)，對(duì)于建立安全性以向用戶(hù)提供保密性和保護(hù)網(wǎng)絡(luò)數(shù)據(jù)機(jī)密性的需求越來(lái)越大。當(dāng)兩個(gè)或更多個(gè)無(wú)線(xiàn)方(例如網(wǎng)絡(luò)服務(wù)器和移動(dòng)客戶(hù)端)希望建立一定級(jí)別的安全性時(shí)，它們通常將彼此“認(rèn)證”，即向彼此證明它們確實(shí)是它們所宣稱(chēng)的那樣。身份證明通常是通過(guò)某種形式的“憑證(credential)”實(shí)現(xiàn)的。這些憑證在工業(yè)中可被用于實(shí)現(xiàn)不同目標(biāo)。例如，“用戶(hù)ID和密碼”充當(dāng)用于向計(jì)算機(jī)證明用戶(hù)有效并因而有權(quán)進(jìn)入系統(tǒng)的憑證。類(lèi)似地，在網(wǎng)絡(luò)中，“用戶(hù)ID和密碼”被用于證明客戶(hù)端的真實(shí)性以準(zhǔn)許訪(fǎng)問(wèn)網(wǎng)絡(luò)。并且，憑證通常被用于通過(guò)以下兩類(lèi)密碼規(guī)則之一來(lái)實(shí)現(xiàn)認(rèn)證“對(duì)稱(chēng)密碼術(shù)”或“不對(duì)稱(chēng)密碼術(shù)”。
對(duì)稱(chēng)密碼術(shù)是基于“預(yù)共享私密(secret)”的，其中兩方通過(guò)某種外部裝置獲得私密；就是說(shuō)，它們可能依賴(lài)于中心源分發(fā)“預(yù)共享私密”，或者其中一方可能在使用私密前公開(kāi)(通過(guò)某個(gè)其他的受保護(hù)裝置)“預(yù)共享私密”。例如，預(yù)共享私密可能是網(wǎng)絡(luò)管理員分配給用戶(hù)的典型“用戶(hù)ID/密碼”。這種對(duì)稱(chēng)密碼術(shù)技術(shù)的安全性強(qiáng)度取決于“預(yù)共享私密”的強(qiáng)度，因此，典型“用戶(hù)ID和密碼”技術(shù)的使用由于密碼的固有安全性弱點(diǎn)而經(jīng)常受到字典攻擊的影響。
不對(duì)稱(chēng)密碼術(shù)基于諸如“公共密鑰基礎(chǔ)設(shè)施(PKI)”之類(lèi)的新技術(shù)，PKI可以用“零知識(shí)”方法來(lái)檢驗(yàn)標(biāo)識(shí)，但以更高計(jì)算負(fù)擔(dān)為代價(jià)。此外，雖然公共密鑰方法提供了比對(duì)稱(chēng)方法更高級(jí)別的安全性，但是公共密鑰方法在其無(wú)法獲得兩方之間的共享私密的情況下必須依賴(lài)于第三方(被稱(chēng)為“憑證權(quán)威機(jī)構(gòu)”)或者還必須依賴(lài)于某種先驗(yàn)知識(shí)來(lái)核實(shí)公共密鑰的真實(shí)性。因此，PKI技術(shù)的成本要高得多，并且可能高到無(wú)法在某些無(wú)線(xiàn)網(wǎng)絡(luò)上實(shí)現(xiàn)。另外，公共密鑰方法通常要求第三方來(lái)認(rèn)證PKI憑證。
總之，無(wú)論是使用對(duì)稱(chēng)密碼術(shù)技術(shù)還是不對(duì)稱(chēng)密碼術(shù)技術(shù)來(lái)認(rèn)證兩方，在這兩方之間都必須具有某種公共的已建立的數(shù)據(jù)或指紋。在對(duì)稱(chēng)密碼術(shù)方案的情況下，預(yù)共享私密必須是相互共享的；而在不對(duì)稱(chēng)密碼術(shù)中，在可以發(fā)起認(rèn)證之前，或者需要第三方進(jìn)行憑證核實(shí)，或者需要向每一方提供指紋。當(dāng)今的解決方案，無(wú)論是在無(wú)線(xiàn)還是有線(xiàn)通信中，這兩種方案都依賴(lài)于這些信息的手工配置或安裝。當(dāng)使用對(duì)稱(chēng)密碼術(shù)技術(shù)時(shí)，通過(guò)外部工具來(lái)提供預(yù)共享私密，這通常很麻煩。不對(duì)稱(chēng)密碼術(shù)技術(shù)通常依賴(lài)于憑證(例如ANSI X.509憑證)和PKI的使用，PKI或者必須被可信的第三方核實(shí)，或者必須依賴(lài)于用于核實(shí)憑證的指紋的手工配置。因此，當(dāng)前沒(méi)有可用的現(xiàn)有解決方案可實(shí)現(xiàn)這些信息(預(yù)共享私密或憑證或指紋)以受保護(hù)和動(dòng)態(tài)的方式分發(fā)。當(dāng)今市面上的工具通常需要對(duì)這些信息進(jìn)行帶外或手工配置。

發(fā)明內(nèi)容
本方法和實(shí)現(xiàn)方式克服了在先類(lèi)型方法遇到的困難和缺陷，本方法和實(shí)現(xiàn)方式用于分發(fā)或提供用于認(rèn)證兩方的信息。利用加密在各方之間建立安全隧道。然后在各方之間執(zhí)行憑證的提供?？梢酝ㄟ^(guò)安全隧道在各方之間執(zhí)行認(rèn)證過(guò)程，以確保在分發(fā)所述憑證前執(zhí)行正確的授權(quán)。
將意識(shí)到，本發(fā)明能夠具有其他和不同的實(shí)施例并且其若干細(xì)節(jié)可以在各個(gè)方面被修改，所有這些都不脫離本發(fā)明。因此，附圖和說(shuō)明書(shū)被看作示例性的，而非限制性的。


圖1一般地示出本發(fā)明公開(kāi)的方法和實(shí)現(xiàn)方式的操作步驟。
具體實(shí)施例方式
如這里所公開(kāi)的，本發(fā)明公開(kāi)了一種提供方法，該方法涉及用于保護(hù)通信的加密技術(shù)的使用，所述通信是服務(wù)器向客戶(hù)端分發(fā)一組憑證來(lái)獲得授權(quán)所需要的。雖然本發(fā)明可特別應(yīng)用于無(wú)線(xiàn)方法，但是在不脫離本發(fā)明的情況下，它也可用在有線(xiàn)網(wǎng)絡(luò)應(yīng)用中。在本發(fā)明的一個(gè)實(shí)施例中，通過(guò)在第一和第二方12、14之間采用Diffie-Hellman密鑰交換以相互導(dǎo)出共享私密來(lái)實(shí)現(xiàn)受保護(hù)的通信。當(dāng)然，應(yīng)該意識(shí)到，在不脫離本發(fā)明的情況下，可以使用除Diffie-Hellman方法之外的任意方案。共享私密建立受共享私密保護(hù)的安全信道。然后，兩方12、14進(jìn)行到彼此認(rèn)證憑證，以確保它們都沒(méi)有真正地與主動(dòng)的第三方攻擊者M(jìn)通話(huà)以及它們是預(yù)期的客戶(hù)端和服務(wù)器。此外，通過(guò)在受共享私密保護(hù)的安全信道上執(zhí)行認(rèn)證序列，它們都不會(huì)有遇到攻擊認(rèn)證交換的被動(dòng)第三方攻擊者E的危險(xiǎn)。一旦認(rèn)證成功，服務(wù)器就可以向客戶(hù)端提供另一組憑證。
如果Diffie-Hellman密鑰交換未被認(rèn)證，并且在出于某種原因受保護(hù)通信內(nèi)的認(rèn)證序列失敗的情況下，兩方12、14可獲得折衷的解決方案?？色@得多種折衷的實(shí)現(xiàn)方式，這些實(shí)現(xiàn)方式將依賴(lài)于由特定網(wǎng)絡(luò)建立的策略。在一種情形中，兩方12、14可能假設(shè)用于認(rèn)證的共享私密已被折衷。在這種情況下，當(dāng)?shù)诙?4是移動(dòng)客戶(hù)端而第一方12是服務(wù)器時(shí)，服務(wù)器12可以使客戶(hù)端14的憑證無(wú)效，并要求客戶(hù)端14通過(guò)帶外信道重新建立憑證。
通過(guò)使客戶(hù)端14能夠認(rèn)證服務(wù)器12，可以獲得其他級(jí)別的安全性。這種益處可以通過(guò)從中心權(quán)威機(jī)構(gòu)提供憑證來(lái)獲得，例如通過(guò)使管理員在服務(wù)器上提供公共/私有密鑰對(duì)并將該公共密鑰提供到所有客戶(hù)端來(lái)獲得。這樣一來(lái)，DH密鑰協(xié)定可利用其公共密鑰來(lái)核實(shí)服務(wù)器的真實(shí)性，以在呈現(xiàn)DH參數(shù)時(shí)核實(shí)由服務(wù)器提供給客戶(hù)端的指紋或簽名。雖然實(shí)現(xiàn)這樣的公共/私有密鑰對(duì)需要額外的成本，但是這種解決方案將避免對(duì)完整的PKI首次展示(rollout)的需求，因此將不會(huì)使最終用戶(hù)承擔(dān)這種解決方案的全部花費(fèi)。應(yīng)該注意，本方法還能夠使用完整服務(wù)器憑證并且其部署需要使用PKI。此外，應(yīng)該注意，本方法可能允許采用任何方法的任何密鑰交換機(jī)制，這任何一種方法都提供了共享私密的相互導(dǎo)出，但是必須防范MitM攻擊。Diffie-Hellman密鑰協(xié)定被選為實(shí)施例是因?yàn)樗鼘?shí)現(xiàn)了安全密鑰協(xié)定機(jī)制；為了減輕對(duì)Diffie-Hellman的可能MitM攻擊，該實(shí)施例還實(shí)現(xiàn)了將被用于標(biāo)記DH參數(shù)的服務(wù)器側(cè)公共/私有密鑰對(duì)的使用，以作為用于認(rèn)證服務(wù)器的裝置。此外，輔助認(rèn)證機(jī)制被用于使客戶(hù)端能夠利用較弱的認(rèn)證機(jī)制來(lái)證明真實(shí)性。認(rèn)證可以是任何類(lèi)型的認(rèn)證機(jī)制，但在優(yōu)選實(shí)施例中，將使用微軟MS-CHAPv2。當(dāng)前，認(rèn)證階段被用于抵御MitM攻擊，并且將提供用于訪(fǎng)問(wèn)控制的任意指示。對(duì)于MitM攻擊的最后防御措施是將散列值包括進(jìn)來(lái)，散列值將來(lái)自Diffie-Hellman密鑰協(xié)定和MS-CHAPv2的密碼結(jié)果綁定在一起，以確保兩方12、14在所有消息交換中都成功(例如M沒(méi)有出現(xiàn))。
優(yōu)選實(shí)施例的細(xì)節(jié)現(xiàn)在將根據(jù)優(yōu)選實(shí)施例描述本發(fā)明，在優(yōu)選實(shí)施例中，經(jīng)認(rèn)證的Diffie-Hellman協(xié)議(ADHP)被用于在無(wú)線(xiàn)應(yīng)用中建立安全隧道，將意識(shí)到，安全隧道并不局限于Diffie-Hellman方法。當(dāng)前公開(kāi)的ADHP優(yōu)選地是預(yù)期將替代當(dāng)前根據(jù)IEEE 802.11標(biāo)準(zhǔn)在無(wú)線(xiàn)傳輸中使用的協(xié)議的協(xié)議的一部分。ADHP提供了一種帶內(nèi)機(jī)制，利用該帶內(nèi)機(jī)制，可在除了用戶(hù)名和密碼之外再無(wú)需任何輸入的情況下向最終用戶(hù)提供憑證。
ADHP優(yōu)選地使用EAP-TLS協(xié)議來(lái)利用Diffie-Hellman(DH)密鑰協(xié)定交換建立安全隧道。一旦在兩方之間建立了安全隧道，客戶(hù)端和服務(wù)器就可以執(zhí)行認(rèn)證方法，利用該認(rèn)證方法，兩方可以實(shí)現(xiàn)相互認(rèn)證。Diffie-Hellman密鑰協(xié)定可以通過(guò)以下述兩種DH TLS協(xié)商之一協(xié)商隧道建立來(lái)實(shí)現(xiàn)TLS_DH_anon_WITH_AES_128_CBC_SHA，其中對(duì)等體和認(rèn)證服務(wù)器建立隧道，而無(wú)需驗(yàn)證任意一方的真實(shí)性；以及TLS_DHE_RSA_WITH_AES_128_CBC_SHA，其中服務(wù)器在提供DH參數(shù)時(shí)有機(jī)會(huì)提供簽名。當(dāng)使用利用簽名標(biāo)記了的臨時(shí)DH時(shí)，應(yīng)該理解，該簽名正在使用RSA指定的算法，并且在客戶(hù)端利用已標(biāo)記的臨時(shí)DH協(xié)商ADHP之前，RSA公共密鑰已通過(guò)某種其他的獨(dú)立安全機(jī)制被正確地提供給客戶(hù)端。還應(yīng)該理解，服務(wù)器可以通過(guò)使用憑證來(lái)提供其身份的完全公開(kāi)。由于隧道建立步驟無(wú)法實(shí)現(xiàn)相互認(rèn)證，因此ADHP也在可以提供憑證之前，采用MSCHAPv2交換來(lái)實(shí)現(xiàn)相互認(rèn)證。
優(yōu)選地，當(dāng)從服務(wù)器請(qǐng)求安全信道時(shí)，由客戶(hù)端單獨(dú)協(xié)商ADHP，作為第一通信交換。如果客戶(hù)端不具有所需憑證，那么它可以請(qǐng)求發(fā)起ADHP交換以從服務(wù)器動(dòng)態(tài)地獲得一個(gè)(憑證)。成功的ADHP交換的示例如下所示

由于最終目標(biāo)是實(shí)現(xiàn)對(duì)對(duì)等體的網(wǎng)絡(luò)訪(fǎng)問(wèn)，因此會(huì)話(huà)開(kāi)始于協(xié)商EAP的對(duì)等體和認(rèn)證者。認(rèn)證者通常將EAP請(qǐng)求/身份分組發(fā)送到對(duì)等體，而對(duì)等體將以EAP響應(yīng)/身份分組來(lái)響應(yīng)認(rèn)證者，該EAP響應(yīng)/身份分組包含EAP身份。利用ADHP，EAP身份可以是匿名的，以進(jìn)一步保護(hù)客戶(hù)端的身份。對(duì)于A(yíng)DHP，會(huì)話(huà)將通常發(fā)生在對(duì)等體和認(rèn)證服務(wù)器之間，該認(rèn)證服務(wù)器優(yōu)選地是可以向?qū)Φ润w提供唯一憑證的服務(wù)器。
對(duì)等體和認(rèn)證服務(wù)器之間的會(huì)話(huà)在正常的TEAP交換時(shí)開(kāi)始在用于無(wú)線(xiàn)對(duì)等體和服務(wù)器的匿名身份確定將發(fā)生TEAP認(rèn)證的情況下，EAP服務(wù)器必須以TEAP/Start分組作出響應(yīng)。假設(shè)對(duì)等體支持ADHP并且對(duì)等體不具有在其設(shè)備上提供的憑證，則對(duì)等體將發(fā)送EAP-Type＝ADHP的EAP響應(yīng)分組。此外，對(duì)等體將通過(guò)在其TLS ClientHello中協(xié)商基于Diffie-Hellman的密碼套件來(lái)發(fā)起ADHP的動(dòng)態(tài)提供階段，在該ADHP的特定版本中，優(yōu)選地使用在RFC3268中定義的TLS_DH_anon_WITH_AES_128_CBC_SHA的TLS密碼套件。因此，對(duì)等體的響應(yīng)將包括128位的客戶(hù)端隨機(jī)值、CSTA和TLS_DH_anon_WITH_AES_128_CBC_SHA，以表示匿名的DH密鑰協(xié)定交換將繼而建立受保護(hù)的隧道。受保護(hù)的隧道將128位的AES-CBC用于機(jī)密性并將HMAC-SHA1用于消息真實(shí)性。
在接收到ClientHello消息時(shí)，服務(wù)器將通過(guò)提供以下各項(xiàng)進(jìn)行響應(yīng)在ServerHello記錄中CipherSuite＝TLS_DH_anon_WITH_AES_128_CBC_SHA(遵從RFC3268)Random＝16字節(jié)的由服務(wù)器生成的隨機(jī)值在ServerKeyExchange記錄中KeyExchangeAlgorithm＝diffie_hellmanServerDHParams＝{dh_p，dh_g，dh_Ys}ServerHelloDone記錄被用于以信號(hào)通知ServerHello序列的結(jié)尾將結(jié)束。
當(dāng)協(xié)商匿名密鑰交換時(shí)，記錄的sha_hash將被用作其簽名。如果協(xié)商經(jīng)標(biāo)記的密鑰交換，則使用服務(wù)器的私有密鑰來(lái)標(biāo)記DH參數(shù)并由服務(wù)器在簽名中提供DH參數(shù)。實(shí)施例還設(shè)想，如果客戶(hù)端能夠驗(yàn)證憑證，則ADHP可被增強(qiáng)以進(jìn)一步支持密碼套件TLS_DHE_RSA_WITH_AES_128_CBC_SHA或TLS_DH_RSA_WITH_128_CBC_SHA并且允許服務(wù)器在其ServerHello中提供有效的x.509憑證，該x.509憑證包括對(duì)等體的憑證(基于RSA的)簽名以及DH參數(shù)以核實(shí)服務(wù)器的真實(shí)性。為了提供最好的安全性實(shí)踐，高度推薦服務(wù)器在參數(shù)簽名或單獨(dú)的服務(wù)器的憑證中提供RSA簽名以實(shí)現(xiàn)服務(wù)器側(cè)的認(rèn)證。另外，服務(wù)器可以通過(guò)傳輸其憑證來(lái)提供其完整的身份。但是，因?yàn)椴皇撬性O(shè)備都支持應(yīng)對(duì)憑證及其核實(shí)所需的基礎(chǔ)設(shè)施，因此憑證或服務(wù)器的公共密鑰被提供，作為安全性與性能之間的折衷。
一旦對(duì)等體已經(jīng)從ServerHello消息接收到ServerDHParams，對(duì)等體就保存生成主私密(master-secret)和隧道密鑰所需的所有信息。對(duì)等體必須基于挑戰(zhàn)CSTA和CAS以及服務(wù)器和對(duì)等體的公共DH密鑰兩者而根據(jù)RFC2246來(lái)生成主私密。對(duì)等體還必須以ClientKeyExchange作出響應(yīng)，以向服務(wù)器提供對(duì)等體的公共DH密鑰和“完成”，以證明其已經(jīng)生成正確的主私密。
在接收到來(lái)自對(duì)等體的ClientKeyExchange之后，服務(wù)器必須從給定的CSTA和CAS以及服務(wù)器和對(duì)等體的公共DH密鑰中生成主私密。它必須驗(yàn)證對(duì)等體的完成摘要并生成其自己的完成摘要。服務(wù)器必須以ChangeCipherSpec和“完成”進(jìn)行響應(yīng)，以確認(rèn)隧道建立的成功和主私密的活躍性。
一旦該交換成功完成，就使用由RFC2246和RFC3268定義的CBC模式中的128位的AES和HMAC-SHA1來(lái)保護(hù)在對(duì)等體和認(rèn)證服務(wù)器之間交換的后續(xù)消息。
利用受保護(hù)的隧道，對(duì)等體必須在服務(wù)器可以向其提供網(wǎng)絡(luò)訪(fǎng)問(wèn)憑證之前向服務(wù)器認(rèn)證其自身。為了輔助對(duì)等體認(rèn)證，使用<用戶(hù)名，密碼>憑證。為了使客戶(hù)端能夠在DH密鑰協(xié)定中不存在認(rèn)證時(shí)檢測(cè)可能的中間人(man-in-the-middle)攻擊，優(yōu)選地使用MSCHAPv2。
客戶(hù)端認(rèn)證繼續(xù)進(jìn)行，對(duì)等體和認(rèn)證服務(wù)器參與MSCHAPv2會(huì)話(huà)，從而調(diào)用MSCHAPv2會(huì)話(huà)。為了進(jìn)一步緩解“中間人”攻擊，由對(duì)等體和認(rèn)證服務(wù)器提供的挑戰(zhàn)被生成作為ADHP中的TLS建立的一部分，并作為MSCHAPv2請(qǐng)求的服務(wù)器和客戶(hù)端挑戰(zhàn)被傳遞。但是，注意，雖然使用了隨機(jī)挑戰(zhàn)，但是它們不是在MSCHAPv2消息的實(shí)際ADHP通信中被傳送的(這些值可以被客戶(hù)端和服務(wù)器清零和忽略)。
在成功的MSCHAPv2認(rèn)證交換之后，服務(wù)器和客戶(hù)端必須證明它們通過(guò)散列化隧道建立和MSCHAPv2會(huì)話(huà)這兩個(gè)會(huì)話(huà)所產(chǎn)生的密鑰，繼而進(jìn)入這兩個(gè)會(huì)話(huà)。如果兩方都證明它們已經(jīng)計(jì)算出相同的散列結(jié)果，則服務(wù)器可以向?qū)Φ润w提供唯一的憑證。注意，在該步驟可以提供任意類(lèi)型的憑證或憑證組。在完成憑證或憑證組的分發(fā)時(shí)，ADHP推斷出授權(quán)失敗，從而以信號(hào)指示雖然已經(jīng)提供了憑證，但是網(wǎng)絡(luò)訪(fǎng)問(wèn)被拒絕，直到各方相繼完成實(shí)際的認(rèn)證提供協(xié)議為止。
當(dāng)生成密鑰時(shí)，DH計(jì)算被用作預(yù)主私密(pre_master_secret)，并根據(jù)RFC2246指定的以下方式被轉(zhuǎn)換成主私密對(duì)于客戶(hù)端，預(yù)主私密＝(DH_Ys)peer-private-DH-keymod DH_p對(duì)于服務(wù)器，預(yù)主私密＝(DH_Yc)peer-private-DH-keymod DH_p主私密＝PRF(預(yù)主私密，“主私密”，ClientHello.random+ServerHello.random)TLS隧道密鑰以類(lèi)似于TLS密鑰計(jì)算的方式被計(jì)算，但還生成將被用于MSCHAPv2交換的額外的32。為了生成密鑰材料，以下各項(xiàng)將被計(jì)算，直到生成足夠的輸出Key_block＝PRF(SecurityParameters.master_secret，“key expansion”，SecurityParameters.server_random+SecurityParameters.client_random)；然后，key_block按如下方式被劃分client_write_MAC_secret[hash_size]server_write_MAC_secret[hash_size]client_write_key[Key_material_length]
server write_key[Key_material_length]client_write_IV[IV_size]server_write_IV[IV_size]MSCHAPv2S erverChallengeMSCHAPv2 ClientChallenge額外的密鑰材料，即ServerChallenge和ClientChallenge分別對(duì)應(yīng)于認(rèn)證服務(wù)器的MSCHAPv2挑戰(zhàn)和對(duì)等體的MSCHAPv2挑戰(zhàn)。
對(duì)于使用對(duì)等體的<用戶(hù)名，密碼>進(jìn)行的認(rèn)證，雖然存在其他實(shí)現(xiàn)相互認(rèn)證的認(rèn)證方法，但是選擇了MSCHAPv2來(lái)防止中間人(MITM)獲得客戶(hù)端的初始響應(yīng)上的明文密碼和身份。MSCHAPv2強(qiáng)迫MITM主動(dòng)發(fā)動(dòng)字典攻擊以成功地響應(yīng)于客戶(hù)端的挑戰(zhàn)響應(yīng)。
MSCHAPv2交換強(qiáng)迫服務(wù)器提供有效的ServerChallengeResponse，該ServerChallengeResponse必須是作為其響應(yīng)一部分的服務(wù)器挑戰(zhàn)、客戶(hù)端挑戰(zhàn)和密碼的函數(shù)。這減小了ADHP協(xié)議中用于強(qiáng)迫充當(dāng)服務(wù)器的中間人在客戶(hù)端的挑戰(zhàn)響應(yīng)時(shí)限內(nèi)成功地破解密碼的弱點(diǎn)窗口。此外，由客戶(hù)端和服務(wù)器兩者用于計(jì)算它們各自的挑戰(zhàn)響應(yīng)的隨機(jī)值被進(jìn)一步保護(hù)以免受MITM攻擊，這是因?yàn)樗鼈兪菑某晒Φ腄H密鑰協(xié)定中得到的值。
本發(fā)明解決了無(wú)線(xiàn)介質(zhì)中的安全性問(wèn)題，在無(wú)線(xiàn)介質(zhì)中，介質(zhì)本身固有地易被竊聽(tīng)。與有線(xiàn)介質(zhì)中攻擊者必須獲得對(duì)有線(xiàn)介質(zhì)的物理訪(fǎng)問(wèn)權(quán)限的情況相反，無(wú)線(xiàn)介質(zhì)允許任何人捕獲被無(wú)線(xiàn)傳輸?shù)男畔?，從而使得被?dòng)攻擊能夠?qū)崿F(xiàn)。因此，無(wú)法假設(shè)物理安全性，并且安全性弱點(diǎn)要大得多。
MitM攻擊也是通過(guò)生成作為DH密鑰協(xié)定的函數(shù)的MSCHAPv2服務(wù)器和客戶(hù)端挑戰(zhàn)來(lái)解決的。在強(qiáng)迫MSCHAPv2挑戰(zhàn)依賴(lài)于DH交換時(shí)，防止MitM與對(duì)等體和合法服務(wù)器兩者之間成功地建立安全隧道，并且成功地獲得憑證。通過(guò)以密碼術(shù)方式綁定以所有方法生成的密鑰材料，來(lái)確保對(duì)等體和AS是所有已有方法的唯一參與者。
由于對(duì)等體指定了用于保護(hù)用于提供的通信的手段，因此，它可以以下兩種方式之一來(lái)調(diào)用DH密鑰協(xié)定匿名地或經(jīng)服務(wù)器認(rèn)證的。利用經(jīng)服務(wù)器認(rèn)證的DH密鑰協(xié)定，服務(wù)器必須向RSA簽名提供臨時(shí)DH參數(shù)，而對(duì)于匿名的DH密鑰協(xié)定，不需要提供簽名。
在經(jīng)服務(wù)器認(rèn)證的DH密鑰協(xié)定中，受保護(hù)的通信可確保AS是真實(shí)的，因?yàn)閷?duì)等體必須在協(xié)商之前已經(jīng)被預(yù)先提供以AS公共(RSA)密鑰。因?yàn)榭蛻?hù)端必須首先通過(guò)身份和(密碼)憑證提供身份證明，因此對(duì)手只能冒充AS來(lái)成功地發(fā)動(dòng)字典攻擊。為了遵循ADHP協(xié)議，實(shí)現(xiàn)方式必須確保能夠通過(guò)協(xié)議范圍外部的安全機(jī)制來(lái)實(shí)現(xiàn)AS公共密鑰(或根憑證)向?qū)Φ润w的提供。僅通過(guò)該機(jī)制，經(jīng)服務(wù)器認(rèn)證的DH密鑰協(xié)定就可以提供對(duì)字典攻擊的抵抗。在匿名DH密鑰協(xié)定中，對(duì)手可能?chē)L試偽裝成客戶(hù)端并實(shí)現(xiàn)用于提供的TEAP。但是，它必須在DH隧道內(nèi)成功認(rèn)證以從服務(wù)器成功獲得憑證。因此，通過(guò)在受保護(hù)的隧道內(nèi)實(shí)現(xiàn)對(duì)等體認(rèn)證來(lái)減輕對(duì)等體偽裝的可能。但是，對(duì)手可以偽裝并獲得對(duì)等體的身份和憑證。雖然對(duì)手必須成功地獲得與希望協(xié)商ADHP以用于提供的對(duì)等體之間的接觸，但這是可能發(fā)生的并使對(duì)手能夠發(fā)動(dòng)字典攻擊。因此，當(dāng)使用匿名的DH密鑰協(xié)定來(lái)建立隧道時(shí)，ADHP兼容的實(shí)現(xiàn)方式必須只能支持MSCHAPv2對(duì)等體認(rèn)證。
當(dāng)AS無(wú)法提供成功的MSCHAPv2服務(wù)器挑戰(zhàn)響應(yīng)時(shí)，對(duì)等體可以檢測(cè)出它正在遭受攻擊。被指定為順序的失敗嘗試的最大次數(shù)的可配置值應(yīng)該由對(duì)等體強(qiáng)制給出，以提供用于使字典攻擊弱點(diǎn)最小化的手段。如果在最大次數(shù)的嘗試都已失敗之后，則對(duì)等體必須改變它的MSCHAPv2憑證。對(duì)等體可以選擇使用更安全的帶外機(jī)制來(lái)用于NAC提供，這提供了比匿名的DH密鑰協(xié)定更好的安全性。類(lèi)似地，對(duì)等體可以找到用于安全地預(yù)先提供服務(wù)器的公共密鑰以調(diào)用經(jīng)服務(wù)器認(rèn)證的DH密鑰協(xié)定的手段。匿名DH密鑰協(xié)定呈現(xiàn)為一種可行選項(xiàng)，因?yàn)榭赡艽嬖谟懈嘞拗频牟渴?，并且該部署很可能接受主?dòng)字典攻擊的危險(xiǎn)。此外，它是唯一一種不需要帶外提供的選項(xiàng)。本方法還可以利用服務(wù)器側(cè)憑證形式的公共密鑰基礎(chǔ)設(shè)施(PKI)來(lái)增強(qiáng)，這將使本解決方案從反應(yīng)性抵抗改善為主動(dòng)性抵抗。
本系統(tǒng)提供了一種不易受基于被動(dòng)掃描的字典攻擊影響并且不需要PKI的提供協(xié)議。但是，同時(shí)，它可能只有在事實(shí)發(fā)生之后才能檢測(cè)到可能的MitM攻擊。這可以通過(guò)簡(jiǎn)單地使用消除該危險(xiǎn)的公共/私有密鑰來(lái)克服，這與完全可擴(kuò)展的PKI的成本相比，可能是更容易接受的一種折衷。類(lèi)似地，如果可以應(yīng)用最好的安全性實(shí)踐，則完整服務(wù)器憑證可被用于最好的服務(wù)器認(rèn)證。
由于這里公開(kāi)的方法采用未經(jīng)加密的交換的初始階段，因此可以識(shí)別攻擊者是否也在使用易受MitM攻擊影響的密鑰交換機(jī)制。然后，在認(rèn)證流通過(guò)經(jīng)加密的隧道時(shí)，對(duì)認(rèn)證服務(wù)器的訪(fǎng)問(wèn)可被監(jiān)控，這將能夠檢測(cè)到隧道化認(rèn)證階段的攻擊者。這樣一來(lái)，本系統(tǒng)的其他用途可被檢測(cè)。
如上所述，本發(fā)明解決了與先前類(lèi)型系統(tǒng)相關(guān)的很多問(wèn)題。但是，將意識(shí)到，本領(lǐng)域技術(shù)人員可以在所附權(quán)利要求表示的本發(fā)明的原理和范圍內(nèi)對(duì)這里為了說(shuō)明本發(fā)明的本質(zhì)而描述和示出的部件的細(xì)節(jié)、材料和布置執(zhí)行各種修改。
權(quán)利要求
1.一種安全通信的方法，包括在至少第一方和第二方之間提供通信實(shí)現(xiàn)方式；利用加密算法在所述至少第一方和第二方之間建立安全隧道；通過(guò)所述安全隧道在所述至少第一方和第二方之間進(jìn)行認(rèn)證；以及利用所述安全隧道在所述至少第一方和第二方之間提供安全憑證。
2.如權(quán)利要求1所述的方法，其中在所述至少第一方和第二方之間的所述通信實(shí)現(xiàn)方式是有線(xiàn)實(shí)現(xiàn)方式和無(wú)線(xiàn)實(shí)現(xiàn)方式中的至少一種。
3.如權(quán)利要求1所述的方法，其中所述加密算法是不對(duì)稱(chēng)加密算法。
4.如權(quán)利要求3所述的方法，其中所述不對(duì)稱(chēng)加密算法被用于導(dǎo)出共享私密，該共享私密隨后在所述建立安全隧道的步驟中被使用。
5.如權(quán)利要求3所述的方法，其中所述不對(duì)稱(chēng)加密算法是Diffie-Hellman密鑰交換。
6.如權(quán)利要求1所述的方法，其中所述認(rèn)證步驟是利用微軟MS-CHAPv2來(lái)執(zhí)行的。
7.如權(quán)利要求1所述的方法，還包括以下步驟在所述至少第一方和第二方中的一方上提供公共/私有密鑰對(duì)，然后將所述公共密鑰提供到所述至少第一方和第二方中的另一方。
8.如權(quán)利要求7所述的方法，其中所述提供公共/私有密鑰對(duì)的步驟包括根據(jù)公共密鑰基礎(chǔ)設(shè)施(PKI)來(lái)提供服務(wù)器側(cè)憑證。
9.一種用于實(shí)現(xiàn)安全通信的實(shí)現(xiàn)方式，包括用于在第一方和第二方之間實(shí)現(xiàn)通信的實(shí)現(xiàn)方式；用于利用加密算法在所述至少第一方和第二方之間建立安全隧道的實(shí)現(xiàn)方式；用于通過(guò)所述安全隧道在所述至少第一方和第二方之間提供安全憑證的實(shí)現(xiàn)方式；以及用于通過(guò)所述安全隧道在所述至少第一方和第二方之間進(jìn)行認(rèn)證的實(shí)現(xiàn)方式。
10.如權(quán)利要求9所述的實(shí)現(xiàn)方式，其中所述用于在第一方和第二方之間實(shí)現(xiàn)通信的實(shí)現(xiàn)方式是有線(xiàn)實(shí)現(xiàn)方式和無(wú)線(xiàn)實(shí)現(xiàn)方式中的至少一種。
11.如權(quán)利要求9所述的實(shí)現(xiàn)方式，其中所述加密算法是不對(duì)稱(chēng)加密算法。
12.如權(quán)利要求11所述的實(shí)現(xiàn)方式，其中所述不對(duì)稱(chēng)加密算法被用于于導(dǎo)出共享私密，該共享私密隨后在所述建立安全隧道的步驟中被使用。
13.如權(quán)利要求11所述的實(shí)現(xiàn)方式，其中所述不對(duì)稱(chēng)加密算法是Diffie-Hellman密鑰交換。
14.如權(quán)利要求9所述的實(shí)現(xiàn)方式，其中所述用于認(rèn)證的實(shí)現(xiàn)方式包括微軟MS-CHAPv2。
15.如權(quán)利要求9所述的實(shí)現(xiàn)方式，還包括以下實(shí)現(xiàn)方式該實(shí)現(xiàn)方式用于在所述至少第一方和第二方中的一方上提供公共/私有密鑰對(duì)，然后將所述公共密鑰提供到所述至少第一方和第二方中的另一方。
16.如權(quán)利要求15所述的實(shí)現(xiàn)方式，所述用于提供公共/私有密鑰對(duì)的實(shí)現(xiàn)方式包括用于根據(jù)公共密鑰基礎(chǔ)設(shè)施(PKI)來(lái)提供服務(wù)器側(cè)憑證的實(shí)現(xiàn)方式。
17.一種包含有用于實(shí)現(xiàn)安全通信的計(jì)算機(jī)可讀程序代碼的計(jì)算機(jī)可用介質(zhì)，在計(jì)算機(jī)程序產(chǎn)品中的所述計(jì)算機(jī)可讀程序代碼包括用于在至少第一方和第二方之間的通信的指令；用于利用加密算法在所述至少第一方和第二方之間建立安全隧道的指令；用于通過(guò)所述安全隧道在所述至少第一方和第二方之間進(jìn)行認(rèn)證的指令；以及用于在所述至少第一方和第二方之間提供安全憑證的指令。
18.如權(quán)利要求17所述的計(jì)算機(jī)程序產(chǎn)品，其中所述用于在所述至少第一方和第二方的通信的指令包括用于無(wú)線(xiàn)實(shí)現(xiàn)方式的指令。
19.如權(quán)利要求17所述的計(jì)算機(jī)程序產(chǎn)品，其中所述加密算法是不對(duì)稱(chēng)加密算法。
20.如權(quán)利要求19所述的計(jì)算機(jī)程序產(chǎn)品，其中所述不對(duì)稱(chēng)加密算法被用于導(dǎo)出共享私密，該共享私密隨后在所述建立安全隧道的步驟中被使用。
21.如權(quán)利要求19所述的計(jì)算機(jī)程序產(chǎn)品，其中所述不對(duì)稱(chēng)加密算法是Diffie-Hellman密鑰交換。
22.如權(quán)利要求17所述的計(jì)算機(jī)程序產(chǎn)品，其中所述用于認(rèn)證的指令包括微軟MS-CHAPv2。
23.如權(quán)利要求17所述的計(jì)算機(jī)程序產(chǎn)品，還包括以下指令該指令用于在所述至少第一方和第二方中的一方上提供公共/私有密鑰對(duì)，然后將所述公共密鑰提供到所述至少第一方和第二方中的另一方。
24.如權(quán)利要求17所述的計(jì)算機(jī)程序產(chǎn)品，其中所述用于提供公共/私有密鑰對(duì)的指令包括用于根據(jù)公共密鑰基礎(chǔ)設(shè)施(PKI)來(lái)提供服務(wù)器側(cè)憑證的指令。
全文摘要
本發(fā)明公開(kāi)了用于兩方或更多方之間的安全通信的方法和實(shí)現(xiàn)方式。利用加密算法在各方之間建立安全隧道。認(rèn)證過(guò)程是通過(guò)安全隧道在各方之間執(zhí)行的。隨后在各方之間執(zhí)行憑證的提供。
文檔編號(hào)H04L29/06GK1875567SQ200480032661
公開(kāi)日2006年12月6日 申請(qǐng)日期2004年10月12日 優(yōu)先權(quán)日2003年11月5日
發(fā)明者南希·卡姆溫恩特, 馬克·克里斯徹爾, 艾蘭·費(fèi)恩克爾, 周浩 申請(qǐng)人:思科技術(shù)公司