Java keytool/用java生成 key 的安全性(一般)

Question

我们正在使用与 java 安装捆绑在一起的 keytool 来生成 key 以进行非对称 RSA 加密。鉴于近期events有人问我在 java keytool 的幕后发生了什么。特别是关于结果数字的随机性。 (例如“嗯，为什么没有像鼠标移动或键盘输入这样的随机用户输入？”

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

我自己进行了快速研究，但我发现的唯一信息是 post从 2000 年开始:

• The keytool.exe uses the SecureRandom as basis of its random numbers.
• The Sun provider for SecureRandom follows the IEEE P1363 standard,
• the Sun SecureRandom provider complies with NIST's FIPS PUB 140-1 section 4.11.
• The Sun provider for SecureRandom mixes in other sources of entropy with the results from the thread contention process. Among other things this includes the current time, the state of the VM's memory usage, system properties, and file system activity.
• The algorithm can perform poorly in the absence of a JIT and so we are considering supplying an alternative provider which will take advantage of platform specific support for an entropy gathering device such as /dev/random or the Pentium III thermal-noise RNG.

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

更新:我现在假设 keytool 使用 java.security.SecureRandom(因此是默认提供程序)作为其随机数的基础。我发现了另一个有趣的 article ，它指向我控制 SecureRandom API JAVA_HOME/lib/security/java.security 的配置的文件

里面写着:

Select the source of seed data for SecureRandom. By default an attempt is made to use the entropy gathering device specified by the securerandom.source property. If an exception occurs when accessing the URL then the traditional system/thread activity algorithm is used. On Solaris and Linux systems, if file:/dev/urandom is specified and it exists, a special SecureRandom implementation is activated by default. This "NativePRNG" reads random bytes directly from /dev/urandom. On Windows systems, the URLs file:/dev/random and file:/dev/urandom enables use of the Microsoft CryptoAPI seed functionality.

securerandom.source=file:/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. 如果不更改 3.) 在 Linux 上，SecureRandom 的默认实现是 NativePRNG ，而在 Windows 上默认为 SHA1PRNG .在我们的例子中，它是一台生成 key 的 Windows 电脑，因此它是 SHA1PRNG。

5. 查看 implementation 时以下是突出的:

   "Note that if a seed is not provided, we attempt to provide sufficient seed bytes to completely randomize the internal state of the generator (20 bytes). However, our seed generation algorithm has not been thoroughly studied or widely deployed."

6. SeedGenerator (所有 SHA1PRNG SecureRandom 对象的单例)的“种子源”顺序如下:

   • NativeSeedGenerator() (Linux 上的/dev/random，Windows 上使用 MS CryptoAPI)
   • URLSeedGenerator(url)如果属性“securerandom.source”是别的东西
   • ThreadedSeedGenerator回退

7. 现在发现 SHA1PRNG 存在以下问题:

   • Inconsistencies
   • Statistical bias I (第 152 页，法语，如果是 n，请使用翻译器。)

     "A black box test with a generated file of 500MB, however, showed the existence of statistical biases of the output by an order of 15."

   • Statistical bias II (第 1 页)

     "The experimental results in this paper show that sequences produced by pseudorandom generators SHA1PRNG (in Java) could be distinguished from uniformly chosen sequences with a high probability"

   • Poor variance (第 12 页)和有限状态大小(第 9 页)

     "The random bytes had grave difficulties with the STS tests, failing Monobit, Runs and the first eight Serial tests. This indicates poor variance in single bits and tuples up to eight bits." AND "In Java adding more entropy (>160bit) to an instance will not enhance security. This limitation is alarming, since it renders the PRNGs useless for key generation > 160 bit (as e.g., in AES' case)."

结果是:

• 所有 java windows 安装的默认实现是 SHA1PRNG
• SHA1PRNG 的行为非常不稳定
• SHA1PRNG 是高度专有的 - 它不符合 FIPS-140-2(它应该符合)。
• 不幸的是(引用实现者的话)“我们的种子生成算法还没有被彻底研究”。但随着 java 的广泛分布，它现在被广泛部署和使用。

因此可以假设 Java key 生成机制(至少在 Windows 上)已损坏。因此，大多数作者建议使用一些硬件，如 HSM/TRNG .