Java keytool/使用Java生成的密钥的安全性(通常) [英] Java keytool / the security of generated keys with java (in general)

问题描述

我们正在使用与Java安装捆绑在一起的keytool生成密钥以进行非对称RSA加密.鉴于最近的事件有人问我下发生了什么Java keytool的引擎盖.特别是关于所得数字的随机性. (例如，为什么没有像鼠标移动或键盘输入这样的随机用户输入?"

We are using the keytool bundled with the java installation to generate keys to do an asymmetric RSA encryption. In the light of recent events somebody asked me whats happening under the hood of the java keytool. Especially regarding the randomness of the resulting numbers. (e.g. "huh why isn't there any random user input taken like mouse movements or keyboard input?"

那么，用于创建其密钥的Java密钥工具的随机性来源"是什么?

我自己进行了快速研究，但是发现的唯一信息是 2000年以来的帖子:

I did a quick research myself however the only information I found was a post from 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.

• 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这样的其他提供者，我会很感兴趣.

But this was back in 2K so may be someone of you could shed some light on that and provide an update to the above (different in Java7?). Depending on your answer I would be interessted if you would advise to switch to another provider like bouncycastle...

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

Update: I now assume that the keytool is using java.security.SecureRandom (and thus the default provider) as a base for its random numbers. I found another interessting article, which pointed me to the file which controls the configuration of the 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和文件:/dev/urandom 启用Microsoft CryptoAPI种子功能的使用.

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 =文件:/dev/urandom

securerandom.source=file:/dev/urandom

由于我们使用的是Windows系统，因此我假设使用了 Microsoft CryptoAPI .由于使用了Win7，因此它是CNG(下一代CryptoAPI). 有人知道什么是"Microsoft CryptoAPI种子功能的使用". ?最可能的方法似乎是:

Since we are on a windows system I assume that the Microsoft CryptoAPI is used. Since Win7 is used it is the CNG (CryptoAPI Next Generation). Does anybody know what 'use of the Microsoft CryptoAPI seed functionality.' means? The most probable method seems to be: CryptGenRandom function

更新:Oracle似乎已经改善了

Update: Oracle seem to have improved some issues with Java 8.

推荐答案

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

I wanted to share my findings here:

1. keytool.exe使用SecureRandom作为其随机数的基础，如其源代码所示:通常，作为 SecureRandom API指出:具有加密强度的随机数至少符合FIPS 140-2，《加密模块的安全性要求》第4.9.1节中指定的统计随机数生成器测试."因此，SecureRandom的所有实现都应符合 FIPS-140-2 .

   Normally, as the SecureRandom API states: "A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1." Thus all implementations of SecureRandom should be in compliance with FIPS-140-2.

   安全提供程序的配置(因此也适用于SecureRandom)在JAVA_HOME/lib/security/java.security中完成.默认值为(列表顶部):security.provider.1=sun.security.provider.Sun

   The configuration of the Security Providers (thus also for SecureRandom) is done in JAVA_HOME/lib/security/java.security. The default is (top of the list): security.provider.1=sun.security.provider.Sun

   在Linux上未更改3.)时，SecureRandom的默认实现为

   When not changing 3.) on Linux, the default implementation for SecureRandom is NativePRNG, while on Windows the default is SHA1PRNG. In our case it is a windows pc generating the keys thus it is SHA1PRNG.

   查看

   When looking at the implementation the following stands out:

   请注意，如果未提供种子，我们会尝试提供足够的种子 种子字节以完全随机化生成器的内部状态 ( 20个字节).但是，我们的种子生成算法尚未实现 经过深入研究或广泛部署的."

   "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."

2. SeedGenerator (所有SHA1PRNG SecureRandom对象中的单个)的种子源"具有以下顺序:

3. The SeedGenerator (singleton across all SHA1PRNG SecureRandom objects) has the following order for its "seed sources":

   • URLSeedGenerator(url)如果属性"securerandom.source"是其他内容
   • ThreadedSeedGenerator 后备
   • NativeSeedGenerator() (/dev/random on linux, on windows MS CryptoAPI is used)
   • URLSeedGenerator(url) if property "securerandom.source" is something else
   • ThreadedSeedGenerator fallback

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

   Now the following problems have been found with SHA1PRNG:

   • 不一致
   • 统计偏差I (第152页，法语，如果使用n，请使用翻译器.)
   • Inconsistencies
   • Statistical bias I (pp.152, french, use translator if n.)

   但是，生成文件为500MB的黑匣子测试表明，输出的统计偏差存在15个数量级."

4. 统计偏差II (第1页)

   "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."

5. Statistical bias II (pp.1)

   本文的实验结果表明，伪随机生成器SHA1PRNG(在Java中)产生的序列可以与均等选择的序列区分开来，并且具有很高的概率"

   "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"

6. 差方差(第12页)和受限状态大小(第9页)

7. Poor variance (page 12) and limited state size (p.9)

   随机字节在STS测试，Monobit，Runs和前八次串行测试失败时遇到严重困难.这表明单个位和最多8位元组的差异很小." AND 在Java中，向实例添加更多的熵(> 160bit)不会增强安全性.此限制令人震惊，因为它使PRNG无法用于大于160位的密钥生成(如 例如，在AES'的情况下."

   "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密钥生成机制(至少在Windows上)视为已损坏.因此，大多数作者建议使用某种硬件，例如HSM/ TRNG .

Thus the Java keygeneration mechanism (at least on windows) can be assumed as broken. As a consequence most of the authors advise to use some piece of hardware like an HSM / TRNG.

这篇关于Java keytool/使用Java生成的密钥的安全性(通常)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！