穷人序列号生成方案，第2部分 [英] Poor man serial number generation scheme, part 2
问题描述
这是我以前的问题的延续：
假设我已经生成私钥/公钥对，但是我想保存私钥在注册的应用程序本身 - 例如生成仅包含数据（公共和私人密钥部分）的.c代码。
当然这是有风险的解决方案 - 因为如果黑客提取私有应用程序的关键 - 他可以自己创建许可证。
但这是穷人解决方案，所以我希望所有内容都可以在一个应用程序中 - 私钥和公钥 - 所以注册表单也将是序列号生成对话框。
所以我想把私钥放在应用程序中，但是要保护它，只有我知道的密码。
所以输入序列号 - 首次尝试再次匹配特定硬件（验证签名），但是如果没有成功，我们会尝试检查最终用户是否为管理员（或序列号生成人员）。
什么是最好的双向加密算法，这将使用密码作为输入，并且将容忍暴力攻击？
我猜管理员密码应该是足够可靠，不容易猜到（没有列出任何知名的暴力黑客字典）。
此外，将密码存储在注册表中或在最小的加密形式。可能有意义的密码=== sha-1哈希===> 20字节哈希 - 将其存储在注册表（管理员密码）中，然后使用哈希加密私钥。
与上一个问题相同的问题 -
作为基础，我更喜欢使用普通C或C ++（而不是C＃），最好是Windows / wincrypt.h或任何现有的普通C源代码注意事项：
b
- 对于一个给定的加密算法的直接问题，而不仅仅是基于您的两个发布的问题和答案和评论，更多地关于您的总体目标的答案。 / li>
- 虽然我一般遵循软件安全问题，但我不是一位专家，所以请随便说一下这里。
- This is less of an answer to the direct question about a given encryption algorithm, but more about your overall goal, based upon your two posted questions and answers and comments.
- While I follow software security issues generally, I'm not an expert, so take anything I say herein accordingly.
您正在尝试保护您的软件。也就是说，您正在寻找的是实施许可方案的一种方式。
您需要[希望有]，但没有发布是功能/设计规范为此。双向加密只是其中的一部分。
你不是第一个需要这个的人。已经有计划这样做了。我建议使用现有的解决方案。可能有一个公开/免费的开放源代码版本。
你谈到了电子邮件和注册表单和剪贴，但没有详细说明它是如何工作的。你也没有提到这与应用程序的互动。您是否使用网络浏览器注册或将应用程序提交到注册对话框？
我猜你有一个用户在一个表单中输入电子邮件地址。然后，您的服务器将发回一封包含特殊代码的电子邮件[例如有效期为15分钟]，用户必须输入完成注册才能证明电子邮件是有效的，以及系统身份信息。
您提到，粘贴是限制因素。但是，IMO，它不是，因为您可以将密钥放入MIME编码的附件中，并将用户保存到文件中。注册表单可以上传该文件。即使是一个冗长的值（例如，10行72个字符/行）仍然适合剪贴板。
您收集[希望]关于客户端系统的唯一标识信息。大多数Pentium III处理器的CPU序列号现在为0（除非在BIOS中启用）。但是，其他 CPUID 部分可能会提供一些独特性。以太网MAC地址 是唯一的，但许多NIC允许在软件中更改。磁盘序列号不是一个不错的选择[IMO]，因为磁盘的故障率最高，需要随时更换。
但是，我们假设你可以收集足够的信息来自上述来源[或许还有其他]获得系统ID。您可以将其与其他东西（如用户名等）连接起来。如果您选择，您可以通过像sha1 [或任何]的单向哈希来运行它。所以现在，你有一个系统身份。保存在某处（例如文件或注册表）
但是，将私人密钥存储在应用程序[或客户端系统上的任何位置]是不起动，IMO。您只需要在生成阶段。
所以，注册过程将系统标识发送到您控制的私有服务器（例如Amazon EC2）。服务器加密/签名[使用公钥/私钥加密（如RSA）]系统标识，并发回公钥和签名结果。这些获取存储。
任何应用程序的验证是重新获得系统身份信息，应用该算法和公钥。它应该符合签名的结果。
这样就无需使用应用程序存储私钥，并使用使用RC4 [或equiv]的密码进行加密。这样可以消除复杂性，这首先就是削弱你的保护。
我对系统管理员或系列许可证生成人有些困惑。如果这不是您[或您的服务器]，那么这意味着您要发出OEM合同，本地管理员可以为此控件下的给定子系统生成许可证。因此，您需要一个OEM密钥[发送到您的服务器]，以允许生成多个许可证。
现在的坏消息。
任何软件授权方案是[容易]易碎的。在应用程序中，无论验证算法多么复杂（或简单），它归结为[或多个] go / nogo测试。就是这样：
#include< stdlib.h>
int user_authorized（void）;
void run_program（）;
int
main（void）
{
if（！user_authorized（））
abort（）;
run_program（）;
return 0;
}
这转换为：
.globl main
main：
subq $ 8，％rsp
call user_authorized
testl％eax，％eax
je .L5＃将其更改为nop
xorl％eax，％eax
调用run_program
xorl％eax，％eax
addq $ 8，％rsp
ret
.L5：
call abort
注意 je .L5 中止程序。如果程序被修补以将该指令更改为 nop ，许可证测试通过，无论 user_authorized 是否。
可以重复执行与程序一样多的安全检查。
安全是一个相对术语。一个50美元的应用程序不需要像$ 50万的保护一样多的保护（例如赛灵思的一些CAD / CAE程序）。
从微软的手册中抽出一张。他们提出您必须接受的许可对话框（即收缩包装）。必须接受协议。它禁止逆向工程等。这给你合法的封面。请咨询律师。
除此之外，您最终决定的任何软件方案除外。
This is continuation to my previous question here:
Poor man serial number generation scheme
Let's say I have generated private / public key pair, but I want to save private key within registered application itself - for example by generating .c code which contains only data (public and private key parts).
Of course it's risky solution - since if hacker extracts private key from application - he can create licenses by himself.
But this is "poor man solution", so I want everything to be in one application - private and public keys - so registration form would be also serial number generation dialog.
So I want to place private key inside application, but to protect it with some password, which only I know about.
So by entering serial number - in first pass we try to match against particular hardware (verify signature), but if that one does not succeeds, we try to check if end-user is "administrator" (or serial number generation person).
What would be best two-way encrypting algorithm , which will use password as an input and would be tolerant to brute force attacks ?
I guess "administrator password" should be reliable enough, not to be easily guessable (not listed in any well known brute-force hack dictionaries).
Also it would be good to store password in registry / or at least in encrypted form. May be makes sense to password === sha-1 hash ===> 20 bytes hash - store it in registry ("administrator password"), and then to use hash to encrypt private key.
Same issue as in previous question - As a base I would prefer to use plain C or C++ (not C#), preferably Windows / wincrypt.h or any existing plain C source code (Preferably not huge 3-rd party libraries).
Caveats:
You're trying to protect your software. That is, what you're looking for is a way to implement a licensing scheme.
What you need [and hopefully have], but did not post is a functional/design specification for this. The two way encryption is but a part of this.
You aren't the first person to need this. There are already schemes to do this. I'd recommend using an existing solution. There is probably a public/free open source version.
You talked about email and registration form and cut-and-paste but didn't detail how that works. Nor did you mention how this interacts with your application. Do you register with a web browser or have the app present a registration dialog?
I'm guessing that you have a user enter an email address into a form. Then, your server will send back an email with some special code [e.g. that is valid for 15 minutes] that the user must enter to complete registration to prove the email is valid, along with the system identity information.
You mentioned that the cut-and-paste is the limiting factor. But, IMO, it isn't really as you could put the key in a MIME encoded attachment and have the user save it to a file. The registration form could then upload this file. Even a lengthy value that is (e.g. 10 lines of 72 chars / line) will still fit inside a clipboard.
You gather [hopefully] unique identifying information about the client system. The CPU serial number is now 0 on most post pentium-III processors [unless enabled in the BIOS]. But, other CPUID parts may provide some uniqueness. The Ethernet MAC address is unique, but many NICs allow it to be changed in software. A disk serial number isn't a good choice [IMO] because disks have the highest failure rate and need to be replaced over time.
But, let's assume you can gather enough information from the above sources [and maybe some others] to get a "system ID". You can concatenate this with other stuff like username, etc. You can run this through a one way hash like sha1 [or whatever] if you choose. So, now, you've got an "system identity". Save that somewhere (e.g. file or registry)
But, storing the private key in the app [or anywhere on the client system] is a non-starter, IMO. You only need this during the generation phase.
So, have the registration process send the system identity to a private server that you control (e.g. Amazon EC2). The server encrypts/signs [using public/private key crypto like RSA] the system identity and sends back the public key and the "signed result". These get stored.
The verification for any app is to regather the system identity information, apply the algorithm with it and the public key. It should match the signed result.
This eliminates the need to store the private key with the app, keep it encrypted with a password that uses RC4 [or equiv]. This eliminates complexity that just served to weaken your protection in the first place.
I'm a bit confused about the "system administrator" or "serial license generation person". If that's not you [or your server], then it implies you're going to give out OEM contracts and the local admin can generate licenses for a given subset of systems under this control. So, you'll need an OEM key [that gets sent to your server] to allow multiple licenses to be generated.
Now, the bad news.
Any software licensing scheme is [easily] breakable. In the app, no matter how complex [or simple] the verification algorithm is, it boils down to a [or multiple] go/nogo tests. That is, something like:
#include <stdlib.h>
int user_authorized(void);
void run_program();
int
main(void)
{
if (! user_authorized())
abort();
run_program();
return 0;
}
This translates to:
.globl main
main:
subq $8, %rsp
call user_authorized
testl %eax, %eax
je .L5 # change this to a nop
xorl %eax, %eax
call run_program
xorl %eax, %eax
addq $8, %rsp
ret
.L5:
call abort
Notice the je .L5 to abort the program. If the program is patched to change this instruction to nop, the license test "passes", regardless of what user_authorized does.
This can be repeated for as many security checks as the program has.
Security is a relative term. A $50 app doesn't need as much protection as one that sells for $500,000 (e.g. some CAD/CAE programs from Xilinx).
Take a leaf from Microsoft's playbook. They present a "licensing" dialog that you must accept (i.e. "shrink wrap"). One must accept the agreement. It prohibits reverse engineering, etc. This gives you legal cover. Consult an attorney on this.
This is, in addition to, whatever software scheme you ultimately decide on.
这篇关于穷人序列号生成方案，第2部分的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
