已签名的 jar 篡改验证

Signed jar tamper verification

我有一个将 OSGI 包作为自签名 jar 文件提供的网络服务器。这些是使用 OSGI API 在我的设备上下载和安装的。我在 knopflerfish OSGI 中启用了安全性,并使用我的 public 密钥将其指向密钥库。我想验证我下载的代码不会在 MITM 攻击或其他情况下被篡改。

为了测试这一点,我尝试稍微更改并重新编译我之前签名和验证的一个包,使用 7zip 解压旧的、签名的 jar 和新编译的 jar,并复制 META-INF 的内容文件夹,覆盖仍未签名的 MANIFEST.MF 并提供 .SF 和 .RSA 文件。 当我尝试下载并安装这个 jar 文件时,我确实遇到了一个错误:

[stderr] org.osgi.framework.BundleException: Failed to install bundle: java.io.IOException: MANIFEST.MF must be first in archive when using signatures.
[stderr]        at org.knopflerfish.framework.Bundles.install0(Bundles.java:178)
[stderr]        at org.knopflerfish.framework.SecurePermissionOps.run(SecurePermissionOps.java:727)
[stderr]        at org.knopflerfish.framework.SecurePermissionOps.run(SecurePermissionOps.java:723)
[stderr]        at java.security.AccessController.doPrivileged(Native Method)
[stderr]        at org.knopflerfish.framework.SecurePermissionOps.callInstall0(SecurePermissionOps.java:722)
[stderr]        at org.knopflerfish.framework.Bundles.install(Bundles.java:118)
[stderr]        at org.knopflerfish.framework.BundleContextImpl.installBundle(BundleContextImpl.java:109)
[stderr]        at no.aventi.sam.Activator.handleEvent(Activator.java:190)
[stderr]        at org.knopflerfish.bundle.event.TrackedEventHandler.handleEventSubjectToFilter(TrackedEventHandler.java:71)
[stderr]        at org.knopflerfish.bundle.event.InternalAdminEvent.deliverToHandles(InternalAdminEvent.java:153)
[stderr]        at org.knopflerfish.bundle.event.InternalAdminEvent.deliver(InternalAdminEvent.java:114)
[stderr]        at org.knopflerfish.bundle.event.QueueHandler.run(QueueHandler.java:120)
[stderr] Caused by: java.io.IOException: MANIFEST.MF must be first in archive when using signatures.
[stderr]        at org.knopflerfish.framework.bundlestorage.file.Archive.downloadArchive(Archive.java:271)
[stderr]        at org.knopflerfish.framework.bundlestorage.file.BundleArchiveImpl.<init>(BundleArchiveImpl.java:133)

[stderr]        at org.knopflerfish.framework.bundlestorage.file.BundleStorageImpl.insertBundleJar(BundleStorageImpl.java:219)
[stderr]        at org.knopflerfish.framework.Bundles.install0(Bundles.java:161)
[stderr]        ... 11 more

我也尝试了另一种方法,将新的 .class 文件复制到正确签名的 jar 中,但得到了同样的错误。

我不确定安全方案的实际验证会得到什么输出。我得到的错误是否意味着 java 检测到错误的签名并因此拒绝了它?或者它只是意味着当我手动写入 jar 文件时 7zip 没有保持结构完整,并且比我更好的黑客仍然可以轻松篡改我的 jar 文件?

jarsigner -verify 篡改的 jar 文件给了我 java.lang.SecurityException: SHA-256 digest error 这更有意义,如果我篡改罐子,我能预料到这一点 'correctly'?

异常告诉你jar文件无效。所以它甚至没有尝试验证签名。

7zip 不适合创建/编辑 jar 文件。您应该使用 java jar 工具。参见 https://www.webucator.com/how-to/how-create-jar-file-java.cfm

(签名的)JAR 的要求之一是清单是 ZIP 文件中的第一个条目。原因是清单包含清单名称部分中 JAR 中资源的摘要。

 Name: foo/bar/Xyz.class
 Digest-SHA-1: 2A345C6D7890F2A345C6D7890F2A345C6D7890F
 Digest-MD5: 7890F2A345C6D789

这些摘要是加载其他资源并验证它们所必需的。签名者文件 (.SF) 包含此 名称部分 的摘要,也是清单格式。然后 .DSA 或 .RSA 文件包含此 .SF 文件的签名。

如果清单不是第一个,您就无法流式传输 JAR,您总是必须将其复制到磁盘,然后从文件中打开它,以便您可以随机访问。通过首先强制 Manifest,JarInputStream 可以在资源到达时加载资源并立即验证它们。不幸的是,Jar signer 工具不是基于标准 JDK 加密库,并且在其他方​​面有点奇怪。您收到不同错误的原因是它可能将 JAR 作为文件打开,因此可以随机访问清单,所以它并不关心清单不是第一个。

该模型非常灵活,但也很难理解。它允许多个签名者,每个签名者都可以对捆绑包进行部分签名。 OSGi 添加了不使用部分签名的额外要求。没有这个要求,我记得有一些安全问题。

请注意,任何人都可以将资源添加到您的包中,如果这些资源未同时添加到清单中的名称部分,则不会被检测到。但是,清单中列出的任何资源都必须与给定的摘要匹配。

其他答案是正确的,因为我的 jar 文件在不考虑文件顺序的情况下使用 7zip 无效,因此安全性不是我遇到问题时遇到的问题。他们没有直接回答我应该怎么做,所以我会展示我是如何工作的,并接受我自己的答案。

我使用 jdk 中的 jar 程序而不是使用 7zip:

用编辑的 .class 文件更新了签名的 jar
jar.exe -uvf <jarfile.jar> </path/to/classfile.class>

这导致了来自 java 的错误:

[stderr] java.lang.SecurityException: SHA-256 digest error for ****.class
[stderr]         at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:223)

对于与签名不同但与 jarsigner -verify

匹配的 class 文件来说,这似乎是一个合理的错误