證書-原理

    接着上篇 數字簽名 無法解決 “僞造公鑰”的問題。證書的出現正式解決此問題的。

    “證書 – 爲公鑰加上數字簽名”

1. 證書

    要開車得先考駕照．駕照上面記有本人的照片、姓名、出生日期等個人信息．以及有效期、準駕車輛的類型等信息，並由公安局在上面蓋章。我們只要看到駕照，就可以知道公安局認定此人具有駕駛車輛的資格。 --駕駛證就相當於 公安局給個人頒發的“證書”。

    公鑰證書（Public-Key Certificate，PKC)其實和駕照很相似，裏面記有姓名、組織、郵箱地址等個人信息，以及屬於此人的公鑰，並由認證機構（Certification Authority、Certifying Authority, CA）施加數字簽名。只要看到公鑰證書，我們就可以知道認證機構認定該公鑰的確屬於此人。公鑰證書也簡稱爲證書（certificate）。

    可能很多人都沒聽說過認證機構，認證機構就是能夠認定 “公鑰確實屬於此人"，並能夠生成數字簽名的個人或者組織。認證機構中有國際性組織和政府所設立的組織，也有通過提供認證服務來盈利的一般企業，此外個人也可以成立認證機構。

2. X.509

    X.509是一種非常通用的證書格式。所有的證書都符合ITU-T X.509國際標準，因此(理論上)爲一種應用創建的證書可以用於任何其他符合X.509標準的應用。X.509證書的結構是用ASN1(Abstract Syntax Notation One)進行描述數據結構，並使用ASN.1語法進行編碼。

    在一份證書中，必須證明公鑰及其所有者的姓名是一致的。對X.509證書來說，認證者總是CA或由CA指定的人，一份X.509證書是一些標準字段的集合，這些字段包含有關用戶或設備及其相應公鑰的信息。X.509標準定義了證書中應該包含哪些信息，並描述了這些信息是如何編碼的(即數據格式)

    一般來說，一個數字證書內容可能包括基本數據（版本、序列號) 、所簽名對象信息（ 簽名算法類型、簽發者信息、有效期、被簽發人、簽發的公開密鑰）、CA的數字簽名，等等.

3. 證書規範

    前使用最廣泛的標準爲ITU和ISO聯合制定的X.509的 v3版本規範 (RFC5280）, 其中定義瞭如下證書信息域：

• 版本號(Version Number）：規範的版本號，目前爲版本3，值爲0x2；
• 序列號（Serial Number）：由CA護的爲它所發的每個證書分配的一的列號，用來追蹤和撤銷證書。只要擁有簽發者信息和序列號，就可以唯一標識一個證書，最大不能過20個字節；
• 簽名算法（Signature Algorithm）：數字簽名所採用的算法，如：sha256-with-RSA-Encryption 或ccdsa-with-SHA2S6；
• 頒發者（Issuer）：發證書單位的標識信息，如 ” C=CN，ST=Beijing, L=Beijing,O=org.example.com，CN=ca.org。example.com ”；
• 有效期(Validity): 證書的有效期很，包括起止時間。
• 主體(Subject): 證書擁有者的標識信息（Distinguished Name），如：" C=CN，ST=Beijing, L=Beijing,CN=person.org.example.com”；
• 主體的公鑰信息(SubJect Public Key Info）：所保護的公鑰相關的信息：
• 公鑰算法 (Public Key Algorithm）公鑰採用的算法；
• 主體公鑰（Subject Unique Identifier）：公鑰的內容。
• 頒發者唯一號（Issuer Unique Identifier）：代表頒發者的唯一信息，僅2、3版本支持，可選；
• 主體唯一號（Subject Unique Identifier）：代表擁有證書實體的唯一信息，僅2，3版本支持，可選：
• 擴展（Extensions，可選）可選的一些擴展。中可能包括：
  • Subject Key Identifier：實體的祕鑰標識符，區分實體的多對祕鑰；
  • Basic Constraints：一指明是否屬於CA;
  • Authority Key Identifier：證書頒發者的公鑰標識符；
  • CRL Distribution Points: 撤銷文件的頒發地址；
  • Key Usage：證書的用途或功能信息。

    此外，證書的頒發者還需要對證書內容利用自己的私鑰添加簽名， 以防止別人對證書的內容進行篡改。

4. 證書格式

    X.509規範中一般推薦使用PEM(Privacy Enhanced Mail）格式來存儲證書相關的文件。證書文件的文件名後綴一般爲 .crt 或 .cer 。對應私鑰文件的文件名後綴一般爲 .key。證書請求文件的文件名後綴爲 .csr 。有時候也統一用pem作爲文件名後綴。

    PEM格式採用文本方式進行存儲。一般包括首尾標記和內容塊，內容塊採用Base64進行編碼。

    編碼格式總結:

• X.509 DER(Distinguished Encoding Rules)編碼，後綴爲：.der .cer .crt
• X.509 BASE64編碼(PEM格式)，後綴爲：.pem .cer .crt

5. 公鑰基礎設施（PKI）

    僅制定證書的規範還不足以支持公鑰的實際運用，我們還需要很多其他的規範，例如證書應該由誰來頒發，如何頒發，私鑰泄露時應該如何作廢證書，計算機之間的數據交換應採用怎樣的格式等。這一節我們將介紹能夠使公鑰的運用更加有效的公鑰基礎設施。

5.1 什麼是公鑰基礎設施

    公鑰基礎設施（Public-Key Infrystructure）是爲了能夠更有效地運用公鑰而制定的一系列規範和規格的總稱。公鑰基礎設施一般根據其英語縮寫而簡稱爲PKI。

    PKI只是一個總稱，而並非指某一個單獨的規範或規格。例如，RSA公司所制定的PKCS（Public-KeyCryptography Standards，公鑰密碼標準）系列規範也是PKI的一種，而互聯網規格RFC（RequestforComments）中也有很多與PKI相關的文檔。此外，X.509這樣的規範也是PKI的一種。在開發PKI程序時所使用的由各個公司編寫的API（Application Programming Interface, 應用程序編程接口）和規格設計書也可以算是PKI的相關規格。

    因此，根據具體所採用的規格，PKI也會有很多變種，這也是很多人難以整體理解PKI的原因之一。

    爲了整體理解PKI,來簡單總結一下PKI的基本組成要素（用戶、認證機構、倉庫）以及認證機構所負責的工作。

5.2 PKI的組成要素

    PKI的組成要素主要有以下三個：

• 用戶 — 使用PKI的人
• 認證機構 — 頒發證書的人
• 倉庫 — 保存證書的數據庫
      不過，由於PKI中用戶的認證機構不僅限於“人”（也有可能是計算機），因此可以給他們起一個特殊的名字，叫作實體（entitiy）。實體就是進行證書和密鑰相關處理的行爲主體。

5.2.1 用戶

    用戶就是像Alice、Bob這樣使用PW的人。用戶包括兩種：一種是希望使用KPI註冊自己的公鑰的人，另一種是希望使用已註冊的公鑰的人。我們來具體看一下這兩種用戶所要進行的操作。

1. 註冊公鑰的用戶所進行的操作
   • 生成密鑰對（也可以由認證機構生成）
   • 在認證機構註冊公鑰
   • 向認證機構申請證書
   • 根據需要申請作廢已註冊的公鑰
   • 解密接收到的密文
   • 對消息進行數字簽名
2. 使用已註冊公鑰的用戶所進行的操作
   • 將消息加密後發送給接收者
   • 驗證數字簽名

5.2.2. 認證機構（CA）

    認證機構（Certification Authority，CA）是對證書進行管理的人。上面的圖中我們給它起了一個名字叫作Trent。認證機構具體所進行的操作如下：

• 生成密鑰對（也可以由用戶生成）
• 在註冊公鑰時對本人身份進行認證
• 生成並頒發證書
• 作廢證書

    認證機構的工作中，公鑰註冊和本人身份認證這一部分可以由註冊機構（Registration Authority，RA) 來分擔。這樣一來，認證機構就可以將精力集中到頒發證書上，從而減輕了認證機構的負擔。不過，引入註冊機構也有弊端，比如說認證機構需要對註冊機構本身進行認證，而且隨着組成要素的增加，溝通過程也會變得複雜，容易遭受攻擊的點也會增。

5.2.3. 倉庫

    倉庫（repository）是一個保存證書的數據庫，PKI用戶在需要的時候可以從中獲取證書．它的作用有點像打電話時用的電話本。在本章開頭的例子中，儘管沒特別提到，但Alice獲取Bob的證書時，就可以使用倉庫。倉庫也叫作證書目錄。

5.3. 認證機構的工作

5.3.1. 生成密鑰對

    生成密鑰對有兩種方式：一種是由PKI用戶自行生成，一種是由認證機構來生成。在認證機構生成用戶密鑰對的情況下，認證機構需要將私鑰發送給用戶，這時就需要使用PKCS#12（Personal InformationExchange Syntax Standard）等規範。（根據本人經驗一般都是用戶自己生成的）

5.3.2. 註冊證書

    在用戶自行生成密鑰對的情況下，用戶會請求認證機構來生成證書。申請證書時所使用的規範是由PKCS#10（Certification Request Syntax Standard）定義的。

    認證機構根據其認證業務準則（Certification Practice Statement，CPS）對用戶的身份進行認證，並生成證書。在生成證書時，需要使用認證機構的私鑰來進行數字簽名。生成的證書格式是由PKCS#6（Extended-Certificate Syntax Standard）和 X.509定義的。

5.3.3. 作廢證書與CRL

    當用戶的私鑰丟失、被盜時，認證機構需要對證書進行作廢（revoke）。此外，即便私鑰安然無恙，有時候也需要作廢證書，例如用戶從公司離職導致其失去私鑰的使用權限，或者是名稱變更導致和證書中記載的內容不一致等情況。

    紙質證書只要撕毀就可以作廢了，但這裏的證書是數字信息，即便從倉庫中刪除也無法作廢，因爲用戶會保存證書的副本，但認證機構又不能人侵用戶的電腦將副本刪除。

    要作廢證書，認證機構需要製作一張證書作廢清單（Certificate Revocation List),簡稱爲CRL。

    CRL是認證機構宣佈作廢的證書一覽表，具體來說，是一張已作廢的證書序列號的清單，並由認證機構加上數字簽名。證書序列號是認證機構在頒發證書時所賦予的編號，在證書中都會記載。

    PKI用戶需要從認證機構獲取最新的CRL,並查詢自己要用於驗證簽名（或者是用於加密）的公鑰證書是否已經作廢這個步驟是非常重要的。

    假設我們手上有Bob的證書，該證書有合法的認證機構簽名，而且也在有效期內，但僅憑這些還不能說明該證書一定是有效的，還需要查詢認證機構最新的CRL，並確認該證書是否有效。一般來說，這個檢查不是由用戶自身來完成的，而是應該由處理該證書的軟件來完成，但有很多軟件並沒有及時更新CRL。

5.4. 各種各樣的PKI

    公鑰基礎設施（PKI）這個名字總會引起一些誤解，比如說“面向公衆的權威認證機構只有一個"，或者“全世界的公鑰最終都是由一個根CA來認證的"，其實這些都是不正確的。認證機構只要對公鑰進行數字簽名就可以了，因此任何人都可以成爲認證機構，實際上世界上已經有無數個認證機構了。

    國家、地方政府、醫院、圖書館等公共組織和團體可以成立認證機構來實現PKI,公司也可以出於業務需要在內部實現PKI,甚至你和你的朋友也可以以實驗爲目的來構建PKI。

    在公司內部使用的情況下，認證機構的層級可以像上一節中一樣和公司的組織層級一一對應，也可以不一一對應。例如，如果公司在東京、大阪、北海道和九州都成立了分公司，也可以採取各個分公司之間相互認證的結構。在認證機構的運營方面，可以購買用於構建PKI的軟件產品由自己公司運營，也可以使用VeriSign等外部認證服務。具體要採取怎樣的方式，取決於目的和規模，並沒有一定之規。

    密碼學探究到這 ， 基本理論基本完了， 下篇就是最常見的SSL/TLS 了，他是綜合了對稱加密、單向散列函數、消息認證碼、以及本篇的數字簽名等技術的框架，比如常見的https等的應用。
探究的過程就像懸疑劇一樣，環環相扣，保密的路上，兵來將擋，水來土掩，頗爲有趣。