如何创建序列密钥以保护应用程序 [英] How to create serials key to protect an application

问题描述

我有一个创建串行密钥的应用程序，如下所示：

I have an application that creates a serial key as follows:

Take customername
Sign customername using privatekey and sha/dsa algorithm

然后可以通过使用公钥解码并检查cuastomername匹配来检查许可证

Then license can be checked by decoding with public key, and checking cuastomername matches

除了生成的序列相当长外，这没关系。因此，客户输入序列密钥并不是真正实用，而是必须在文件中提供序列，这与薄雾应用程序和工作方式有很大不同，并且令人困惑。

This works okay except that the generated serial is rather long. So it is not really practical for customer to type in the serial key instead they have to provide a serial with in a file, which is rather different to how mist applications and work and is confusing.

许多其他应用程序仅在用户购买时向其提供Guid

Many other applications just provide the user with a Guid when they make a purchase

即5bd1060b-8608-4817-93ca-207f7c828e2f

i.e 5bd1060b-8608-4817-93ca-207f7c828e2f

并且用户必须输入他们的电子邮件地址和guid来许可他们的申请。

and the user has to enter their email address and guid to license their application.

这对用户来说看起来像一个更整洁的解决方案但我不明白这样的应用程序如何验证来自无效guid的有效guid，除非它通过检查数据库上的emailaddress / guid对在线完成。但是我真的希望在不需要在线检查的情况下进行某种验证：

This looks like a neater solution for the user but I don't understand how such an application verifies a valid guid from an invalid guid unless its done all online by checking emailaddress/guid pairs on a database. But I really would like some kind of verification to be done without requiring an online check otherwise:

a>如果互联网连接/我的服务器关闭$ b，应用程序将无法运行$ b或
b>他们可以通过禁用互联网访问来规避检查

a>The application will not work if internet connection/my server down or b>they can circumvent check by disabling internet access

编辑：

我的理解解决方案如下面的答案所示：

用户购买

取电子邮件地址+盐

使用SHA1加密可提供160位哈希值
转换为十六进制表示法可提供20个十六进制值，即40个字符

最后8个字符的最后一个为Guid提供>
电子邮件用户Gui和电子邮件地址，他们输入程序
程序通过获取电子邮件地址，添加盐，加密ectera
并检查生成有效的guid来验证此配对。

User makes purchase
Take emailaddress + salt
Encrypt with SHA1 gives 160bit hash
Convert to hex notation gives 20 hex values, i.e 40 characters
Lop of last 8 characters to give a Guid
Email User Gui and Email address which they enter into program Program verifies this pairing by taking the email address, adding salt, encrypting ectera and checking generates a valid guid.

我的主要问题是我需要将盐存储在某个地方的程序中，因此如果黑客找到盐并找出我正在做的事情，他们可以创建一个任何电子邮件地址的有效许可密钥生成器

My main problem with this is that I need to store the salt in the program somewhere, therefore if the hacker finds the salt and works out what Im doing they can create a valid license key generator for any email address.

我目前使用其他程序的方法：

我已经生成了一个公钥/私钥对

用户购买

我通过签署电子邮件地址生成许可证

BaseEncode生成的许可证

发送许可证到user

程序通过basedecoding验证许可证并使用公钥解密

I have generated a public key/private key pair
User makes purchase
I generate a license by signing the emailaddress
BaseEncode the generated license
Send license to user
Program verifies license by basedecoding and decrypting with public key

我的问题是当我签署电子邮件地址时太长所以我最终将它放在一个文件而不是用户将其输入字段，但问题可能是我是base64encoding而不是转换为十六进制。

My problem has been that when I sign the emailaddress is too long so I end up putting it in a file instead of the user entering it into a field, but maybe the problem is that I am base64encoding rather than converting to Hex.

输出多长时间签名是，它取决于输入的长度还是总是相同的？

How long can the output of signing be, does it depend on the length of the input or is it always the same ?

因为我用公钥解密密钥，所以我可以删除一些字符许可证密钥，但如果生成密钥只有40个字符，我想这没关系

Because I decrypt the key with the public key I canot lop some chars of the license key, but if the generate key is only 40 characters I guess that is okay

我认为这种方法的优点是即使哈cker计算出我是如何做的，他们不能创建许可证生成器，因为他们没有，并且无法获取私钥，因为它只存储在我的服务器上。如果他们创建了新的私钥/公钥配对，他们只能生成许可证，然后如果我的应用程序有自己编码的公钥，则应用程序可以拒绝许可证。

I think the advantage of this method is that even if hacker works out how I'm doing things, they cannot create a license generator because they do not, and cannot get the private key because it is only stored on my server. They could only generate licenses if they created a new private/public key pairing and then if my application had the public key encoded in itself the application could reject the license anyway.

当然，他们可以破解应用程序，但如果应用程序定期更新，这将会有很多努力。

Of course they could hack the application, but if the application was updated regularly this would become alot of effort.

所以总结：
我是否理解这一点，哪种方法最好，以及为第二种方法生成了多少数据。

So in summary: Have I understood this correctly, which method is best, and how much data is generated for second approach.

推荐答案

我认为签名方法目前是最佳实践。顺便说一句。有许多免费的库包含这个主题。

I think the signature approach is currently best practice. Btw. there are a number of free libs that cover this topic.

许可证密钥的长度至少由签名密钥长度决定 - 1024位密钥产生128字节许可证（如果没有添加其他有效负载）。

The length of the license key is at least determined by the signature key length - a 1024 bit key produces a 128 byte license (if no other payload is added).

许可证文件通常包含有关许可使用本身的更多信息，如有效期，许可子模块，吞吐量...... - 签名本身嵌入在此结构中。这样你就获得了灵活性，我强烈建议这个解决方案，即使许可证变得更大。

Often the license file consists of more information on the licensed use itself, like validity period, licensed submodules, throughput... - the signature itself is embedded within this structure. This way you gain flexibility and i strongly advise this solution, even if the license gets even bigger.

为了在应用程序中导入许可证，你可以采用混合方式（如我们做了）。一方面，您可以提供经典的导入许可证文件解决方案。另一方面，我们生成一个随机的短ID（如您的GUID）并将其与许可证数据相关联。注册后，用户输入短ID，应用程序通过HTTP查找完整的许可证。您必须只在线一次，您仍然可以提供复杂的许可证，用户只需要一个简短的ID。

For importing the license in an application you can adopt a hybrid way (like we did). On one hand you can provide the classic "import license file" solution. On the other, we generate a random, short ID (like your GUID) and associate it with the license data. Upon registration the user enters the the short ID and the application looks up the complete license via HTTP. You must be online only once, you can still provide complex licenses and the user only needs a short ID.

编辑

1. 签名的长度是密钥的长度。例如。 1024位（或128字节）


2. 如果您的应用程序知道签名的数据（例如邮件），您可以单独使用此签名。


3. 您可以签署许可证文件，其中包含的内容不仅仅是邮件。在这种情况下，许可证包含属性和签名（因此，只比签名更长）


4. 您不需要在线连接进行许可证检查。只需随应用程序导入许可证并随时查看。


5. 除了许可证文件导入之外，您还可以使用短ID作为密钥在线下载许可证文件。许可证已下载并脱机。所以你有两全其美。

1. The length of s signature is the length of the key. E.g. 1024 bit (or 128 byte)
2. You can use this signature alone if your application knows what data is signed (e.g. the mail)
3. You can sign a "license document" containing more properties than only the mail. In this case the license contains property AND signature (and is, accordingly, longer than only the signature)
4. You dont need online connection for license check. Just import a license with the application and check whenever you like.
5. An addition to license file import you CAN adopt an online download of the license file using a short ID as a key. The license is downloaded and offline. So you have the best of both worlds.

这篇关于如何创建序列密钥以保护应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！