開發者工具 · SHA 雜湊計算器
匹配的校驗和不是簽名：完整性與真實性
· 為什麼它很重要
sha-256 密碼學 安全
已發佈的 SHA-256 允許使用者偵測損壞的下載，但如果攻擊者控制頁面，他們也會控制校驗和。這篇文章將完整性與真實性分開，並解釋了簽名添加的內容。
校驗和與下載位於同一頁 - 為什麼它可以防止損壞，但不能防止受感染的主機
軟體版本在下載的相同頁面上發布，並帶有 SHA-256 校驗和。使用者可以取得存檔，對其進行雜湊處理，並將結果與發布的值進行比較。如果它們匹配，則下載未損壞。這就是完整性驗證，並是真實且有用的檢查。但是，如果攻擊者破壞了託管該版本的 Web 伺服器，他們可以替換二進位檔案，重新計算其 SHA-256，並更新頁面上的校驗和。使用者驗證校驗和，攻擊者的惡意軟體似乎來自發布者。該系統完全按照設計工作，但它未能回答用戶認為他們提出的問題。
這不是校驗和本身的失敗。這是關於校驗和做什麼和不做什麼的正確觀察。校驗和證明資料的兩個副本是相同的。它不能證明誰創建了資料。這就是完整性和真實性之間的區別，將它們混為一談是發布驗證中最常見的安全錯誤之一。許多系統被破壞並不是因為它們的校驗和錯誤，而是因為使用者相信它們能夠回答他們無法回答的問題。
雜湊證明了什麼——兩個輸入是相同的位元組，並不知道是誰產生了它們
完整性是資料本身的屬性。如果您有檔案及其 SHA-256，且該檔案尚未修改，則雜湊值相符。哈希證明每個位元組與計算時相比沒有變化。如果檔案因傳輸錯誤、磁碟故障或網路電纜上的翻轉位元而損壞，則雜湊將不匹配。這就是校驗和的擅長之處。他們非常擅長發現事故和隨機腐敗。他們無法對抗也可以計算哈希值的對手。
真實性是關於誰產生資料的宣告的屬性。問題「此檔案來自我信任的發布者嗎？」與「這個檔案是否被修改過？」的問題有根本的不同。哈希本身無法回答真實性問題，因為任何人都可以計算哈希。修改檔案的攻擊者可以計算新的雜湊值並像合法發布者一樣輕鬆地發布它。哈希是對稱的；防禦者和攻擊者都具有相同的計算能力。
可信通道要求 - 為什麼校驗和僅與您獲得它的地方一樣可信
可信通道需求是關鍵見解。校驗和的可信度取決於它所通過的通道。如果您從發行商的官方 CDN 下載軟體二進位檔案並從同一台伺服器下載校驗和，則它們會走相同的路徑。破壞伺服器意味著攻擊者控制兩者。校驗和可防止交付過程中的損壞（損壞的檔案將不符），但不能防止控制來源的攻擊者。校驗和和檔案共享單點故障。
如果校驗和是在不同的伺服器上使用不同的存取控制單獨發布的，那麼它可以提供更多的防禦。破壞主站點的攻擊者需要破壞兩個位置才能偽造配對。這更好，但它仍然依賴兩個獨立的控制點來保持安全。攻擊者現在必須破壞兩個系統而不是一個系統，這提高了攻擊成本。但這仍然不能證明真實性；這只是一次更昂貴的攻擊。
簽章將雜湊值綁定到身分 - 如何使用私鑰對摘要進行簽署以增加真實性
數位簽章透過使用加密技術將資料綁定到身分來解決這個問題。發布者產生一個金鑰對：他們保密的私鑰和他們發布的公鑰。他們透過計算摘要然後使用私鑰加密該摘要來簽署檔案。結果就是簽名。使用者透過使用發布者的公鑰解密簽章並檢查結果是否與接收的檔案的計算摘要相符來驗證簽章。密碼學產生了校驗和無法實現的不對稱性。
如果這有效，則證明了兩件事：資料與發布者簽署的摘要匹配，並用於簽署的私鑰與發布的公鑰匹配。這證明了它是發布者創建的，而不僅僅是攻擊者創建的。公鑰必須透過安全通道（通常是來自受信任的憑證授權單位的憑證）取得，但一旦擁有公鑰，您就可以無限期地驗證來自該發行者的簽章。現在的攻擊需要竊取私鑰，這比破壞網頁伺服器要困難得多。
工作範例 - 三種威脅情境（損壞的鏡像、受損的頁面、惡意內部人員）以及每個擷取的校驗和和簽名
三種威脅情境說明了這種差異。情況一：下載鏡像因隨機錯誤而損壞。校驗和捕獲它；簽名抓住了它。兩者都同樣有效，因為兩者都不需要擊敗攻擊者。場景二：鏡像被攻擊者取代了檔案和校驗和。校驗和無法保護；簽名仍然有效，因為攻擊者沒有私鑰，無法偽造有效簽名。攻擊者可以發布任何內容，但簽名證明它不是來自發布者。
場景三：CDN 遭到破壞，但簽名是透過不同管道發布的。 CDN 上的校驗和無法信任，但驗證簽章仍然有效，因為完整性檢查以加密方式與發布者的金鑰相關聯，而不是與通道相關聯。攻擊者現在必須偽造簽名，這需要私鑰。簽名是唯一能在伺服器外流後存活下來的驗證。這就是為什麼簽名對於真實性是必要的；儘管管道受到損害，它們是唯一可以證明身份的工具。
TLS 的作用及其限制 — 傳輸安全保護傳輸中的下載，而不是發布者的伺服器
傳輸安全保護與憑證指定的主機的連線。它可以阻止路徑上的觀察者替換下載字節，但不能使受損的發布者來源變得誠實。如果該來源提供修改後的存檔和透過有效 TLS 新計算的校驗和，則兩者都完好無損地到達並仍然描述攻擊者控制的內容。
這就是為什麼傳輸、完整和真實性是不同的層。 TLS 保護通道的安全，摘要比較字節，簽章將驗證結果與私鑰的控制連結起來。任何層都不應該被描述為證明另一層提供的屬性，即使發布工作流程明智地結合了所有三層。
這不包括什麼－金鑰分發和信任根，這是簽章的困難部分
密鑰分配是該摘要計算器不會跨越的硬邊界。簽章驗證者仍然需要真實的公鑰或憑證鏈以及輪換、撤銷和可接受的演演算法的策略。不受信任密鑰下的數學上有效的簽名僅證明該不受信任密鑰的持有者簽署了位元組。
因此，工作場景在可信任金鑰已經可用的情況下停止。他們沒有規定證書固定、公鑰基礎設施或發布密鑰儀式。這些部署選擇需要自行審查設計； ToolAcre 提供可以簽署的明文摘要，而不是用於驗證身分的信任根。
重點：完整性校驗和真實性簽章 — ToolAcre SHA 雜湊計算器計算摘要；驗證誰發布了它們是一個單獨的步驟
ToolAcre SHA 雜湊計算器計算此驗證的完整性。使用它對下載的檔案進行哈希處理並對照發布的值進行檢查。如果它們匹配，則下載未損壞。但是，如果由於攻擊者重寫了兩者而導致它們匹配，則僅靠完整性驗證將無法捕獲它。該工具誠實地對待這一限制，並不聲稱可以驗證真實性。僅出於完整性考慮，校驗和是快速且良好的。為了保證真實性，您需要簽名。 TLS 為下載本身提供傳輸安全性。與伺服器的連線經過加密和身份驗證，因此網路上的攻擊者無法修改傳輸中的檔案。但是，如果伺服器本身受到威脅，TLS 就無濟於事。受感染的伺服器可以透過任何安全 TLS 連線提供任何檔案。這就是為什麼應用程式層級驗證（校驗和和簽名）與傳輸安全分開的重要性。
軟體發佈中的常見模式是發佈校驗和和簽章。校驗和很方便；使用者可以使用一行 shell 命令快速驗證它們。簽名為擁有發布者公鑰的用戶提供了真實性。使用者可以先檢查校驗和以實現快速完整性傳遞，然後根據儲存在其 GPG 金鑰環中的金鑰驗證簽章的真實性。這兩種檢查有不同的目的，並可以分層進行深度防禦。簽署的難點在於金鑰分發和信任。您需要發布者的公鑰，並您需要相信它確實是他們的。這就是證書頒發機構要解決的問題：它們簽署發布者證書，並根 CA 證書預先加載在瀏覽器和作業系統中。對於較小的項目，您可以在單獨的強化網站或公鑰伺服器上發布 GPG 金鑰。驗證校驗和的成本很低；簽章需要管理信任根。額外的複雜性是真實性的代價。