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?
当前回答
如果您不是特别关心密钥的长度,那么使用公钥和私钥加密是一种行之有效的方法。
本质上有某种临时的和固定的签名。
例如: 0001 - 123456789
其中0001是您的临时签名,123456789是您的固定签名。
然后用你的私钥加密,得到你的CD密钥,就像这样: ABCDEF9876543210
然后在应用程序中分发公钥。公钥可用于解密CD密钥“ABCDEF9876543210”,然后验证其固定签名部分。
这可以防止某人猜测nonce 0002的CD密钥是什么,因为他们没有私钥。
唯一的主要缺点是,当使用1024位的私有/公共密钥时,您的CD密钥将非常长。您还需要选择一个足够长的nonce,这样您就不会加密少量的信息。
好的一面是,这种方法不需要“激活”就可以工作,你可以使用电子邮件地址或被许可方的名称作为临时标识。
其他回答
请查看关于部分密钥验证的文章,其中包括以下要求:
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.
所有的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.
总的来说,与客户建立信任关系要容易得多!
cd - key对于任何非网络的东西都不是很安全,所以从技术上讲,它们不需要安全生成。如果你使用的是。net,你几乎可以使用guide . newguid()。
它们现在主要用于多人游戏组件,服务器可以在其中验证CD Key。因此,生成它的安全性并不重要,因为归根结底就是“查找传入的任何东西,并检查其他人是否已经在使用它”。
话虽如此,你可能想要使用算法来实现两个目标:
Have a checksum of some sort. That allows your Installer to display "Key doesn't seem valid" message, solely to detect typos (Adding such a check in the installer actually means that writing a Key Generator is trivial as the hacker has all the code he needs. Not having the check and solely relying on server-side validation disables that check, at the risk of annoying your legal customers who don't understand why the server doesn't accept their CD Key as they aren't aware of the typo) Work with a limited subset of characters. Trying to type in a CD Key and guessing "Is this an 8 or a B? a 1 or an I? a Q or an O or a 0?" - by using a subset of non-ambigous chars/digits you eliminate that confusion.
话虽如此,你仍然需要一个大的分布和一些随机性,以避免盗版只是猜测一个有效的密钥(在你的数据库中是有效的,但仍然在商店货架上的一个盒子里),并欺骗碰巧买了那个盒子的合法客户。
您可以在使用它的软件项目中非常容易地使用和实现安全许可API(您需要从https://www.systemsoulsoftwares.com/下载创建安全许可的桌面应用程序)。
Creates unique UID for client software based on System Hardware(CPU,Motherboard,Hard-drive) (UID acts as Private Key for that unique system) Allows to send Encrypted license string very easily to client system, It verifies license string and works on only that particular system This method allows software developers or company to store more information about software/developer/distributor services/features/client It gives control for locking and unlocked the client software features, saving time of developers for making more version for same software with changing features It take cares about trial version too for any number of days It secures the License timeline by Checking DateTime online during registration It unlocks all hardware information to developers It has all pre-build and custom function that developer can access at every process of licensing for making more complex secure code
我意识到这个答案晚了10年。
一个好的软件许可密钥/序列号生成器不仅仅由一串随机字符或某个曲线生成器的值组成。使用有限的字母数字字母表,数据可以嵌入到一个短字符串中(例如XXXX-XXXX-XXXX-XXXX),其中包括各种有用的信息,例如:
创建日期或license过期日期 产品ID、产品分类、主要版本号和次要版本号 自定义位,如硬件哈希 每个用户哈希校验和位(例如,用户输入他们的电子邮件地址和许可密钥,这两个信息都用于计算/验证哈希)。
然后对许可证密钥数据进行加密,然后使用有限的字母数字字母进行编码。对于在线验证,许可证服务器保存解密信息的秘密。对于脱机验证,解密秘密连同解密/验证代码一起包含在软件本身中。很明显,离线验证意味着软件不安全,无法防止有人输入密钥。
Probably the hardest part about creating a license key is figuring out how to cram as much data as possible into as few bytes as possible. Remember that users will be entering in their license keys by hand, so every bit counts and users don't want to type extremely long, complex strings in. 16 to 25 character license keys are the most common and balance how much data can be placed into a key vs. user tolerance for entering the key to unlock the software. Slicing up bytes into chunks of bits allows for more information to be included but does increase code complexity of both the generator and validator.
Encryption is a complex topic. In general, standard encryption algorithms like AES have block sizes that don't align with the goal of keeping license key lengths short. Therefore, most developers making their own license keys end up writing their own encryption algorithms (an activity which is frequently discouraged) or don't encrypt keys at all, which guarantees that someone will write a keygen. Suffice it to say that good encryption is hard to do right and a decent understanding of how Feistel networks and existing ciphers work are prerequisites.
验证密钥就是解码和解密字符串、验证散列/校验和、检查数据中的产品ID和主要版本号和次要版本号、验证许可证没有过期,以及执行其他需要执行的检查。
编写密钥生成器就是要知道许可密钥由什么组成,然后生成与原始密钥生成器生成的相同的输出。如果用于许可证密钥验证的算法包含在软件中并由软件使用,那么只需创建与验证过程相反的软件。
为了了解整个过程是什么样子的,下面是我最近写的一篇关于选择许可密钥长度、数据布局、加密算法和最终编码方案的博客文章:
https://cubicspot.blogspot.com/2020/03/adventuring-deeply-into-software-serial.html
从博客文章中可以看到一个实用的、真实的密钥生成器和密钥验证器的实现:
https://github.com/cubiclesoft/php-misc/blob/master/support/serial_number.php
上面类的文档:
https://github.com/cubiclesoft/php-misc/blob/master/docs/serial_number.md
可以在这里找到一个生产就绪的开源许可服务器,它使用上面的序列号代码生成和管理许可密钥:
https://github.com/cubiclesoft/php-license-server
上述许可服务器支持在线和离线验证模式。一个软件产品可能只从在线验证开始存在。当软件产品准备退役并且不再受支持时,它可以很容易地转移到离线验证,一旦用户升级到切换到离线验证的软件的最后一个版本,所有现有的密钥将继续工作。
在这里可以找到如何将上述许可证服务器集成到网站中以销售软件许可证和可安装的演示应用程序的现场演示(网站和演示应用程序都是开源的):
https://license-server-demo.cubiclesoft.com/
完全公开:我是许可证服务器和演示站点软件的作者。
推荐文章
- 为什么人们会写“throw 1;<不要邪恶>”和“for(;;);”在json响应前?
- 非加密用途的最快哈希?
- SHA512 vs. Blowfish和Bcrypt
- cer、pvk和pfx文件有什么区别?
- Django设置“SECRET_KEY”的目的是什么?
- 如何从命令行重置Jenkins安全设置?
- 如何通过SFTP从服务器检索文件?
- SecureString在c#应用中实用吗?
- 密码盐如何帮助对抗彩虹表攻击?
- 浏览器会通过https缓存内容吗
- 在git存储库中处理密码的最佳实践是什么?
- 支付处理器-如果我想在我的网站上接受信用卡,我需要知道什么?
- 如何加密和解密一个PHP字符串?
- 使用80端口运行Node.js时的最佳实践(Ubuntu / Linode)
- 使用PHP进行最简单的双向加密