Java密钥工具/使用Java生成密钥的安全性（一般）

Question

我们正在使用与java安装捆绑在一起的keytool生成密钥，以进行非对称RSA加密。鉴于最近发生的事件，有人问我在java keytool的引擎盖下发生了什么。特别是关于结果数字的随机性。（例如，“为什么没有任何随机的用户输入，比如鼠标移动或键盘输入？”

那么，java keytool创建密钥的“随机性来源”是什么呢？

我自己做了一个快速的调查，但我发现的唯一信息是2000年的一篇帖子：

• 钥匙工具。exe使用SecureRandom作为其随机数的基础
• SecureRandom的Sun提供商遵循IEEE P1363标准。
• Sun SecureRandom供应商遵守NIST的FIPS PUB 140-1第4.11节
• SecureRandom的Sun提供程序将其他熵源与线程争用过程的结果混合在一起。其中包括当前时间、虚拟机内存使用状态、系统属性和文件系统活动
• 在没有JIT的情况下，该算法的性能可能会很差，因此我们正在考虑提供一个替代供应商，该供应商将利用特定于平台的对熵收集设备的支持，如/dev/random或奔腾III热噪声RNG

但是这是在2K，所以也许你们中的某个人可以对此有所了解，并提供对上述内容的更新（不同于Java7？）。根据你的回答，如果你建议切换到另一个提供商，比如bouncyCastle，我会很感兴趣...

更新：我现在假设keytool使用的是java。安全SecureRandom（以及默认的提供者）作为其随机数的基础。我找到了另一篇有趣的文章，它指向了控制SecureRandom API JAVA_HOME/lib/security/JAVA配置的文件。安全

其中规定如下：

选择SecureRandom的种子数据源。默认情况下，会尝试使用securerandom.source属性指定的熵收集设备。如果在访问URL时发生异常，则使用传统的系统/线程活动算法。在Solaris和Linux系统上，如果指定了file：/dev/urandom并且它存在，则默认情况下会激活特殊的SecureRandom实现。此“NativePRNG”直接从 /dev/urandom.读取随机字节在Windows系统上，URL文件：/dev/Anywhere和file：/dev/urandom允许使用Microsoft CryptoAPI种子功能。

securerandom.source=file：/dev/urandom

因为我们是在windows系统上，所以我假设使用的是Microsoft CryptoAPI。因为使用的是Win7，所以它是CNG（CryptoAPI下一代）。有人知道“使用Microsoft CryptoAPI种子功能”是什么意思吗？最可能的方法似乎是：CryptGenRandom函数

更新：Oracle似乎改善了Java8的一些问题。

Answer 1

实际上，波鸿大学的Michaelis，Meyer，Schwenk发表了一篇论文，对Java中的随机性进行了更深入的分析。它被称为“随机失败”。它并没有给Java实现打上最好的分数，但它似乎不太警觉。

• http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations
• http://mail.openjdk.java.net/pipermail/security-dev/2013-March/007034.html

请注意，Java 8对JEP123做了一些改进（但是它仍然缺少使用更具弹性算法（如Fortuna）的RNG）。您可以在OpenJDK安全开发列表中看到关于JEP123的一些讨论：

• http://mail.openjdk.java.net/pipermail/security-dev/2013-January/006319.html

Answer 2

看起来，除了这里记录的高级API的细节之外，实现可能是特定于平台（Windows/Linux）和JDK实现（OpenJDK/OracleJDK）。您可以在这里看到NativePRNG（在Linux上使用）的OpenJDK实现的源代码。

也许可以考虑使用bouncyCastle提供商来提高跨平台的透明度和一致性。

Answer 3

我想在这里分享我的发现：

>

keytool.exe使用SecureRandom作为其随机数的基础，可以在其源代码中看到：Keyool和CertAndKeyGen。

通常，正如SecureRandom API所述：“加密强随机数至少符合FIPS 140-2《加密模块的安全要求》第4.9.1节中规定的统计随机数生成器测试。”因此，SecureRandom的所有实现都应符合FIPS-140-2。

安全提供程序（也适用于SecureRandom）的配置是在JAVA_HOME/lib/Security/java.security中完成的。默认值是（列表顶部）：security.provider.1=sun.security.provider.Sun

不改变的时候3。）在Linux上，SecureRandom的默认实现是NativePRNG，而在Windows上，默认实现是SHA1PRNG。在我们的例子中，是windows pc生成密钥，因此它是SHA1PRNG。

在实施过程中，以下几点尤为突出：

“请注意，如果未提供种子，我们将尝试提供足够的种子字节，以完全随机发生器的内部状态（20字节）。然而，我们的种子生成算法尚未得到彻底研究或广泛部署。”

SeedGenerator（所有SHA1PRNG SecureRandom对象的单例）的种子源顺序如下：

• NativeSeedGenerator（）（在linux上/dev/随机，在windows上使用MS CryptoAPI）
• URLSeedGenerator（url）如果属性securerandom.source是其他
• ThreadedSeedGenerator回退

现在在SHA1PRNG中发现了以下问题：

>

统计偏差II（第1页）

“本文的实验结果表明，伪随机生成器SHA1PRNG（Java）产生的序列可以以高概率与均匀选择的序列区分开来。”

较差的差异（第12页）和有限的州规模（第9页）

“随机字节在STS测试、失败的单位测试、运行测试和前八个串行测试中有严重困难。这表明单位和八位元组的差异很小。”以及“在Java中增加更多的熵”(

结果是：

• 所有java windows安装的默认实现都是SHA1PRNG

因此，可以假设Java密钥生成机制（至少在windows上）已损坏。因此，大多数作者建议使用一些硬件，比如HSM/TRNG。