2009-12-24 208 views
0

是否有一种将AES密钥与应用程序一起运输的好方法,但是仍然足够安全吗?存储AES密钥

我不太喜欢硬编码键的想法(因为应用程序可以反编译),但是另一种方法是将它们保存在远程服务器上,这对服务器来说看起来相当危险或者网络中断。

我知道Java提供的机制叫做key-store,但是AFAIK,如果代码是反编译的,那么这个key-store也可以打开?

有什么想法?

在此先感谢!

回答

1

你不能相信你的应用程序来保证你的密钥安全。你不能相信该应用程序真的是你的。

您可以安全地传输密钥,因为在应用程序末端没有硬件保护您的密钥,这意味着您丢失了密钥,任何拥有十六进制编辑器或调试器的人都可以将密钥从您的应用程序中取出。

如果一个应用程序“需要”一个密钥,我会试图让每个用户(或许可证)只是一个私钥和证书。

然后,您可以使用签名检查和Diffie-Hellman密钥交换,在运行时从网络服务器为应用程序的每个许可实例提供一个密钥。这也可以让你确保只有一个许可证实例正在运行。

+0

嗨。 是否有任何实施此方法的开源(首选)/商业软件包? 谢谢。 – SyBer 2009-12-31 13:49:22

+0

您可以使用OpenSSL的库或标准JCE完成所有这些工作。 – IanNorton 2011-04-13 19:42:01

0

这取决于你打算使用什么钥匙,什么算作“足够安全”,但总的来说,我不认为你可以在客户端的机器上使用钥匙执行代码,并仍然阻止客户从获得钥匙。

+0

只是想加密一些信息,这些信息将存储在一个纯文件中。 – SyBer 2009-12-24 17:00:40

+1

如果你想防止临时用户(而不是一个确定的逆向工程专家),AES是一种矫枉过正。在这样的情况下,我使用了一个简单的异或密钥加密和一个硬编码的密钥。一般来说,所有数据保护任务都有两种形式 - 防止错误的用户和防止故意破解的良好意义。第二个更复杂;就你而言,这在理论上是不可解的。所以假设你正在解决第一类问题并采取相应的行动。 – 2010-01-02 01:49:25

4

你必须更好地描述应用程序。

如果您试图将密钥从安装软件的计算机的所有者处绝对安全,你不能。你不应该尝试。这是他们的机器,他们有权知道它的一切。

在某些软件的每个副本中嵌入相同的对称密钥似乎是一种糟糕的设计。对称密钥应该是新鲜生成的,然后使用一些非对称算法进行交换。这样,只有公钥的完整性需要得到保护;如果有人发现密钥并不重要。

+0

我想使用密钥加密剩余宽限期的数量 - 即应用程序运行所剩的时间,但无法连接到在线授权机构进行许可证检查。 你能提供一些关于非对称密钥的更多信息吗? 有没有在这方面的Java的任何好的文章? 谢谢。 – SyBer 2009-12-24 17:26:56

0

不,这些键应该由应用程序本身生成并由用户存储。如果您传输的私钥已经损失了很多,几乎与丢失私有密钥副本一样多,然后再发货。

用户的安全不应该成为目标。

+0

为什么我迷路了,如果密钥移动通过SSL? – SyBer 2009-12-24 17:07:55

+0

因为你拥有你的私钥。当至少有两个人拥有该密钥时,这使得两倍的安全难以保证。如果你只是在客户端机器上加密信息,那么所有的_you_需要的是他们的公钥,它是安全的传输。私钥应该锁定在只有加密人员才能访问的小盒子中。 否则跳过AES,只是去做3DES。如果您没有利用公钥/私钥架构,请不要使用它。 – 2009-12-24 18:05:03

+0

我需要在同一台机器上同时加密和解密信息。 密钥在传输后保持非常短的时间,然后丢弃。 那么还有什么风险吗? – SyBer 2009-12-25 20:49:51

3

如果应用程序使用密钥,密钥将在某个时间位于内存中。一个足够复杂的用户/攻击者可以看到它。调试器和适时的断点是他们需要的。

+0

你在这里,仍然需要更大的经验水平,这可能只有攻击者的1%。 – SyBer 2009-12-24 17:08:42

+0

取决于用户群。和数据的价值。实际上攻击的攻击者很复杂:) – 2009-12-24 17:25:46

1

不,传送私人加密密钥是一个坏主意。

一个典型的方法是将加密密钥存储在配置文件中,该配置文件在安装/更新时由系统管理员或部署人员编辑。密钥本身可以通过安全(加密)电子邮件进行通信,或通过电话简单地读出,或者只是在安装时随机产生(针对每个用户)。

+0

为什么它很糟糕,如果链接是安全的,例如HTTPS? – SyBer 2009-12-24 17:27:41