0.PKI理論基礎
網絡通訊安全威脅
密碼技術
| 密碼技術 |
圖示 |
解決問題 |
|---|---|---|
| 對稱加密（舉例：AES） |
|
保證了傳輸信息的機密性
存在問題： 需要事先將密鑰進行共享，密鑰的配送問題 |
| 非對稱加密（舉例：RSA） |
|
解決了傳輸信息的機密性
與對稱加密相比：效率較低 |
| 組合加密技術 |
|
非對稱加密用於對稱加密的密鑰協商，解決了密鑰配送問題。 對稱加密用於通訊。
|
| 摘要算法（哈希算法）（舉例：md5，sha1，sha2） |
|
保證了信息的完整性 |
| 數字簽名（摘要算法+非對稱加密） |
|
解決了否認的問題
|
信息安全威脅解決方法
| 信息安全所面臨的威脅 |
受威脅的特性 |
如何解決？對應的密碼技術 |
|---|---|---|
| 竊聽（秘密泄露） |
機密性 |
對稱加密、非對稱加密 |
| 篡改（信息被修改） |
完整性 |
摘要算法---------->數字簽名（非對稱加密+哈希算法） |
| 偽裝（偽裝成真正的發送者）
身份證明： 如何告訴別人你是誰？ 如何向別人證明，你確實是此人？ |
鑒別與授權（身份認證） |
數字證書 |
| 否認（事后稱自己沒有做） |
不可否認性 |
數字簽名--------->數字證書
數字簽名證明信息已經被發送或接收。
|
數字證書
公鑰算法的最大問題：如何確認獲得的對方的公鑰的身份？A與B通信，A如何知道如何知道這個公鑰確實是Alice的?
中間人攻擊
如何理解證書？
通過第三方可信機構(CA)簽名，將用戶身份信息與其公鑰進行綁定。
1.什么是PKI？
PKI是Public Key Infrastructure（公鑰基礎設施）的縮寫，是一種普遍適用的網絡安全基礎設施。
PKI（Public Key Infrastructure）是硬件、軟件、人員、策略和操作規程的總和，它們要完成創建、管理、保存、發放和廢止數字證書的功能。數字證書是PKI中最基本的元素。
PKI是Public Key Infrastructure的縮寫，其主要功能是綁定證書持有者的身份和相關的密鑰對（通過為公鑰及相關的用戶身份信息簽發數字證書），為用戶提供方便的證書申請、證書作廢、證書獲取、證書狀態查詢的途徑，並利用數字證書及相關的各種服務（證書發布，黑名單發布，時間戳服務等）實現通信中各實體的身份認證、完整性、抗抵賴性和保密性。
PKI基於公鑰加密算法來保證網絡通訊安全。
字面理解，為什么叫公鑰基礎設施（Public Key Infrastructure）？
公鑰：基於公鑰加密算法保證網絡通訊安全
基礎設施：可以基於PKI解決網絡通信中的4大威脅，身份標識和認證、保密性、數據完整性和不可否認。
2.PKI系統的組成
2.1 PKI系統組成
一個PKI系統由以下幾個部分組成：
| 角色 |
描述 |
|---|---|
| 證書簽發系統（Certification Authorities) CA |
|
| 證書注冊系統（Registration Authorities) RA |
|
| 證書存儲系統（Repositories） |
存儲證書請求、已簽發的證書、已吊銷的證書等 |
| 密鑰歸檔服務器（Key Archival Server） |
存儲證書對應的私鑰，以免私鑰丟失時進行恢復 （如果證書的私鑰用於加密的話，需要對其進行歸檔備份） |
2.2 PKI系統如何工作
證書申請
1）新用戶發起證書申請，發起注冊信息給RA
2）RA系統審核用戶身份，審核通過的注冊請求發送給CA，CA為用戶簽發證書下載憑證
3）RA系統將證書下載憑證發送給用戶，用戶提交證書申請請求
4）證書下載到用戶本地，同時，證書發布到證書倉庫
應用程序校驗證書：
-
獲取用戶的身份信息
-
進行證書吊銷狀態檢查（CRL、OCSP）
-
檢查證書的有效期
-
檢驗數字證書
3.CA層次結構
3.1 單層
Root CA和負責給實體頒發證書的CA是同一個CA。通常為了安全性考慮，這兩個角色是分開的。
3.2 兩層
兩層結構可以滿足大部分公司的需求了。
Root CA是離線的，負責頒發證書的CA是在線的。
相較於單層的優點：
1）安全性提升
Root CA和負責頒發證書的CA是分開的，更重要的是Root CA是離線的，所以CA的私鑰可以更好地被保護。
2）靈活性和可擴展性提升
頒發證書的CA可以有多個，多個CA可以在不同的地理位置。
3.3 三層
相較於2級CA，在RootCA和頒發證書的CA間又多了一層。
多了這層有啥原因？
這層CA可以作為Policy CA。Policy CA可以限制頒發證書的CA可以頒發哪種證書。
從管理的角度看，Policy CA可以被用作管理邊界，就是說你只能簽發指定的證書，在頒發證書前執行指定級別的驗證。
4. 信任模型——證書鏈
證書類型
根證書：RootCA的證書，是自簽證書，即證書的申請者和簽發者信息是一樣的。
中間CA證書：二級CA的證書。
實體證書：最終實體的證書。
信任模型——證書鏈
如何進行有效性驗證？僅僅擁有實體證書是無法進行有效性驗證的，需要驗證證書鏈。
安全問題——保證CA的私鑰安全
CA，尤其Root CA對整個系統來說至關重要，如果Root CA的私鑰被泄露，那么就可以簽發任意域名的虛假證書。
另外，如果Root CA被吊銷掉，所用使用這個CA簽發的證書的網站都會無法訪問。
現在仍然還有很多CA直接使用他們的根證書直接簽發最終實體證書，這其實是非常危險的。Baseline Requirements限制所有的根證書密鑰只能由人手動執行命令(自動化是不允3.4 證書鏈 59許的)，也就是說根證書密鑰必須離線保存。
雖然還有很多依舊在使用的舊系統有這個漏洞，但是直接由根證書簽發最終實體證書是不允許的。
5.X.509公鑰證書
5.1 X.509公鑰證書格式
X.509公鑰證書共有3個版本（V1，V2，V3），高版本的會含有低版本的字段。
3.1.1證書字段（v1+v2）
V1基本字段信息
-
版本（Version）
證書一共有3個版本號，分別用0、1、2編碼表示版本1、版本2、版本3。
版本1只支持簡單的字段，版本2增加了兩個標識符，版本3增加了擴展功能。現在大部分證書都采用版本3格式。
-
序列號（Serial Number）
證書的序列號，用於唯一標識證書，為唯一的正整數。
-
簽名算法（Signature Algorithm Identifier）
證書簽名所使用的算法
-
頒發者（Issuer Name）
證書的頒發者，比如包含了國家、組織和組織單位三個部分。
-
有效期（Validity Period）
證書有效的開始日期和結束日期，在這段時間內證書是有效的。
-
使用者（Subject Name）
指明證書的使用者，和公鑰一起用於證書的簽發。
在自簽名證書里，使用者和頒發者是一樣的。
最開始的時候，使用者字段通常為服務器主機名，但是為證書匹配多個主機名就很麻煩。
如今，使用者字段已經被廢棄，轉而使用使用者可選名稱擴展。
-
公鑰信息（Public Key Information）
公鑰相關信息，主要是算法ID，可選參數和公鑰本身。
V2中新加的字段
-
頒發者唯一ID（Issuer unique ID）
-
使用者唯一ID（Subject unique ID）
3.1.2 擴展字段（v3）
為了讓原本死板的證書格式變得更加靈活，版本3引入了證書擴展。
| Extension |
Description |
|---|---|
| Authority Key Identifier(2.5.29.19)
|
Identifies the certification authority (CA) public key that corresponds to the CA private key used to sign the certificate. 這個擴展的內容是簽發此證書的CA的私鑰對應的公鑰的唯一標識符，通常用於在構建證書鏈時找到頒發者的證書。 |
| Basic Constraints(2.5.29.35) |
Specifies whether the entity can be used as a CA and, if so, the number of subordinate CAs that can exist beneath it in the certificate chain. 基礎約束擴展用來表明證書是否為CA證書，同時通過路徑長度(path length)約束字段，來限制二級CA證書路徑的深度(例如限制CA證書是否可以簽發更深一層的CA證書以及 |
| Certificate Policies(2.5.29.32) |
Specifies the policies under which the certificate has been issued and the purposes for which it can be used. 該擴展包含了一個或多個策略，每個策略都包括一個OID和可選限定符(qualifier)。限定符一般包括一個URI，從這個URI可以獲得完整的策略說明。Baseline Requirements要求每一張最終實體證書需要包括至少一條策略信息，來表明該證書是在何種條款下簽發的。另外這個擴展還能表明證書的驗證類型。 |
| CRL Distribution Points(2.5.29.31) CRL分發點 |
Contains the URI of the base certificate revocation list (CRL). 該擴展用來確定證書吊銷列表(certificate revocation list，CRL)的LDAP或者HTTP URI地址。按照Baseline Requirements，每一張證書都至少需要包括CRL或者OCSP吊銷信息。 |
| Enhanced Key Usage(2.5.29.46) |
Specifies the manner in which the public key contained in the certificate can be used. 為了更加靈活地支持和限制公鑰的使用場景，該擴展可以通過OID支持更多的場景。例如最終實體證書一般都擁有id-kp-serverAuth和id-kp-clientAuth兩個OID，代碼簽名證書 |
| Issuer Alternative Name(2.5.29.8) 簽發者可選名稱 |
Specifies one or more alternative name forms for the issuer of the certificate request. |
| Key Usage(2.5.29.15) 密鑰用法 |
Specifies restrictions on the operations that can be performed by the public key contained in the certificate. 該擴展定義了證書中密鑰可以使用的場景，這些場景已經定義好了，可以通過設置來讓證書支持某個場景。例如CA證書一般都設置了證書簽名者(certificate signer)和CRL簽 |
| Name Constraints(2.5.29.30) |
Specifies the namespace within which all subject names in a certificate hierarchy must be located. The extension is used only in a CA certificate. 名稱約束擴展可以限制CA簽發證書的對象，這樣命名空間就在可控范圍內。這個功能非常有用，例如，它允許一個組織可以擁有一個二級CA，而這個CA只能簽發這個公司所擁有的那些域名下的證書。有了這個限制，這類CA就不會影響整個生態系統了(例如，CA不能簽發任意網站的證書)。RFC 5280要求將這個擴展設置為關鍵擴展，但是實際情況是，大部分CA都將其設置為非關鍵擴展，而Baseline Requirements也明確表示允許這么處理。主要原因是有一些產品無法解析名稱限制這個擴展，如果標記為關鍵擴展，就會導致這些產品拒絕此類證書。 |
| Policy Constraints(2.5.29.36) 策略限制
|
Constrains path validation by prohibiting policy mapping or by requiring that each certificate in the hierarchy contain an acceptable policy identifier. The extension is used only in a CA certificate. |
| Policy Mappings(2.5.29.33) 策略映射 |
Specifies the policies in a subordinate CA that correspond to policies in the issuing CA. |
| Private Key Usage Period(2.5.29.16) |
Specifies a different validity period for the private key than for the certificate with which the private key is associated. |
| Subject Alternative Name(2.5.29.17) |
Specifies one or more alternative name forms for the subject of the certificate request. Example alternative forms include email addresses, DNS names, IP addresses, and URIs. 原本使用者證書字段(更准確地說是其中的通用名部分)是用來將身份信息和公鑰綁定在一起的。而在實際使用的時候發現使用者字段不夠靈活，只能支持與一個主機名進行綁定，無法同時處理多個身份信息。使用者可選名稱擴展就是為了替換使用者字段，它支持通過DNS名稱、IP地址和URI來將多個身份綁定在一起。 |
| Subject Directory Attributes(2.5.29.9)
|
Conveys identification attributes such as the nationality of the certificate subject. The extension value is a sequence of OID-value pairs. |
| Subject Key Identifier(2.5.29.14) 使用者密鑰標識符
|
Differentiates between multiple public keys held by the certificate subject. The extension value is typically a SHA-1 hash of the key. 該擴展包含了唯一的值，可以用來識別包含特別公鑰的證書，一般建議使用公鑰本身來建立這個標識符(例如通過散列)。所有的CA證書都必須包含這個擴展，並且它的值要與CA所簽發出來的證書上的授權密鑰標識符的值一樣。 |
| Authority Information Access 頒發機構信息訪問 |
（OCSP URL）頒發機構信息訪問擴展表明如何訪問簽發CA提供的額外信息和服務，其中之一就是OCSP響應程序的HTTP URI地址。信賴方可以使用這個服務來實時檢測證書的吊銷信息。 （CA證書URL）另外還有一些證書包含了簽發CA的URI地址，有了這個地址，即便服務器返回的證書鏈中缺少了簽發CA的證書，客戶端也可以通過下載簽發CA重新構建證書鏈。 |
3.2 證書生命周期
證書申請、生成、存儲、發布
申請階段：終端實體注冊——》密鑰對產生——》證書創建和密鑰/證書分發
頒發階段：證書檢索，證書驗證
取消階段：證書過期，，證書吊銷，證書恢復
證書吊銷
證書具有一個指定的壽命，但 CA 可通過稱為證書吊銷的過程來縮短這一壽命。
可將下列情況指定為吊銷證書的理由：
-
泄露密鑰；
-
泄露 CA；
-
從屬關系改變；
-
被取代；
-
業務終止；
| 說明 |
優缺點 |
|
|---|---|---|
| CRL |
CRL 證書吊銷列表 (Certificate Revocation List ，簡稱： CRL) 是 PKI 系統中的一個結構化數據文件。 該文件包含了證書頒發機構 (CA) 已經吊銷的證書的序列號及其吊銷日期。 CRL 文件中還包含證書頒發機構信息、吊銷列表失效時間和下一次更新時間，以及采用的簽名算法等。 證書吊銷列表最短的有效期為一個小時，一般為 1 天，甚至一個月不等，由各個證書頒發機構在設置其證書頒發系統時設置。
CDP 證書吊銷列表分發點 (CRL Distribution Point ，簡稱 CDP) 是含在數字證書中的一個可以共各種應用軟件自動下載（下載到本地）的最新的 CRL 的位置信息。 一個 CDP 通常出現在數字證書的 詳細信息 選項卡的 CRL 分發點 域，一般會列出多個使用不同的訪問方法，以確保如 Web 瀏覽器和 Web 服務器程序始終可以獲取最新的 CRL 。 CDP 一般是一個可以訪問 http 網址。 |
優點： 效率高（因為客戶端將CRL下載到本地，客戶端本地進行比對）
缺點： 1）不能及時反映證書的實際狀態 2）隨着下發證書增多，CRL會越來越大（解決方法：增量CRL） |
| OSCP |
Online Certificate Status Protocol, 證書狀態在線查詢協議， 是用於實時查詢數字證書在某一時間是否有效的標准。
CRL的缺點：不能實時 上面已經提到，一般 CA 都只是 每隔一定時間 ( 幾天或幾個月 ) 才發布新的吊銷列表，可以看出： CRL 是 不能及時反映證書的實際狀態的。
OCSP實時在線查詢 而 OCSP 就能滿足實時在線查詢證書狀態的要求。它為電子商務網站提供了一種實時檢驗數字證書有效性的途徑，比下載和處理 CRL 的傳統方式更快、更方便和更具獨立性。請求者發送查詢請求， OCSP 服務器會返回證書可能的三個狀態：正常、吊銷和未知。
OCSP 服務由獨立的 OCSP 服務器來提供服務。 OCSP 也是一個可以訪問的 http 網站。 |
能夠及時反映證書實際狀態 |
證書校驗
1）證書完整性校驗
使用CA的RSA公鑰解密驗證證書上的私鑰簽名是否合法，如果簽名無效，則可認定證書被修改，直接報錯。
2）證書有效性校驗
CA在頒發證書時，都為每個證書設定了有效期，包括開始時間與結束時間。系統當前時間不在證書起止時間的話，都認為證書是無效的。
3）證書吊銷狀態監測
證書在有效期之內需要丟了怎么辦？需要吊銷證書了，那么這里就多了一個證書吊銷狀態的檢測。
用戶將需要吊銷的證書通知到CA服務商，CA服務商通知瀏覽器該證書的撤銷狀態。來看一個證書吊銷后的瀏覽器提醒：
4）驗證發行者
HTTPS數字證書的使用分兩個角色：
-
證書發行方issuer，有簽名的私鑰。
-
證書申請方subject，使用證書公鑰進行身份驗證的用戶（一般瀏覽器）
-
瀏覽器檢查證書的發行者字段與證書路徑中上級證書的subject字段相同。
-
為了增加安全性，PKI在實現時，多數都驗證了發行方的密鑰、簽名等信息是否跟當前證書的密鑰相同。但對於信任鏈來說，根證書自己簽發的，也就是說它們的issuer和subject是一樣的。
根據CA的DN，得到CA證書，得到CA公鑰，利用CA公鑰校驗簽名；循環，直到校驗到根證書，簽發者和申請者是一樣的。
3.3 證書示例
百度的證書
| Root CA證書（自簽證書） |
二級CA證書 |
實體證書 |
|---|---|---|
|
|
|
|
6.PKI應用
web安全
SSL/TLS
安全電子郵件
保證電子郵件傳輸安全
SET
SET協議(Secure Electronic Transaction，安全電子交易)是由VISA和Master Card兩大信用卡公司聯合推出的規范它采用公鑰密碼體制和X.509數字證書標准，主要應用於保障網上購物信息的安全性。
VPN
利用IPSec等保證私有性
IPSec
IP層安全
7.PKI安全性
CA私鑰保護
對於PKI來說，最重要的就是對CA的私鑰的保護。
CA私鑰可以
1.頒發證書時的簽名
2.發布CRL時進行簽名
如何保護CA私鑰？
最安全的是HSM。
角色分離（管理上）
可能管理員可以執行CA的全部功能
但是從對安全性有更高要求的環境來說，需要對CA的訪問有更細粒度的控制。
-
CA or PKI Administrator ：管理CA
-
Certificate Manager ：頒發和撤銷證書
-
Enrollment Agent：代替用戶注冊用書 -
Key Recovery Manager：當證書的私鑰丟失了，進行恢復
其他輔助角色：
Backup Operator：負責備份CA，用於CA故障時恢復數據
Auditor：reivew審計日志，保證security policy沒有被違反
安全策略（運營上）
Security policy包括CP和CPS
很多公司，尤其是頒發證書的第三方機構，有公開的Certificate Policy 和Certification Practice Statement。
Certificate Policy : 在簽發證書時使用什么方法確定與實體建立聯系（比如使用什么加密算法）
Certification Practice Statement：從安全的角度說明PKI操作。
一些由商業證書發放機構（CCA）或者可信的第三方操作的PKI系統需要CPS。這是一個包含如何在實踐中增強和支持安全策略的一些操作過程的詳細文檔。它包括CA是如何建立和運作的，證書是如何發行、接收和廢除的，密鑰是如何產生、注冊的，以及密鑰是如何存儲的，用戶是如何得到它的等等。
參考資料
https://wenku.baidu.com/view/74ff14e66137ee06eef91815.html?from=search PKI技術詳解
https://wenku.baidu.com/view/ac0c6aa5f524ccbff121841d.html?sxts=1577168241761 PKI技術及其應用
https://www.anquanke.com/post/id/183339#h2-10
https://www.cfca.com.cn/20150811/101230759.html 證書的有效性管理和驗證—CRL及OCSP的異曲同工之妙