信息安全學(xué)第3章 密鑰分配與管理技術(shù)

海軍工程大學(xué)主要內(nèi)容3.1.1密鑰分配中心方式

密鑰分配中心方式是當(dāng)前的主流方式。每個(gè)節(jié)點(diǎn)或用戶只需保管與密鑰分配中心(KDC)之間使用的密鑰加密密鑰，而KDC為每個(gè)用戶保管一個(gè)不相同的密鑰加密密鑰。當(dāng)兩個(gè)用戶需要通信時(shí)，需向KDC申請。KDC將工作密鑰(或稱會(huì)話密鑰)用這兩個(gè)用戶的密鑰加密密鑰分別加密后送給這兩個(gè)用戶(通常是通過其中一個(gè)轉(zhuǎn)送)。這種方式的特點(diǎn)是，用戶不必保存大量的工作密鑰，可實(shí)現(xiàn)一報(bào)一密；缺點(diǎn)是通信量大，而且需要有較好的鑒別功能，以識(shí)別KDC和用戶。KDC可變形成為號(hào)碼本方式，適用于非對稱密碼體制。通過建立用戶的公開密鑰表，在密鑰的連通范圍內(nèi)散發(fā)，也可采用目錄方式動(dòng)態(tài)去查詢，后面介紹的公開密鑰管理體制采用的就是這種思想。3.1.2離散對數(shù)方法設(shè)P是一個(gè)質(zhì)數(shù)，a是P的一個(gè)本原元，要求a和P是公開的，網(wǎng)絡(luò)中的每個(gè)用戶I選一個(gè)小于p的整數(shù)作為秘密密鑰。設(shè)甲和乙是兩個(gè)用戶，各自的密鑰分別是和，那么他們可基于離散對數(shù)方法用如下過程建立彼此間的會(huì)話密鑰。雙方各自計(jì)算(2)交換和；(3)求出會(huì)話密鑰為這種方法不能防止從信道進(jìn)行竊聽，因此還需要某種加密機(jī)制的保護(hù)，并且同時(shí)需要使用密鑰協(xié)商機(jī)制來防止橋接攻擊。針對這些問題，Hughes提出了一種改進(jìn)方式，使得雙方密鑰的生成呈異步形式。要做到這一點(diǎn)，必須：(1)甲事先計(jì)算密鑰；(2)乙在需要與甲通信時(shí)計(jì)算并送給甲；(3)甲計(jì)算并送給乙；(4)乙計(jì)算而，從而表現(xiàn)甲和乙使用的密鑰相同。3.1.3智能卡方法智能卡方法的根本思想是將RSA與Diffie-Hellman協(xié)議相結(jié)合，通過KDC分配可進(jìn)行密鑰管理的智能卡，而平時(shí)使用密鑰時(shí)不需要KDC。整個(gè)系統(tǒng)有一個(gè)通信各方均使用的公開密鑰，而對應(yīng)的秘密密鑰保存在發(fā)卡方，用戶持有的是該秘密密鑰的一個(gè)變形。需要通信時(shí)，使用智能卡產(chǎn)生一個(gè)工作密鑰。具體做法如下：

(1)磁卡分發(fā)時(shí)：在對應(yīng)的RSA體制下，找一個(gè)為p或q的本原元的整數(shù)g。對于用戶I，設(shè)定他的身份標(biāo)志為整數(shù)，計(jì)算。將整數(shù)組(r，g，，)存儲(chǔ)在磁卡中發(fā)給用戶，其中需要保密(因?yàn)樗l(fā)卡中心的秘密密鑰的信息)，而其他數(shù)據(jù)是可公開的。

(2)需要通信時(shí)：基于Diffie-Hellman協(xié)議。用戶I和用戶J要建立一共同的工作密鑰時(shí)，用戶I產(chǎn)生一個(gè)隨機(jī)數(shù)并計(jì)算并連同自己的發(fā)給用戶J。J也產(chǎn)生一個(gè)隨機(jī)數(shù)并計(jì)算，并連同自己的發(fā)給用戶I。然后雙方分別計(jì)算出共享的工作密鑰：因?yàn)樗?/p>

(3)需要驗(yàn)證身份時(shí)：利用RSA體制確認(rèn)通信的對方擁有正確的。用戶I產(chǎn)生一個(gè)隨機(jī)數(shù)，并計(jì)算將和發(fā)給用戶J。

用戶J也類似地產(chǎn)生一個(gè)隨機(jī)數(shù)并計(jì)算

并將和發(fā)給用戶I。因?yàn)樵谀的情況下有所以用戶I和J均可用此方法驗(yàn)證對方的身份。注意：在智能卡方法中，RSA的秘密密鑰只在磁卡發(fā)行時(shí)使用，在磁卡使用過程中并不需要，因此智能卡系統(tǒng)在使用時(shí)不需要KDC。整個(gè)系統(tǒng)的平安性依賴于RSA的可靠性。3.1.4加密的密鑰交換EKE

加密的密鑰交換(EncryptedKeyExchange-EKE)方法由SteveBellovin和MichaelMerritt設(shè)計(jì)；用共享的對稱密鑰P(如口令)來保護(hù)隨機(jī)產(chǎn)生的公開密鑰K，進(jìn)而提高對會(huì)話密鑰的保護(hù)程度。具體的做法如下：(1)Ａ隨機(jī)產(chǎn)生一個(gè)公開／秘密密鑰對，使用對稱密鑰算法將公開密鑰加密，然后標(biāo)識(shí)符Ａ和送給Ｂ。(2)Ｂ收到后，再產(chǎn)生一個(gè)隨機(jī)的會(huì)話密鑰Ｋ，然后向Ａ發(fā)送。(3)Ａ收到后，解出Ｋ，然后產(chǎn)生一個(gè)隨機(jī)串，并向Ｂ發(fā)送。Ｂ收到后，產(chǎn)生一個(gè)，向Ａ發(fā)送。Ａ收到后，向Ｂ發(fā)送。(6)Ｂ收到后，假設(shè)確認(rèn)正確，那么雙方密鑰交換與鑒別成功。這是一個(gè)密鑰交換(前三步)加雙向身份認(rèn)證(后三步)的方法，這種方法的優(yōu)點(diǎn)是即使口令被攻擊者猜出，他只能獲得，而這個(gè)公開密鑰只能用于加密，不能用于解密，因此他仍然無法獲得實(shí)際使用的會(huì)話密鑰Ｋ的內(nèi)容。這種方法的缺點(diǎn)是交互次數(shù)較多，比較繁瑣。3.1.5Internet密鑰交換IKE

IKE(TheInternetKeyExchange)是IETF制定的Internet環(huán)境下的密鑰交換協(xié)議。IKE是由RFC2409文件描述的一種混合密鑰交換協(xié)議，IKE協(xié)商分兩個(gè)階段：階段一定義了主模式和野蠻模式，階段二定義了快速模式；另外還有兩個(gè)額外的交換，即信息交換和新組交換

IKE協(xié)議針對可能的攻擊設(shè)計(jì)了相應(yīng)的平安機(jī)制，并制定了五種交換模式，下面針對IKE協(xié)議的平安機(jī)制和交換模式，進(jìn)行分析。1.IKE的平安隱患(1)洪泛攻擊(FloodingAttack)FloodingAttack也叫DoS(DenialofService)攻擊，在Diffie-Hellman交換中，攻擊者可以制造大量的偽造IP的請求包，發(fā)給被攻擊者。每一個(gè)請求包讓被攻擊者響應(yīng)，考慮到這些包來自“不同的IP〞，響應(yīng)者對每一個(gè)包進(jìn)行計(jì)算開銷很大的冪運(yùn)算處理，一旦偽造包到達(dá)率到達(dá)一定程度，響應(yīng)者將無法響應(yīng)真正的合法用戶。針對“FloodingAttack〞IKE設(shè)計(jì)了“cookie〞交換，cookie生成方式為：聯(lián)系雙方的IP地址/端口/協(xié)議散列運(yùn)算的結(jié)果，或者是時(shí)間戳。這樣每個(gè)cookie可以和一個(gè)遠(yuǎn)程通信方對應(yīng)起來。一旦發(fā)起者和響應(yīng)者cookie交換完以后，余下的密鑰交換消息都必須包含cookie對，相應(yīng)的cookie與發(fā)起者和響應(yīng)者的IP地址聯(lián)系起來。

如果攻擊者與被攻擊者交換cookie后，攻擊者想發(fā)送多個(gè)不同的偽造IP地址和同一對cookie進(jìn)行Diffie-Hellman交換消息，被攻擊者會(huì)將這類信息輕易丟棄，因?yàn)閏ookie不與這些偽IP地址對應(yīng)。攻擊者必須為每一個(gè)偽IP進(jìn)行一次cookie交換，而且必須接收被攻擊者發(fā)出的響應(yīng)者cookie消息，由于IP地址是偽造的，這將是開銷很大的被動(dòng)竊聽。Cookie消息機(jī)制不能從根本上保證防御DoS攻擊，但它能讓攻擊者增大發(fā)起DoS的代價(jià)，是一種被動(dòng)防御方式。(2)中間人攻擊(ManInTheMiddleAttack)Diffie-Hellman交換最大的缺乏是它易遭受中間人攻擊。在這種攻擊中，攻擊者在發(fā)起者面前模仿響應(yīng)者，而在響應(yīng)者面前模仿發(fā)起者。那么攻擊者共享發(fā)起者和響應(yīng)者的秘密。

但在IKE提供對共享秘密的認(rèn)證后，便能有效的防范此類攻擊，攻擊者無法提供讓通信雙方認(rèn)可的認(rèn)證消息。IKE提供了三種認(rèn)證方式：預(yù)共享密鑰、數(shù)字簽名、公鑰加密

在預(yù)共享密鑰認(rèn)證中，通常通過發(fā)起者身份Idi和響應(yīng)者身份Idr來對應(yīng)共享密鑰表，但在IKE的主模式PSKEY只能通過發(fā)起者和響應(yīng)者的IP地址確定，所以主模式下的預(yù)共享密鑰認(rèn)證必須在發(fā)起者和響應(yīng)者的IP地址固定才能實(shí)施。但是在野蠻模式下，可以通過Idi和Idr來確定PSKEY。野蠻模式?jīng)]有提供身份保密。

簽名認(rèn)證是最具推廣性的認(rèn)證方式，但是如何對方的公鑰一直是個(gè)難題?；谧C書的數(shù)字簽名認(rèn)證，可以與PKI對應(yīng)起來，組建PKI的VPN，通過可信的第三方簽發(fā)的證書來獲取對方的公鑰。IKE將基于證書的數(shù)字簽名認(rèn)證作為可選項(xiàng)。數(shù)字簽名認(rèn)證提供了不可抵賴性，因?yàn)閿?shù)字簽名可以作為證實(shí)特定實(shí)體的證據(jù)，這也是其它兩種認(rèn)證方式不能提供的能力。公鑰加密認(rèn)證采用對方的公鑰對身份信息Idi/r和隨機(jī)數(shù)Ni/r進(jìn)行加密，因?yàn)镹i/r也為種子密鑰奉獻(xiàn)過力量，所以公鑰加密認(rèn)證比前兩種方式Ni/r均采用明文傳遞要平安。缺乏的是它需要代價(jià)高昂的兩次公共密鑰加密運(yùn)算。同時(shí)它有一局部容易抵賴的特性，也就是說每一方都可以否認(rèn)它曾是一次交換的參與者，因?yàn)殡p方完全可以重建雙方交換的信息。2.IKE協(xié)商模式的平安IKE的主模式的平安主要基于Diffie-Hellman交換的平安，增加了局部抗DoS攻擊能力和身份認(rèn)證能力。此外它還額外提供了身份保護(hù)——IDi/r都是加密后傳輸，和ISAKMP協(xié)商能力——保護(hù)套件經(jīng)過雙方協(xié)商。IKE的野蠻模式以降低平安強(qiáng)度的代價(jià)來提高IKE的協(xié)商速度。野蠻模式不提供身份保護(hù)，也沒有利用ISAKMP協(xié)商能力——保護(hù)套件由發(fā)起者直接確定。第二階段的快速模式，用第一階段生成的加密密鑰SKEYIDd衍生出用于IPSecSA的加密密鑰：NEWKEY=hashfunc(SKEYIDd，protocol|SPI|Ni|Nr)每個(gè)IPSecSA通過平安參數(shù)索引SPI和隨機(jī)數(shù)Ni、Nr使自己的密鑰獨(dú)一無二。但是所有的密鑰都與SKEYIDd有關(guān)聯(lián)，如果攻擊者能夠在第一階段判斷出SKEYIDd，那么由SKEYIDd衍生的密鑰將變的不再平安。IKE因此提供了PFS(PerfectForwardSecrecy)，完美向前保護(hù)的選項(xiàng)。就是再一次進(jìn)行Diffie-Hellman交換，生成新的共享秘密K。而新的IPSecSA加密密鑰將與新的共享秘密K有關(guān)：NEWKEY=hashfunc(SKEYIDd，K|protocol|SPI|Ni|Nr)IKE密鑰交換協(xié)議被認(rèn)為較難理解，它是IETF推崇的標(biāo)準(zhǔn)的密鑰交換協(xié)議。IKE的平安機(jī)制，主要依賴第一階段的認(rèn)證方式，而認(rèn)證方式中目前有兩個(gè)方向：平安DNS、IKE與PKI結(jié)合。平安DNS將加密系統(tǒng)運(yùn)用到DNS中，當(dāng)兩個(gè)通信系統(tǒng)在DNS中尋找域名時(shí)，就提供認(rèn)證信息，以便實(shí)現(xiàn)時(shí)機(jī)加密(OpportunitisticEncryption)。而IKE與PKI的結(jié)合是最具有伸縮性的平安系統(tǒng)，而且PKI的建設(shè)，已日益受到重視。3.2公鑰根底設(shè)施3.2公鑰根底設(shè)施3.2.1公鑰根底設(shè)施的根本組件為了確保信息的平安傳輸，一個(gè)有效的PKI系統(tǒng)必須是平安的和透明的，用戶在獲得加密和數(shù)字簽名效勞時(shí)，不需要詳細(xì)地了解PKI是怎樣管理證書和密鑰的。一個(gè)典型、完整、有效的PKI系統(tǒng)一般應(yīng)包含認(rèn)證機(jī)構(gòu)、注冊機(jī)構(gòu)﹑證書效勞器、證書庫、證書驗(yàn)證、密鑰備份恢復(fù)效勞器、時(shí)間效勞器、簽名效勞器等八個(gè)局部，下面分別介紹這幾局部功能。3.2公鑰根底設(shè)施1.認(rèn)證機(jī)構(gòu)在PKI中，認(rèn)證機(jī)構(gòu)CA是負(fù)責(zé)創(chuàng)立或者證明身份的可信賴的權(quán)威機(jī)構(gòu)。認(rèn)證機(jī)構(gòu)CA是可信的權(quán)威機(jī)構(gòu)，其權(quán)威性首先表達(dá)在它的所有用戶都知道其驗(yàn)證簽名公鑰及加密公鑰。因此，CA負(fù)責(zé)確認(rèn)身份和創(chuàng)立數(shù)字證書以建立一個(gè)身份和一對公/私鑰之間的聯(lián)系。3.2公鑰根底設(shè)施CA是PKI的核心局部，核心功能就是發(fā)放和管理數(shù)字證書。所以，CA的主要功能具體描述為：·接收驗(yàn)證最終用戶數(shù)字證書的申請?！ご_定是否接受最終用戶數(shù)字證書的申請――證書的審批。·向申請者頒發(fā)、拒絕頒發(fā)數(shù)字證書――證書的發(fā)放。

3.2公鑰根底設(shè)施·接收、處理最終用戶的數(shù)字證書更新請求――證書的更新。·接收最終用戶數(shù)字證書的查詢、撤銷?！ぎa(chǎn)生和發(fā)布證書撤消列表〔CertificateRevocationList,CRL〕?！?shù)字證書的歸檔?！っ荑€歸檔?！v史數(shù)據(jù)歸檔。3.2公鑰根底設(shè)施在信息網(wǎng)絡(luò)中，認(rèn)證中心認(rèn)證機(jī)構(gòu)CA為了實(shí)現(xiàn)其功能，主要由以下三局部組成：注冊效勞器：通過WebServer建立的站點(diǎn)，可為客戶提供每日24小時(shí)的效勞。證書申請受理和審核機(jī)構(gòu)：負(fù)責(zé)證書的申請和審核。它的主要功能是接受客戶證書申請并進(jìn)行審核。認(rèn)證中心認(rèn)證機(jī)構(gòu)效勞器：是數(shù)字證書生成、發(fā)放的運(yùn)行實(shí)體，同時(shí)提供發(fā)放證書的管理、證書撤消列表〔CRL〕的生成和處理等效勞。3.2公鑰根底設(shè)施2.注冊機(jī)構(gòu)

注冊機(jī)構(gòu)(RegistryAuthority，RA)作為CA和最終用戶之間的中間實(shí)體，負(fù)責(zé)控制注冊過程中、證書傳遞過程中及密鑰和證書生命周期過程中最終實(shí)體和PKI間的交換。3.2公鑰根底設(shè)施

其主要的功能有：主體注冊證書時(shí)個(gè)人身份認(rèn)證、確認(rèn)主體所提供的信息的有效性、根據(jù)被請求證書的屬性確定主體的權(quán)利、確認(rèn)主體確實(shí)擁有注冊證書的私鑰——這一般稱為擁有證據(jù)、在需要撤消證書時(shí)向CA報(bào)告密鑰泄露或終止事件、產(chǎn)生公/私鑰對、代表主體開始注冊過程、私鑰歸檔、開始密鑰恢復(fù)處理、包含私鑰的物理令牌的分發(fā)等。

3.2公鑰根底設(shè)施然而，任何情況下RA都不能代表CA發(fā)起關(guān)于主體的可信聲明，既不能代表CA驗(yàn)證主體的身份，也不能頒發(fā)證書或者頒發(fā)證書撤消狀態(tài)信息。3.2公鑰根底設(shè)施3.證書效勞器證書效勞器是負(fù)責(zé)根據(jù)注冊過程中提供的信息生成證書的機(jī)器或者效勞。3.2公鑰根底設(shè)施4.證書庫證書庫是CA或者RA代替CA發(fā)布證書的地方。它必須使用某種穩(wěn)定可靠的、規(guī)模可擴(kuò)充的在線資料庫系統(tǒng)，以便用戶能夠找到平安通信所需要的證書。證書庫的實(shí)現(xiàn)方式有很多種，包括X.500協(xié)議、輕量級(jí)目錄訪問協(xié)議(LDAP)、Web效勞器、ftp效勞器等，其中以LDAP最為常用。3.2公鑰根底設(shè)施5.證書驗(yàn)證證書用戶需要驗(yàn)證收到的證書。驗(yàn)證一個(gè)證書需要：·驗(yàn)證該證書的簽名者的簽名；·檢查證書的有效期，以確定該證書仍然有效；·檢查該證書的預(yù)期用途是否符合CA在該證書中指定的所有策略限制；·確認(rèn)該證書沒有被CA撤銷。3.2公鑰根底設(shè)施6.密鑰備份恢復(fù)效勞器密鑰備份恢復(fù)效勞器為CA提供了在創(chuàng)立私鑰時(shí)備份和在以后恢復(fù)私鑰的一種簡單方式。當(dāng)CA創(chuàng)立私鑰后，CA一方面通過RA將私鑰和證書分發(fā)給最終用戶，另一方面將私鑰傳送給密鑰備份恢復(fù)效勞器進(jìn)行備份。當(dāng)用戶私鑰喪失后，用戶通過RA向CA報(bào)告私鑰泄露終止事件，并要求恢復(fù)原私鑰以解密未讀信息。當(dāng)CA恢復(fù)出私鑰后，通過RA交給用戶。3.2公鑰根底設(shè)施7.時(shí)間效勞器時(shí)間效勞器是一個(gè)單調(diào)增加的精確的時(shí)間源，用來發(fā)布可驗(yàn)證的時(shí)間戳，并對時(shí)間戳簽名以便驗(yàn)證這個(gè)可信時(shí)間值的發(fā)布者。3.2公鑰根底設(shè)施8.簽名效勞器簽名效勞器是用來專門為用戶事務(wù)執(zhí)行集中的簽名和驗(yàn)證效勞。3.2公鑰根底設(shè)施3.2.2公鑰證書PKI根底設(shè)施通過證書來管理公鑰，通過第三方的可信任機(jī)構(gòu)――認(rèn)證機(jī)構(gòu)，把用戶的公鑰同用戶的其他標(biāo)識(shí)信息捆綁在一起，在Internet網(wǎng)上驗(yàn)證用戶的身份。因此，公鑰證書作為PKI的根底，是PKI的重要組成局部。3.2公鑰根底設(shè)施1.證書結(jié)構(gòu)目前國際上認(rèn)定的標(biāo)準(zhǔn)化的證書結(jié)構(gòu)形式主要為由國際電信聯(lián)盟ITU〔InternationalTelecommunicationUnion，前身即CCITT〕和國際標(biāo)準(zhǔn)化組織ISO共同推薦的一個(gè)標(biāo)準(zhǔn)的認(rèn)證框架，稱為ITU-TX.509或ISO9594-8。該國際標(biāo)準(zhǔn)定義了一種證書格式，稱為X.509公鑰證書。該標(biāo)準(zhǔn)先后推出了V1、V2和V3三個(gè)版本的證書格式。其中X.509V3的證書格式得到了廣泛的應(yīng)用。3.2公鑰根底設(shè)施目前，最常使用的是X.509v3版本的證書，其根本格式和內(nèi)容如下：·版本號(hào)：用于區(qū)分各連續(xù)版本的證書?！ぷC書序列號(hào)：與證書一一對應(yīng)的整數(shù)值，由證書頒發(fā)機(jī)構(gòu)產(chǎn)生。3.2公鑰根底設(shè)施·簽名算法標(biāo)識(shí)符：說明簽發(fā)證書所使用的算法以及相關(guān)參數(shù)。·頒發(fā)者名稱：用于標(biāo)識(shí)生成和簽發(fā)該證書的證書頒發(fā)機(jī)構(gòu)的名稱。·有效期：該項(xiàng)含有兩個(gè)日期/時(shí)間值：指定在某時(shí)間前無效和某時(shí)間后無效。3.2公鑰根底設(shè)施·主體名稱：持有該證書的最終實(shí)體?！ぶ黧w公鑰信息：包括主體的公鑰、算法標(biāo)識(shí)符以及算法所使用的任何相關(guān)參數(shù)?！ゎC發(fā)者唯一標(biāo)識(shí)符：該項(xiàng)是可選項(xiàng)，用于區(qū)分在不同時(shí)間內(nèi)不同的實(shí)體重用相同的頒發(fā)者名稱，使得證書頒發(fā)機(jī)構(gòu)的名字沒有二義性。3.2公鑰根底設(shè)施·主體唯一標(biāo)識(shí)符：該項(xiàng)是可選項(xiàng)，用于區(qū)分在不同時(shí)間內(nèi)不同的實(shí)體重用相同的證書擁有者名稱，使得證書擁有者的名字沒有二義性?！U(kuò)展項(xiàng)：一組擴(kuò)展字段。·簽名：用CA的私鑰對證書中其它所有字段的簽名。3.2公鑰根底設(shè)施2.證書生成與發(fā)放3.2公鑰根底設(shè)施同時(shí)，用戶也可通過RA向CA申請證書。RA只負(fù)責(zé)驗(yàn)證用戶提交的材料，然后把經(jīng)過驗(yàn)證的材料給CA，由證書效勞器生成證書。3.2公鑰根底設(shè)施對于生成的證書，既可以在線方式也可以離線方式返回給用戶。這取決于具體的用戶要求，證書平安等級(jí)，密鑰對生成方式等，PCA將對此做出明確規(guī)定。另外，所有CA生成的公鑰證書都必須在該CA所維護(hù)的目錄效勞器上公布，以供用戶查詢。3.2公鑰根底設(shè)施3.證書驗(yàn)證證書驗(yàn)證是決定證書自在某一時(shí)刻可以被有效使用以及確認(rèn)它能符合用戶意圖的過程。為到達(dá)這一目的，需要驗(yàn)證證書所涉及的多個(gè)方面:·證書必須包含一個(gè)有效數(shù)字簽名，以此確定證書內(nèi)容沒有被修改?！ゎC發(fā)者的公開密鑰必須可以用來驗(yàn)證證書上的數(shù)字簽名。3.2公鑰根底設(shè)施·證書起止日期必須在證書的有效日期內(nèi)?！ぷC書可以包含一些字段，它們可被標(biāo)記為關(guān)鍵的或者非關(guān)鍵的。如果證書是有效的，那么所有被標(biāo)記為關(guān)鍵的字段必須能夠被證書驗(yàn)證者的證書所理解。·證書只能用于最初創(chuàng)立它的目的。例如，被標(biāo)記為僅僅在簽名程序中使用的密鑰和證書不能被加密操作使用。·檢查指定使用條件并必須滿足其策略約束?！ぷ詈?，證書必須沒有被撤銷。3.2公鑰根底設(shè)施一般情況下，驗(yàn)證者取得被驗(yàn)證者的證書，使用CA的公鑰(假定此時(shí)CA公鑰的真實(shí)性和完整性已經(jīng)得到驗(yàn)證)對簽名字段的內(nèi)容SigCA(H(M))進(jìn)行加密運(yùn)算，得到H(M)，記為h1。然后對證書中除簽名字段以外的所有字段數(shù)據(jù)(記為M)，計(jì)算M的雜湊值H(M)，記為h2。比較h1和h2是否相等，如果相等，那么該證書得到驗(yàn)證。在PKI的一個(gè)體系結(jié)構(gòu)－－PKIX模型中，常常采用QCSP、SCVP、OCSP-X三種證書驗(yàn)證協(xié)議。3.2公鑰根底設(shè)施4.證書分發(fā)證書分發(fā)問題針對不同的平安效勞具有不同的解決方案。其具體實(shí)現(xiàn)方法主要為：3.2公鑰根底設(shè)施(1)在協(xié)議內(nèi)局部發(fā)證書證書可以作為實(shí)現(xiàn)一種密碼效勞所使用協(xié)議交換的一局部提供。3.2公鑰根底設(shè)施目前主要是下面兩種途徑：·電子郵件使用S/MIME協(xié)議實(shí)現(xiàn)電子郵件簽名時(shí)，與簽名者私鑰相應(yīng)的證書、公開密鑰和電子郵件消息一起發(fā)送。另外，在認(rèn)證路徑中證書的其余局部也可以被發(fā)送?！た蛻舳薙SL認(rèn)證瀏覽器或者其他客戶應(yīng)用在平安套接字層〔SecuritySocketLayer,SSL〕效勞器催促時(shí)通過協(xié)議發(fā)送客戶證書來進(jìn)行客戶端認(rèn)證。3.2公鑰根底設(shè)施(2)使用庫分發(fā)證書

對大容量證書集的訪問，如與一個(gè)用戶群通信或者由一個(gè)潛在的巨大用戶數(shù)據(jù)庫中認(rèn)證單個(gè)用戶時(shí)，需要一個(gè)比帶內(nèi)證書傳輸容量更大的解決的方案。3.2公鑰根底設(shè)施目前主要是下面兩種途徑：·電子郵件當(dāng)某些個(gè)體發(fā)送已簽名的電子郵件時(shí)，證書也作為數(shù)字簽名的處理的一局部進(jìn)行發(fā)送。另外的方法是證書分發(fā)在共享庫或者目錄庫中?！ば谄鞫薙SL認(rèn)證對個(gè)體用戶來說，當(dāng)在效勞器端SSL認(rèn)證期間驗(yàn)證一個(gè)Web效勞器提供的證書時(shí)，可以在一個(gè)證書庫中發(fā)現(xiàn)需要用來完成證書鏈驗(yàn)證的CA證書。3.2公鑰根底設(shè)施5.證書廢除(掛起)當(dāng)與證書相對應(yīng)的數(shù)字簽名無法被驗(yàn)證等原因從而使得無法保證證書真實(shí)可靠性時(shí)，就會(huì)宣布仍在有效期內(nèi)的證書作廢(稱為證書廢除(Revocation))。與廢除不同，證書掛起〔Suspending〕是暫時(shí)宣布某證書無效，度過“掛起期〞后，該證書仍是有效證書，當(dāng)然也可能被廢除.證書的廢除有兩種情況：一種是用戶提出的廢除申請，另一種是CA造成的證書廢除。3.2公鑰根底設(shè)施3.2公鑰根底設(shè)施證書廢除的另一種情況是由CA自身私鑰泄露而造成的。當(dāng)CA私鑰泄露或毀壞時(shí)，由此CA發(fā)放的所有證書，包括終端實(shí)體用戶證書與子CA的證書都必須被廢除。在CA產(chǎn)生自己的新密鑰對并由其父CA為其發(fā)放新證書后，CA必須更新它所發(fā)放的所有證書。由于每個(gè)證書上都有該證書的生成日期，因此在CA私鑰泄露前所發(fā)放的證書其內(nèi)容是真實(shí)可靠的。更新后證書的內(nèi)容與舊證書一樣，只是CA用自己的新私鑰對它進(jìn)行數(shù)字簽名。

3.2公鑰根底設(shè)施無論在何種情況下被廢除的證書，都必須在CA用來公布已更改的證書狀態(tài)的機(jī)制——證書撤消列表(CertificateRevocationList，CRL)中予以公布，以供用戶查詢。在大多數(shù)情況下，CRL證書撤消列表是一個(gè)帶有時(shí)間戳并且經(jīng)過CA數(shù)字簽名的已撤消證書的列表。當(dāng)用戶的證書使用期超過證書屬性中的有效期時(shí)或者與證書所對應(yīng)的私鑰泄露時(shí)，CA為用戶頒發(fā)新的證書并把原來的證書上傳到CRL。3.2公鑰根底設(shè)施6.證書存檔3.2公鑰根底設(shè)施證書存檔的目的有兩個(gè)：一是保存證書申請者的原始信息以及有關(guān)證書信息〔如生成、使用、到期無效、廢除等〕，以供日后核查；另一個(gè)是保證在證書無效或被廢除后，仍能驗(yàn)證在其有效期內(nèi)由其對應(yīng)私鑰所進(jìn)行的數(shù)字簽名，即所謂的可追溯性，這對于許多商務(wù)活動(dòng)是十分必要的。因此證書存檔是CA的一項(xiàng)重要職責(zé)。3.2公鑰根底設(shè)施3.2.3信任模型及管理大型開放的網(wǎng)絡(luò)系統(tǒng)中存在多個(gè)認(rèn)證機(jī)構(gòu)，需要建立認(rèn)證機(jī)構(gòu)之間可相互信賴的模型，才能建立可信賴的公鑰證書路徑，實(shí)現(xiàn)對遠(yuǎn)端用戶公鑰的平安使用。3.2公鑰根底設(shè)施1.信任模型(1)樹型層次結(jié)構(gòu)

多層樹型結(jié)構(gòu)(hierarchicalinfrastructure)是一個(gè)好的理論模型。它將用戶作為樹的端節(jié)點(diǎn)，端節(jié)點(diǎn)可以分為幾組，每組有一個(gè)上級(jí)節(jié)點(diǎn)作為可信賴機(jī)構(gòu)。而本級(jí)節(jié)點(diǎn)又分為幾組，每組又由更上一級(jí)節(jié)點(diǎn)作為它們的可信賴機(jī)構(gòu)。依此類推，最后到達(dá)根節(jié)點(diǎn)，即最高級(jí)的可信賴認(rèn)證機(jī)構(gòu)。3.2公鑰根底設(shè)施任意兩個(gè)端節(jié)點(diǎn)都可依靠這種樹型結(jié)構(gòu)找到共同的信任節(jié)點(diǎn)，從而形成可信賴的證書鏈。X.509采用的就是這種結(jié)構(gòu)，如以下圖。在這種結(jié)構(gòu)中，經(jīng)常進(jìn)行聯(lián)絡(luò)的節(jié)點(diǎn)之間可以建立直接的信賴關(guān)系，稱為交叉證書(crosscertificate)。3.2公鑰根底設(shè)施

如果甲想和乙通信，他首先必須從證書庫中取得乙的證書，然后對它進(jìn)行認(rèn)證。如果他們使用相同的CA，事情就很簡單。甲只需認(rèn)證乙證書上CA的簽名；如果他們使用不同的CA，問題就稍微復(fù)雜一些。甲必須從CA的樹形結(jié)構(gòu)底部開始，從底層CA往上層CA查詢，一起追蹤到同一個(gè)CA為止，找出共同信任的CA。3.2公鑰根底設(shè)施(2)網(wǎng)狀認(rèn)證結(jié)構(gòu)網(wǎng)狀結(jié)構(gòu)(mesh/networkinfrastructure)的CA由幾個(gè)樹型結(jié)構(gòu)組成，各個(gè)獨(dú)立樹的根節(jié)點(diǎn)沒有上下級(jí)的領(lǐng)導(dǎo)關(guān)系，相互通過雙邊認(rèn)證連接起來。這種結(jié)構(gòu)靈活簡單，比較符合國際上的團(tuán)體交往原那么。如圖所示。3.2公鑰根底設(shè)施

不同CA用戶之間的相互認(rèn)證也依靠搜索交叉證書對來實(shí)現(xiàn)，比樹型結(jié)構(gòu)要相對容易。網(wǎng)狀CA結(jié)構(gòu)的缺點(diǎn)在于缺乏統(tǒng)一管理的機(jī)制，證書路徑有時(shí)會(huì)很復(fù)雜并有可能不唯一。3.2公鑰根底設(shè)施2.信任管理

當(dāng)信任關(guān)系建立之后，對信任關(guān)系的管理成為確保信任關(guān)系的可信性的保障。信任關(guān)系的管理有兩個(gè)主要方面：一方面是為證書用戶管理信任錨的問題，另一方面是在認(rèn)證機(jī)構(gòu)間建立信任關(guān)系的管理問題。其實(shí)現(xiàn)方式主要為：3.2公鑰根底設(shè)施(1)局部信任列表局部信任列表是通常將所有層次證書的可信根CA的證書保存在用戶Web瀏覽器或其他客戶程序處的一種信任列表。由于通常只被單一用戶訪問，所以被稱為“局部的〞。在因特網(wǎng)上，用戶一般在Web站點(diǎn)上先點(diǎn)擊要訪問的站點(diǎn)按鈕，由局部信任列表來查看證書時(shí)，可以獲得證書簽名者的其他信息，最后瀏覽器詢問用戶是否信任該證書。用戶那么檢驗(yàn)證書是否是自己可信任的CA簽名，然后決定是否對證書持有人以及頒發(fā)者給予信任。3.2公鑰根底設(shè)施(2)全局/動(dòng)態(tài)信任列表在處理不同PKI方案時(shí)，全局信任列表實(shí)現(xiàn)了不同PKI與信任模型之間的交互性。而動(dòng)態(tài)信任列表使一個(gè)組織中可以有一個(gè)中央管理員來管理確定策略.這種方法的優(yōu)點(diǎn)是有助于通常的證書撤銷處理過程，從信任列表中刪除一個(gè)信任錨使得相應(yīng)CA頒發(fā)都可以被有效地撤銷掉。從證書用戶的角度來看，對建立信任來說，擁有一個(gè)被指定在特定場合可以信賴的信任錨很重要。3.2公鑰根底設(shè)施(3)CA信任錨發(fā)布認(rèn)證機(jī)構(gòu)給用戶頒發(fā)證書時(shí)，其自身已自然成為一個(gè)發(fā)布CA證書給用戶作為信任錨的地方。這時(shí)，它已經(jīng)被當(dāng)作可信來源，用戶需要在注冊時(shí)與其進(jìn)行交互。因此，CA信任錨發(fā)布方式的信任管理只適用于特定的認(rèn)證機(jī)構(gòu)自身。3.2公鑰根底設(shè)施3.2.4基于證書的PKI概述

Diffie和Hellman在1976年提出非對稱密鑰概念時(shí)，為了解決公鑰的分配問題和公眾文件(Publicfile)的概念，用一個(gè)中央數(shù)據(jù)庫作為可信的第三方來保存公鑰。為了解決這種中央數(shù)據(jù)庫訪問的性能問題，MIT的Kohnfelder于1978年在他的本科畢業(yè)論文中提出了證書的概念，建議通過數(shù)字簽名來保護(hù)命名證書(名字／密鑰對)，從而可將這些公鑰分散存放和訪問。10年后，他的建議變?yōu)楝F(xiàn)實(shí)，出現(xiàn)了X.509標(biāo)準(zhǔn)。3.2公鑰根底設(shè)施作為目錄效勞標(biāo)準(zhǔn)x.500的一局部，X.509(對應(yīng)的ISO標(biāo)準(zhǔn)是ISO/IEC9594-8)的第一版發(fā)表于1988年，1993年修訂為第二版，并應(yīng)用于PEM(InternetPrivacyEnhancedMail，一種帶平安功能的電子郵件)系統(tǒng)中。經(jīng)過使用，X.509于1996年6月改進(jìn)為第三版。IETF的PKIX工作組致力于將X.509系統(tǒng)引入到Internet中。3.2公鑰根底設(shè)施2.PKI的結(jié)構(gòu)模型PKI是公鑰的一種管理機(jī)制，宏觀上呈現(xiàn)為域結(jié)構(gòu)，即每個(gè)PKI都有一定的覆蓋范圍，形成一個(gè)管理域。以以下圖列出了PKI的根本框架模型。3.2公鑰根底設(shè)施3.2公鑰根底設(shè)施3.2公鑰根底設(shè)施證書管理中心(CertificateAuthority-CA)負(fù)責(zé)具體的證書頒發(fā)和管理，它是可信任的第三方，其作用就像頒發(fā)護(hù)照的部門。單位注冊機(jī)構(gòu)(OrganizationalRegistryAuthority-ORA)，有時(shí)也簡稱為RA，它可以幫助遠(yuǎn)離CA的端實(shí)體在CA處注冊并獲得證書。一個(gè)ORA并不是一個(gè)CA。

3.2公鑰根底設(shè)施3.2公鑰根底設(shè)施3.2公鑰根底設(shè)施3.2公鑰根底設(shè)施3.2公鑰根底設(shè)施

由加拿大政府的各個(gè)部門管理運(yùn)行各自的CA層次結(jié)構(gòu)，發(fā)布自己管轄范圍之內(nèi)的證書和CRL。如果一個(gè)CA的覆蓋范圍較大，可以使用ORA(又可稱為LocalRegistryAuthority-LRA)來負(fù)責(zé)標(biāo)識(shí)和注冊本地用戶的公鑰證書，具體包括：3.2公鑰根底設(shè)施協(xié)助注冊、取消或改變下屬實(shí)體的屬性確認(rèn)用戶的標(biāo)識(shí)授權(quán)進(jìn)行私鑰恢復(fù)或證書恢復(fù)請求接受和授權(quán)進(jìn)行證書撤銷請求進(jìn)行智能卡管理(如果使用)

管理本地的工作人員3.2公鑰根底設(shè)施3.PKI的操作模型PKI框架中有兩種管理實(shí)體：證書管理中心CA和注冊中心RA。CA是PKI框架中唯一能夠發(fā)布／撤銷證書的實(shí)體，它維護(hù)著證書的生存周期；RA負(fù)責(zé)處理用戶請求，在驗(yàn)證了請求的有效性后，代替用戶向CA提交。作為管理實(shí)體，CA／RA以證書方式向端實(shí)體提供公開密鑰的分發(fā)效勞。3.2公鑰根底設(shè)施PKI框架中有兩種端實(shí)體：持證者(Holder)和驗(yàn)證者(Verifier)。持證者是證書的擁有者，是證書所聲明事實(shí)的主體。持證者向管理實(shí)體申請并獲得證書，也可以在需要時(shí)請求撤銷或更新證書。驗(yàn)證者通常是授權(quán)方，它需要確認(rèn)持證者所提供的證書的有效性以及對方是否為該證書的真正擁有者，只有在成功認(rèn)證之后才會(huì)授予對方相應(yīng)的權(quán)力。3.2公鑰根底設(shè)施證書庫用于證書/CRL的存取和檢索。在PKI框架中，它是一個(gè)可選的組件，有很多種實(shí)現(xiàn)方式，如Web、FTP或X.509目錄。由于證書庫中存取的對象是X.509證書和CRL，其完整性由數(shù)字簽名來保證，因此對證書庫的操作可以在普通的傳輸通道上進(jìn)行，無需特殊的平安保護(hù)。3.2公鑰根底設(shè)施

不同的實(shí)體之間通過PKI操作完成證書的請求、確認(rèn)、發(fā)布、撤銷、更新、獲取等過程。PKI操作模型見圖所示。3.3.1密鑰托管體制結(jié)構(gòu)密鑰托管體制的結(jié)構(gòu)從邏輯上可分為三個(gè)局部：用戶平安模塊USC(UserSecurityComponent)，密鑰托管模塊KEC(KeyEscrowComponent)和數(shù)據(jù)恢復(fù)模塊DRC(DataRecoveryComponent)。圖所示的是這幾個(gè)模塊的相互關(guān)系：用戶平安模塊USC用戶平安模塊是硬件設(shè)備或軟件程序，提供數(shù)據(jù)加密、解密能力，同時(shí)也支持密鑰托管。這種支持表現(xiàn)為將數(shù)據(jù)恢復(fù)字段DRF附加到加密數(shù)據(jù)上。DRF可作為通用密鑰分配機(jī)制的組成局部。(1)應(yīng)用范圍USC應(yīng)用范圍是通信中的應(yīng)急解密。應(yīng)急解密(emergedecryption)是法律執(zhí)行機(jī)構(gòu)獲得法庭授權(quán)的通信接入，即搭線竊聽(wiretap)。USC應(yīng)急解密包括以下一個(gè)或兩個(gè)功能：通信，包括、e—mail以及其他聯(lián)絡(luò)方式；存貯數(shù)據(jù)，存貯的數(shù)據(jù)可以是簡單的數(shù)據(jù)文件或普通的電子信息。(2)數(shù)據(jù)加密算法USC需要標(biāo)明以下屬性：操作模式和名稱：操作模式是指符合FIPSPUB81中規(guī)定的四種模式之一或幾種模式的組合使用；為了不影響EES芯片出口，一般不允許采用3DES加密模式。

密鑰長度：密鑰長度同樣影響出口，目前美國政府規(guī)定密鑰長度在56bits以上的DES算法不允許出口。保密級(jí)別：在USC中采用的算法可以是保密的，也可以是公開的。(3)標(biāo)識(shí)符和密鑰存儲(chǔ)

USC存儲(chǔ)應(yīng)急解密所需的標(biāo)識(shí)符和密鑰：標(biāo)識(shí)符：包括用戶或USC的標(biāo)識(shí)符、密鑰標(biāo)識(shí)符、KEC或托管機(jī)構(gòu)標(biāo)識(shí)符。密鑰：包括USC的密鑰、用戶密鑰、KEC使用的全球系統(tǒng)密鑰。

(4)DRF及其機(jī)制

密鑰K加密數(shù)據(jù)時(shí)，USC必須把密文和K與數(shù)據(jù)恢復(fù)密鑰連接在一起，通常采用把DRF附加于加密數(shù)據(jù)的方法。

選擇數(shù)據(jù)恢復(fù)密鑰：K可以連接到發(fā)送者或接收者的托管機(jī)構(gòu)所持的數(shù)據(jù)恢復(fù)密鑰上，托管機(jī)構(gòu)的選擇影響數(shù)據(jù)恢復(fù)。密鑰分配：DRF、連接機(jī)制以及把K傳送給指定接收者的協(xié)議形成一個(gè)整體。因此，發(fā)送者必須傳送有效的DRF使接收者能獲得密鑰。DRF的內(nèi)容：DRF一般包括用一個(gè)以上數(shù)據(jù)恢復(fù)密鑰加密的K，數(shù)據(jù)恢復(fù)密鑰的種類有乘積密鑰、發(fā)送者或接收者的公鑰、KEC主公鑰等。某些情況下，通過DRF后密鑰K只有局部字節(jié)是有效的，因此必須利用窮舉搜索算法恢復(fù)其余字節(jié)。DRF包含有另外一些信息，可以檢驗(yàn)數(shù)據(jù)恢復(fù)密鑰、KEC或密鑰托管機(jī)構(gòu)、加密算法及加密模式、DRF生成方法。傳輸和頻度：通常DRF先于密文嵌入消息或文件頭上。在開放式連接下，可按一定間隔進(jìn)行重發(fā)。有效性：DRF包含托管認(rèn)證符(EA)，接收者驗(yàn)證EA以確定DRF的完整性。如果用公鑰生成DRF，接收者可重新計(jì)算DRF并把結(jié)果與接收到的DRF比較，驗(yàn)證其正確性。(5)互操作能力只有和老實(shí)的USC合作時(shí)，USC才能設(shè)計(jì)為互操作的，而對已被竄擾或不支持密鑰托管的USC，USC是不能具備互操作能力的。(6)實(shí)現(xiàn)USC可以用硬件、軟件或其它固件方式實(shí)現(xiàn)。一般說來，硬件比軟件平安、抗攻擊能力強(qiáng)。如果采用保密算法，必須使用防竄擾硬件完成。硬件實(shí)現(xiàn)包括：專用密碼處理器、隨機(jī)數(shù)產(chǎn)生器、高精度的時(shí)鐘。USC設(shè)備有時(shí)稱為托管加密設(shè)備，也稱為托管執(zhí)行設(shè)備。USC應(yīng)能保證用戶不能損毀密鑰托管機(jī)制或其它特性。一般把那些有欺騙性質(zhì)的USC稱作“騙子USC〞。騙子USC能否得逞，在很大程度上依賴數(shù)據(jù)恢復(fù)機(jī)制及其實(shí)現(xiàn)?！膀_子USC〞分為單一欺騙和合作欺騙，前者可以和老實(shí)的USC通信、后者那么只能和其他騙子USC通信。單一欺騙因?yàn)椴恍枰邮照吲c其合作，是備份數(shù)據(jù)恢復(fù)的最大威脅。2.密鑰托管模塊KECKEC是由密鑰托管機(jī)構(gòu)控制，管理著數(shù)據(jù)恢復(fù)密鑰的存儲(chǔ)、傳送或使用，它可以作為公鑰證書管理系統(tǒng)的組成局部，也可以作為通用密鑰管理的根底局部。KEC負(fù)責(zé)存儲(chǔ)所有的數(shù)據(jù)恢復(fù)密鑰，并提供給DRC必需的數(shù)據(jù)和效勞。KEC有以下組成局部：(1)托管機(jī)構(gòu)管托機(jī)構(gòu)也稱為托管部門，負(fù)責(zé)操作KEC。托管機(jī)構(gòu)可以在密鑰托管中心托管托管注冊，該中心為機(jī)構(gòu)具有以下特點(diǎn)：

機(jī)構(gòu)類型：托管機(jī)構(gòu)制定操作規(guī)那么，也可作為USC、DRC的聯(lián)系機(jī)構(gòu)。檢驗(yàn)?zāi)芰Γ喊▽τ脩羯矸莺退谖恢玫臋z驗(yàn)。接入能力：由托管機(jī)構(gòu)所在的位置和操作時(shí)數(shù)確定。平安性：指KEC防止托管密鑰妥協(xié)、喪失或?yàn)E用的能力，包括可靠性和反彈性，反彈性是對托管機(jī)構(gòu)在防止密鑰妥協(xié)和促進(jìn)數(shù)據(jù)恢復(fù)方面可信程度的量度?？煽啃裕罕ＷC檢驗(yàn)出那些不支持?jǐn)?shù)據(jù)恢復(fù)，并把密鑰傳送給非法部門或在無授權(quán)情況下傳送密鑰的托管機(jī)構(gòu)。(2)數(shù)據(jù)恢復(fù)密鑰

采用托管加密，所有加密數(shù)據(jù)都與數(shù)據(jù)恢復(fù)密鑰有關(guān)，因?yàn)橹挥袛?shù)據(jù)恢復(fù)密鑰能夠接入數(shù)據(jù)加密密鑰。數(shù)據(jù)恢復(fù)密鑰相關(guān)內(nèi)容如下：密鑰種類：包括數(shù)據(jù)恢復(fù)密鑰、乘積密鑰、用戶密鑰、主密鑰。數(shù)據(jù)恢復(fù)密鑰：包括會(huì)話密鑰KS，網(wǎng)絡(luò)密鑰(networkkey)，文件密鑰(filekey)。密鑰分配中心產(chǎn)生、分配并托管這些密鑰。乘積密鑰：是USC獨(dú)有的。用戶密鑰：通常是公鑰／私鑰對，用于構(gòu)造數(shù)據(jù)加密密鑰。KEC可以作為用戶的公鑰證書簽發(fā)機(jī)構(gòu)，負(fù)責(zé)簽發(fā)用戶公鑰證書。主密鑰：與KEC相關(guān)，可由多個(gè)USC共享。密鑰分割：一個(gè)數(shù)據(jù)恢復(fù)密鑰可以分割為幾個(gè)子密鑰，每個(gè)子密鑰都分別保存在不同托管機(jī)構(gòu)。密鑰的產(chǎn)生和分配：KEC和USC都可產(chǎn)生密鑰。托管時(shí)間：在托管設(shè)備生產(chǎn)階段、系統(tǒng)和設(shè)備的初始化階段、用戶注冊期間，密鑰需要托管。密鑰更新：某些體制允許更新數(shù)據(jù)恢復(fù)密鑰，但只能按一定規(guī)那么進(jìn)行。全部和局部：代替托管全部密鑰而只托管局部密鑰，在需要進(jìn)行數(shù)據(jù)恢復(fù)時(shí)，通過窮舉搜索可確定密鑰其余的字節(jié)。密鑰存儲(chǔ)：在線或不在線都可進(jìn)行密鑰存儲(chǔ)。(3)數(shù)據(jù)恢復(fù)效勞授權(quán)過程在此過程中，人們可利用KEC的效勞操作使用DRC，包括建立身份證明和接入加密數(shù)據(jù)的授權(quán)證明。效勞提供傳送數(shù)據(jù)恢復(fù)密鑰：一般在數(shù)據(jù)恢復(fù)密鑰是會(huì)話密鑰或乘積密鑰時(shí)采用這種方法。傳送派生密鑰：KEC傳送派生密鑰，如時(shí)限密鑰，該密鑰只允許在特定時(shí)段內(nèi)解密在特定時(shí)段內(nèi)加密的數(shù)據(jù)。解密密鑰：DRF中用主數(shù)據(jù)恢復(fù)密鑰加密數(shù)據(jù)加密密鑰時(shí)常用這種方法執(zhí)行門限解密：每個(gè)托管機(jī)構(gòu)分別將其解密結(jié)果提供給DRC，由DRC合成明文。數(shù)據(jù)傳輸人工或自動(dòng)地將數(shù)據(jù)傳入或傳出DRC。(4)托管密鑰的保護(hù)3.數(shù)據(jù)恢復(fù)模塊DRCDRC由算法、協(xié)議和專用設(shè)備組成。專用設(shè)備可以從KEC所提供的、包含于DRF中的信息中恢復(fù)出數(shù)據(jù)加密密鑰，從而解密密文。只有在執(zhí)行專門的數(shù)據(jù)恢復(fù)時(shí)才能使用DRC。(1)DRC能力適時(shí)解密：實(shí)時(shí)解密接入的信息；滯后解密：解密以前接入的或記錄的通信；透明度：沒有相關(guān)模塊的知識(shí)也可解密；不相關(guān)性：獲得密鑰后，DRC可用自己的資源解密而不依賴KEC。(2)數(shù)據(jù)加密密鑰的恢復(fù)為了解密數(shù)據(jù)，DRC必須采用以下方法以獲得數(shù)據(jù)加密密鑰：從發(fā)送者S或接收者R接入。重要的是要確定發(fā)送者S或接收者R相關(guān)的數(shù)據(jù)恢復(fù)密鑰能否恢復(fù)密鑰K。如果只能利用發(fā)送者S的托管機(jī)構(gòu)持有的子密鑰才能獲取K，當(dāng)各個(gè)用戶分別向?qū)ｉT的用戶傳送消息，尤其是在各個(gè)用戶散布在不同的國家或使用不同的托管機(jī)構(gòu)時(shí)，DRC必須獲得密鑰托管數(shù)據(jù)后才能進(jìn)行實(shí)時(shí)解密。與KEC的聯(lián)絡(luò)頻度：DRC每次獲得數(shù)據(jù)加密密鑰都必須與KEC合作。要求DRC和KEC是在線聯(lián)系，以提供會(huì)話密鑰改變時(shí)的實(shí)時(shí)解密。窮舉搜索能力：當(dāng)托管機(jī)構(gòu)把局部密鑰返回給DRC，DRC必須使用窮舉搜索以確定密鑰其余字節(jié)。(3)解密保護(hù)3.3.2托管加密標(biāo)準(zhǔn)EES1994年2月14日，美國政府宣布了托管加密標(biāo)準(zhǔn)EES，該標(biāo)準(zhǔn)是一種敏感的但又是非密的民用通信標(biāo)準(zhǔn)，目的是為授權(quán)的政府官員提供秘密密鑰和訪問各種信息所需要的證據(jù)。它的加密算法使用的是SKIPJACK。EES采用分組密碼，字長64位，密鑰80位，32圈置亂。

EES擁有兩種加密芯片：第一種叫Clipper芯片，又叫MYK-78T芯片，主要功能有：是防篡改、和用作聲語音加密。第二種EES芯片叫Capstone芯片，又叫MYK-80芯片，已裝在PCMCIA密碼卡中1.托管算法密鑰分量EES包括的密鑰分量主要有：UID：芯片編號(hào)，又叫器件唯一標(biāo)識(shí)符，30比特或更長；KU：單元密鑰，80比特，器件唯一密鑰；KC1：單元密鑰第1分量，由托管機(jī)構(gòu)1秘密保管；KC2：單元密鑰第2分量，由托管機(jī)構(gòu)2秘密保管；KF：80比特，公用簇密鑰；KFC1：簇密鑰分