使用 jar 签名作为一种许可证密钥
相关这个问题，我是否可以/应该使用 jar 签名来创建一个防篡改 jar，并嵌入信息以在运行时强制执行允许使用该应用程序的用户数量？我的想法是这样的：
- 使用包含静态字段的单个类创建 jar，其中包含正确数量的用户
- 对 jar 进行签名并将其放入 Grails war lib 文件夹中，以便在类路径上
- （假设，这是正确的吗？） 我可以访问我的 Grails 应用程序中签名的 jar 文件中的类中的静态字段可以安全地知道该 jar 没有被篡改（否则将引发异常），并且不需要任何额外的工作，例如“接受”签名。
我的第 3 步假设正确吗？对于我想做的事情来说，这是一个好方法吗？如果不是，标准做法是什么？
谢谢！
Related to this question, can / should I use jar signing to create a tamper proof jar with information embedded for run-time enforcement of the number of users allowed to use the application? My idea is this:
- Create jar with single class containing static field holding the right number of users
- Sign the jar and place in Grails war lib folder so on classpath
- (Assumption, is this correct?) I can access the the static field in the class in the signed jar file from my grails application safely knowing that the jar has not been tampered with (otherwise an exception will be thrown), and also without any extra work required like "accepting" the signature.
Is my step 3 assumption correct? Is this a good approach for what I am trying to do? If not, what is standard practice?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只有当用户必须在某些坚持签名存在且有效的环境中运行它时，它才是“防篡改”。如果您将一个 jar 交给一个可以在普通 JVM 中运行它的普通人（不是作为 applet，不是作为 webstart），他们可以完全删除签名。如果您想尝试阻止这种情况，则必须编写代码来调用 Class.getSigners 并在您没有看到自己时爆炸。因此，他们需要启动 asm 来写出该支票的存在，然后他们就可以开始了。
Java 代码签名允许某些容器验证 jar 文件是否保持其源的完整性。它没有为您提供创建防篡改包的方法。
It's only 'tamper proof' if the user has to run it in some environment that insists that the signature is present and functional. If you hand a jar to an ordinary person who can run it in an ordinary JVM (not as an applet, not as a webstart), they are free to remove the signature altogether. If you want to try to stop this, you'd have to write code to call
Class.getSignersand explode if you didn't see yourself. So, they'd need to fire up asm to write that check out of existence, and they'd be good to go.Java code signing allows some container to verify that a jar file maintains integrity from its source. It does not give you a means of creating a tamper-proof package.
简单的 JAR 签名不起作用。 JAR 签名就是让客户端信任您的 JAR 文件。它不会阻止客户端从您的 JAR 内容（经过调整）创建新的 JAR 并将其作为未签名的 JAR 运行。
JAR 中的类可能会尝试检查它们是否是从适当签名的 JAR 中加载的，但可以调整任何此类类以禁用该检查。因此，对于坚定的攻击者来说，这是一个减速带……但肯定不是一个不可取消的解决方案。
对同时用户实施限制的正常方法是实施单独的许可证管理器/许可证密钥系统；例如FlexLM。 （当然，这也可以通过调整您的类以跳过许可证检查来解决。）
底线是，在客户端控制的计算机上运行的代码的任何许可证管理方案都可以被解决。
Simple JAR signing won't work. JAR signing is all about the client trusting your JAR file. It doesn't prevent the client from creating a new JAR from your JAR's contents (with tweaks) and running it as an unsigned JAR.
Classes in your JAR could attempt to check that they are loaded from a suitably signed JAR, but any such class could be tweaked to disable the check. So that is a speed-bump for a determined attacker ... but certainly not an indefeasible solution.
The normal way to implement limits on simultaneous users is to implement a separate license manager / license key system; e.g. FlexLM. (And of course, that too can be defeated by tweaking your classes to skip the license check.)
The bottom line is that any license management scheme for code running on machines controlled by your client can be defeated.