使用 RSA 实施许可证验证
我即将出售我用 C# 编写的程序，并且我想严格控制它的许可证。这意味着我想让客户端每次启动时都连接到我的服务器。这也使我能够禁用密钥（以防贝宝退款或分发代码）。当然这对于其他用户来说可能会很麻烦，但在这种情况下这是必要的。 由于我无法找到任何好的未破解的.NET 许可系统，因此我想采取自己编写一个小系统的方法。 我的计划是执行以下操作：
- 生成包含软件附带的 1024 个字符的 key.dat（针对每个用户）
- 在应用程序入口点中向我的服务器添加一个 httprequest，该请求发送 key.dat + 当前时间戳（加密）。
- 我的 HTTP 服务器（运行 PHP）解密请求并检查密钥是否有效（在我的数据库中）并回复“访问级别”（许可证类型）。如果密钥无效或被禁用，它会回复错误代码。就像请求一样，回复也带有时间戳，因此某人无法通过向自己发送有效数据包来验证他的程序。正在客户端中检查时间戳。回复使用 RSA 和之前生成的公钥进行加密。
- 客户端收到响应，用私钥解密并做出反应。
RSA 是正确的方法吗？因此我可以确保数据包是由我发送的并且不是由其他人拥有公钥制作的？ 有没有更好的方法来解决这个问题？
I am about to sell a program I have written in C# and I want to control licenses for it, strictly. That means I want to let the client connect to my server every single time it starts. This also gives me the ability to disable keys (in case of chargebacks on paypal or distribution of the code). Of course this might be a hassle for other users, but it is necessary in this case.
Since I was unable to find any good .NET Licensing systems that are uncracked, I wanted to take the approach of writing a little one myself.
My plan was to do the following:
- Generate a key.dat containing 1024 characters that gets shipped with the software (individual to each user)
- In the application entrypoint add a httprequest to my server that sends the key.dat + current timestamp, encrypted.
- My HTTP server (running PHP) decrypts the request and checks if the key is valid (in my database) and replies with the "access level" (license type). If the key is invalid or disabled it replies with an errorcode. Just like with the request, the reply is being salted with a timestamp, so someone can't validate his program by sending a valid packet to himself. The timestamp is being checked in the client. The reply is encrypted with RSA and a previously generated public key.
- Client receives response, decrypts with private key and reacts.
Is RSA the correct approach for this, so I can assure that the packets are sent by me and are not crafted (by noone else having the public key)?
Is there a better approach for solving this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果有人非常想要你的软件，他只会对其进行反编译，并删除在启动时打电话回家的部分代码。
如果您要向应用程序添加一个校验和来检查代码是否已被更改，那么有人可以更改程序检查的校验和（或完全删除检查）。
那些想要你的应用程序足够多的人会找到绕过你能想到的任何类型的保护的方法。你最好坚持做一些简单的事情，拥有一个值得花钱（而且很容易）的产品，并确保它物有所值。
编辑
鉴于保护很重要，用户将在其计算机上运行代码这一事实是您可以避免的风险。如果用户没有密码，就无法破解。他们无法复制并分享它。
现在，它可能不适用于您打算编写的应用程序，但您应该考虑编写 Web、Flash 或 Silverlight 应用程序，而不是常规客户端应用程序。这样您就不必将代码分发给客户。您所要做的就是管理应用程序中的凭据，这应该比您的迂回 RSA 系统容易得多。
以集中模式推出软件的新版本也更容易，而且您根本不必担心被盗。当然，负载将成为一个问题，而以前并不是这样。并非所有应用程序都可以轻松（或根本）集中化。我提出这个建议只是为了确保您考虑它，因为它是解决您问题的有效方法。
基于 Web 的应用程序将具有与您的应用程序相同的问题（即，每当用户离线、每当网络中断、每当您的服务器中断等时，它就会关闭）。因此，在这方面不存在额外的风险。
Someone who wants your software bad enough will just decompile it and remove the part of the code that phones home on startup.
If you were to add a checksum to the app that checks whether the code has been altered, someone can just change the checksum the program checks against (or remove the check entirely).
People who want your application enough will find ways around any type of protection you can conceive. You're better off sticking to something simple, having a product that is worth paying for (and easily) and make sure it's worth the price you're asking.
EDIT
Given that protection is important, the fact that the users will have code running on their machines is a risk you can avoid. If the users don't have the code, they can't crack it. They can't copy it and share it.
Now, it might not apply to the application you intend to write, but you should consider writing a web, Flash or Silverlight application instead of a regular client application. That way you don't have to distribute the code to customers. All you have to do is manage credentials into the application, which should be a lot easier than your round-about RSA system.
It's also easier to push out new versions of the software in a centralized model, and you won't have to worry about theft at all. Of course, load will become an issue when it wasn't before. And not all applications can be centralized easily (or at all). I'm just proposing this to make sure you consider it because it is a valid solution to your problem.
A web-based application will have the same issues as your application (i.e. it will be down whenever the user is offline, whenever the network is down, whenever your server is down, etc). So there's no added risk in that regard.
我不认为 RSA 是您的最佳选择。
PKE（公钥加密）的功能之一是它可以让以前从未交换过信息的各方（例如陌生人）相互交谈。
我认为这不适用于您的情况。您的软件非常了解您的服务器。他们不是“陌生人”。
请考虑使用共享密钥加密，其中您分发的软件的每个副本都被赋予一个唯一的密钥，并且您的服务器也知道每个用户的密钥。密钥永远不会发送，必须受到保护，但仍可用于加密、签名和验证通信。
编辑考虑评论和其他答案后。
任何非常想要您的软件的人都可以完全绕过身份验证。 RSA 没有采取任何措施来阻止这种情况。
真正的问题是：破坏单个许可证是否会使所有许可证变得脆弱/毫无价值。在这两种情况下（RSA 和密钥），答案是否定的。仅仅因为软件的一份副本被黑客攻击并暴露其密钥，或者许可证系统被绕过，其他副本就不会再暴露。在我看来，PKE 和 SSE 在这方面似乎是平等的。
因为共享密钥更容易实现，并且计算执行速度更快，所以我认为在这种情况下它比 RSA/PKE 更受欢迎。这并不是说 RSA 是“错误的”。它将实现您所追求的目标，达到与 SSE 相同的程度（不多也不少）。但我认为上交所是更明智的选择。
I do not think RSA is your best choice.
One of the capabilities of PKE (Public Key Encryption) is that it lets parties talk to each other who previously have never exchanged information before (eg. strangers).
I do not see this applying to your case. Your software knows your server well. They are not "strangers".
Consider instead Shared Secret Key encryption, where each copy of the software you distribute is given a unique secret key, and your server knows each user's secret key as well. The keys are never sent, and must be protected, but can still be used to encrypt, sign, and validate communications.
Edit After considering the comments and other answers.
Anyone who wants your software badly enough will be able to bypass the authentication completely. RSA does nothing to prevent that.
The real question is: Does breaking a single license make all licenses vulnerable/worthless. In both cases, (RSA and Secret Key), the answer is No. Just because one copy of the software got hacked and got its key exposed, or the licenses system bypassed, other copies are no more exposed. PKE and SSE seem equal in that respect to me.
Because Shared Secret Key is easier to implement, and computationally faster to execute, I think it is preferred in this case over RSA/PKE. That is not to say RSA is "wrong". It will accomplish what you are after, to the same degree that SSE will (no more, no less). But I think SSE is the smarter choice.