PKI資訊保安知識點詳細解答包含HTTPS

1. 什麼是X.509？

X.509標準是ITU-T設計的PKI標準，他是為了解決X.500目錄中的身份鑑別和訪問控制問題設計的。

 

2. 數字證照

數字證照的意義在於回答公鑰屬於誰的問題，以幫助使用者安全地獲得對方的公開金鑰。證照中應對公鑰和公鑰私有者資訊，並由可信任的CA簽署，即CA對這些資訊進行數字簽名。一張數字證照由證照內容、簽名演算法和演算法結果組成。

數字證照的結構如下：

版本號 version

序列號 serialNumber

簽名演算法 signature

有效日期 vaildity

主體 subject

主體公鑰資訊 subjectPublicKeyInfo

頒發者唯一識別符號 issuerUniqueID

主體唯一識別符號 subjectUniqueID

擴充套件 extensions

 

3. CRL基本原理和概念

釋出證照撤銷資訊的最基本思路就是：PKI系統中的CA機構將當前被撤銷證照的標識（通常是證照序列號）集中到一個列表中，向PKI系統的所有使用者公佈。和簽發證照一樣，為了防止偽造和篡改，CA需要對這個列表進行數字簽名。

• 使用CRL驗證證照的有效性。驗證CRL簽名上的數字簽名是否正確、當前是否處於有效期。
• 構造被撤銷證照的證照序列號列表。對於不同的CRL機制，有著不同的方法來構造被撤銷證照的資訊列表。對於基本的CRL機制，從每一個單獨的CRL檔案就能夠得到完整的、當前被撤銷證照的證照序列號列表。
• 檢查證照是否已經被撤銷。檢查被撤銷證照的證照序列號列表，檢視驗證的證照序列號是否在其中。

CRL結構：

CertificateList:: = Sequence{

tbaCertList   TBSCertList,

signatureAlgorithm   AlgorithmIdentifier,

signatureValue  BIT STRING
}

其中tbaCertList又分為：

TBSCertList::=SEQUENCE{
signature             AlgorithmIdentifier,

Issuer                   Name,

thisUpdate           Time,

nextUpdate         Time OPTIONAL

revokedCertificates SEQUENCE OF SEQUENCE{

userCertificate CertificateSerialNumber,

revocationDate Time,

crlEntryExtions Extensions  optional
}

crlExtensions [0]EXPLICIT Extionsions OPTIONALS

}

其中revocationCertificates是CRL最有意義的一部分，對於每一個被撤銷的證照，CRL中給出證照序列號，和證照撤銷時間。證照撤銷時間一定早於CRL更新時間。

 

4. 數字簽名

數字簽名就是非對稱金鑰和數字摘要技術的應用。

數字簽名就是附加在數字單元上的一些資料。這種資料或變換允許資料單元的接受者用以確認資料單元的來源和資料單元的完整性並保護資料，防止被人進行偽造。

傳送方用特殊的hash演算法，由明文中產生固定長度的【摘要】，然後利用自己的私鑰對形成的摘要進行加密，這裡加密後的資料就是數字簽名。

驗證：接受方利用傳送方的公鑰解密被加密的摘要得到結果A，然後對明文也進行hash操作產生摘要B.最後,把A和B作比較。此方式既可以保證傳送方的身份正確性，又可以保證資料在傳輸過程中不會被篡改。

 

5.數字信封加密解密原理

數字信封則採用密碼技術保證了只有規定的接收人才能閱讀資訊的內容。

數字信封中採用了單鑰加密體制和公鑰密碼體制。資訊傳送者首先利用隨機產生的【對稱密碼】加密資訊(因為非對稱加密技術的速度比較慢)，再利用接收方的【公鑰】加密對稱密碼，被公鑰加密後的對稱金鑰被稱之為數字信封。在傳遞資訊時，資訊接收方要解密資訊時，必須先用自己的私鑰解密數字信封，得到對稱密碼，才能利用對稱密碼解密所得到的資訊。

數字信封既發揮了對稱加密演算法速度快、安全性好的優點，又發揮了非對稱加密演算法金鑰管理方便的優點。

 

6. 常見的加密演算法：

對稱加密演算法：DES,3DES,AES

非對稱加密演算法：RSA/ECC/SM2

摘要演算法：MD5,sha1,sha256

填充演算法：pkcs7填充。填充字串由一個位元組序列組成，每個位元組填充該位元組序列的長度。

資料： FF FF FF FF FF FF FF FF FF

PKCS7 填充： FF FF FF FF FF FF FF FF FF 07 07 07 07 07 07 07

 

7. 瞭解ASN.1編碼規則：BER、DER

基本編碼規則（BER）：對相同的資料可以有多種編碼格式，比如長位元組型，短位元組型，不定長型。

區分編碼規則（DER）：DER是BER的子集，和BER相比，它的編碼格式只有固定一種，比如boolean變數，在BER中可以是0-255中任意一個，在DER中只能是1；

 

8. 國際標準PKCS系列(如PKCS#7,PKCS#10,PKCS#12)

PKCS#7：密碼訊息語法標準。PKCS#7為使用密碼演算法的資料規定了通用語法，比如數字簽名和數字信封。PKCS#7提供了許多格式選項，包括未加密或簽名的格式化訊息、已封裝（加密）訊息、已簽名訊息和既經過簽名又經過加密的訊息

signedData

SignedData ::= SEQUENCE {

     version Version,

     digestAlgorithms DigestAlgorithmIdentifiers,

     contentInfo ContentInfo,

     certificates

        [0] IMPLICIT ExtendedCertificatesAndCertificates

          OPTIONAL,

     crls

       [1] IMPLICIT CertificateRevocationLists OPTIONAL,

     signerInfos SignerInfos }

signerinfo type

SignerInfo ::= SEQUENCE {

     version Version,

     issuerAndSerialNumber IssuerAndSerialNumber,

     digestAlgorithm DigestAlgorithmIdentifier,

     authenticatedAttributes

       [0] IMPLICIT Attributes OPTIONAL,

     digestEncryptionAlgorithm

       DigestEncryptionAlgorithmIdentifier,

     encryptedDigest EncryptedDigest,

     unauthenticatedAttributes

       [1] IMPLICIT Attributes OPTIONAL }

 

 

EnvelopedData type

EnvelopedData ::= SEQUENCE {

     version Version,

     recipientInfos RecipientInfos,

     encryptedContentInfo EncryptedContentInfo }

 

   RecipientInfos ::= SET OF RecipientInfo

 

   EncryptedContentInfo ::= SEQUENCE {

     contentType ContentType,

     contentEncryptionAlgorithm

       ContentEncryptionAlgorithmIdentifier,

     encryptedContent

       [0] IMPLICIT EncryptedContent OPTIONAL }

 

PKCS#10：證照請求語法標準。PKCS#10定義了證照請求的語法。證照請求包含了一個唯一識別名、公鑰和可選的一組屬性，它們一起被請求證照的實體簽名（證照管理協議中的PKIX證照請求訊息就是一個PKCS#10）。

CertificationRequest ::= SEQUENCE {

        certificationRequestInfo CertificationRequestInfo,

        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},

        signature          BIT STRING

   }

 

   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {

        algorithm          ALGORITHM.&id({IOSet}),

        parameters         ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL

   }

 

   SignatureAlgorithms ALGORITHM ::= {

        … — add any locally defined algorithms here — }

 

PKCS#12：個人資訊交換語法標準。PKCS#12定義了個人身份資訊（包括私鑰、證照、各種祕密和擴充套件欄位）的格式。PKCS#12有助於傳輸證照及對應的私鑰，於是使用者可以在不同裝置間移動他們的個人身份資訊。

 

9.什麼是RFC5280？

RFC5280是X.509公鑰基礎設施證照和證照撤銷列表的的配置檔案。

 

 

10. 什麼是LDAP

LDAP是Lightweight Directory Access Protocol的縮寫，中文名是輕量目錄訪問協議。

首先來談一下目錄服務，目錄服務就是按照樹狀儲存資訊的模式。 LDAP的結構用樹來表示，可以很快的查詢結果，但是寫入資料很慢。LDAP是一種開放Internet標準，LDAP協議是跨平臺的 的Interent協議 它是基於X.500標準的， 與X.500不同，LDAP支援TCP/IP(即可以分散式部署)。

11.什麼是HTTPS以及SSL？

超文字傳輸協議HTTP協議被用於在Web瀏覽器和網站伺服器之間傳遞資訊。HTTP協議以明文方式傳送內容，不提供任何方式的資料加密，如果攻擊者擷取了Web瀏覽器和網站伺服器之間的傳輸報文，就可以直接讀懂其中的資訊，因此HTTP協議不適合傳輸一些敏感資訊，比如信用卡號、密碼等。

為了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文字傳輸協議HTTPS。為了資料傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證照來驗證伺服器的身份，併為瀏覽器和伺服器之間的通訊加密。

HTTPS和HTTP的區別主要為以下四點：

一、https協議需要到ca申請證照，一般免費證照很少，需要交費。

二、http是超文字傳輸協議，資訊是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。

三、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。

四、http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。

總的來說HTTPS是HTTP基於SSL（或者TLS）的一個資料傳輸協議。

SSL：

協議介紹：

1.SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。

2.SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。

 

SSL協議提供的服務主要有：

1.認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器。

2.加密資料以防止資料被中途竊取

3.維護資料的完整性，確保資料在傳輸過程中不被改變。

 

SSL握手過程：

①　客戶端的瀏覽器向伺服器傳送客戶端SSL協議的版本號，加密演算法的種類，產生的隨機數，以及其他伺服器和客戶端通訊所需要的各種資訊。

②　伺服器向客戶端傳送SSL協議的版本號，加密演算法的種類，隨機數以及其他資訊，同時伺服器還將自己的證照傳送給客戶端。

③　客戶端利用伺服器傳過來的資訊驗證伺服器的合法性，伺服器的合法性包括：證照是否過期，發行伺服器證照的CA是否可靠，發行者證照的公鑰能否正確解開伺服器證照的“發行者數字簽名”，伺服器證照上域名是否和伺服器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開，如果合法性驗證通過，將繼續進行第四步。

④　客戶端隨機產生一個用於後面通訊的對稱密碼，然後用伺服器的公鑰對其加密，然後將加密後的“預主密碼”傳遞給伺服器。

⑤　如果伺服器要求客戶的身份認證（在握手過程中可選），使用者可以生成一個隨機數然後對其進行數字簽名，將這個含有簽名的隨機數和客戶自己的證照以及加密過的“預主密碼”一起傳給伺服器。

⑥　如果伺服器要求客戶的身份認證，伺服器必須檢查客戶證照和簽名隨機數的合法性，具體的合法驗證過程包括：證照使用日期是否有有效，為客戶提供證照的CA是否可靠，發行CA的公鑰能夠正確解開客戶證照發行CA的數字簽名，檢查客戶證照是否被廢除。如果檢驗沒有通過，通訊立刻中斷，如果驗證通過，伺服器將用自己的私鑰解開加密的預主密碼，然後執行一系列的步驟來產生通訊密碼（客戶端也將通過同樣的方法產生相同的主通訊密碼）。

⑦　伺服器和客戶端用相同的主密碼即通訊密碼，一個對稱金鑰用於SSL協議的安全資料通訊的加解密通訊。同時在SSL通訊過程中還要完成資料通訊的完整性，防止資料通訊中的任何變化。

⑧　客戶端向服務端發出訊息，指明後面的資料通訊將使用步驟七中的主密碼為對稱金鑰，同時通知伺服器客戶端的握手過程結束。

⑨　伺服器向客戶端發出訊息，指明後面的資料通訊將使用步驟七中主密碼為對稱金鑰，同時通知客戶端伺服器的握手過程結束。

⑩　SSL的握手部分結束，SSL安全通道的資料通訊開始，客戶和伺服器開始使用相同的對稱金鑰進行資料通訊，同時校驗資料的完整性。

 

12.什麼是KeyStore?

Keytool是一個Java資料證照的管理工具 ,Keytool將金鑰（key）和證照（certificates）存在一個稱為keystore的檔案中。

在keystore裡，包含兩種資料：

1. 金鑰實體（Key entity）——金鑰（secret key）又或者是私鑰和配對公鑰（採用非對稱加密）

2. 可信任的證照實體（trusted certificate entries）——只包含公鑰

ailas(別名)每個keystore都關聯這一個獨一無二的alias，這個alias通常不區分大小寫。

 

13.證照發放流程是什麼？

1. 使用者在RA 註冊資訊，RA稽核通過後，簽發證照請求。
2. RA把使用者資訊傳到CA，CA從KMC中取金鑰對（一般金鑰對由加密機生成）
3. CA把使用者資訊和公約製成使用者證照，並對證照籤名。CA把自己的使用者證照和使用者的私鑰通過SSL通路傳遞給RA。
4. 使用者從RA下載證照。

 

14.常見的證照擴充有哪些：

參見RFC3280,常見的擴充有證照策略，證照用途，是否為CA.

 

15.公鑰基礎設施的整體架構。

主要是證照認證中心，證照持有者，依賴方。

輔助元件還包括序號產生器構RA,資料庫系統、金鑰管理系統KM，OCSP伺服器。

 

16.金鑰不落地原理：

ca向瀏覽器發加密證照和私鑰的時候，私鑰不能明文傳輸，需要用簽名證照的公鑰保護，私鑰在km中儲存的時候也不能明文，要用km的主金鑰保護所以加密機有個介面，把加密機主金鑰，保護公鑰就是簽名證照公鑰，和主金鑰加密的私鑰明文一起傳到加密機中，加密機用主金鑰解密然後用保護公鑰加密再傳出來

 

17.什麼是雙證照體系，與單證照的不同？

雙證照分為簽名證照和加密證照。用於簽名的私鑰應該有訂戶自己保管。加密金鑰由KMC共同保管。同一使用者的兩個證照除了證照序列號、公鑰資訊、KEY Usage擴充、private key usage period擴充、CA簽名簽名結果不同之外，其他都是相同的。

個人部落格網站 http://www.janti.cn