开发者工具 · 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 密钥。验证校验和的成本很低；签名需要管理信任根。额外的复杂性是真实性的代价。