存储 AES 密钥
有没有一种好方法可以将 AES 密钥与应用程序一起发送，但仍然使它们足够安全？
我不太喜欢对密钥进行硬编码的想法（因为应用程序可以反编译），但其他替代方案（将它们保存在远程服务器上）对我来说看起来相当危险，以防服务器出现故障或网络中断切断。
我知道Java提供了称为密钥存储的机制，但是据我所知，如果代码被反编译，这个密钥存储也可以打开吗？
有什么想法吗？
提前致谢！
Is there a good way to ship AES keys together with the application, but still make them safe enough?
I don't quite fond regarding the idea of hard-coding the keys (as the app can be de-compiled), but other alternative, saving them on remote server, looks quite dangerous to me in case the server goes down or the network cuts off.
I know that Java provides mechanism called key-store, but AFAIK, if the code is de-compiled, this key-store can be opened as well?
Any idea?
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您必须更好地描述该应用程序。
如果您试图确保密钥绝对安全，不让安装该软件的计算机的所有者知晓……您做不到。你不应该尝试。这是他们的机器，他们有权知道上面的一切。
在某些软件的每个副本中嵌入相同的对称密钥似乎是一个糟糕的设计。对称密钥应该是新鲜生成的，然后使用某种非对称算法进行交换。这样，只需保护公钥的完整性即可；即使有人发现了钥匙也没关系。
You'd have to describe the application better.
If you are trying to keep the key absolutely safe from the owner of the computer on which the software is installed… you can't. And you shouldn't try. It's their machine and they have a right to know everything on it.
Having the same symmetric key embedded in every copy of some software seems like a bad design. Symmetric keys should be generated fresh, then exchanged using some asymmetric algorithm. This way, only the integrity of the public key needs to be protected; it doesn't matter if someone discovers the key.
如果应用程序使用该密钥，则该密钥将在某个时刻位于内存中。足够复杂的用户/攻击者可以看到它。他们只需要一个调试器和一个适时的断点。
If the application uses the key, the key will be in memory at some point. A sophisticated enough user/attacker can see it then. A debugger and a breakpoint at the right moment is all they need.
您不能相信您的应用程序能够保证您的密钥安全。您不能相信该应用程序确实是您的。
您可以随心所欲地安全地传输密钥，事实上，在应用程序端没有硬件保护您的密钥，这意味着您丢失了，任何拥有十六进制编辑器或调试器的人都可以从您的应用程序中获取密钥。
如果应用程序“需要”密钥，我会想让每个用户（或许可证）只是一个私钥和证书。
然后，您可以使用签名检查和 Diffie-Hellman 密钥交换在运行时从网络服务器“给予”应用程序的每个许可实例一个密钥。这还可以让您确保一次只有一个许可证实例正在运行。
You cannot trust your application to keep your key safe. You cannot trust that the application is really yours.
You can transport the key securely all you like, it's the fact that there is no hardware protecting your key at the application end that means you loose, anyone with a hex editor or debugger can get the key out of your application.
If an application "needs" a key I would be tempted to have each user (or license) simply be a private key and certificate.
You could then use signature checking and Diffie-Hellman key-exchange to 'give' each licensed instance of your application a key from a networked server at runtime. This would also let you make sure only one instance of a license is running at once.
不，传输私有加密密钥不是一个好主意。
典型的方法是将加密密钥存储在配置文件中，该文件由系统管理员或部署人员在安装/更新时进行编辑。密钥本身可以通过安全（加密）电子邮件进行通信，或者只是通过电话读出，或者只是在安装时随机生成（为每个用户）。
No, transmitting private encryption keys is a bad idea.
A typical approach is to store encryption keys in a configuration file, which is edited at install/update time by a sysadmin or deployment person. The key itself can be communicated through secure (encrypted) email, or simply read out over the phone, or simply just generated randomly (for each user) at install time.
这取决于您计划使用密钥的用途，以及什么才算是“足够安全”，但总的来说，我认为您不能在使用密钥的客户端计算机上执行代码，并且仍然阻止客户端获取密钥钥匙。
It depends what you're planning to use the keys for, and what counts as "safe enough", but in general I don't think you can execute code on the client's machine which uses a key and still prevent the client from getting the key.
不，这些密钥应该由应用程序本身生成并由用户存储。如果您传输私钥，您就会损失很多，几乎与您在发货之前拥有私钥副本所损失的一样多。
用户的安全不应该成为目标。
No, these keys should be generated by the application itself and stored by the user. If you're transmitting the private key you've lost a lot, almost as much as you've lost by having a copy of the private key before you ship the product.
Safety from the user shouldn't be the goal.