現(xiàn)在安全體系中，最重要的一部分是數(shù)字安全加密體系，包括數(shù)字內(nèi)容的加密解密，數(shù)字簽名和驗證。本文蟲蟲給大家介紹一下數(shù)字證書簽名以及世界最大的網(wǎng)站Https免費簽名Let's Encrypts，及數(shù)字證書簽名的安全性等問題。

概述

數(shù)字簽名就是在信息的后面再加上一段內(nèi)容，可以證明信息沒有被修改過，怎么樣可以達到這個效果呢?一般是對信息做不可逆的哈希計算得到一個哈希值。在把信息發(fā)送出去時，把這個哈希值加密后做為一個簽名和信息一起發(fā)出去。接收方在收到信息后，會重新計算信息的哈希值，并和信息所附帶的哈希值(解密后)進行對比，如果一致，就說明信息的內(nèi)容沒有被修改過。數(shù)字簽名在現(xiàn)在現(xiàn)代安全體系中非常重要基礎(chǔ)，可以用來確保文件的完整性、防止文件篡改以及身份認證等。首先我們說說幾個常見的數(shù)字證書基本概念：

RFC

RFC的意思是Request For Comments，中文對應(yīng)為請求注釋，它是一堆描述不同協(xié)議的文本文件。如果想了解SSL，TLS(新的SSL)和x509證書(用于SSL和TLS的證書)如何工作，例如，想編寫自己的OpenSSL，則必須閱讀相應(yīng)的TLS RFC。：的X509證書對應(yīng)的rfc5280和TLS(1.2)對應(yīng)的rfc5246。

x509

x509是為非正式的互聯(lián)網(wǎng)電子郵件，IPsec和WWW應(yīng)用程序定義的證書規(guī)范，x509發(fā)展了三個版本，現(xiàn)在廣泛使用的RFC v3，其結(jié)構(gòu)如下：

Certificate ::= SEQUENCE {  
tbsCertificate TBSCertificate,  
signatureAlgorithm AlgorithmIdentifier,  
signatureValue BIT STRING } 

這些是ASN.1結(jié)構(gòu)。現(xiàn)代的證書就是這樣的：

• 第一個對象包含將要簽名的所有感興趣的內(nèi)容，因此我們將其稱為"待簽名證書"
• 第二個對象包含CA用于對該證書簽名的簽名類型(例如：sha256)
• 最后一個對象不是對象，只是與DER編碼后的TBSCertificate 簽名相對應(yīng)的一些位

ASN.1

它看起來很小，但是每個對象都有一定深度。

TBSCertificate是最大的TBSCertificate，包含一堆有關(guān)客戶端，CA，客戶端的公鑰等信息。

DER

當(dāng)然不會像這樣發(fā)送證書。而使用DER將其編碼為二進制格式。

每個字段名都會被忽略，如果我們證書的形成方式，那么將不可能理解每個值的含義。

每個值都編碼為TLV三元組：[TAG，LENGTH，VALUE]

例如，查看Github的證書

右邊是DER編碼證書的十六進制轉(zhuǎn)儲，左邊是ASN.1格式的譯文。

如上面所見，如果沒有RFC，我們真的不知道每個值對應(yīng)什么。openssl工具中自帶了很方面的命令行工具，可以用來解析證書的內(nèi)容，簡單使用

openssl x509 -in cert.pem -noout -text即可

Let's Encrypt數(shù)字簽名

說到數(shù)字簽名就不能不對Let's Encrypt豎起大拇指，可以說它以一己之力為整個互聯(lián)網(wǎng)網(wǎng)站撐起了HTTPS的天。Let's Encrypt成立于2014年，是一家非盈利性的認證機構(gòu)，目前為約2億個網(wǎng)站提供了數(shù)字證書認證，累積簽發(fā)了10億張的證書。

[[318393]]

Let's Encrypt成功的關(guān)鍵取決于兩點：

(1) 它是免費的。Let's Encrypt之前，大多數(shù)證書頒發(fā)機構(gòu)向要獲得證書的網(wǎng)站管理員收取費用。

Let's Encrypt證書和商業(yè)證書的區(qū)別：

(2) 它是自動化的。如果遵循其標(biāo)準(zhǔn)化協(xié)議，則可以通過API請求，續(xù)訂甚至吊銷證書。與此形成對比的是其他證書機構(gòu)需要手動處理并需要一些時間來頒發(fā)證書。

如果網(wǎng)站管理員希望網(wǎng)站example-com(通過HTTPS)向用戶提供安全的連接，則可以向Let's Encrypt發(fā)出申請證書，并在證明自己擁有域example-com并頒發(fā)證書后，便可以使用該證書來與任何信任"Let's Encrypt"的瀏覽器協(xié)商安全連接。

這個實際流程如下：

• Alice使用RSA公鑰在Let's Encrypt中注冊。
• Alice要求Let's Encrypt證書example-com。
• Let's Encrypt讓Alice證明自己是example-com所有者，需要簽發(fā)一些數(shù)據(jù)并將其上傳到example-com/.well-known/acme-challenge/some_file。
• 愛麗絲簽署并上傳簽名后，要求Let's Encrypt其進行檢查。
• Let's Encrypt檢查是否可以訪問上的文件example-com，如果它成功下載了簽名并且簽名有效，則Let's Encrypt向Alice頒發(fā)證書。

這個過程的流程圖如下：

數(shù)字證書劫持

那么，我們假設(shè)Alice并不會實際擁有example-com，但是她通過中間劫持的方法實現(xiàn)了步驟5中進行加密。自從Let's Encrypt推出以來，這一直是個問題。事實上普林斯頓大學(xué)的一組研究人員在Bamboozling證書頒發(fā)機構(gòu)的BGP中證明了這一點：他們執(zhí)行了一個真實的BGP攻擊演示，以合乎道德的方式從頂級CA獲得虛假證書。為了評估PKI的脆弱性，研究人員收集了180萬個證書的數(shù)據(jù)集，發(fā)現(xiàn)這些數(shù)據(jù)集中絕大多數(shù)域都可以成功偽造證書。

該論文中，研究人員提出了兩種解決方案，以進行補救，或至少降低這些針對KPI攻擊的風(fēng)險：

• CA機構(gòu)從多個有利位置對域名進行驗證，以使其難以發(fā)起成功的攻擊;
• CA機構(gòu)通過BGP監(jiān)視系統(tǒng)，檢測可疑BGP路由并延遲證書驗證使網(wǎng)絡(luò)運營商有時間對BGP攻擊做出反應(yīng)。

最近Let's Encrypt實現(xiàn)了第一個解決方案：多角度域驗證。該方法改變了上述流程的第5步：在新的策略下Let's Encrypt會從多個位置下載域名的證書驗證。

Let's Encrypt攻擊的工作原理

安德魯·艾耶(Andrew Ayer)在2015年發(fā)現(xiàn)了對Let's Encrypt的攻擊。在其中，Andrew提出了一種方法來控制已經(jīng)驗證了域的Let's Encrypt帳戶(例如example-com)

攻擊是這樣的：

• Alice通過在example-com上的一些數(shù)據(jù)上載簽名(example-com/.well-known/acme-challenge/some_file) 來注冊并完成域驗證。然后，成功地從Let's Encrypt獲得證書。
• 之后Eve使用新帳戶和新的RSA公鑰簽署了Let's Encrypt，并請求恢復(fù)example-com域
• Let's Encrypt要求Eve簽發(fā)一些新數(shù)據(jù)，并將其上傳到example-com/.well-known/acme-challenge/some_file。
• Eve制作了一個新的假冒密鑰對，并在Let's Encrypt上更新了其公共密鑰。然后，她要求Let's Encrypt以檢查簽名。
• Let's Encrypt從example-com獲取簽名文件，簽名匹配，于是Eve被授予example-com域所有權(quán)。

攻擊的圖示如下：

在上述攻擊中，Eve設(shè)法創(chuàng)建了一個有效的公鑰，該公鑰驗證了給定的簽名和消息。數(shù)字簽名不能唯一地標(biāo)識密鑰或消息

根據(jù)RSA的工作原理(這是現(xiàn)代證書交換鏈的基礎(chǔ))：

對于固定簽名signature和(PKCS#1 v1.5)消息message，公鑰(e，N)必須滿足以下方程式以驗證簽名：

一個人可以很容易地制作一個(大部分時間)滿足以下等式的公鑰：

可以輕松驗證驗證是否有效：

根據(jù)定義，最后一行是正確的。

數(shù)字簽名的安全性

由于理論領(lǐng)域與應(yīng)用領(lǐng)域之間安全性證明與已實施協(xié)議之間存在差距。密碼學(xué)中的簽名通常使用EUF-CMA模型進行分析，該模型代表自適應(yīng)選擇消息攻擊下的存在不可偽造性。

通過模型中，生成了一個密鑰對，然后要求簽署一些任意消息。在觀察簽署的簽名時，如果可以在某個時間點對未請求的消息產(chǎn)生有效的簽名，將獲勝。

不幸的是，盡管現(xiàn)代簽名方案似乎通過了EUF-CMA測試，但它們往往表現(xiàn)出一些令人驚訝的特性。論文《Automated Analysis of Subtle Attacks on Protocols that Use Signatures》中Dennis Jackson，Cas Cremers，Katriel Cohn-Gordon和Ralf Sasse試圖對使用簽名的協(xié)議進行細微的攻擊的自動化分析，試圖列出這些令人驚訝的特性以及受它們影響的簽名方案(然后找到一堆)在使用正式驗證的協(xié)議。

保守的排他性(CEO)/破壞性的排他性(DEO)：

(1) 密鑰替換攻擊(CEO)，其中使用不同的密鑰對或公鑰來驗證給定消息上的給定簽名。

(2) 消息密鑰替換攻擊(DEO)，其中使用不同的密鑰對或公共密鑰來驗證新消息上的給定簽名。

• 可延展性。大多數(shù)簽名方案都是可塑的，這意味著如果給出一個有效的簽名，就可以對其進行篡改，以使其成為一個不同但仍然有效的簽名。請注意，如果我是簽名人，通常可以為同一條消息創(chuàng)建不同的簽名。不清楚這是否會對任何現(xiàn)實世界的協(xié)議產(chǎn)生影響，盡管比特幣MtGox交易所將其資金損失歸咎于該協(xié)議，2014年2月，曾經(jīng)是最大的比特幣交易所MtGox關(guān)閉并申請破產(chǎn)，聲稱攻擊者利用可塑性攻擊來耗盡其帳戶。

請注意，一種新的安全模型SUF-CMA(用于強EUF-CMA)試圖將這種行為包含在簽名方案的安全定義中，并且一些最新標(biāo)準(zhǔn)(如RFC 8032指定Ed25519)正在緩解對其簽名方案的延展性攻擊。。

• 可重新簽名。這很容易解釋。要驗證消息上的簽名，通常不需要消息本身，但需要摘要。這樣，任何人都可以使用自己的密鑰重新簽名消息，而無需知道消息本身
• 可碰撞性。有些方案允許制作簽名，這些簽名將在幾條消息下進行驗證。更糟糕的是，按設(shè)計Ed25519允許人們制作公鑰和簽名，從而很有可能驗證任何消息。(在某些實現(xiàn)中，例如libsodium，此問題已修復(fù)。)

下圖中概括了證書替代攻擊：

最后，好的簽名方案會將有有效的安全的方法都會累積完善起來，所以在使用時候選擇主要的方法一般是沒有問題。而如果你要重復(fù)造輪子，要自己實現(xiàn)一套更為復(fù)雜的加密協(xié)議，則需要考慮這些問題。