请不要将其标记为重复。这是这两个问题的后续问题。
我知道,取代
securerandom.source=file:/dev/urandom
与
securerandom.source=file:/dev/./urandom
在$JAVA_PATH/jre/lib/security/java.security会解决这个问题。
$JAVA_PATH/jre/lib/security/java.security
我的问题是,可以在生产中这样做吗?这会对安全性产生任何影响(例如会话ID变得可预测)吗?如果这不太安全,还有其他方法可以更快地提供足够的熵吗?
我使用openstack进行部署(或者说,使用AWS或GCP或任何其他云提供商)。因此,添加硬件设备(如声卡)对我来说不是一种选择。
在使用正确的搜索词进行了广泛的谷歌搜索之后,我在DigitalOcean上看到了这篇不错的文章。我只是在这里引用相关部分。
Linux上有两种常规的随机设备:/ dev / random和/ dev / urandom。最好的随机性来自/ dev / random,因为它是一个阻塞设备,它将等待直到有足够的熵来继续提供输出。假设您的熵足够了,您应该从/ dev / urandom中看到相同的随机性。但是,由于它是一种非阻塞设备,即使熵池用完了,它也将继续产生“随机”数据。这可能会导致质量较低的随机数据,因为更可能重复以前的数据。当生产服务器上的可用熵不足时,尤其是当该服务器执行加密功能时,可能会发生很多坏事。
因此,这有潜在的安全风险。
Linux已经从不同的硬件来源获得了质量很好的随机数据,但是由于无头机器通常没有键盘或鼠标,因此产生的熵要少得多。磁盘和网络I / O代表了这些机器的大多数熵生成源,并且它们产生的熵非常稀疏。由于极少数无头机器(例如服务器或云服务器/虚拟机)具有任何可用的专用硬件RNG解决方案,因此存在一些用户域解决方案,可使用比硬盘(如视频卡)“噪音大”的设备的硬件中断来产生额外的熵,声卡等。不幸的是,这再次成为服务器的问题,因为它们通常不包含任何一个
基于HAVEGE原理,并且先前基于其关联的库,Haveged允许根据处理器上代码执行时间的变化来生成随机性。由于即使在相同的环境下,在相同的硬件上,一段代码几乎都不可能花费相同的准确时间来执行,因此运行单个或多个程序的时机应该适合于植入随机源。重复执行循环之后,使用处理器时间戳计数器(TSC)的差异,已实现的实现会播发系统的随机源(通常是/ dev / random)
请按照本文中的步骤。https://www.digitalocean.com/community/tutorials/how-to-setup- additional-entropy-for-cloud-servers-using- haveged