CA與區(qū)塊鏈驗(yàn)證本質(zhì)上都是數(shù)字簽名，首先，我們看一下什么是數(shù)字簽名！

數(shù)字簽名

數(shù)字簽名是公鑰密碼學(xué)中的一種技術(shù)，用于驗(yàn)證信息的完整性和發(fā)送者的身份。簡而言之，數(shù)字簽名是一種確認(rèn)信息來源和信息完整性的手段。它通常與區(qū)塊鏈、數(shù)字證書、加密郵件等技術(shù)結(jié)合使用。

基本工作原理?

核心要點(diǎn)：信息完整性與身份認(rèn)證！數(shù)字簽名的基本工作原理如下：

1. 消息摘要：首先，使用某種哈希函數(shù)（如SHA-256）計(jì)算原始消息（或文檔）的摘要（digest）。

   1. 摘要是消息的哈希值，是通過某種哈希函數(shù)（如SHA-256）從原始消息中產(chǎn)生的。哈希函數(shù)的特點(diǎn)是，哪怕只有一點(diǎn)點(diǎn)的輸入變化，輸出的哈希值也會發(fā)生巨大的變化。因此，哈希值可以作為消息的“指紋”。

2. 加密摘要：然后，使用發(fā)送者的私鑰加密上一步得到的摘要。這就得到了數(shù)字簽名。

3. 發(fā)送消息及簽名：發(fā)送者將原始消息和數(shù)字簽名一起發(fā)送給接收者。

4. 驗(yàn)證簽名：

   • 接收者使用發(fā)送者的公鑰解密數(shù)字簽名，得到摘要A。
   • 接收者使用相同的哈希函數(shù)計(jì)算收到的原始消息的摘要，得到摘要B。
   • 比較摘要A和摘要B。如果它們匹配，這意味著消息沒有被篡改。

為什么接收者能夠知道發(fā)送者用的哈希函數(shù)呢？

1. 標(biāo)準(zhǔn)化協(xié)議：在許多安全協(xié)議中，哈希函數(shù)（如SHA-256、SHA-3等）已經(jīng)被明確規(guī)定。因此，當(dāng)雙方遵循同一協(xié)議時，他們都知道應(yīng)使用哪個哈希函數(shù)。

2. 數(shù)字證書：在使用數(shù)字證書的場景中（如TLS/SSL），證書中通常會包含用于簽名的哈希函數(shù)的信息。當(dāng)接收者收到證書時，它就可以知道應(yīng)使用哪個哈希函數(shù)來驗(yàn)證簽名。

3. 明確聲明：在某些情況下，發(fā)送者可以在消息的某個部分明確指定使用的哈希函數(shù)。這樣，接收者在收到消息時就知道如何進(jìn)行驗(yàn)證。

總之，為了數(shù)字簽名的有效性和安全性，雙方必須有一個共同的、已知的方式來確定使用哪個哈希函數(shù)。在大多數(shù)現(xiàn)實(shí)世界的應(yīng)用中，這一點(diǎn)已經(jīng)得到了很好的處理和規(guī)定。

數(shù)字簽名的關(guān)鍵作用

• 身份驗(yàn)證：數(shù)字簽名確保了交易的發(fā)送者是交易所聲稱的發(fā)送者。
• 不可否認(rèn)性：一旦發(fā)送者簽署了交易，他們不能否認(rèn)進(jìn)行了該交易。
• 完整性：任何對已簽名的交易的修改都會導(dǎo)致簽名無效，這確保了交易的完整性。

為什么數(shù)字簽名是安全的？它的安全性來自于私鑰的秘密性和公鑰密碼學(xué)的數(shù)學(xué)屬性。私鑰是只有發(fā)送者知道的，而公鑰是可以公開分享的。沒有私鑰，就不能生成一個與給定公鑰匹配的有效簽名，這確保了只有私鑰的持有者才能創(chuàng)建有效的簽名。

中間人攻擊

關(guān)于中間人攻擊：

• 中間人攻擊者確實(shí)可以使用發(fā)送者的公鑰來解密數(shù)字簽名得到摘要A。但是，攻擊者不能使用公鑰來創(chuàng)建一個新的有效簽名，因?yàn)閯?chuàng)建數(shù)字簽名需要發(fā)送者的私鑰，這是攻擊者不知道的。

• 如果攻擊者修改了消息，那么摘要（哈希值）自然會發(fā)生變化。這意味著，即使攻擊者能夠生成新的摘要，他們還需要使用發(fā)送者的私鑰加密新摘要以產(chǎn)生一個新的數(shù)字簽名。由于攻擊者沒有私鑰，他們無法這樣做。

• 因此，接收者在驗(yàn)證過程中會發(fā)現(xiàn)摘要A（從數(shù)字簽名解密得到）與摘要B（從修改后的消息計(jì)算得到）不匹配，從而知道消息已被篡改。

即：任何人都可以得到摘要A和摘要B，但是如果沒有發(fā)送者的私鑰，就無法生成正確的數(shù)字簽名（中間人用自己的私鑰生成數(shù)字簽名有個卵用，接收者又不用中間人的公鑰驗(yàn)證）。所以，中間人只能修改信息，但是不能修改數(shù)字簽名。

轉(zhuǎn)眼中間人又把沒法修改的數(shù)字簽名（沒有私鑰，中間人是無法完美修改的）和修改后的信息給到了接收方，接收方首先通過發(fā)送者的公鑰解密數(shù)字簽名得到摘要A，又使用哈希函數(shù)包裝中間人修改后的信息，得到摘要B'。

因?yàn)楣：瘮?shù)即使只有一點(diǎn)點(diǎn)的輸入變化，輸出的哈希值也會發(fā)生巨大的變化，所以摘要B'和原本正確的、應(yīng)該和摘要A的值相等的摘要B差別巨大，而接收方就是看摘要AB是否相同，現(xiàn)在變成了驗(yàn)證摘要AB'是否相同，很明顯已經(jīng)不同了，所以接收方能快速明白：

1. 經(jīng)過數(shù)字簽名的驗(yàn)證得到摘要A，該信息能夠通過A的公鑰解密，生成合理的有意義的摘要。說明該信息確實(shí)是來自于發(fā)送方，驗(yàn)證了發(fā)送方的身份。

2. 兩種過程產(chǎn)生的摘要信息不同，說明發(fā)送過來的原始數(shù)據(jù)已經(jīng)不完整不正確了，有可能受到中間人的干擾。

據(jù)此，我們說到數(shù)字簽名和消息的驗(yàn)證，有兩個主要的步驟：

1. 驗(yàn)證發(fā)送者的身份：這是通過數(shù)字簽名完成的。只有發(fā)送者的私鑰能產(chǎn)生一個可以由其公鑰解密的數(shù)字簽名。如果攻擊者沒有私鑰，他們無法為任何消息生成有效的簽名。所以，當(dāng)接收者使用公鑰成功解密了數(shù)字簽名并得到了摘要A，這驗(yàn)證了消息是從擁有私鑰的發(fā)送者處發(fā)出的。

2. 驗(yàn)證消息的完整性：這是通過比較兩個摘要來完成的。

   • 摘要A是從數(shù)字簽名解密得到的，它是基于發(fā)送者發(fā)送的原始消息生成的。
   • 摘要B是接收者從他們收到的消息計(jì)算其哈希得到的。

如果攻擊者修改了消息，他們可以很容易地為這個修改后的消息計(jì)算出新的摘要B'（使用哈希函數(shù)就可以，發(fā)送者也是通過哈希函數(shù)生成摘要的，只不過數(shù)字簽名是進(jìn)一步使用私鑰加密）。但問題是，這個摘要B'不會與摘要A匹配（除非攻擊者同時擁有發(fā)送者的私鑰，并且為修改后的消息創(chuàng)建了新的數(shù)字簽名，這在實(shí)際應(yīng)用中是極不可能的情況）。因此，接收者仍然可以檢測到消息被篡改的事實(shí)。

只要有發(fā)送者的私鑰，中間人就可以篡改信息？

理論上，如果攻擊者獲得了發(fā)送者的私鑰，那么他們可以對任何消息進(jìn)行簽名，從而偽裝成該發(fā)送者。這意味著攻擊者可以：

1. 生成一個篡改后的消息。
2. 使用發(fā)送者的私鑰為這個篡改后的消息創(chuàng)建一個數(shù)字簽名。
3. 將篡改后的消息和新的數(shù)字簽名發(fā)送給接收者。

在這種情況下，當(dāng)接收者進(jìn)行驗(yàn)證時：

1. 使用發(fā)送者的公鑰，接收者可以解密數(shù)字簽名并獲得摘要。
2. 接收者還會對篡改后的消息生成一個摘要。
3. 由于這兩個摘要是匹配的，接收者可能會認(rèn)為這個篡改后的消息確實(shí)來自原始發(fā)送者。

因此，確實(shí)，如果攻擊者獲得了私鑰，他們可以篡改消息并偽造有效的數(shù)字簽名，從而欺騙接收者。

這就是為什么私鑰的安全性非常關(guān)鍵，為什么它必須被嚴(yán)格保護(hù)。在實(shí)際應(yīng)用中，私鑰往往被存儲在安全的環(huán)境中，如硬件安全模塊（HSM），或使用其他加密手段進(jìn)行保護(hù)，以防止未經(jīng)授權(quán)的訪問。

如果私鑰被認(rèn)為是丟失或被盜，應(yīng)立即撤銷相應(yīng)的公鑰證書，并生成一個新的公私鑰對。這確保即使私鑰落入錯誤的手中，它也不能被用于偽造簽名。

作者思考

作者學(xué)到這里的時候，其實(shí)認(rèn)為不需要比較摘要。原因是：如果中間人有私鑰，那么數(shù)字簽名被篡改，摘要AB都可以被輕松修改成新的值，并且相等，比較摘要也比較不出來；如果中間人沒有私鑰，他就不能生成一個合法的簽名，解密后的結(jié)果也將是無意義的，也不用通過比較摘要得出結(jié)論。

是不是看上去很有道理？！其實(shí)作者并沒有理清第二種情況，上面的想法是錯誤的！！

作者搞錯了 “中間人沒有私鑰” 的情況，實(shí)際上，沒有私鑰，中間人未必不能生成正確的簽名，他可以完全不修改簽名??！請讀者明確一點(diǎn)：發(fā)送者傳遞的是原始信息和數(shù)字簽名，如果對于數(shù)字簽名，中間人一點(diǎn)都不改，但他修改了原始信息，這時，倘若沒有摘要比較，那么接收者的行為會是什么樣呢？下面我們綜合比較講解一下：

1. 中間人沒有私鑰，但嘗試篡改消息：

   • 傳遞虛假消息與正確的簽名：這種情況下，雖然簽名是對原始消息的正確簽名，但由于消息已被篡改，所以當(dāng)接收者對篡改后的消息計(jì)算哈希得到新的摘要，并與簽名解密得到的摘要進(jìn)行比較時，會發(fā)現(xiàn)它們不匹配。因此，接收者可以確定消息已被篡改。如果不比較摘要，接收者可能會認(rèn)為這是一個有效的、未被篡改的消息，這是不安全的。

     • 如果只依賴數(shù)字簽名的解密，那么在這種情況下，接收者可能會誤以為消息是有效的。因?yàn)閷?shí)際上傳遞的簽名中不包含所有的信息，只有摘要。簽名正確，不意味著你額外傳遞的原始信息正確，除非將原始信息葉轉(zhuǎn)換成摘要，和簽名轉(zhuǎn)換的摘要對比，才能驗(yàn)證原始信息正確，所以這種情況下摘要比較是必要的。

   • 傳遞虛假消息與錯誤的簽名：這種情況下，由于簽名是錯誤的，當(dāng)接收者嘗試用公鑰解密它時，解密后的結(jié)果將不是有效的摘要格式。即使解密操作可以完成，得到的結(jié)果與任何有效的摘要都不會匹配。此外，當(dāng)接收者對篡改后的消息計(jì)算哈希得到新的摘要，并與簽名解密得到的摘要進(jìn)行比較時，會發(fā)現(xiàn)它們不匹配。因此，接收者會知道消息已被篡改。

     • 當(dāng)接收者使用公鑰對錯誤的簽名進(jìn)行解密時，得到的結(jié)果確實(shí)不會是一個有效的摘要，這時就已經(jīng)能夠確定消息或簽名被篡改了。因此，確實(shí)沒有必要再進(jìn)行摘要比較。

2. 中間人有私鑰：這是一種非常罕見的情況，因?yàn)樗借€應(yīng)當(dāng)被妥善保管，不應(yīng)落入他人之手。但如果這確實(shí)發(fā)生了，那么中間人確實(shí)可以偽造任何消息，并為其創(chuàng)建有效的簽名。這種情況下，數(shù)字簽名和摘要驗(yàn)證的確都會失效。這也是為什么私鑰的安全性是如此重要的原因。

3. “消息正確、簽名錯誤”的情況通常不會發(fā)生。

比較摘要的意義（了解）

1. 系統(tǒng)的健壯性：摘要比較提供了一個另外的安全層。這在系統(tǒng)設(shè)計(jì)中是一個常見的原則，即不完全依賴一個安全機(jī)制（數(shù)字簽名），而是使用多重機(jī)制。這可以抵御未知的攻擊和缺陷。

2. 誤操作或傳輸錯誤：在數(shù)字簽名有效的情況下，消息在傳輸過程中可能會受到損壞，如因網(wǎng)絡(luò)問題、存儲問題等。通過比較摘要，可以驗(yàn)證消息的完整性。

3. 舊的或延遲的消息：攻擊者可能會重放舊的消息。雖然這些消息的數(shù)字簽名是有效的，但它們可能不再是最新或者相關(guān)的。通過比較摘要，可以檢查消息是否是最新的。

4. 確認(rèn)發(fā)送者的真實(shí)意圖：比如，攻擊者可能會截獲一個有效的、簽名過的消息，然后將它發(fā)送給另一個不相關(guān)的接收者。盡管數(shù)字簽名是有效的，但消息可能不是發(fā)送者打算發(fā)送給這個特定接收者的。通過比較摘要，可以確保消息是發(fā)送者打算發(fā)送的。

5. 未來證明：摘要比較也為未來可能出現(xiàn)的新的攻擊或漏洞提供了保護(hù)。盡管現(xiàn)有的簽名算法可能是安全的，但未來可能會發(fā)現(xiàn)它的弱點(diǎn)。摘要的存在和驗(yàn)證提供了一個額外的安全層，使得對消息的完整性和來源的驗(yàn)證更加嚴(yán)格。

現(xiàn)在我們對誤操作或傳輸錯誤進(jìn)行學(xué)習(xí)：

誤操作或傳輸錯誤

1. 發(fā)送過程：

   • Alice想向Bob發(fā)送一個簡單的消息："Hello"。
   • Alice首先對這個消息進(jìn)行哈希，得到一個摘要，例如（為了簡化，假設(shè)摘要只是消息的第一個字母）：摘要 = "H"。
   • Alice使用她的私鑰對摘要進(jìn)行加密，得到數(shù)字簽名。
   • 然后，Alice將消息："Hello" 和數(shù)字簽名一起發(fā)送給Bob。

2. 傳輸過程中的錯誤：

   • 在傳輸過程中，由于網(wǎng)絡(luò)故障、軟件錯誤或其他原因，消息的某個部分被誤改。假設(shè)，由于這種錯誤，Bob收到的消息變成了："Hellp"，而不是原始的"Hello"。

3. Bob的驗(yàn)證過程：

   • Bob首先使用Alice的公鑰解密數(shù)字簽名，得到摘要A，這個摘要是"H"。
   • 然后，Bob對他收到的消息"Hellp"進(jìn)行哈希，得到一個摘要B，這個摘要是"P"（因?yàn)槲覀兗僭O(shè)摘要只是消息的最后一個字母）。
   • Bob比較摘要A和摘要B，發(fā)現(xiàn)它們不匹配（"H"不等于"P"）。

因此，Bob知道他收到的消息已經(jīng)在傳輸過程中被更改或損壞了。

• 如果Bob只解密數(shù)字簽名，他會得到一個摘要。這個摘要是原始消息的摘要，但由于消息已經(jīng)被修改，這個摘要不能與當(dāng)前消息匹配。
• 如果Bob沒有使用哈希函數(shù)再次對收到的消息進(jìn)行哈希，他將無法知道消息已經(jīng)被修改。只有當(dāng)他使用哈希函數(shù)對收到的消息進(jìn)行哈希并將其與解密的摘要進(jìn)行比較時，他才會發(fā)現(xiàn)摘要不匹配。

此外，也請大家明確一點(diǎn)：

當(dāng)接收到的消息出現(xiàn)錯誤或與數(shù)字簽名不匹配時，這種不匹配可能是由于多種原因引起的：

1. 中間人攻擊：惡意的第三方可能已經(jīng)修改了消息內(nèi)容，試圖篡改或偽造消息。
2. 消息傳輸錯誤：在數(shù)據(jù)傳輸過程中，由于網(wǎng)絡(luò)問題或其他因素，消息可能出現(xiàn)了誤差。這可能是由于噪聲、數(shù)據(jù)包丟失或數(shù)據(jù)包順序錯亂等原因引起的。
3. 軟件或硬件故障：發(fā)送或接收消息的設(shè)備可能出現(xiàn)了故障，導(dǎo)致消息被誤改。

當(dāng)數(shù)字簽名驗(yàn)證失敗時，我們只知道消息與原始簽名不匹配，但我們不能確定是上述哪種情況導(dǎo)致的不匹配。因此，數(shù)字簽名機(jī)制確實(shí)不能單獨(dú)確定消息的不匹配是由于哪種原因引起的。

這也是為什么在實(shí)際的安全通信中，我們不僅依賴數(shù)字簽名，還會使用其他機(jī)制，如錯誤檢測和糾正代碼、時間戳、證書、雙向認(rèn)證等，以提高消息的完整性、認(rèn)證性和非否認(rèn)性。

總而言之，數(shù)字簽名只能確認(rèn)消息與原始簽名是否匹配。如果不匹配，數(shù)字簽名不能告訴我們?yōu)槭裁床黄ヅ洌怯捎谥虚g人攻擊、傳輸錯誤、還是其他原因。所以，雖然數(shù)字簽名提供了數(shù)據(jù)完整性和身份驗(yàn)證，但在實(shí)際應(yīng)用中，為了增強(qiáng)安全性，通常還需要結(jié)合其他安全措施和機(jī)制。

如何防止中間人篡改數(shù)字簽名？

關(guān)于防止中間人攻擊和消息篡改，以下是一些方法：

1. 使用安全的通信協(xié)議：例如，使用TLS/SSL來加密傳輸中的數(shù)據(jù)。這確保了數(shù)據(jù)的機(jī)密性和完整性，并驗(yàn)證了雙方的身份。

2. 數(shù)字證書和CA（證書頒發(fā)機(jī)構(gòu)）：數(shù)字證書包含公鑰及其所有者的信息，并由受信任的第三方（即CA）簽名。接收者可以驗(yàn)證數(shù)字證書的有效性來確定公鑰的真實(shí)性和合法性，從而避免中間人攻擊。

3. 時間戳和過期時間：為消息或簽名添加時間戳可以防止重放攻擊，確保消息在特定的時間窗口內(nèi)是有效的。

4. 使用多重簽名：在某些情況下，一個操作可能需要多方的批準(zhǔn)。通過要求多個數(shù)字簽名，可以增加系統(tǒng)的安全性。

數(shù)字簽名在區(qū)塊鏈中的應(yīng)用

數(shù)字簽名在區(qū)塊鏈技術(shù)中起到了核心的作用，特別是在確保交易的完整性和不可否認(rèn)性方面。在區(qū)塊鏈中，不是保存上一個區(qū)塊的公鑰，而是保存上一個區(qū)塊的哈希值。下面將詳細(xì)解釋區(qū)塊鏈中的數(shù)字簽名機(jī)制：

1. 數(shù)字簽名的基本原理:

   • 當(dāng)某人想在區(qū)塊鏈上發(fā)送一個交易時，他們首先創(chuàng)建一個交易的描述，這通常包括發(fā)送者的地址、接收者的地址、金額等信息。
   • 發(fā)送者使用他們的私鑰對這個交易描述進(jìn)行簽名，生成數(shù)字簽名。
   • 交易（包括交易描述和數(shù)字簽名）被發(fā)送到網(wǎng)絡(luò)，并由網(wǎng)絡(luò)中的其他參與者（例如比特幣中的礦工）驗(yàn)證。

2. 交易的驗(yàn)證:

   • 網(wǎng)絡(luò)中的驗(yàn)證者使用發(fā)送者的公鑰來驗(yàn)證數(shù)字簽名。如果簽名驗(yàn)證通過，這意味著交易確實(shí)來自聲稱的發(fā)送者并且沒有被篡改。
   • 另外，驗(yàn)證者還會檢查發(fā)送者是否擁有足夠的資金來完成交易。

3. 區(qū)塊的創(chuàng)建:

   • 一旦交易被驗(yàn)證，它會被放入待打包的交易池。
   • 礦工或驗(yàn)證者將這些交易打包成一個新的區(qū)塊。
   • 新區(qū)塊包含了這些交易的信息以及前一個區(qū)塊的哈希值（而不是公鑰）。這種鏈接方式確保了所有區(qū)塊的連續(xù)性和不可更改性。

4. 區(qū)塊的添加:

   • 新創(chuàng)建的區(qū)塊會被添加到區(qū)塊鏈上，成為鏈的一部分。
   • 一旦區(qū)塊被添加到鏈上，其中的交易就被認(rèn)為是已確認(rèn)的，并且難以更改。因?yàn)橐囊粋€區(qū)塊中的信息，你不僅需要更改那個區(qū)塊，還需要更改它之后的所有區(qū)塊，這在計(jì)算上是非常困難的。

數(shù)字簽名確保了區(qū)塊鏈上的每個交易的真實(shí)性和完整性。同時，通過將每個新區(qū)塊鏈接到前一個區(qū)塊的哈希值，確保了區(qū)塊鏈的不可更改性和安全性。

總之，數(shù)字簽名和哈希函數(shù)都是區(qū)塊鏈安全性的基石。數(shù)字簽名確保交易的真實(shí)性，而哈希函數(shù)通過連續(xù)鏈接每個區(qū)塊來確保整個鏈的不可更改性。

數(shù)字簽名在信息安全證書中的作用

信息安全的證書，尤其是X.509證書，是在許多安全應(yīng)用中使用的，包括SSL/TLS、電子郵件加密和身份驗(yàn)證。這些證書為公鑰加密提供了一個框架，允許實(shí)體證明自己的數(shù)字身份，確保數(shù)據(jù)的完整性和機(jī)密性。

以下是關(guān)于X.509證書的詳細(xì)介紹：

X.509證書的結(jié)構(gòu)

• 版本號：表示證書的版本。
• 序列號：證書的唯一標(biāo)識符。
• 簽名算法標(biāo)識：用于簽名證書的算法。
• 頒發(fā)者：簽發(fā)證書的證書頒發(fā)機(jī)構(gòu)(CA)的名稱。
• 有效期：證書的有效開始日期和結(jié)束日期。
• 主題：證書持有者的名稱。
• 公鑰信息：持有者的公鑰及其相關(guān)信息。
• 擴(kuò)展（可選）：關(guān)于證書的其他信息。
• 數(shù)字簽名：由CA的私鑰生成的簽名。

證書的頒發(fā)

• 當(dāng)實(shí)體（可以是個人、組織或設(shè)備）需要證書時，它會生成一個公鑰和私鑰對，然后創(chuàng)建一個證書簽名請求（Certificate Signing Request, CSR），這個請求通常包括公鑰、實(shí)體的名稱（例如網(wǎng)站的域名）和其他相關(guān)信息，這個CSR會發(fā)送給CA。
• CA驗(yàn)證實(shí)體的身份信息，然后生成一個證書，將實(shí)體的公鑰和其他信息利用哈希函數(shù)（通常是SHA256）計(jì)算得到的摘要打包進(jìn)去，并使用CA的私鑰簽名。
• 這個數(shù)字簽名會與原始的公鑰和其他信息一起被打包成一個X.509證書，然后返回給請求的實(shí)體。實(shí)體現(xiàn)在有了一個由CA簽發(fā)的證書，并可以用它證明自己的身份。

  

證書的驗(yàn)證

• 當(dāng)某個實(shí)體（例如，一個網(wǎng)站）向另一個實(shí)體（例如，一個瀏覽器）呈現(xiàn)其證書時，接收者可以使用CA的公鑰來驗(yàn)證證書的簽名。驗(yàn)證過程如下;
  • 驗(yàn)證證書的實(shí)體（瀏覽器）會使用CA的公鑰解密證書中的數(shù)字簽名，得到摘要。
  • 同時，瀏覽器會對證書中的公鑰和其他信息生成一個新的摘要。
  • 如果這兩個摘要匹配，證書就被認(rèn)為是有效的，這意味著它確實(shí)是由CA簽發(fā)的，并且沒有被篡改。
  • 也就是說，驗(yàn)證證書就是數(shù)字簽名驗(yàn)證數(shù)據(jù)完整性的過程。數(shù)字簽名驗(yàn)證中，對原始信息計(jì)算得到摘要；在證書驗(yàn)證中，原始信息包括實(shí)體網(wǎng)站的公鑰和其他信息。
• 如果簽名驗(yàn)證成功，這證明證書是由受信任的CA簽發(fā)的，因此接收者可以信任證書中的公鑰。

證書的有效期和算法更新

• 證書有一個有效期，通常為一年或幾年。這是為了安全考慮，確保即使私鑰被泄露，它也不會被長時間地濫用。
• 隨著時間的推移，加密算法可能會因?yàn)閿?shù)學(xué)進(jìn)展或計(jì)算能力的增強(qiáng)而變得不安全。當(dāng)這發(fā)生時，證書需要使用新的、更安全的算法重新頒發(fā)。這就是證書需要定期更新，以及為什么證書的內(nèi)容（如簽名算法）可能會改變的原因。

CA層次結(jié)構(gòu)

CA（證書頒發(fā)機(jī)構(gòu)）層次結(jié)構(gòu)是一個分層的體系，用于在安全和可信任的方式中管理和頒發(fā)數(shù)字證書。在這種層次結(jié)構(gòu)中，各級的CA具有不同的角色和責(zé)任，它們彼此之間存在信任關(guān)系。以下是關(guān)于CA層次結(jié)構(gòu)的詳細(xì)解釋：

根CA（Root CA）

• 根CA位于CA層次結(jié)構(gòu)的最頂部。它是最受信任的實(shí)體，因?yàn)樗鼮檎麄€證書信任鏈提供基礎(chǔ)。
• 根CA自簽名其證書，意味著它的證書不是由其他CA簽發(fā)的。
• 根證書通常具有很長的有效期，例如10年或20年。
• 當(dāng)瀏覽器或操作系統(tǒng)預(yù)裝了一個根證書，意味著它們信任該根CA及其簽發(fā)的所有下級證書。

中間CA（Intermediate CA）

• 中間CA位于根CA和最終實(shí)體（如網(wǎng)站或個人）之間。
• 中間CA的證書是由上一級CA（可能是另一個中間CA或根CA）簽發(fā)的。
• 使用中間CA可以提供更多的靈活性和安全性。例如，如果中間CA的私鑰被泄露，只需要吊銷該CA的證書，而不需要吊銷整個層次結(jié)構(gòu)的證書。
• 中間CA也可以用于組織內(nèi)部的分部門或分功能管理，或者用于特定的業(yè)務(wù)或地理區(qū)域。

最終實(shí)體CA（End-entity CA）或葉證書（Leaf Certificates）

• 這些是實(shí)際被用于服務(wù)器、客戶端或個人的證書。
• 它們是由中間CA或根CA簽發(fā)的。
• 這些證書具有相對較短的有效期，例如1年或2年。

在實(shí)際應(yīng)用中，當(dāng)我們訪問一個使用SSL/TLS的網(wǎng)站時，網(wǎng)站不僅會提供自身的證書，而且還會提供一個證書鏈。這個鏈從根證書開始，通過一個或多個中間證書，最終到達(dá)網(wǎng)站的證書。您的瀏覽器或操作系統(tǒng)會驗(yàn)證這個證書鏈，確保每個證書都是由其上級簽發(fā)的，并且檢查證書是否被吊銷或過期。CA層次結(jié)構(gòu)提供了一種分層的方法來管理和驗(yàn)證數(shù)字證書。這種結(jié)構(gòu)使得數(shù)字證書系統(tǒng)既有靈活性又有安全性。

信任鏈（Trust Chain）

• 當(dāng)客戶端（例如，一個瀏覽器）接收到證書鏈時，它會嘗試構(gòu)建一個從受信任的根證書到服務(wù)器證書的路徑。這就是信任鏈。
• 為了驗(yàn)證這個鏈，客戶端首先檢查第一個證書（服務(wù)器證書）是否是由第二個證書（中間CA）簽發(fā)的，然后檢查第二個證書是否是由第三個證書簽發(fā)的，以此類推，直到達(dá)到一個預(yù)先知道和信任的根證書。
• 如果客戶端可以成功地驗(yàn)證這個鏈，那么它就會信任服務(wù)器證書。

對于客戶端來說，它接收到的是一個證書鏈，但它試圖建立的是一個信任鏈。簡而言之，證書鏈?zhǔn)欠?wù)器提供給客戶端的，而信任鏈?zhǔn)强蛻舳嘶谶@個證書鏈和它本地受信任的根證書存儲來建立的。文章來源地址http://www.zghlxwxcb.cn/news/detail-765188.html

到了這里，關(guān)于CA與區(qū)塊鏈之?dāng)?shù)字簽名詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！