PKI和X509證書

PKI 體系

按照 X.509 規範,公鑰可以通過證書機制來進行保護,但證書的生成、分發、撤銷等步驟並未涉及。

實際上,要實現安全地管理、分發證書需要遵循 PKI(Public Key Infrastructure)體系。該體系解決了證書生命週期相關的認證和管理問題。

需要注意,PKI 是建立在公私鑰基礎上實現安全可靠傳遞消息和身份確認的一個通用框架,並不代表某個特定的密碼學技術和流程。實現了 PKI 規範的平臺可以安全可靠地管理網絡中用戶的密鑰和證書。目前包括多個具體實現和規範,知名的有 RSA 公司的 PKCS(Public Key Cryptography Standards)標準和 OpenSSL 等開源工具。
PKI 基本組件
一般情況下,PKI 至少包括如下核心組件:

  • CA(Certification Authority):負責證書的頒發和吊銷(Revoke),接收來自 RA 的請求,是最核心的部分;
  • RA(Registration Authority):對用戶身份進行驗證,校驗數據合法性,負責登記,審覈過了就發給 CA;
  • 證書數據庫:存放證書,多采用 X.500 系列標準格式。可以配合LDAP 目錄服務管理用戶信息。

其中,CA 是最核心的組件,主要完成對證書信息的維護。

常見的操作流程爲,用戶通過 RA 登記申請證書,提供身份和認證信息等;CA 審覈後完成證書的製造,頒發給用戶。用戶如果需要撤銷證書則需要再次向 CA 發出申請。

證書的簽發

CA 對用戶簽發證書實際上是對某個用戶公鑰,使用 CA 的私鑰對其進行簽名。這樣任何人都可以用 CA 的公鑰對該證書進行合法性驗證。驗證成功則認可該證書中所提供的用戶公鑰內容,實現用戶公鑰的安全分發。

用戶證書的簽發可以有兩種方式。可以由用戶自己生成公鑰和私鑰,然後 CA 來對公鑰內容進行簽名(只有用戶持有私鑰);也可以由 CA 直接來生成證書(內含公鑰)和對應的私鑰發給用戶(用戶和 CA 均持有私鑰)。

前者情況下,用戶一般會首先自行生成一個私鑰和證書申請文件(Certificate Signing Request,即 csr 文件),該文件中包括了用戶對應的公鑰和一些基本信息,如通用名(common name,即 cn)、組織信息、地理位置等。CA 只需要對證書請求文件進行簽名,生成證書文件,頒發給用戶即可。整個過程中,用戶可以保持私鑰信息的私密性,不會被其他方獲知(包括 CA 方)。

需要注意,用戶自行生成私鑰情況下,私鑰文件一旦丟失,CA 方由於不持有私鑰信息,無法進行恢復,意味着通過該證書中公鑰加密的內容將無法被解密。

證書的吊銷

證書超出有效期後會作廢,用戶也可以主動向 CA 申請吊銷某證書文件。

由於 CA 無法強制收回已經頒發出去的數字證書,因此爲了實現證書的作廢,往往還需要維護一個吊銷證書列表(Certificate Revocation List,CRL),用於記錄已經吊銷的證書序號。

因此,通常情況下,當對某個證書進行驗證時,需要首先檢查該證書是否已經記錄在列表中。如果存在,則該證書無法通過驗證。如果不在,則繼續進行後續的證書驗證過程。

爲了方便同步吊銷列表信息,IETF 提出了在線證書狀態協議(Online Certificate Status Protocol,或 OCSP),支持該協議的服務可以實時在線查詢吊銷的證書列表信息。

數字證書

對於非對稱加密算法和數字簽名來說,很重要的步驟就是公鑰的分發。理論上任何人都可以獲取到公開的公鑰。然而這個公鑰文件有沒有可能是僞造的呢?傳輸過程中有沒有可能被篡改呢?一旦公鑰自身出了問題,則整個建立在其上的的安全性將不復成立。

數字證書機制正是爲了解決這個問題,它就像日常生活中的證書一樣,可以確保所記錄信息的合法性。比如證明某個公鑰是某個實體(個人或組織)擁有,並且確保任何篡改都能被檢測出來,從而實現對用戶公鑰的安全分發。

根據所保護公鑰的用途,數字證書可以分爲加密數字證書(Encryption Certificate)和簽名驗證數字證書(Signature Certificate)。前者往往用於保護用於加密用途的公鑰;後者則保護用於簽名用途的公鑰。兩種類型的公鑰也可以同時放在同一證書中。

一般情況下,證書需要由證書認證機構(CA)來進行簽發和背書。權威的商業證書認證機構包括 DigiCert、GlobalSign、VeriSign 等。用戶也可以自行搭建本地 CA 系統,在私有網絡中進行使用。

X.509 證書規範

一般的,一個數字證書內容可能包括證書域(證書的版本、序列號、簽名算法類型、簽發者信息、有效期、被簽發主體、簽發的公開密鑰)、CA 對證書的簽名算法和簽名值等。
目前使用最廣泛的標準爲 ITU 和 ISO 聯合制定的 X.509 的 v3 版本規範(RFC 5280),其中定義瞭如下證書信息域:
• 版本號(Version Number):規範的版本號,目前爲版本 3,值爲 0x2;
• 序列號(Serial Number):由 CA 維護的爲它所頒發的每個證書分配的唯一的序列號,用來追蹤和撤銷證書。只要擁有簽發者信息和序列號,就可以唯一標識一個證書。最大不能超過 20 個字節;
• 簽名算法(Signature Algorithm):數字簽名所採用的算法,如 sha256WithRSAEncryption 或 ecdsa-with-SHA256;
• 頒發者(Issuer):頒發證書單位的信息,如 “C=CN, ST=Beijing, L=Beijing, O=org.example.com, CN=ca.org.example.com”;
• 有效期(Validity):證書的有效期限,包括起止時間(如 Not Before 2018-08-08-00-00UTC,Not After 2028-08-08-00-00UTC);
• 被簽發主體(Subject):證書擁有者的標識信息(Distinguished Name),如 “C=CN, ST=Beijing, L=Beijing, CN=personA.org.example.com”;
• 主體的公鑰信息(Subject Public Key Info):所保護的公鑰相關的信息;

  • 公鑰算法(Public Key Algorithm):公鑰採用的算法;
  • 主體公鑰(Subject Public Key):公鑰的內容;

• 頒發者唯一號(Issuer Unique Identifier,可選):代表頒發者的唯一信息,僅 2、3 版本支持,可選;
• 主體唯一號(Subject Unique Identifier,可選):代表擁有證書實體的唯一信息,僅 2、3 版本支持,可選;
• 擴展(Extensions,可選):可選的一些擴展。可能包括:

  • Subject Key Identifier:實體的密鑰標識符,區分實體的多對密鑰;
  • Basic Constraints:一般指明該證書是否屬於某個 CA;
  • Authority Key Identifier:頒發這個證書的頒發者的公鑰標識符;
  • Authority Information Access:頒發相關的服務地址,如頒發者證書獲取地址和吊銷證書列表信息查詢地址;
  • CRL Distribution Points:證書註銷列表的發佈地址;
  • Key Usage: 表明證書的用途或功能信息,如 Digital Signature、Key CertSign;
  • Subject Alternative Name:證書身份實體的別名,如該證書可以同樣代表 .org.example.com,org.example.com,.example.com,example.com 身份等。
    此外,證書的頒發者還需要對證書內容利用自己的私鑰進行簽名,以防止他人篡改證書內容。

證書信任鏈

證書中記錄了大量信息,其中最重要的包括“簽發的公開密鑰”和“CA數字簽名”兩個信息。因此,只要使用 CA 的公鑰再次對這個證書進行簽名比對,就能證明所記錄的公鑰是否合法。

讀者可能會想到,怎麼證明用來驗證對實體證書進行簽名的CA公鑰自身是否合法呢?畢竟在獲取CA公鑰的過程中,它也可能被篡改掉。

實際上,CA 的公鑰是否合法,一方面可以通過更上層的CA頒發的證書來進行認證;另一方面某些根 CA(Root CA)可以通過預先分發證書來實現信任基礎。例如,主流操作系統和瀏覽器裏面,往往會提前預置一些權威 CA 的證書(通過自身的私鑰簽名,系統承認這些是合法的證書)。之後所有基於這些 CA 認證過的中間層 CA(Intermediate CA)和後繼 CA 都會被驗證合法。這樣就從預先信任的根證書,經過中間層證書,到最底下的實體證書,構成一條完整的證書信任鏈。

某些時候用戶在使用瀏覽器訪問某些網站時,可能會被提示是否信任對方的證書。這說明該網站證書無法被當前系統中的證書信任鏈進行驗證,需要進行額外檢查。另外,當信任鏈上任一證書不可靠時,則依賴它的所有後繼證書都將失去保障。

可見,證書作爲公鑰信任的基礎,對其生命週期進行安全管理十分關鍵。後面章節將介紹的 PKI 體系提供了一套完整的證書管理的框架,包括生成、頒發、撤銷過程等。

證書的申請和撤銷

證書的申請有兩種方式,一是在線申請,另外一個就是離線申請。在線申請就是通過瀏覽器或其他應用系統通過在線的方式來申請證書,這種方式一般用於申請普通用戶證書或測試證書。離線方式一般通過人工的方式直接到證書機構證書受理點去辦理證書申請手續,通過審覈後獲取證書,這種方式一般用於比較重要的場合,如服務器證書和商家證書等。下面討論的主要是在線申請方式。

當證書申請時,用戶使用瀏覽器通過Internet訪問安全服務器,下載CA的數字證書(又叫做根證書),然後註冊機構服務器對用戶進行身份審覈,認可後便批准用戶的證書申請,然後操作員對證書申請表進行數字簽名,並將申請及其簽名一起提交給CA服務器。

CA 操作員獲得註冊機構服務器操作員簽發的證書申請,發行證書或者拒絕發行證書,然後將證書通過硬拷貝的方式傳輸給註冊機構服務器。註冊機構服務器得到用戶的證書以後將用戶的一些公開信息和證書放到LDAP服務器上提供目錄瀏覽服務,並且通過電子郵件的方式通知用戶從安全服務器上下載證書。用戶根據郵件的提示到指定的網址下載自己的數字證書,而其他用戶可以通過LDAP服務器獲得他的公鑰數字證書。

證書申請的步驟如下:

1)用戶申請
用戶首先下載CA的證書,又叫根證書,然後在證書的申請過程中使用SSL安全方式與服務器建立連接,用戶填寫個人信息,瀏覽器生成私鑰和公鑰對,將私鑰保存客戶端特定文件中,並且要求用口令保護私鑰,同時將公鑰和個人信息提交給安全服務器。安全服務器將用戶的申請信息傳送給註冊機構服務器。

2)註冊機構審覈
用戶與註冊機構人員聯繫,證明自己的真實身份,或者請求代理人與註冊機構聯繫。註冊機構操作員利用自己的瀏覽器與註冊機構服務器建立SSL安全通信,該服務器需要對操作員進行嚴格的身份認證,包括操作員的數字證書、IP地址,爲了進一步保證安全性,可以設置固定的訪問時間。操作員首先查看目前系統中的申請人員,從列表中找出相應的用戶,點擊用戶名,覈對用戶信息,並且可以進行適當的修改,如果操作員同意用戶申請證書請求,必須對證書申請信息進行數字簽名。操作員也有權利拒絕用戶的申請。操作員與服務器之間的所有通信都採用加密和簽名,具有安全性、抗否認性,保證了系統的安全性和有效性。

3)CA發行證書
註冊機構RA通過硬拷貝的方式向CA傳輸用戶的證書申請與操作員的數字簽名,CA操作員查看用戶的詳細信息,並且驗證操作員的數字簽名,如果簽名驗證通過,則同意用戶的證書請求,頒發證書。然後CA將證書輸出。如果CA操作員發現簽名不正確,則拒絕證書申請,CA頒發的數字證書中包含關於用戶及CA自身的各種信息,如:能唯一標識用戶的姓名及其他標識信息,如個人的email地址;證書持有者的公鑰。公鑰用於爲證書持有者加密敏感信息、簽發個人證書的認證機構的名稱、個人證書的序列號和個人證書的有效期(證書有效起止日期)等

4)註冊機構證書轉發
註冊機構RA操作員從CA處得到新的證書,首先將證書輸出到LDAP目錄服務器以提供目錄瀏覽服務,最後操作員向用戶發送一封電子郵件,通知用戶證書已經發行成功,並且把用戶的證書序列號告訴用戶到指定的網址去下載自己的數字證書。並且告訴用戶如何使用安全服務器上的LDAP配置,讓用戶修改瀏覽器的客戶端配置文件以便訪問LDAP服務器,獲得他人的數字證書。

5)用戶證書獲取
用戶使用證書申請時的瀏覽器到指定的網址,鍵入自己的證書序列號,服務器要求用戶必須使用申請證書時的瀏覽器,因爲瀏覽器需要用該證書相應的私鑰去驗證數字證書。只有保存了相應私鑰的瀏覽器才能成功下載用戶的數字證書。
這時用戶打開瀏覽器的安全屬性,就可以發現自己已經擁有了CA頒發的數字證書,可以利用該數字證書與其他人以及web服務器(擁有相同CA頒發的證書)使用加密、數字簽名進行安全通信。

認證中心還涉及到CRL的管理。用戶向特定的操作員(僅負責CRL的管理)發一份加密簽名的郵件,申明自己希望撤消證書。操作員打開郵件,填寫CRL註冊表,並且進行數字簽名,提交給CA,CA操作員驗證註冊機構操作員的數字簽名,批准用戶撤消證書,並且更新CRL,然後CA將不同格式的CRL輸出給註冊 機構,公佈到安全服務器上,這樣其他人可以通過訪問服務器得到CRL。

證書撤銷流程步驟如下:
1)用戶向註冊機構操作員CRLManager發送一封簽名加密的郵件,聲明自己自願撤消證書。
2)這冊機構同意證書撤消,操作員鍵入用戶的序列號,對請求進行數字簽名。
3)CA查詢證書撤消請求列表,選出其中的一個,驗證操作員的數字簽名,如果正確的話,則同意用戶的證書撤消申請,同時更新CRL列表,然後將CRL以多種格式輸出。
4)註冊機構轉發證書撤消列表。操作員導入CRL,以多種不同的格式將CRL公佈於衆。
5)用戶瀏覽安全服務器,下載或瀏覽CRL。
在一個PKI,特別是CA中,信息的存儲是一個非常核心的問題,它包括兩個方面:一是CA服務器利用數據庫來備份當前密鑰和歸檔過期密鑰,該數據庫需高度安全和機密,其安全等級同CA本身相同;另外一個就是目錄服務器,用於分發證書和CRL,一般採用LDAP目錄服務器。

密鑰管理

密鑰管理也是PKI(主要指CA)中的一個核心問題,主要是指密鑰對的安全管理,包括密鑰產生、密鑰備份、密鑰恢復和密鑰更新等。

1)密鑰產生
密鑰對的產生是證書申請過程中重要的一步,其中產生的私鑰由用戶保留,公鑰和其他信息則交於CA中心進行簽名,從而產生證書。根據證書類型和應用的不同,密鑰對的產生也有不同的形式和方法。對普通證書和測試證書,一般由瀏覽器或固定的終端應用來產生,這樣產生的密鑰強度較小,不適合應用於比較重要的安全網絡交易。而對於比較重要的證書,如商家證書和服務器證書等,密鑰對一般由專用應用程序或CA中心直接產生,這樣產生的密鑰強度大,適合於重要的應用場合。
另外,根據密鑰的應用不同,也可能會有不同的產生方式。比如簽名密鑰可能在客戶端或RA中心產生,而加密密鑰則需要在CA中心直接產生。

2)密鑰備份和恢復
在一個PKI系統中,維護密鑰對的備份至關重要,如果沒有這種措施,當密鑰丟失後,將意味着加密數據的完全丟失,對於一些重要數據,這將是災難性的。所以,密鑰的備份和恢復也是PKI密鑰管理中的重要一環。

使用PKI的企業和組織必須恩能夠得到確認:即使密鑰丟失,受密要加密保護的重要信息也必須能夠恢復,並且不能讓一個獨立的個人完全控制最重要的主密鑰,否則將引起嚴重後果。

企業級的PKI產品至少應該支持用於加密的安全密鑰的存儲、備份和恢復。密鑰一般用口令進行保護,而口令丟失則是管理員最常見的安全疏漏之一。所以,PKI產品應該能夠備份密鑰,即使口令丟失,它也能夠讓用戶在一定條件下恢復該密鑰,並設置新的口令。

例如,在某些情況下用戶可能有多對密鑰,至少應該有兩個密鑰:一個用於加密,一個用於簽名。簽名密要不需要備份,因爲用於驗證簽名的公鑰(或公鑰證書)廣泛發佈,即使簽名私鑰丟失,任何用於相應公要的人都可以對已簽名的文檔進行驗證。但PKI系統必須備份用於加密的密鑰對,並允許用戶進行恢復,否則,用於解密的私鑰丟失將意味着加密數據的完全不可恢復。

另外,使用PKI的企業也應該考慮所使用密鑰的生命週期,它包括密鑰和證書的有效時間,以及已撤銷密鑰和證書的維護時間等。

3)密鑰更新
對每一個由CA頒發的證書都會有有效期,密鑰對生命週期的長短由簽發證書的CA中心來確定,各CA系統的證書有效期限有所不同,一般大約爲2-3年。
當用戶的私鑰被泄漏或證書的有效期快到時,用戶應該更新私鑰。這時用戶可以廢除證書,產生新的密鑰對,申請新的證書。

證書的使用

在實際應用中,爲了驗證信息的數字簽名,用戶首先必須獲取信息發送者的公鑰證書,以及一些額外需要的證書(如CA證書等,用於驗證發送者證書的有效性)。
證書的獲取可以有多種方式,如發送者發送簽名信息時附加發送自己的證書,或以另外的單獨信息發送證書,或者可以通過訪問證書發佈的目錄服務器來獲得,或者直接從證書相關的實體處獲得。在一個PKI體系中,可以採取某種或某幾種上述方式獲得證書。
在電子商務系統中,證書的持有者可以是個人用戶、企事業單位、商家、銀行等。無論是電子商務中的哪一方,在使用證書驗證數據時,都遵循同樣的驗證流程。一個完整的驗證過程有以下幾步:

  1. 將客戶端發來的數據解密 (如解開數字信封)。
  2. 將解密後的數據分解成原始數據,簽名數據和客戶證書三部分。
  3. 用CA根證書驗證客戶證書的簽名完整性。
  4. 檢查客戶證書是否有效 (當前時間在證書結構中的所定義的有效期內)。
  5. 檢查客戶證書是否作廢 (OCSP方式或CRL方式)。
  6. 驗證客戶證書結構中的證書用途。
  7. 客戶證書驗證原始數據的簽名完整性。

如果以上各項均驗證通過,則接受該數據。

參考:

RFC 2459 Internet X.509 Public Key Infrastructure

X.509證書結構簡介及實例

PKI系統深入介紹

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章