License keys are the defacto-standard as an anti-piracy measure. To be honest, this strikes me as (in)Security Through Obscurity, although I really have no idea how license keys are generated. What is a good (secure) example of license key generation? What cryptographic primitive (if any) are they using? Is it a message digest? If so, what data would they be hashing? What methods do developers employ to make it difficult for crackers to build their own key generators? How are key generators made?


当前回答

所有的CD拷贝保护算法给诚实的用户带来不便,同时没有提供任何防止盗版的保护。

“盗版者”只需要获得一张合法的cd及其访问代码,他就可以制作n份拷贝并分发它们。

无论代码的加密安全性如何,都需要以明文形式提供CD,否则合法用户无法激活该软件。

Most secure schemes involve either the user providing the software supplier with some details of the machine which will run the software (cpu serial numbers, mac addresses, Ip address etc.), or, require online access to register the software on the suppliers website and in return receive an activitation token. The first option requires a lot of manual administration and is only worth it for very high value software, the, second option can be spoofed and is absolutly infuriating if you have limited network access or you are stuck behind a firewall.

总的来说,与客户建立信任关系要容易得多!

其他回答

还有一些DRM行为将多个步骤合并到流程中。最著名的例子之一是Adobe验证其Creative Suite安装的方法之一。使用这里讨论的传统CD Key方法,然后调用Adobe的支持线。CD密钥将提供给Adobe代表,他们将返回用户使用的激活号码。

然而,尽管被分成了几个步骤,但这与正常过程中使用的破解方法相同。人们很快发现了用于创建与原始CD密钥进行检查的激活密钥的过程,并制作了包含这两个密钥的生成器。

然而,这种方法仍然作为一种没有互联网连接的用户验证产品的方式存在。展望未来,随着互联网接入变得无处不在,很容易看到这些方法将被淘汰。

请查看关于部分密钥验证的文章,其中包括以下要求:

License keys must be easy enough to type in. We must be able to blacklist (revoke) a license key in the case of chargebacks or purchases with stolen credit cards. No “phoning home” to test keys. Although this practice is becoming more and more prevalent, I still do not appreciate it as a user, so will not ask my users to put up with it. It should not be possible for a cracker to disassemble our released application and produce a working “keygen” from it. This means that our application will not fully test a key for verification. Only some of the key is to be tested. Further, each release of the application should test a different portion of the key, so that a phony key based on an earlier release will not work on a later release of our software. Important: it should not be possible for a legitimate user to accidentally type in an invalid key that will appear to work but fail on a future version due to a typographical error.

如果您不是特别关心密钥的长度,那么使用公钥和私钥加密是一种行之有效的方法。

本质上有某种临时的和固定的签名。

例如: 0001 - 123456789

其中0001是您的临时签名,123456789是您的固定签名。

然后用你的私钥加密,得到你的CD密钥,就像这样: ABCDEF9876543210

然后在应用程序中分发公钥。公钥可用于解密CD密钥“ABCDEF9876543210”,然后验证其固定签名部分。

这可以防止某人猜测nonce 0002的CD密钥是什么,因为他们没有私钥。

唯一的主要缺点是,当使用1024位的私有/公共密钥时,您的CD密钥将非常长。您还需要选择一个足够长的nonce,这样您就不会加密少量的信息。

好的一面是,这种方法不需要“激活”就可以工作,你可以使用电子邮件地址或被许可方的名称作为临时标识。

密钥系统必须具有以下几个属性:

只有很少的键是有效的 即使给定用户拥有的一切,有效的键也必须是不可派生的。 一个系统上的有效密钥在另一个系统上不是有效密钥。 其他人

One solution that should give you these would be to use a public key signing scheme. Start with a "system hash" (say grab the macs on any NICs, sorted, and the CPU-ID info, plus some other stuff, concatenate it all together and take an MD5 of the result (you really don't want to be handling personally identifiable information if you don't have to)) append the CD's serial number and refuse to boot unless some registry key (or some datafile) has a valid signature for the blob. The user activates the program by shipping the blob to you and you ship back the signature.

潜在的问题包括,你提供的签名几乎是任何东西,所以你需要假设有人会运行选定的纯文本和/或选定的密文攻击。可以通过检查提供的序列号并拒绝处理来自无效序列号的请求,以及拒绝在一段时间内(例如每年2次)处理来自给定s/n的超过给定数量的查询来缓解这一问题。

我应该指出几件事:首先,一个熟练和坚定的攻击者将能够绕过他们拥有无限制访问权限的部分(即CD上的所有内容)的任何和所有安全性,您对该帐户所能做的最好的事情是使其更难获得非法访问而不是获得合法访问。其次,我不是专家,所以这个提议的方案可能存在严重的缺陷。

对于老式的CD键来说,这只是一个容易生成和验证CD键(可以是任何字符串)的算法的问题,但是有效CD键与无效CD键的比例是如此之小,以至于随机猜测CD键不太可能得到有效的CD键。

错误的做法:

《星际争霸》和《半条命》都使用了相同的校验和,即第13个数字验证了前12个数字。因此,您可以为前12位输入任何数字,并猜测第13位(只有10种可能),从而得到臭名昭著的1234-56789-1234

验证算法是公开的,看起来像这样:

x = 3;
for(int i = 0; i < 12; i++)
{
    x += (2 * x) ^ digit[i];
}
lastDigit = x % 10;

正确的方法

Windows XP收集了相当多的信息,对其进行加密,然后将字母/数字编码放在贴纸上。这允许MS同时验证您的密钥并获得产品类型(家庭、专业等)。此外,它需要在线激活。 完整的算法相当复杂,但在德国发表的这篇(完全合法的!)论文中很好地概述了它。

当然,无论你做什么,除非你提供的是在线服务(如《魔兽世界》),任何类型的版权保护都只是一种拖延:不幸的是,如果这是一款有价值的游戏,就会有人破坏(或至少绕过)CD-key算法和所有其他版权保护。

真正正确的做法:

对于在线服务来说,情况要简单一些,因为即使使用二进制文件,你也需要通过服务器的身份验证才能使用它。拥有一个WoW账号)。魔兽世界的CD-key算法——例如,在购买游戏卡时使用——可能看起来像这样:

生成一个非常大的加密安全随机数。 储存在我们的数据库中,并打印在卡片上。 然后,当有人输入游戏时间卡号时,检查它是否在数据库中,如果是,将该号码与当前用户关联,以便它永远不会再被使用。

对于网上服务,没有理由不使用上述方案;使用其他任何方法都可能导致问题。