一尘不染

Tomcat花费太多时间启动-Java SecureRandom

tomcat

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

我知道,取代

securerandom.source=file:/dev/urandom

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

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

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

更新资料

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


阅读 279

收藏
2020-06-16

共1个答案

一尘不染

在使用正确的搜索词进行了广泛的谷歌搜索之后,我在DigitalOcean上看到了这篇不错的文章。我只是在这里引用相关部分。

Linux上有两种常规的随机设备:/ dev / random和/ dev / urandom。最好的随机性来自/ dev /
random,因为它是一个阻塞设备,它将等待直到有足够的熵来继续提供输出。假设您的熵足够了,您应该从/ dev /
urandom中看到相同的随机性。但是,由于它是一种非阻塞设备,即使熵池用完了,它也将继续产生“随机”数据。这可能会导致质量较低的随机数据,因为更可能重复以前的数据。当生产服务器上的可用熵不足时,尤其是当该服务器执行加密功能时,可能会发生很多坏事。

因此,这有潜在的安全风险。

填充熵池的解决方案

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

解决方案:已避险

基于HAVEGE原理,并且先前基于其关联的库,Haveged允许根据处理器上代码执行时间的变化来生成随机性。由于即使在相同的环境下,在相同的硬件上,一段代码几乎都不可能花费相同的准确时间来执行,因此运行单个或多个程序的时机应该适合于植入随机源。重复执行循环之后,使用处理器时间戳计数器(TSC)的差异,已实现的实现会播发系统的随机源(通常是/
dev / random)

如何安装Haveged

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

2020-06-16