有没有一种很好的方法可以将AES密钥与应用程序一起发送,但是仍然可以使它们足够安全吗?
我不太喜欢硬编码密钥的想法(因为应用程序可以解压缩),但是其他替代方案,将它们保存在远程服务器上,在服务器出现故障的情况下对我来说非常危险或网络切断。
我知道Java提供了一种名为key-store的机制,但是AFAIK,如果代码被解编,那么这个密钥库也可以打开吗?
有什么想法吗?
提前致谢!
答案 0 :(得分:4)
您必须更好地描述应用程序。
如果您试图将密钥与安装软件的计算机的所有者保持绝对安全......则不能。你不应该试试。这是他们的机器,他们有权知道它的一切。
在某些软件的每个副本中嵌入相同的对称密钥似乎是一个糟糕的设计。应该重新生成对称密钥,然后使用一些非对称算法进行交换。这样,只需要保护公钥的完整性;如果有人发现密钥并不重要。
答案 1 :(得分:3)
如果应用程序使用密钥,则密钥将在某个时刻位于内存中。一个足够复杂的用户/攻击者可以看到它。正确的时刻调试器和断点就是他们所需要的。
答案 2 :(得分:1)
不,传输私有加密密钥是一个坏主意。
典型的方法是将加密密钥存储在配置文件中,该文件由系统管理员或部署人员在安装/更新时进行编辑。密钥本身可以通过安全(加密)电子邮件进行通信,或者只是通过电话进行通信,或者只是在安装时随机生成(针对每个用户)。
答案 3 :(得分:1)
您无法信任您的应用程序以确保您的密钥安全。您不能相信该应用程序确实属于您的。
您可以安全地传输密钥,事实上,在应用程序端没有硬件保护您的密钥意味着您松动,任何拥有十六进制编辑器或调试器的人都可以从您的应用程序中获取密钥。< / p>
如果某个应用程序“需要”某个密钥,我很想让每个用户(或许可证)只是一个私钥和证书。
然后,您可以使用签名检查和Diffie-Hellman密钥交换,在运行时从网络服务器“为”应用程序的每个许可实例提供密钥。这也可以确保一次只运行一个许可证实例。
答案 4 :(得分:0)
这取决于你计划使用的密钥,以及什么算得上“足够安全”,但总的来说,我认为你不能在客户机的机器上执行使用密钥的代码而仍然阻止客户端从得到钥匙。
答案 5 :(得分:0)
不,这些密钥应由应用程序本身生成并由用户存储。如果您正在传输私钥,那么您丢失了很多,几乎与您在运送产品之前拥有私钥的副本一样多。
用户的安全不应成为目标。