Tomcat 需要太多时间才能启动 - Java SecureRandom更新

请不要将其标记为重复。这是这两个问题的后续问题。

我明白,替换

securerandom.source=file:/dev/urandom

securerandom.source=file:/dev/./urandom

将解决这个问题。$JAVA_PATH/jre/lib/security/java.security

我的问题是,在生产中这样做可以吗?这会对安全性产生任何影响(例如会话 ID 变得可预测)?如果这不太安全,有没有其他方法可以更快地给出足够的熵?

更新

我使用openstack进行部署(或者说,使用AWS或GCP或任何其他云提供商)。因此,添加硬件设备(如声卡)对我来说不是一个选择。


答案 1

在对正确的搜索词进行了广泛的谷歌搜索之后,我遇到了这篇关于DigitalOcean的好文章。我在这里只是引用相关部分。

Linux上有两种通用的随机设备:/dev/random和/dev/urandom。最佳随机性来自 /dev/random,因为它是一个阻塞设备,并且将等到有足够的熵可用来继续提供输出。假设你的熵是足够的,你应该从/dev/urandom中看到相同的随机性质量;但是,由于它是一个非阻塞设备,因此即使熵池耗尽,它仍将继续产生“随机”数据。这可能导致随机数据质量降低,因为重复先前数据的可能性要大得多。当生产服务器上的可用熵不足时,可能会发生许多不好的事情,特别是当此服务器执行加密功能时。

因此,这是一个潜在的安全风险。

填充熵池的解决方案

Linux已经从不同的硬件来源获得了非常高质量的随机数据,但是由于无头机器通常没有键盘或鼠标,因此生成的熵要少得多。磁盘和网络 I/O 代表了这些计算机的大多数熵生成源,并且这些生成非常稀疏的熵量。由于很少有无外设机器(如服务器或云服务器/虚拟机)具有任何类型的专用硬件RNG解决方案,因此存在几种用户空间解决方案,可以使用来自比硬盘“更嘈杂”的设备(如视频卡,声卡等)的硬件中断来生成额外的熵。不幸的是,这再次被证明是服务器的问题,因为它们通常不包含任何一个。

解决方案:哈维德

基于HAVEGE原理,并且以前基于其相关库,hasged允许基于处理器上代码执行时间的变化来生成随机性。由于一段代码几乎不可能花费相同的确切时间来执行,即使在相同硬件上的相同环境中也是如此,因此运行单个或多个程序的时间应该适合于为随机源设定种子。在重复执行循环后,使用处理器时间戳计数器(TSC)的差异,将系统的随机源(通常是/dev/random)种子化

如何安装哈维格德

按照本文中的步骤操作。https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged


答案 2

如果有人遇到此问题

我只是通过删除所有调试器断点来解决我的问题。