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

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

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

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

(2)需要通信時：基于Diffie-Hellman協(xié)議。用戶I和用戶J要建立一共同的工作密鑰時，用戶I產(chǎn)生一個隨機數(shù)并計算并連同自己的發(fā)給用戶J。J也產(chǎn)生一個隨機數(shù)并計算，并連同自己的發(fā)給用戶I。然后雙方分別計算出共享的工作密鑰：因為所以

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(4)DRF及其機制

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

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

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

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

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