區塊鏈-密碼學與安全技術
密碼學與安全技術
工程領域從來沒有黑科技；密碼學不僅是工程。
密碼學相關的安全技術在整個資訊科技領域的重要地位無需多言。如果沒有現代密碼學和資訊保安的研究成果，人類社會根本無法進入資訊時代。區塊鏈技術大量依賴了密碼學和安全技術的研究成果。
實際上，密碼學和安全領域所涉及的知識體系十分繁雜，本章將介紹密碼學領域中跟區塊鏈相關的一些基礎知識，包括Hash演算法與數字摘要、加密演算法、數字簽名、數字證書、PKI體系、Merkle樹、布隆過濾器、同態加密等。讀者通過閱讀本章可以瞭解如何使用這些技術保護資訊的機密性、完整性、認證性和不可抵賴性。
一、Hash演算法與數字摘要
1.1、Hash定義
Hash（雜湊或雜湊）演算法是非常基礎也非常重要的計算機演算法，它能將任意長度的二進位制明文串對映為較短的（通常是固定長度的）二進位制串（Hash值），並且不同的明文很難對映為相同的Hash值。
例如計算一段話“hello blockchain world，this is [email protected]”的SHA-256 Hash值。
$ echo "hello blockchain world, this is [email protected]"|shasum -a 256
db8305d71a9f2f90a3e118a9b49a4c381d2b80cf7bcef81930f30ab1832a3c90 這意味著對於某個檔案，無需檢視其內容，只要其SHA-256 Hash計算後結果同樣為db8305d71a9f2f90a3e118a9b49a4c381d2b80cf7bcef81930f30ab1832a3c90，則說明檔案內容極大概率上就是“hello blockchain world，this is [email protected]”。
Hash值在應用中又常被稱為指紋（fingerprint）或摘要（digest）。Hash演算法的核心思想也經常被應用到基於內容的編址或命名演算法中。
一個優秀的Hash演算法將能實現如下功能：
正向快速：給定明文和Hash演算法，在有限時間和有限資源內能計算得到Hash值；
逆向困難：給定（若干）Hash值，在有限時間內很難（基本不可能）逆推出明文；
輸入敏感：原始輸入資訊發生任何改變，新產生的Hash值都應該出現很大不同；
衝突避免：很難找到兩段內容不同的明文，使得它們的Hash值一致（發生碰撞）。
衝突避免有時候又稱為“抗碰撞性”，分為“弱抗碰撞性”和“強抗碰撞性”。如果給定明文前提下，無法找到與之碰撞的其他明文，則演算法具有“弱抗碰撞性”；如果無法找到任意兩個發生Hash碰撞的明文，則稱演算法具有“強抗碰撞性”。
很多場景下，也往往要求演算法對於任意長的輸入內容，可以輸出定長的Hash值結果。
1.2、常見演算法
目前常見的Hash演算法包括MD5和SHA系列演算法。
MD4（RFC 1320）是MIT的Ronald L.Rivest在1990年設計的，MD是Message Digest的縮寫。其輸出為128位。MD4已被證明不夠安全。
MD5（RFC 1321）是Rivest於1991年對MD4的改進版本。它對輸入仍以512位進行分組，其輸出是128位。MD5比MD4更加安全，但過程更加複雜，計算速度要慢一點。MD5已被證明不具備“強抗碰撞性”。
SHA（Secure Hash Algorithm）並非一個演算法，而是一個Hash函式族。NIST（National Institute of Standards and Technology）於1993年釋出其首個實現。目前知名的SHA-1演算法在1995年面世，它的輸出為長度160位的Hash值，抗窮舉性更好。SHA-1設計時模仿了MD4演算法，採用了類似原理。SHA-1已被證明不具備“強抗碰撞性”。
為了提高安全性，NIST還設計出了SHA-224、SHA-256、SHA-384和SHA-512演算法（統稱為SHA-2），跟SHA-1演算法原理類似。SHA-3相關演算法也已被提出。
目前，MD5和SHA1已經被破解，一般推薦至少使用SHA2-256或更安全的演算法。
提示：MD5是一個經典的Hash演算法，和SHA-1演算法一起都被認為安全性已不足應用於商業場景。
1.3、效能
Hash演算法一般都是計算敏感型的。意味著計算資源是瓶頸，主頻越高的CPU執行Hash演算法的速度也越快。因此可以通過硬體加速來提升Hash計算的吞吐量。例如採用FPGA來計算MD5值，可以輕易達到數十Gbps的吞吐量。
也有一些Hash演算法不是計算敏感型的。例如scrypt演算法，計算過程需要大量的記憶體資源，節點不能通過簡單地增加更多CPU來獲得Hash效能的提升。這樣的Hash演算法經常用在避免算力攻擊的場景。
1.4、數字摘要
顧名思義，數字摘要是對數字內容進行Hash運算，獲取唯一的摘要值來指代原始完整的數字內容。數字摘要是Hash演算法最重要的一個用途。利用Hash函式的抗碰撞性特點，數字摘要可以解決確保內容未被篡改過的問題。
細心的讀者可能會注意到，從網站下載軟體或檔案時，有時會提供一個相應的數字摘要值。使用者下載原始檔案後可以在本地自行計算摘要值，並與提供的摘要值進行比對，可檢查檔案內容是否被篡改過。
1.5、Hash攻擊與防護
Hash演算法並不是一種加密演算法，不能用於對資訊的保護。但Hash演算法常用於對口令的儲存上。例如使用者登入網站需要通過使用者名稱和密碼來進行驗證。如果網站後臺直接儲存使用者的口令明文，一旦資料庫發生洩露後果不堪設想。大量使用者傾向於在多個網站選用相同或關聯的口令。
利用Hash的特性，後臺可以僅儲存口令的Hash值，這樣每次比對Hash值一致，則說明輸入的口令正確。即便資料庫洩露了，也無法從Hash值還原回口令，只有進行窮舉測試。
然而，由於有時使用者設定口令的強度不夠，只是一些常見的簡單字串，如password、123456等。有人專門蒐集了這些常見口令，計算對應的Hash值，製作成字典。這樣通過Hash值可以快速反查到原始口令。這一型別以空間換時間的攻擊方法包括字典攻擊和彩虹表攻擊（只儲存一條Hash鏈的首尾值，相對字典攻擊可以節省儲存空間）等。
為了防範這一類攻擊，一般採用加鹽（salt）的方法。儲存的不是口令明文的Hash值，而是口令明文再加上一段隨機字串（即“鹽”）之後的Hash值。Hash結果和“鹽”分別存放在不同的地方，這樣只要不是兩者同時洩露，攻擊者就很難破解了。
二、加密演算法
加解密演算法是密碼學的核心技術，從設計理念上可以分為兩大基本型別，如表5-1所示。
表5-1 加解密演算法的型別
2.1、加解密系統基本組成
現代加解密系統的典型元件一般包括：加解密演算法、加密金鑰、解密金鑰。其中，加解密演算法自身是固定不變的，並且一般是公開可見的；金鑰則是最關鍵的資訊，需要安全地儲存起來，甚至通過特殊硬體進行保護。一般來說，對同一種演算法，金鑰需要按照特定演算法每次加密前隨機生成，長度越長，則加密強度越大。加解密的基本過程如圖5-1所示。
圖5-1 加解密的基本過程
加密過程中，通過加密演算法和加密金鑰，對明文進行加密，獲得密文。
解密過程中，通過解密演算法和解密金鑰，對密文進行解密，獲得明文。
根據加解密過程中所使用的金鑰是否相同，演算法可以分為對稱加密（symmetric cryptography，又稱公共金鑰加密，common-key cryptography）和非對稱加密（asymmetric cryptography，又稱公鑰加密，public-key cryptography）。兩種模式適用於不同的需求，恰好形成互補。某些時候可以組合使用，形成混合加密機制。
並非所有加密演算法的安全性都可以從數學上得到證明。公認的高強度的加密演算法和實現往往經過長時間各方面充分實踐論證後，才被大家所認可，但也不代表其絕對不存在漏洞。因此，自行設計和發明未經過大規模驗證的加密演算法是一種不太明智的行為。即便不公開演算法加密過程，也很容易被攻破，無法在安全性上得到保障。
實際上，密碼學實現的安全往往是通過演算法所依賴的數學問題來提供，而並非通過對演算法的實現過程進行保密。
2.2、對稱加密演算法
對稱加密演算法，顧名思義，加密和解密過程的金鑰是相同的。該類演算法優點是加解密效率（速度快，空間佔用小）和加密強度都很高。缺點是參與方都需要提前持有金鑰，一旦有人洩露則安全性被破壞；另外如何在不安全通道中提前分發金鑰也是個問題，需要藉助Diffie–Hellman協議或非對稱加密方式來實現。
對稱密碼從實現原理上可以分為兩種：分組密碼和序列密碼。前者將明文切分為定長資料塊作為基本加密單位，應用最為廣泛。後者則每次只對一個位元組或字元進行加密處理，且密碼不斷變化，只用在一些特定領域，如數字媒介的加密等。
分組對稱加密代表演算法包括DES、3DES、AES、IDEA等：
DES（Data Encryption Standard）：經典的分組加密演算法，1977年由美國聯邦資訊處理標準（FIPS）採用FIPS-46-3，將64位明文加密為64位的密文，其金鑰長度為64位（包含8位校驗位）。現在已經很容易被暴力破解；詳見http://blog.csdn.net/zyhlwzy/article/details/77948137
3DES：三重DES操作：加密→解密→加密，處理過程和加密強度優於DES，但現在也被認為不夠安全；
AES（Advanced Encryption Standard）：由美國國家標準研究所（NIST）採用，取代DES成為對稱加密實現的標準，1997～2000年NIST從15個候選演算法中評選Rijndael演算法（由比利時密碼學家Joan Daemon和Vincent Rijmen發明）作為AES，標準為FIPS-197。AES也是分組演算法，分組長度為128、192、256位三種。AES的優勢在於處理速度快，整個過程可以用數學描述，目前尚未有有效的破解手段；詳見http://blog.csdn.net/zyhlwzy/article/details/77948165
IDEA（International Data Encryption Algorithm）：1991年由密碼學家James Massey與來學嘉聯合提出。設計類似於3DES，金鑰長度增加到128位，具有更好的加密強度。
序列密碼，又稱流密碼。1949年，Claude Elwood Shannon（資訊理論創始人）首次證明，要實現絕對安全的完善保密性（perfect secrecy），可以通過“一次性密碼本”的對稱加密處理。即通訊雙方每次使用跟明文等長的隨機金鑰串對明文進行加密處理。序列密碼採用了類似的思想，每次通過偽隨機數生成器來生成偽隨機金鑰串。代表演算法包括RC4等。
對稱加密演算法適用於大量資料的加解密過程；不能用於簽名場景；並且往往需要提前分發好金鑰。
注意：分組加密每次只能處理固定長度的明文，因此對於過長的內容需要採用一定模式進行分割處理，《實用密碼學》一書中推薦使用密文分組鏈（Cipher Block Chain，CBC）、計數器（Counter，CTR）等模式。
2.3、非對稱加密演算法
非對稱加密是現代密碼學歷史上一項偉大的發明，可以很好地解決對稱加密中提前分發金鑰的問題。
顧名思義，非對稱加密演算法中，加密金鑰和解密金鑰是不同的，分別稱為公鑰（public key）和私鑰（private key）。私鑰一般需要通過隨機數演算法生成，公鑰可以根據私鑰生成。公鑰一般是公開的，他人可獲取的；私鑰一般是個人持有，他人不能獲取。
非對稱加密演算法的優點是公私鑰分開，不安全通道也可使用。缺點是處理速度（特別是生成金鑰和解密過程）往往比較慢，一般比對稱加解密演算法慢2～3個數量級；同時加密強度也往往不如對稱加密演算法。
非對稱加密演算法的安全性往往需要基於數學問題來保障，目前主要有基於大數質因子分解、離散對數、橢圓曲線等經典數學難題進行保護。
代表演算法包括：RSA、ElGamal、橢圓曲線（Elliptic Curve Crytosystems，ECC）、SM2等系列演算法。
RSA：經典的公鑰演算法，1978年由Ron Rivest、Adi Shamir、Leonard Adleman共同提出，三人於2002年因此獲得圖靈獎。演算法利用了對大數進行質因子分解困難的特性，但目前還沒有數學證明兩者難度等價，或許存在未知演算法在不進行大數分解的前提下解密；詳見：http://blog.csdn.net/zyhlwzy/article/details/77948195
Diffie-Hellman金鑰交換：基於離散對數無法快速求解，可以在不安全的通道上，雙方協商一個公共金鑰；
ElGamal：由Taher ElGamal設計，利用了模運算下求離散對數困難的特性。被應用在PGP等安全工具中；
橢圓曲線演算法（Elliptic Curve Cryptography，ECC）：現代備受關注的算法系列，基於對橢圓曲線上特定點進行特殊乘法逆運算難以計算的特性。最早在1985年由Neal Koblitz和Victor Miller分別獨立提出。ECC系列演算法一般被認為具備較高的安全性，但加解密計算過程往往比較費時；
SM2（ShangMi 2）：國家商用密碼演算法，由國家密碼管理局於2010年12月17日釋出，同樣基於橢圓曲線演算法，加密強度優於RSA系列演算法。
非對稱加密演算法一般適用於簽名場景或金鑰協商，但不適於大量資料的加解密。
目前普遍認為RSA類演算法可能在不遠的將來被破解，一般推薦可採用安全強度更高的橢圓曲線系列演算法。
2.4、選擇明文攻擊
細心的讀者可能會意識到，在非對稱加密中，由於公鑰是公開可以獲取的，因此任何人都可以給定明文，獲取對應的密文，這就帶來選擇明文攻擊的風險。
為了規避這種風險，現有的非對稱加密演算法（如RSA、ECC）都引入了一定的保護機制。對同樣的明文使用同樣金鑰進行多次加密，得到的結果完全不同，這就避免了選擇明文攻擊的破壞。
在實現上可以有多種思路。一種是對明文先進行變形，新增隨機的字串或標記，再對新增後結果進行處理。另外一種是先用隨機生成的臨時金鑰對明文進行對稱加密，然後再對對稱金鑰進行加密，即混合利用多種加密機制。
2.5、混合加密機制
混合加密機制同時結合了對稱加密和非對稱加密的優點。
先用計算複雜度高的非對稱加密協商出一個臨時的對稱加密金鑰（也稱為會話金鑰，一般相對所加密內容來說要短得多），然後雙方再通過對稱加密演算法對傳遞的大量資料進行快速的加解密處理。
典型的應用案例是現在大家常用的HTTPS協議。HTTPS協議正在替換掉傳統的不安全的HTTP協議，成為最普遍的Web通訊協議。
HTTPS在傳統的HTTP層和TCP層之間通過引入Transport Layer Security/Secure Socket Layer（TLS/SSL）加密層來實現可靠的傳輸。
SSL協議最早是Netscape於1994年設計出來實現早期HTTPS的方案，SSL 3.0及之前版本存在漏洞，被認為不夠安全。TLS協議是IETF基於SSL協議提出的安全標準，目前最新的版本為1.2（2008年釋出）。推薦使用的版本號至少為TLS 1.0，對應到SSL 3.1版本。除了Web服務外，TLS協議也廣泛應用於Email、實時訊息、音視訊通話等領域。
採用HTTPS建立安全連線（TLS握手協商過程）的基本步驟如下（可參見圖5-2）：
圖5-2 TLS握手協商過程
- 客戶端瀏覽器傳送資訊到伺服器，包括隨機數R1、支援的加密演算法型別、協議版本、壓縮演算法等。注意該過程為明文。
- 服務端返回資訊，包括隨機數R2、選定加密演算法型別、協議版本以及伺服器證書。注意該過程為明文。
- 瀏覽器檢查帶有該網站公鑰的證書。該證書需要由第三方CA來簽發，瀏覽器和作業系統會預置權威CA的根證書。如果證書被篡改作假（中間人攻擊），很容易通過CA的證書驗證出來。
- 如果證書沒問題，則客戶端用服務端證書中的公鑰加密隨機數R3（又叫Pre-MasterSecret），傳送給伺服器。此時，只有客戶端和伺服器都擁有R1、R2和R3資訊，基於隨機數R1、R2和R3，雙方通過偽隨機數函式來生成共同的對稱會話金鑰MasterSecret。
- 後續客戶端和服務端的通訊都通過對稱加密演算法（如AES）進行保護。
可以看出，該過程的主要功能是在防止中間人竊聽和篡改的前提下完成會話金鑰的協商。為了保障前向安全性（perfect forward secrecy），TLS對每個會話連線都可以生成不同的金鑰，避免某次會話金鑰洩露之後影響了其他會話連線的安全性。需要注意，TLS協商過程支援加密演算法方案較多，要合理地選擇安全強度高的演算法，如DHE-RSA、ECDHE-RSA和ECDHE-ECDSA。
示例中對稱金鑰的協商過程採用了RSA非對稱加密演算法，實踐中也可以通過Diffie–Hellman協議來完成。
2.6、離散對數與Diffie–Hellman金鑰交換協議
Diffie–Hellman（DH）金鑰交換協議是一個經典的協議，最早發表於1976年，應用十分廣泛。使用該協議可以在不安全通道完成對稱金鑰的協商，以便後續通訊採用對稱加密。
DH協議的設計基於離散對數問題（Discrete Logarithm Problem，DLP）。離散對數問題是指對於一個很大的素數p，已知g為p的模迴圈群的原根，給定任意x，求解X=g^x mod p是可以很快獲取的。但在已知p、g和X的前提下，逆向求解x目前沒有多項式時間實現的演算法。該問題同時也是ECC類加密演算法的基礎。
DH協議的基本交換過程如下：
- Alice和Bob兩個人協商金鑰，先公開商定p，g；
- Alice自行選取私密的整數x，計算X=g^x mod p，傳送X給Bob；
- Bob自行選取私密的整數y，計算Y=g^y mod p，傳送Y給A；
- Alice根據x和Y，求解共同金鑰Z_A=Y^x mod p；
- Bob根據X和y，求解共同金鑰Z_B=X^y mod p。
實際上，Alice和Bob計算出來的結果將完全相同，因為在mod p的前提下，Y^x=（g^y）^x=g^（xy）=（g^x）^y=X^y。而通道監聽者在已知p、g、X、Y的前提下，無法求得Z。
三、訊息認證碼與數字簽名
訊息認證碼和數字簽名技術通過對訊息的摘要進行加密，可用於訊息防篡改和身份證明問題。
3.1、訊息認證碼
訊息認證碼全稱是“基於Hash的訊息認證碼”（Hash-based Message Authentication Code，HMAC）。訊息驗證碼基於對稱加密，可以用於對訊息完整性（integrity）進行保護。
基本過程為：對某個訊息利用提前共享的對稱金鑰和Hash演算法進行加密處理，得到HMAC值。該HMAC值持有方可以證明自己擁有共享的對稱金鑰，並且也可以利用HMAC確保訊息內容未被篡改。
典型的HMAC（K，H，Message）演算法包括三個因素，K為提前共享的對稱金鑰，H為提前商定的Hash演算法（一般為公認的經典演算法如SHA-256），Message為要處理的訊息內容。如果不知道K或H的任何一個，則無法根據Message得到正確的HMAC值。
訊息認證碼一般用於證明身份的場景。如Alice、Bob提前共享和HMCA的金鑰和Hash演算法，Alice需要知曉對方是否為Bob，可傳送隨機訊息給Bob。Bob收到訊息後進行計算，把訊息HMAC值返回給Alice，Alice通過檢驗收到HMAC值的正確性可以知曉對方是否是Bob。注意這裡並沒有考慮中間人攻擊的情況，假定通道是安全的。
訊息認證碼使用過程中主要問題是需要共享金鑰。當金鑰可能被多方擁有的場景下，無法證明訊息來自某個確切的身份。反之，如果採用非對稱加密方式，則可以追溯到來源身份，即數字簽名。
3.2、數字簽名
與在紙質合同上簽名確認合同內容和證明身份類似，數字簽名基於非對稱加密，既可以用於證實某數字內容的完整性，又同時可以確認來源（或不可抵賴，Non-Repudiation）。
一個典型的場景是，Alice通過通道發給Bob一個檔案（一份資訊），Bob如何獲知所收到的檔案即為Alice發出的原始版本？Alice可以先對檔案內容進行摘要，然後用自己的私鑰對摘要進行加密（簽名），之後同時將檔案和簽名都發給Bob。Bob收到檔案和簽名後，用Alice的公鑰來解密簽名，得到數字摘要，與收到檔案進行摘要後的結果進行比對。如果一致，說明該檔案確實是Alice發過來的（別人無法擁有Alice的私鑰），並且檔案內容沒有被修改過（摘要結果一致）。
知名的數字簽名演算法包括DSA（Digital Signature Algorithm）和安全強度更高的ECSDA（Elliptic Curve Digital Signature Algorithm）等。
除普通的數字簽名應用場景外，針對一些特定的安全需求，產生了一些特殊數字簽名技術，包括盲簽名、多重簽名、群簽名、環簽名等。
3.2.1、盲簽名
盲簽名（blind signature）是在1982年由David Chaum在論文《Blind Signatures for Untraceable Payment》中提出。簽名者需要在無法看到原始內容的前提下對資訊進行簽名。
盲簽名可以實現對所簽名內容的保護，防止簽名者看到原始內容；另一方面，盲簽名還可以實現防止追蹤（unlinkability），簽名者無法將簽名內容和簽名結果進行對應。典型的實現包括RSA盲簽名演算法等。
3.2.2、多重簽名
多重簽名（multiple signature）即n個簽名者中，收集到至少m個（n>=m>=1）的簽名，即認為合法。其中，n是提供的公鑰個數，m是需要匹配公鑰的最少的簽名個數。
多重簽名可以有效地被應用在多人投票共同決策的場景中。例如雙方進行協商，第三方作為稽核方。三方中任何兩方達成一致即可完成協商。
比特幣交易中就支援多重簽名，可以實現多個人共同管理某個賬戶的比特幣交易。
3.2.3、群簽名
群簽名（group signature）即某個群組內一個成員可以代表群組進行匿名簽名。簽名可以驗證來自於該群組，卻無法準確追蹤到簽名的是哪個成員。
群簽名需要存在一個群管理員來新增新的群成員，因此存在群管理員可能追蹤到簽名成員身份的風險。
群簽名最早於1991年由David Chaum和Eugene van Heyst提出。
3.2.4、環簽名
環簽名（ring signature），由Rivest、Shamir和Tauman三位密碼學家在2001年首次提出。環簽名屬於一種簡化的群簽名。
簽名者首先選定一個臨時的簽名者集合，集合中包括簽名者自身。然後簽名者利用自己的私鑰和簽名集合中其他人的公鑰就可以獨立地產生簽名，而無需他人的幫助。簽名者集合中的其他成員可能並不知道自己被包含在最終的簽名中。
環簽名在保護匿名性方面有很多的用途。
3.3、安全性
數字簽名演算法自身的安全性由數學問題進行保障，但在使用上，系統的安全性也十分關鍵。目前常見的數字簽名演算法往往需要選取合適的隨機數作為配置引數，配置引數不合理的使用或洩露都會造成安全漏洞，需要進行安全保護。
2010年，SONY公司因為其PS3產品上採用安全的ECDSA進行簽名時，不慎採用了重複的隨機引數，導致私鑰被最終破解，造成重大經濟損失。
四、數字證書
對於非對稱加密演算法和數字簽名來說，很重要的一點就是公鑰的分發。理論上任何人可以公開獲取到對方的公鑰。然而這個公鑰有沒有可能是偽造的呢？傳輸過程中有沒有可能被篡改掉呢？一旦公鑰自身出了問題，則整個建立在其上的安全體系的安全性將不復存在。
數字證書機制正是為了解決這個問題，它就像日常生活中的一個證書一樣，可以證明所記錄資訊的合法性。比如證明某個公鑰是某個實體（如組織或個人）的，並且確保一旦內容被篡改能被探測出來，從而實現對使用者公鑰的安全分發。
根據所保護公鑰的用途，可以分為加密數字證書（Encryption Certificate）和簽名驗證數字證書（Signature Certificate）。前者往往用於保護用於加密資訊的公鑰；後者則保護用於進行解密簽名進行身份驗證的公鑰。兩種型別的公鑰也可以同時放在同一證書中。
一般情況下，證書需要由證書認證機構（Certification Authority，CA）來進行簽發和背書。權威的證書認證機構包括DigiCert、GlobalSign、VeriSign等。使用者也可以自行搭建本地CA系統，在私有網路中進行使用。
4.1、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）：證書的有效期限，包括起止時間；
主體（Subject）：證書擁有者的標識資訊（Distinguished Name），如“C=CN，ST=Beijing，L=Beijing，CN=person.org.example.com”；
主體的公鑰資訊（Subject Public Key Info）：所保護的公鑰相關的資訊；
公鑰演算法（Public Key Algorithm）：公鑰採用的演算法；
主體公鑰（Subject Public Key）：公鑰的內容；
頒發者唯一號（Issuer Unique Identifier）：代表頒發者的唯一資訊，僅2、3版本支援，可選；
主體唯一號（Subject Unique Identifier）：代表擁有證書實體的唯一資訊，僅2、3版本支援，可選；
擴充套件（Extensions，可選）：可選的一些擴充套件。v3中可能包括：
Subject Key Identifier：實體的金鑰識別符號，區分實體的多對金鑰；
Basic Constraints：一般指明是否屬於CA；
Authority Key Identifier：證書頒發者的公鑰識別符號；
CRL Distribution Points：撤銷檔案的釋出地址；
Key Usage：證書的用途或功能資訊。
此外，證書的頒發者還需要對證書內容利用自己的公鑰添加簽名，以防止別人對證書內容進行篡改。
4.2、證書格式
X.509規範中一般推薦使用PEM（Privacy Enhanced Mail）格式來儲存證書相關的檔案。證書檔案的檔名字尾一般為.crt或.cer，對應私鑰檔案的檔名字尾一般為.key，證書請求檔案的檔名字尾為.csr。有時候也統一用.pem作為檔名字尾。
PEM格式採用文字方式進行儲存，一般包括首尾標記和內容塊，內容塊採用Base64進行編碼。
例如，一個PEM格式的示例證書檔案如下所示：
-----BEGIN CERTIFICATE-----
MIICMzCCAdmgAwIBAgIQIhMiRzqkCljq3ZXnsl6EijAKBggqhkjOPQQDAjBmMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy
YW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFDASBgNVBAMTC2V4YW1wbGUu
Y29tMB4XDTE3MDQyNTAzMzAzN1oXDTI3MDQyMzAzMzAzN1owZjELMAkGA1UEBhMC
VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
FDASBgNVBAoTC2V4YW1wbGUuY29tMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABCkIHZ3mJCEPbIbUdh/Kz3zWW1C9wxnZOwfy
yrhr6aHwWREW3ZpMWKUcbsYup5kbouBc2dvMFUgoPBoaFYJ9D0SjaTBnMA4GA1Ud
DwEB/wQEAwIBpjAZBgNVHSUEEjAQBgRVHSUABggrBgEFBQcDATAPBgNVHRMBAf8E
BTADAQH/MCkGA1UdDgQiBCBIA/DmemwTGibbGe8uWjt5hnlE63SUsXuNKO9iGEhV
qDAKBggqhkjOPQQDAgNIADBFAiEAyoMO2BAQ3c9gBJOk1oSyXP70XRk4dTwXMF7q
R72ijLECIFKLANpgWFoMoo3W91uzJeUmnbJJt8Jlr00ByjurfAvv
-----END CERTIFICATE-----可以通過OpenSSL工具來檢視其內容：
# openssl x509 -in example.com-cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
22:13:22:47:3a:a4:0a:58:ea:dd:95:e7:b2:5e:84:8a
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=example.com,
CN=example.com
Validity
Not Before: Apr 25 03:30:37 2017 GMT
Not After : Apr 23 03:30:37 2027 GMT
Subject: C=US, ST=California, L=San Francisco, O=example.com,
CN=example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:29:08:1d:9d:e6:24:21:0f:6c:86:d4:76:1f:ca:
cf:7c:d6:5b:50:bd:c3:19:d9:3b:07:f2:ca:b8:6b:
e9:a1:f0:59:11:16:dd:9a:4c:58:a5:1c:6e:c6:2e:
a7:99:1b:a2:e0:5c:d9:db:cc:15:48:28:3c:1a:1a:
15:82:7d:0f:44
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign,
CRL Sign
X509v3 Extended Key Usage:
Any Extended Key Usage, TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
48:03:F0:E6:7A:6C:13:1A:26:DB:19:EF:2E:5A:3B:79:86:
79:44:EB:74:94:B1:7B:8D:28:EF:62:18:48:55:A8
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:ca:83:0e:d8:10:10:dd:cf:60:04:93:a4:d6:
84:b2:5c:fe:f4:5d:19:38:75:3c:17:30:5e:ea:47:bd:a2:8c:
b1:02:20:52:8b:00:da:60:58:5a:0c:a2:8d:d6:f7:5b:b3:25:
e5:26:9d:b2:49:b7:c2:65:af:4d:01:ca:3b:ab:7c:0b:ef此外，還有DER（Distinguished Encoding Rules）格式，是採用二進位制對證書進行儲存，可以與PEM格式互相轉換。
4.3、證書信任鏈
證書中記錄了大量資訊，其中最重要的包括“簽發的公開金鑰”和“CA數字簽名”兩個資訊。因此，只要使用CA的公鑰再次對這個證書進行簽名比對，就能證明某個實體的公鑰是否是合法的。
讀者可能會想到，怎麼證明用來驗證對實體證書進行簽名的CA公鑰自身是否合法呢？畢竟在獲取CA公鑰的過程中，它也可能被篡改掉。
實際上，要想知道CA的公鑰是否合法，一方面可以通過更上層的CA頒發的證書來進行認證；另一方面某些根CA（Root CA）可以通過預先分發證書來實現信任基礎。例如，主流作業系統和瀏覽器裡面，往往會提前預置一些權威CA的證書（通過自身的私鑰簽名，系統承認這些是合法的證書）。之後所有基於這些CA認證過的中間層CA（Intermediate CA）和後繼CA都會被驗證合法。這樣就從預先信任的根證書，經過中間層證書，到最底下的實體證書，構成一條完整的證書信任鏈。
某些時候使用者在使用瀏覽器訪問某些網站時，可能會被提示是否信任對方的證書。這說明該網站證書無法被當前系統中的證書信任鏈進行驗證，需要進行額外檢查。另外，當信任鏈上任一證書不可靠時，則依賴它的所有後繼證書都將失去保障。
可見，證書作為公鑰信任的基礎，對其生命週期進行安全管理十分關鍵。下節將介紹的PKI體系提供了一套完整的證書管理的框架，包括生成、頒發、撤銷過程等。
五、PKI體系
在非對稱加密中，公鑰可以通過證書機制來進行保護，但證書的生成、分發、撤銷等過程並沒有在X.509規範中進行定義。
實際上，安全地管理和分發證書可以遵循PKI（Public Key Infrastructure）體系來完成。PKI體系核心解決的是證書生命週期相關的認證和管理問題，在現代密碼學應用領域處於十分基礎和重要的地位。
需要注意，PKI是建立在公私鑰基礎上實現安全可靠傳遞訊息和身份確認的一個通用框架，並不代表某個特定的密碼學技術和流程。實現了PKI規範的平臺可以安全可靠地管理網路中使用者的金鑰和證書。目前包括多個實現和規範，知名的有RSA公司的PKCS（Public Key Cryptography Standards）標準和X.509相關規範等。
5.1、PKI基本元件
一般情況下，PKI至少包括如下核心元件：
CA（Certification Authority）：負責證書的頒發和作廢，接收來自RA的請求，是最核心的部分；
RA（Registration Authority）：對使用者身份進行驗證，校驗資料合法性，負責登記，稽核過了就發給CA；
證書資料庫：存放證書，多采用X.500系列標準格式。可以配合LDAP目錄服務管理使用者資訊。
其中，CA是最核心的元件，主要完成對證書資訊的維護。
常見的操作流程為，使用者通過RA登記申請證書，提供身份和認證資訊等；CA稽核後完成證書的製造，頒發給使用者。使用者如果需要撤銷證書則需要再次向CA發出申請。
5.2、證書的簽發
CA對使用者簽發證書實際上是對某個使用者公鑰，使用CA的私鑰對其進行簽名。這樣任何人都可以用CA的公鑰對該證書進行合法性驗證。驗證成功則認可該證書中所提供的使用者公鑰內容，實現使用者公鑰的安全分發。
使用者證書的簽發可以有兩種方式。一般可以由CA直接來生成證書（內含公鑰）和對應的私鑰發給使用者；也可以由使用者自己生成公鑰和私鑰，然後由CA來對公鑰內容進行簽名。
後者情況下，使用者一般會首先自行生成一個私鑰和證書申請檔案（Certificate Signing Request，即csr檔案），該檔案中包括了使用者對應的公鑰和一些基本資訊，如通用名（common name，即cn）、組織資訊、地理位置等。CA只需要對證書請求檔案進行簽名，生成證書檔案，頒發給使用者即可。整個過程中，使用者可以保持私鑰資訊的私密性，不會被其他方獲知（包括CA方）。
生成證書申請檔案的過程並不複雜，使用者可以很容易地使用開源軟體openssl來生成csr檔案和對應的私鑰檔案。
例如，安裝OpenSSL後可以執行如下命令來生成私鑰和對應的證書請求檔案：
$ openssl req -new -keyout private.key -out for_request.csr
Generating a 1024 bit RSA private key
...........................++++++
............................................++++++
writing new private key to 'private.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:Beijing
Locality Name (eg, city) []:Beijing
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Blockchain
Organizational Unit Name (eg, section) []:Dev
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:生成過程中需要輸入地理位置、組織、通用名等資訊。生成的私鑰和csr檔案預設以PEM格式儲存，內容為Base64編碼。
如生成的csr檔案內容可能為：
$ cat for_request.csr
1
-----BEGIN CERTIFICATE REQUEST-----
MIIBrzCCARgCAQAwbzELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB0JlaWppbmcxEDAO
BgNVBAcTB0JlaWppbmcxEzARBgNVBAoTCkJsb2NrY2hhaW4xDDAKBgNVBAsTA0Rl
djEZMBcGA1UEAxMQeWVhc3kuZ2l0aHViLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEA8fzVl7MJpFOuKRH+BWqJY0RPTQK4LB7fEgQFTIotO264ZlVJVbk8
Yfl42F7dh/8SgHqmGjPGZgDb3hhIJLoxSOI0vJweU9v6HiOVrFWE7BZEvhvEtP5k
lXXEzOewLvhLMNQpG0kBwdIh2EcwmlZKcTSITJmdulEvoZXr/DHXnyUCAwEAAaAA
MA0GCSqGSIb3DQEBBQUAA4GBAOtQDyJmfP64anQtRuEZPZji/7G2+y3LbqWLQIcj
IpZbexWJvORlyg+iEbIGno3Jcia7lKLih26lr04W/7DHn19J6Kb/CeXrjDHhKGLO
I7s4LuE+2YFSemzBVr4t/g24w9ZB4vKjN9X9i5hc6c6uQ45rNlQ8UK5nAByQ/TWD
OxyG
-----END CERTIFICATE REQUEST-----openssl工具提供了檢視PEM格式檔案明文的功能，如使用如下命令可以檢視生成的csr檔案的明文：
$ openssl req -in for_request.csr -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CN, ST=Beijing, L=Beijing, O=Blockchain, OU=Dev,
CN=yeasy.github.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:f1:fc:d5:97:b3:09:a4:53:ae:29:11:fe:05:6a:
89:63:44:4f:4d:02:b8:2c:1e:df:12:04:05:4c:8a:
2d:3b:6e:b8:66:55:49:55:b9:3c:61:f9:78:d8:5e:
dd:87:ff:12: