Java keytool / java生成密钥的安全性（一般）

Question

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

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

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

• keytool.exe使用SecureRandom作为其随机数的基础。
• SecureRandom的Sun提供商遵循IEEE P1363标准，
• Sun SecureRandom提供商遵守NIST的FIPS PUB 140-1第4.11节。
• SecureRandom的Sun提供程序将其他熵源与线程争用过程的结果混合在一起。 除此之外，还包括当前时间，VM内存使用状态，系统属性和文件系统活动。
• 在没有JIT的情况下，该算法可能表现不佳，因此我们正在考虑提供替代供应商，该供应商将利用对熵收集设备（例如/ dev / random或Pentium III热噪声RNG）的平台特定支持。

但是这已经回到了2K，所以你们中的某些人可能会对此有所了解并提供上述更新（在Java7中有所不同吗？）。 根据你的回答，如果你建议改用另一个像bouncycastle这样的提供商，我会被强调...

更新 ：我现在假设keytool使用java.security.SecureRandom（因而是默认提供程序）作为其随机数的基础。 我发现了另一篇有趣的文章 ，它指出了控制SecureRandom API JAVA_HOME / lib / security / java.security配置的文件。

在那里它陈述如下：

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

securerandom.source =文件是：/ dev / urandom的

由于我们在Windows系统上，我假设使用了Microsoft CryptoAPI 。 自从使用Win7以来，它就是CNG（CryptoAPI Next Generation）。 有没有人知道什么是'使用Microsoft CryptoAPI种子功能'。 手段？ 最可能的方法似乎是： CryptGenRandom function

更新 ：Oracle似乎改进了Java 8的一些问题。

Answer 1

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

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

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

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

4. 在Linux上不更改3.）时，SecureRandom的默认实现是NativePRNG ，而在Windows上默认为SHA1PRNG 。 在我们的例子中，它是一个生成密钥的Windows PC，因此它是SHA1PRNG 。

5. 在查看实施时 ，以下内容突出：

   “请注意，如果没有提供种子，我们会尝试提供足够的种子字节来完全随机化生成器的内部状态（ 20个字节 ）。但是， 我们的种子生成算法尚未得到彻底研究或广泛部署 。 ”

6. SeedGenerator （跨所有SHA1PRNG SecureRandom对象的单例）对其“种子源”具有以下顺序：

   • NativeSeedGenerator（） （在linux上使用/ dev / random，在Windows上使用MS CryptoAPI）
   • 如果属性“securerandom.source”是其他内容，则URLSeedGenerator（url）
   • ThreadedSeedGenerator后备

7. 现在SHA1PRNG发现了以下问题：

   • 不一致性
   • 统计偏差I （pp.152，法语，如果n，则使用翻译）

     “然而，生成的500MB文件的黑盒测试显示输出的统计偏差为15阶。”

   • 统计偏差II （第1页）

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

   • 方差差 （第12页）和有限的州规模（第9页）

     “随机字节在STS测试中遇到了严重困难，Monobit失败，运行失败以及前八次串行测试。这表明单个位的差异很大，而元组的差异高达8位。” AND “在Java中为实例添加更多熵（> 160位）不会增强安全性。这种限制令人担忧，因为它使PRNG对密钥生成> 160位无效（例如，在AES情况下）。”

结果是：

• 所有Java Windows安装的默认实现是SHA1PRNG
• SHA1PRNG表现得非常不稳定
• SHA1PRNG是高度专有的 - 它不符合FIPS-140-2（应该是这样）。
• 不幸的是（引用实现者）“我们的种子生成算法尚未彻底研究”。 但随着java的广泛分布，它现在被广泛部署和使用。

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

Answer 2

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

也许考虑使用bouncycastle提供程序只是为了提高跨平台的透明度和一致性。

Answer 3

实际上有一篇来自Ruhr-Uni Bochum的Michaelis，Meyer，Schwenk撰写的论文，它更加密切地分析了Java中的随机性。 它被称为“随机失败”。 它并没有给Java实现最好的标记，但它似乎并不太警报，eighter。

• 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进行了一些改进（但它仍然错过了使用更具弹性的算法的RNG（如Fortuna）。您可以在OpenJDK security-dev列表中看到有关JEP123的一些讨论：

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

Answer 4

除非您使用硬件安全模块 ，否则我真的不会担心它。 关于你的密钥是否存在于硬盘上的主要问题，对你的随机数是否真正随机的微妙担忧逐渐消失。

回到你的问题 - keytool将把所有加密操作交给JCA / JCE提供者。 每个提供商都将拥有自己的SecureRandom实现，除了挖掘源代码外，在线查找这些实现的细节可能很棘手。 您链接的主题包含的信息比我之前看到的更多。