郭建偉,燕 娜,陳佳宇
(北京市科學技術情報研究所 北京100044)
目前,國內外主流的網絡身份認證系統是基于證書(PKI/CA)技術的認證模式。但是,PKI/CA認證模式存在不足,它是采用RSA(或ECC)算法和證書認證系統,PKI/CA是通過建立CA認證中心,為地區的多個網絡節點提供第三方認證。由于PKI/CA的并發認證速度較慢,單一認證中心管理用戶量不足,認證中心建設成本偏高,日常維護工作量較大;另外,PKI/CA的證書和公鑰,是以明文方式存放在CA認證中心的數據庫中,容易受到黑客的攻擊,存在安全隱患,使得PKI技術在網絡認證領域很難得到廣泛應用。要實現網絡實名制,必須同時解決認證安全性高、速度快、規模化、建設成本低、易于維護等難題。為此,我們提出一種使用加密卡(或加密機)硬件設備,將全部證書加密成密文,存儲在CA認證中心的證書數據庫中,保證證書的存儲安全和運行安全,實現“芯片級”的PKI安全協議,提高PKI的安全等級。
(數字)證書是用于標識實體身份的電子信息[1],它由CA(證書)簽發機構簽發,一個證書中包含的信息如圖1所示。

圖1 實體身份的電子信息Fig.1 Electronic information of entity identity
圖1中的信息就是一張證書的內容,其中簽發者名、主體名采用的是X.500定義的甄別名格式,甄別名中通常包含有證書實體的名字,稱為通用名。還包含:證書的公鑰、簽名的密碼算法,以及實體所在的機構(O)、部門(OU),所在的國家、省或州(S),郵件(E)等信息,證書序列號(證書的標識)在對應的證書簽發CA下是唯一的。
最終實體證書[2](對應用戶的個人證書)由CA(證書)簽發機構的私鑰簽名,而該CA簽發機構私鑰對應的公鑰用于對最終實體證書的簽名進行驗證,以確定該證書的簽名是否有效、證書是否由該CA簽發機構簽發。實際上,CA簽發機構的公鑰也是通過一個證書發布的,這個包含有CA簽發機構公鑰的證書,稱為CA證書,并定義為中級CA證書(CA簽發機構的證書)。該中級CA證書的主體名(即證書持有者名字),就是用該中級CA證書的私鑰簽發的最終實體證書中的簽發者名(即證書的簽發機構名字)。
與最終實體證書類似,該中級CA證書也是由CA簽發機構的另一個私鑰簽名的,即:該私鑰是CA簽發機構的另一個公開密鑰對的私鑰,這個中級CA證書的主體名與簽發者名必須不同(即使它們是指向同一個認證機構);該私鑰對應的公鑰,也對應有一個中級CA證書,稱為前一個中級CA證書的上一級中級CA證書。該上一級的中級CA證書有可能再由CA簽發機構的另一個公開密鑰對的私鑰簽名,即它可能也有它的上一級的中級CA證書……當最上一級的中級CA證書的主體名與簽發者名相同時,該中級CA證書是一個自簽名的證書,被稱為根CA證書(圖2)。

圖2 根證書的簽發流程圖Fig.2 Root certificate issuing flow chart
從最終實體證書的簽發者出發[3],可以找到對其簽名的CA簽發機構私鑰對應的中級CA證書(最下一級的中級CA證書),即:最終實體CA證書的簽發者名,是最下一級中級CA的主體名,用該中級CA的私鑰對最終實體CA證書進行簽名,用該中級CA的公鑰驗證最終實體CA證書的簽名是否有效。從該最下一級中級CA證書的簽發者,我們可以找到其上一級的中級CA證書,即:該CA證書的簽發者名,是上一級中級CA的主體名,用上一級中級CA的私鑰對該中級CA證書進行簽名,用上一級中級CA的公鑰驗證該中級CA證書的簽名是否有效。重復這個過程,直到遇到一個自簽發的驗證CA證書,即:根CA的簽發者是根CA的主體名,用根CA的私鑰對根CA證書進行簽名,用根CA的公鑰驗證根CA證書的簽名是否有效,同時,用根CA的私鑰對下一級中級CA證書進行簽名,用根CA的公鑰驗證下一級中級CA證書的簽名是否有效。這一系列的最終實體證書、各個中級CA證書和根CA證書形成了一個證書鏈,也稱為證書信任鏈,或證書信任路徑(圖3)。證書鏈的長度在理論上是沒有限定的,它可以只包含有根CA證書,也可以包含有多個中級CA證書(根CA以下的CA證書都稱為中級CA證書),甚至可以是僅包含一個自簽名的最終實體證書(這種自簽名最終實體證書通常用于特殊的場合)。
因此,在判斷一個最終實體證書是否有效時,根CA證書起著極其重要的作用,它是證書信任的“根”[4]。驗證一個實體證書的可信性,需要找到相關的各級中級CA證書和根CA證書,構造證書鏈,并需要確定證書鏈的根CA證書是否可信。
但是,全部最終實體CA證書都是以明文形式存放在CA認證中心的證書數據庫中,對全部最終實體CA證書進行簽名的中級證書,以及該中級CA證書的上一級的其他中級CA和根CA證書,也都是以明文形式存放在證書數據庫里,這就給PKI的CA認證中心留下了安全隱患。
證書的主要漏洞是:全部用戶的最終實體CA證書、各個中級CA證書和根CA證書,都是以明文形式[5]分別存放在CA認證中心的證書數據庫里,PKI的各種安全協議是在CA認證中心的服務器里運行,僅僅依靠CA認證中心的防火墻和防病毒系統無法保證它們的存儲安全,國際標準化(公開)的PKI各種安全協議也為黑客攻擊PKI系統提供了途經。

圖3 實體證書的簽發者流程圖Fig.3 Flow chart for issuers of physical certificates
攻擊者能夠使用計算機病毒程序獲取CA認證中心證書數據庫中全體用戶的證書。根據證書公開的內容獲得如下重要信息:①該PKI系統采用的公鑰密碼算法類型和密鑰長度,如RSA算法的密鑰長度為512bit、1024bit、2048bit、4096bit,ECC算法的密鑰長度為160bit、190bit等;②該PKI系統采用的摘要算法類型,如SHA-1摘要算法對文件摘要的長度為256bit,MD5摘要算法對文件摘要的長度為128bit。
攻擊者通過對證書進行分析[6],偽造密鑰對(公鑰和私鑰),通過分析確定了證書中哪些是最終實體證書,哪些是證書信任鏈中的中級CA證書和根CA證書,再偽造證書信任鏈上的所有證書的密鑰對,來躲避PKI的安全自檢系統對證書信任鏈的安全檢測(即簽名驗證)。
首先,在客戶端,攻擊者可以從芯片生產商那里買含有PKI標準安全協議的加密芯片(USB-KEY),將偽造客戶端對應的私鑰和證書(這兩組數據)寫入USB-KEY里,存放在USB-KEY芯片里的PKI安全協議不用替換,從而在客戶端USB-KEY里建立起基于偽造私鑰和證書的各種PKI安全協議[7]。
之后,對CA認證中心端全體證書內容進行修改,主要篡改各個證書中的公鑰和數字簽名內容,證書中的其他內容都不變。先偽造每個證書的“密鑰對”,并用偽造的根CA證書對應的公鑰,來替換原根CA證書中的公鑰,用偽造的根CA證書對應的私鑰,對根CA證書進行簽名并將偽造的簽名代替根CA證書的原簽名。同時,用偽造的根CA證書對應的私鑰,對最上一級的中級CA證書進行簽名,將該偽造的簽名結果來代替原最上一級的中級CA證書中的簽名;用偽造的最上一級的中級CA證書對應的公鑰,來替換原最上一級的中級CA證書中的公鑰,用偽造的最上一級的中級CA證書對應的私鑰,對下一級中級證書進行簽名,如此類推,用偽造的最下一級的中級CA證書對應的公鑰,來替換原最下一級中級CA證書中的公鑰,用偽造的最下一級的中級CA證書對應的私鑰,分別來對全部用戶的最終實體證書進行簽名,得到全部用戶的最終實體證書中的偽造簽名,并用這些偽造簽名代替原最終實體證書中的簽名。這樣,攻擊者篡改了CA認證中心全體證書。
攻擊者再利用病毒程序,將修改后的全體證書替換原CA認證中心證書數據庫中的證書內容。CA認證中心端的公鑰密碼算法、摘要算法和各種安全協議都保持不變。另外,當證書吊銷列表里只存儲了證書的標識和證書的狀態時,攻擊者也不需要篡改證書吊銷列表中的內容。若證書吊銷列表里存儲證書全部內容,則需要將偽造的證書替換證書吊銷列表里的存儲證書。至此,攻擊者基本完成對CA認證中心端的攻擊準備。
當CA認證中心為第三方提供密碼認證時,攻擊者不需要偽造WEB服務器證書就能對第三方WEB服務器進行攻擊。由于CA認證中心將認證結果轉發給應用系統WEB服務器,攻擊者通過PKI安全協議的認證后已經成為合法用戶,則CA認證中心里的安全協議直接調用該WEB服務器證書的公鑰加密偽造的認證結果,并發送給應用系統的WEB服務器。在WEB服務器里,服務器證書對應的私鑰再對認證結果密文進行解密,得到CA認證中心認證結果的明文。這時,認證結果已經被黑客篡改了。
在CA認證中心全部用戶的最終實體證書都是以密文形式存儲在證書數據庫中,證書信任鏈上各中級證書和根證書存放在芯片硬件里,能保證認證中心全部最終實體證書、信任鏈上各個中級證書和根證書的存儲安全,同時,保證CA認證中心端的各種證書是可信的。即使攻擊者想篡改用戶的最終實體證書,但在無法獲得加密證書的密鑰的情況下,也無法將篡改后的最終實體證書加密成攻擊者可用的密文,從而防止攻擊者通過篡改最終實體證書,來攻擊CA認證中心的各種安全協議。
PKI/CA的解決方案也存在一些問題,用戶可用性、應用的標準化和安全性是突出問題之一。一般而言CA負責證書的簽發和有效性認證并不對應用負責,數字證書的應用在工程層面面臨的兼容性、可用性、規范性、安全性問題依然很多,各家CA中心和產業參與者積極推動解決方案和應用創新,制定和推動數字證書應用標準化、規范化的相關行業、國家標準,但應用問題整體上的改觀依然遙遙無期。例如,PC瀏覽器的兼容性就是證書應用揮之不去的噩夢,這也是CA業務推廣受限的核心問題之一。同時,不同CA中心證書的互通性受制于信任體系和服務協議的制約,不是一個單純靠技術可以解決的問題。另外,應用依賴單一服務機構的單點問題,是證書應用的另一個擔心,很多以聯盟或應用能力平臺的解決方案試圖解決單個CA中心依賴的問題,其實質是用一個更大的中心單點取代另一個中心單點而已。核心訴求解決匿名、去單點依賴的中心化問題,匿名通過賬戶地址去實現,賬戶地址是非對稱密鑰對的公鑰變形,以每次交易生成一個賬戶的原則,可以避免識別出賬戶的持有者身份,也就是你可以知道一個賬號,但不知道賬號的持有者。其實由于數字貨幣的可分割特性,在一筆交易中如果出現多個關聯賬號,只要一個賬號的泄露或可推測,就存在賬號持有身份被推測出來的可能性。由于非法交易和洗錢的嫌疑始終和匿名密不可分,匿名屬性是各國政府是否接納比特幣等數字貨幣的一個判斷依據。同時,隨著區塊鏈的賬本長度增加和比特幣賬戶私鑰保管問題的突出,云錢包是一種主流發展趨勢,云錢包需要賬戶的認證,對匿名性原則有較大的影響。從監管、技術的角度上來看,數字貨幣或區塊鏈記賬賬戶匿名性原則的堅持存在爭議。
本方案通過對標準PKI的分析,指出了PKI的CA認證中心普遍存在的用戶證書安全漏洞,分析了攻擊者能夠利用PKI存在的安全漏洞,攻擊CA認證中心的方法和過程,提出了在證書初始化階段對CA認證中心的全體最終實體CA證書進行加密,并將信任鏈上的各個中級證書和根證書存放在芯片里,以保證CA認證中心全體最終實體CA證書,以及信任鏈上的各中級CA證書和根CA證書數據的安全存儲,防止攻擊者利用計算機病毒替換用戶的最終實體CA證書。