[[337722]]

通過 OpenSSL 深入了解密碼學的細節(jié)：哈希值、數(shù)字簽名、數(shù)字證書等。

本系列的第一篇文章通過 OpenSSL 庫和命令行實用程序介紹了哈希、加密/解密、數(shù)字簽名和數(shù)字證書。這第二篇文章將對細節(jié)進行深入探討。讓我們從計算中無處不在的哈希開始，并考慮是什么使哈希函數(shù)具備密碼學意義。

密碼學哈希

OpenSSL 源代碼的下載頁面包含了一個帶有最新版本的表格。每個版本都有兩個哈希值hash：160 位 SHA1 和 256 位 SHA256。這些值可以用來驗證下載的文件是否與存儲庫中的原始文件相匹配：下載者在本地重新計算下載文件的哈希值，然后將結果與原始文件進行比較。現(xiàn)代系統(tǒng)有計算這種哈希值的實用程序。例如，Linux 有 md5sum 和 sha256sum。OpenSSL 本身也提供了類似的命令行實用程序。

哈希值被用于計算的許多領域。例如，比特幣區(qū)塊鏈使用 SHA256 哈希值作為區(qū)塊標識符。挖比特幣就是生成一個低于指定閾值的 SHA256 哈希值，也就是至少有 N 個前導零的哈希值。（N 的值可以上升或下降，這取決于特定時間的挖礦生產(chǎn)力）。作為一個興趣點，如今的礦機是為并行生成 SHA256 哈希值而設計的硬件集群。在 2018 年的一個高峰期，全球的比特幣礦工每秒產(chǎn)生約 7500 萬個太哈希值terahash —— 這真是一個不可思議的數(shù)字。

網(wǎng)絡協(xié)議也使用哈希值（在這里通常叫做“校驗和checksum”）來支持消息的完整性；也就是說，保證收到的消息與發(fā)送的消息是一樣的。消息發(fā)送者計算消息的校驗和，并將結果與消息一起發(fā)送。當消息到達時，接收方重新計算校驗和。如果發(fā)送的校驗和與重新計算的校驗和不一致，那么消息在傳輸過程中可能出現(xiàn)了一些問題，或者發(fā)送的校驗和出現(xiàn)了問題，或者兩者都出現(xiàn)了問題。在這種情況下，應該重新發(fā)送消息和它的校驗和，或者至少應該觸發(fā)一個錯誤情況。（如 UDP 這樣的低級網(wǎng)絡協(xié)議不會理會校驗和。）

哈希的其他例子大家都很熟悉。比如一個網(wǎng)站，要求用戶用密碼進行驗證，用戶在瀏覽器中輸入密碼，然后，他們通過 HTTPS 連接到服務器，密碼從瀏覽器加密發(fā)送到服務器。一旦密碼到達服務器，就會被解密，然后進行數(shù)據(jù)庫表的查詢。

在這個查詢表中應該存儲什么？存儲密碼本身是有風險的。風險要小得多的方式是存儲一個由密碼生成的哈希值，也許在計算哈希值之前“加一些鹽salt（額外的位）改善口味”。你的密碼可能會被發(fā)送到 Web 服務器上，但網(wǎng)站可以向你保證，密碼不會存儲在那里。

哈希值還出現(xiàn)在安全的各個領域。例如，基于哈希值的消息認證碼hash-based message authentication code（HMAC）使用一個哈希值和一個秘密的加密密鑰cryptographic key來認證通過網(wǎng)絡發(fā)送的消息。HMAC 碼輕量級且易于在程序中使用，在 Web 服務中很受歡迎。一個 X509 數(shù)字證書包括一個稱為指紋fingerprint的哈希值，它可以方便證書驗證。一個存放于內存中的可信存儲truststore可以實現(xiàn)為一個以這種指紋為鍵的查找表 —— 作為一個支持恒定查找時間的哈希映射hash map。來自傳入的證書的指紋可以與可信存儲中的密鑰進行比較，以確定是否匹配。

密碼學哈希函數(shù)cryptographic hash function應該具有什么特殊屬性？它應該是單向one-way的，這意味著很難被逆轉。一個加密哈希函數(shù)應該是比較容易計算的，但是計算它的反函數(shù)（將哈希值映射回輸入位串的函數(shù)）在計算上應該是困難的。下面是一個描述，用 chf 作為加密哈希函數(shù)，我的密碼 foobar 作為樣本輸入。

        +---+
foobar—>|chf|—>hash value ## 簡單直接
        +--–+

相比之下，逆向操作是不可行的：

            +-----------+
hash value—>|chf inverse|—>foobar ## 棘手困難
            +-----------+

例如，回憶一下 SHA256 哈希函數(shù)。對于一個任意長度為 N > 0 的輸入位串，這個函數(shù)會生成一個 256 位的固定長度的哈希值；因此，這個哈希值甚至不會反映出輸入位串的長度 N，更不用說字符串中每個位的值了。順便說一下，SHA256 不容易受到長度擴展攻擊length extension attack。唯一有效的逆向工程方法是通過蠻力搜索將計算出的 SHA256 哈希值逆向返回到輸入位串，這意味著需要嘗試所有可能的輸入位串，直到找到與目標哈希值匹配的位串。這樣的搜索在 SHA256 這樣一個完善的加密哈希函數(shù)上是不可行的。

現(xiàn)在，最后一個回顧的知識點是有序in order。加密哈希值是統(tǒng)計學上的唯一，而不是無條件的唯一，這意味著兩個不同的輸入位串產(chǎn)生相同的哈希值是不太可能的，但也不是不可能的 —— 這稱之為碰撞collision。生日問題提供了一個很好的反直覺的碰撞例子。對各種哈希算法的抗碰撞性collision resistance有著廣泛的研究。例如，MD5（128 位哈希值）在大約 2²¹ 次哈希之后，抗碰撞能力就會崩潰。對于 SHA1（160 位哈希值），大約在 2⁶¹ 次哈希后開始崩潰。

對于 SHA256 的抗碰撞能力的剖析，目前還沒有一個很好的估計。這個事實并不奇怪。SHA256 有 2²⁵⁶ 個不同的哈希值范圍，這個數(shù)字的十進制表示法有 78 位之多！那么，SHA256 哈希會不會發(fā)生碰撞呢？當然可能，但可能性極小。

在下面的命令行示例中，有兩個輸入文件被用作位串源：hashIn1.txt 和 hashIn2.txt。第一個文件包含 abc，第二個文件包含 1a2b3c。

為了便于閱讀，這些文件包含的是文本，但也可以使用二進制文件代替。

在命令行（百分號 % 是提示符）使用 Linux sha256sum 實用程序對這兩個文件進行處理產(chǎn)生以下哈希值（十六進制）:

% sha256sum hashIn1.txt
9e83e05bbf9b5db17ac0deec3b7ce6cba983f6dc50531c7a919f28d5fb3696c3 hashIn1.txt
 
% sha256sum hashIn2.txt
3eaac518777682bf4e8840dd012c0b104c2e16009083877675f00e995906ed13 hashIn2.txt

OpenSSL 哈希對應的結果與預期相同：

% openssl dgst -sha256 hashIn1.txt
SHA256(hashIn1.txt)= 9e83e05bbf9b5db17ac0deec3b7ce6cba983f6dc50531c7a919f28d5fb3696c3
 
% openssl dgst -sha256 hashIn2.txt
SHA256(hashIn2.txt)= 3eaac518777682bf4e8840dd012c0b104c2e16009083877675f00e995906ed13

這種對密碼學哈希函數(shù)的研究，為我們仔細研究數(shù)字簽名及其與密鑰對的關系奠定了基礎。

數(shù)字簽名

顧名思義，數(shù)字簽字digital signature可以附在文件或其他一些電子工件artifact（如程序）上，以證明其真實性。因此，這種簽名類似于紙質文件上的手寫簽名。驗證數(shù)字簽名就是要確認兩件事：第一，被擔保的工件在簽名被附上后沒有改變，因為它部分是基于文件的加密學哈希值。第二，簽名屬于一個人（例如 Alice），只有她才能獲得一對密鑰中的私鑰。順便說一下，對代碼（源碼或編譯后的代碼）進行數(shù)字簽名已經(jīng)成為程序員的普遍做法。

讓我們來了解一下數(shù)字簽名是如何創(chuàng)建的。如前所述，沒有公鑰和私鑰對就沒有數(shù)字簽名。當使用 OpenSSL 創(chuàng)建這些密鑰時，有兩個獨立的命令：一個是創(chuàng)建私鑰，另一個是從私鑰中提取匹配的公鑰。這些密鑰對用 base64 編碼，在這個過程中可以指定它們的大小。

私鑰private key由數(shù)值組成，其中兩個數(shù)值（一個模數(shù)modulus和一個指數(shù)exponent）組成了公鑰。雖然私鑰文件包含了公鑰public key，但提取出來的公鑰并不會透露相應私鑰的值。

因此，生成的帶有私鑰的文件包含了完整的密鑰對。將公鑰提取到自己的文件中是很實用的，因為這兩把鑰匙有不同的用途，而這種提取方式也將私鑰可能被意外公開的危險降到最低。

接下來，這對密鑰的私鑰被用來生成目標工件（如電子郵件）的哈希值，從而創(chuàng)建簽名。在另一端，接收者的系統(tǒng)使用這對密鑰的公鑰來驗證附在工件上的簽名。

現(xiàn)在舉個例子。首先，用 OpenSSL 生成一個 2048 位的 RSA 密鑰對：

openssl genpkey -out privkey.pem -algorithm rsa 2048

在這個例子中，我們可以舍去 -algorithm rsa 標志，因為 genpkey 默認為 RSA 類型。文件的名稱（privkey.pem）是任意的，但是隱私增強郵件Privacy Enhanced Mail（PEM）擴展名 .pem 是默認 PEM 格式的慣用擴展名。（如果需要的話，OpenSSL 有命令可以在各種格式之間進行轉換。）如果需要更大的密鑰大小（例如 4096），那么最后一個參數(shù) 2048 可以改成 4096。這些大小總是二的冪。

下面是產(chǎn)生的 privkey.pem 文件的一個片斷，它是 base64 編碼的：

-----BEGIN PRIVATE KEY-----
MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBANnlAh4jSKgcNj/Z
JF4J4WdhkljP2R+TXVGuKVRtPkGAiLWE4BDbgsyKVLfs2EdjKL1U+/qtfhYsqhkK
...
-----END PRIVATE KEY-----

接下來的命令就會從私鑰中提取出這對密鑰的公鑰：

openssl rsa -in privkey.pem -outform PEM -pubout -out pubkey.pem

由此產(chǎn)生的 pubkey.pem 文件很小，可以在這里完整地顯示出來：

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZ5QIeI0ioHDY/2SReCeFnYZJY
z9kfk11RrilUbT5BgIi1hOAQ24LMilS37NhHYyi9VPv6rX4WLKoZCmkeYaWk/TR5
4nbH1E/AkniwRoXpeh5VncwWMuMsL5qPWGY8fuuTE27GhwqBiKQGBOmU+MYlZonO
O0xnAKpAvysMy7G7qQIDAQAB
-----END PUBLIC KEY-----

現(xiàn)在，有了密鑰對，數(shù)字簽名就很容易了 —— 在本例中，源文件 client.c 是要簽名的工件：

openssl dgst -sha256 -sign privkey.pem -out sign.sha256 client.c

client.c 源文件的摘要是 SHA256，私鑰在前面創(chuàng)建的 privkey.pem 文件中。由此產(chǎn)生的二進制簽名文件是 sign.sha256，這是一個任意的名字。要得到這個文件的可讀版本（比如 base64），后續(xù)命令是：

openssl enc -base64 -in sign.sha256 -out sign.sha256.base64

文件 sign.sha256.base64 現(xiàn)在包含如下內容：

h+e+3UPx++KKSlWKIk34fQ1g91XKHOGFRmjc0ZHPEyyjP6/lJ05SfjpAJxAPm075
VNfFwysvqRGmL0jkp/TTdwnDTwt756Ej4X3OwAVeYM7i5DCcjVsQf5+h7JycHKlM
o/Jd3kUIWUkZ8+Lk0ZwzNzhKJu6LM5KWtL+MhJ2DpVc=

或者，可執(zhí)行文件 client 也可以被簽名，由此產(chǎn)生的 base64 編碼簽名將如預期的不同：

VMVImPgVLKHxVBapJ8DgLNJUKb98GbXgehRPD8o0ImADhLqlEKVy0HKRm/51m9IX
xRAN7DoL4Q3uuVmWWi749Vampong/uT5qjgVNTnRt9jON112fzchgEoMb8CHNsCT
XIMdyaPtnJZdLALw6rwMM55MoLamSc6M/MV1OrJnk/g=

這一過程的最后一步是用公鑰驗證數(shù)字簽名。作為驗證的一個重要步驟，應重新計算用于簽署工件（在本例中，是可執(zhí)行的 client 程序）的哈希值，因為驗證過程應表明工件在簽署后是否發(fā)生了變化。

有兩個 OpenSSL 命令用于這個目的。第一條命令是對 base64 簽名進行解碼。

openssl enc -base64 -d -in sign.sha256.base64 -out sign.sha256

第二條是核實簽名：

openssl dgst -sha256 -verify pubkey.pem -signature sign.sha256 client

第二條命令的輸出，應該是這樣的：

Verified OK

為了了解驗證失敗時的情況，一個簡短但有用的練習是將最后一個 OpenSSL 命令中的可執(zhí)行的 client 文件替換為源文件 client.c，然后嘗試驗證。另一個練習是改變 client 程序，無論多么輕微，然后再試一次。

數(shù)字證書

數(shù)字證書digital certificate匯集了到目前為止所分析的各個部分：哈希值、密鑰對、數(shù)字簽名和加密/解密。生產(chǎn)級證書的第一步是創(chuàng)建一個證書簽名請求certificate signing request（CSR），然后將其發(fā)送給證書頒發(fā)機構certificate authority（CA）。在 OpenSSL 的例子中，要做到這一點，請運行：

openssl req -out myserver.csr -new -newkey rsa:4096 -nodes -keyout myserverkey.pem

這個例子生成了一個 CSR 文檔，并將該文檔存儲在文件 myserver.csr（base64 文本）中。這里的目的是：CSR 文檔要求 CA 保證與指定域名相關聯(lián)的身份，域名也就是 CA 所說的通用名common name（CN）。

盡管可以使用現(xiàn)有的密鑰對，但這個命令也會生成一個新的密鑰對。請注意，在諸如 myserver.csr 和 myserverkey.pem 等名稱中使用 server 暗示了數(shù)字證書的典型用途：作為與 www.google.com 等域名相關的 Web 服務器的身份擔保。

然而，無論數(shù)字證書如何使用，同樣使用這個命令都會創(chuàng)建一個 CSR。它還會啟動一個問題/回答的交互式會話，提示有關域名的相關信息，以便與請求者的數(shù)字證書相連接。這個交互式會話可以通過在命令中提供基本的信息，用反斜杠來續(xù)行一步完成。-subj 標志提供了所需的信息。

% openssl req -new \
-newkey rsa:2048 -nodes -keyout privkeyDC.pem \
-out myserver.csr \
-subj "/C=US/ST=Illinois/L=Chicago/O=Faulty Consulting/OU=IT/CN=myserver.com"

產(chǎn)生的 CSR 文件在發(fā)送給 CA 之前可以進行檢查和驗證。這個過程可以創(chuàng)建具有所需格式（如 X509）、簽名、有效期等的數(shù)字證書。

openssl req -text -in myserver.csr -noout -verify

這是輸出的一個片斷：

verify OK
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73:
…
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
…

自簽證書

在開發(fā) HTTPS 網(wǎng)站的過程中，手頭有一個不用經(jīng)過 CA 流程的數(shù)字證書是很方便的。在 HTTPS 握手的認證階段，自簽證書self-signed certificate就能滿足要求，盡管任何現(xiàn)代瀏覽器都會警告說這樣的證書毫無價值。繼續(xù)這個例子，自簽證書的 OpenSSL 命令（有效期為一年，使用 RSA 公鑰）如下：

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:4096 -keyout myserver.pem -out myserver.crt

下面的 OpenSSL 命令呈現(xiàn)了生成的證書的可讀版本：

openssl x509 -in myserver.crt -text -noout

這是自簽證書的部分輸出：

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 13951598013130016090 (0xc19e087965a9055a)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com
Validity
Not Before: Apr 11 17:22:18 2019 GMT
Not After : Apr 10 17:22:18 2020 GMT
Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91
X509v3 Authority Key Identifier:
keyid:3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91
 
        X509v3 Basic Constraints:
            CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
     3a:eb:8d:09:53:3b:5c:2e:48:ed:14:ce:f9:20:01:4e:90:c9:
     ...

如前所述，RSA 私鑰包含的值是用來生成公鑰的。但是，給定的公鑰不會泄露匹配的私鑰。關于底層數(shù)學理論的介紹，見 https://simple.wikipedia.org/wiki/RSA_algorithm。

數(shù)字證書與用于生成該證書的密鑰對之間存在著重要的對應關系，即使證書只是自簽的：

• 數(shù)字證書包含構成公鑰的指數(shù)和模數(shù)值。這些值是最初生成的 PEM 文件中密鑰對的一部分，在本例中，是文件 myserver.pem。
• 指數(shù)exponent幾乎總是 65,537（如本例中），所以可以忽略。
• 密鑰對的模數(shù)modulus應該與數(shù)字證書的模數(shù)相匹配。

模數(shù)是一個很大的值，為了便于閱讀，可以進行哈希處理。下面是兩個 OpenSSL 命令，它們檢查相同的模數(shù)，從而確認數(shù)字證書是基于 PEM 文件中的密鑰對。

% openssl x509 -noout -modulus -in myserver.crt | openssl sha1 ## 證書中的模數(shù)
(stdin)= 364d21d5e53a59d482395b1885aa2c3a5d2e3769
 
% openssl rsa -noout -modulus -in myserver.pem | openssl sha1 ## 密鑰中的模數(shù)
(stdin)= 364d21d5e53a59d482395b1885aa2c3a5d2e3769

所產(chǎn)生的哈希值匹配，從而確認數(shù)字證書是基于指定的密鑰對。

回到密鑰分發(fā)問題上

讓我們回到第一部分末尾提出的一個問題：client 程序和 Google Web 服務器之間的 TLS 握手。握手協(xié)議有很多種，即使是用在 client 例子中的 Diffie-Hellman 版本也有不同的方式。盡管如此，client 例子遵循了一個共同的模式。

首先，在 TLS 握手過程中，client 程序和 Web 服務器就加密套件cipher suite達成一致，其中包括要使用的算法。在本例中，該套件是 ECDHE-RSA-AES128-GCM-SHA256。

現(xiàn)在值得關注的兩個要素是 RSA 密鑰對算法和 AES128 塊密碼，用于在握手成功的情況下對消息進行加密和解密。關于加密/解密，這個過程有兩種流派：對稱symmetric和非對稱asymmetric。在對稱流派中，加密和解密使用的是相同的密鑰，這首先就引出了密鑰分發(fā)問題key distribution problem。如何將密鑰安全地分發(fā)給雙方？在非對稱流派中，一個密鑰用于加密（在這種情況下，是 RSA 公鑰），但另一個密鑰用于解密（在這種情況下，是來自同一對密鑰的 RSA 私鑰）。

client 程序擁有來認證證書的 Google Web 服務器的公鑰，而 Web 服務器擁有來自同一對密鑰的私鑰。因此，client 程序可以向 Web 服務器發(fā)送加密信息，而 Web 服務器可以單獨對該通信進行解密。

在 TLS 的情況下，對稱方式有兩個顯著的優(yōu)勢：

• 在 client 程序與 Google Web 服務器之間的互動中，認證是單向的。Google Web 服務器向 client 程序發(fā)送三張證書，但 client 程序并沒有向 Web 服務器發(fā)送證書，因此，Web 服務器沒有來自客戶端的公鑰，無法加密發(fā)給客戶端的消息。
• 使用 AES128 的對稱加密/解密比使用 RSA 密鑰的非對稱加密/解密快了近千倍。

TLS 握手將兩種加密/解密方式巧妙地結合在一起。在握手過程中，client 程序會生成隨機位，即所謂的預主密pre-master secret（PMS）。然后，client 程序用服務器的公鑰對 PMS 進行加密，并將加密后的 PMS 發(fā)送給服務器，服務器再用 RSA 密鑰對的私鑰對 PMS 信息進行解密：

              +-------------------+ encrypted PMS  +--------------------+
client PMS--->|server’s public key|--------------->|server’s private key|--->server PMS
              +-------------------+                +--------------------+

在這個過程結束時，client 程序和 Google Web 服務器現(xiàn)在擁有相同的 PMS 位。每一方都使用這些位生成一個主密碼master secret，并立即生成一個稱為會話密鑰session key的對稱加密/解密密鑰。現(xiàn)在有兩個不同但等價的會話密鑰，連接的每一方都有一個。在 client 的例子中，會話密鑰是 AES128 類的。一旦在 client 程序和 Google Web 服務器兩邊生成了會話密鑰，每一邊的會話密鑰就會對雙方的對話進行保密。如果任何一方（例如，client 程序）或另一方（在這種情況下，Google Web 服務器）要求重新開始握手，握手協(xié)議（如 Diffie-Hellman）允許整個 PMS 過程重復進行。

總結

在命令行上說明的 OpenSSL 操作也可以通過底層庫的 API 完成。這兩篇文章重點使用了這個實用程序，以保持例子的簡短，并專注于加密主題。如果你對安全問題感興趣，OpenSSL 是一個很好的開始地方，并值得深入研究。