2.5哈希和代码签名

使用加密验证的历史可以追溯到几十年前，通过诸如MD5和SHA-256之类的算法构建单向哈希。其理念是由于这是不可逆的加密，不能被操控，并且因为哈希理论上应该是唯一的，可以用于表示文件的完整性。如果攻击者修改了软件，并且你计算的文件的结果哈希与软件供应商提供的哈希不匹配，你是安全的。但如果攻击者在替换软件时也替换了哈希呢？它是否以任何方式在带外计算或存储？如果答案是否定的，那么很难确定哈希的合法性。此外，像monomorph（https://github.com/DavidBuchanan314/monomorph）这样的工具允许创建所谓的哈希碰撞，即两个不同的文件可以产生相同的哈希，从而使其唯一性失效。因此，MD5在法医学上已经不被认为是可靠的。更强的哈希机制如SHA-256等更好，但它们仍然存在信任问题。

此外，单独计算哈希的过程在操作上并不高效。考虑以下八步过程：

1. 确定要下载的文件。
2. 下载文件。
3. 确定哈希的存储位置。
4. 下载哈希文件。
5. 确定哈希方法。
6. 如果尚未安装，则下载并安装哈希计算工具。
7. 使用哈希工具处理文件。
8. 将输出与文件的哈希进行比较。

另外，有一些工具可以使这一过程更容易，但你仍然需要处理源文件。一些供应商已经开始在其软件更新机制中执行哈希验证，但很难知道他们在这里具体做了什么以及是否有效。

哈希不仅用于验证下载文件的完整性，还可以确保软件物料清单中元素的有效性，查找恶意软件数据库中的组件哈希，并理解你所看到的证明是否真的与你认为的一致。许多逆向工程工具甚至会创建代码块或函数级别的哈希，以唯一标识函数，在某些工具中被称为函数ID（FIDs）。

然而，哈希可能非常脆弱，因为两个完全相同的文件在生成哈希的过程中，可能会由于生成方式或生成时间的不同而产生不同的哈希。一些典型的场景包括在构建过程中哈希一个组件，而不是在源代码中表示的组件。代码中的优化，如去除符号或特殊字符，可能会导致功能上相同但哈希不同的软件。甚至在Windows和Linux上创建的哈希也可能不同，具体取决于创建哈希时如何处理行尾字符。

法医学中出现的一种技术是哈希相似性，或使用距离算法进行哈希。像ssdeep和TLSH（https://tlsh.org）这样的哈希函数提供了一种手段，用于识别两个哈希何时非常相似，并且在试图识别不完全相同但足够接近以进行比较的独特软件组件时非常有用。

类似于哈希的概念是代码签名，这是一种通过受信实体加密签名代码或文件对象以验证他们生成该工件的技术。这是使用公钥加密完成的，其中签名者使用私钥证明其身份，任何人都可以使用公钥验证签名。

这是一个非常强大的机制，直到你意识到任何人都可以获得代码签名证书，如果验证者不验证签名文件的实体是否是他们期望看到的实体，这可能会导致一种虚假的安全感。在公钥加密的背景下，如果证书颁发机构被破坏，可能会使签名或对所颁发证书的信任失效。最后，我们已经看到几个场景，其中合法软件的签名加密材料被盗并嵌入到恶意文件中，或者实体被破坏并其私钥被盗。然而，如果需要使用时间戳机构（TSA），可以在一定程度上减轻这种风险。

一种出现并显示出希望的技术是通过签名链进行证明。例如，一个大的SBOM可能需要来自多个利益相关者的输入，或者我们可能希望将构建证明与SBOM链接。通过签署这些证明，我们创建了一个机制，可以进行多个证明的自动验证和链接，而无需单个实体了解SBOM的所有方面。

签名领域最新的创新之一是名为Sigstore的努力，它将在后续章节中详细讨论。