As is known, /dev/random, a cryptographically secure pseudorandom number generator (CSPRNG), has one unpleasant problem – blocking. This article discusses how to resolve it.
In the past few months, the random number generation mechanisms in the kernel have been somewhat reworked, but issues in this subsystem have been addressed over a broader timeline. were made to prevent prolonged blocking of the getrandom() system call during system boot, but the underlying cause was the behavior of the blocking random pool. A recent patch would remove this pool, and it was expected to head toward the main kernel. two major semantic changes to the Linux random APIs.
The patch adds a new flag, GRND_INSECURE, to the getrandom() system call (although Lutomirski refers to it as getentropy(), which is implemented in glibc using getrandom() with fixed flags); this flag ensures that the call always returns the requested amount of data, but without guaranteeing that this data is random. The kernel will simply make its best effort to provide the best random data available at that moment. It's probably best to label it 'INSECURE'(not secure), to discourage using this API for things that require security. The patches also remove the blocking pool. Currently, the kernel supports two pools of random data, one corresponding to /dev/random and the other to /dev/urandom, as described in this 2015 document. The blocking pool is the pool for /dev/random; reading from this device will be blocked (as its name implies) until 'sufficient' entropy has been collected from the system to satisfy the request. Further reads from this file are also blocked if there is insufficient entropy in the pool.
Patches also remove the blocking pool. Currently, the kernel supports two pools of random data, one corresponding to /dev/random and the other to /dev/urandom, as described in this. 2015. The blocking pool is the pool for /dev/random; reading from this device will be blocked (as indicated by its name) until 'sufficient' entropy has been collected from the system to satisfy the request. Further readings from this file are also blocked if there is insufficient entropy in the pool.
The removal of the blocking pool means that reading from /dev/random behaves like getrandom() with the flags value set to zero (and turns the GRND_RANDOM flag into a noop). After initializing the cryptographic random number generator (CRNG), reading from /dev/random and calling getrandom(…,0) will not block and will return the requested amount of random data.
Lutomirski says: "I believe that the blocking pool in Linux has outlived its usefulness. The Linux CRNG generates output that is good enough to be used even for key generation. The blocking pool is no stronger in any material sense, and maintaining it requires a lot of infrastructure of questionable value."
Changes have been made with the aim of ensuring that existing programs are not adversely affected, and in fact, the issues with long waits for things like GnuPG key generation will reduce.
"These series should not disrupt any existing programs. /dev/urandom remains unchanged. /dev/random still blocks immediately after boot, but it blocks less than before. getentropy() with existing flags will return results that are just as suitable for practical purposes as before."
Lutomirski noted that the question remains open as to whether the kernel should provide so-called 'true random numbers,' which the blocking kernel was supposed to do to some extent. He sees only one reason for this: 'compliance with government standards.' Lutomirski suggested that if the kernel is to provide this, it should be done through an entirely different interface or should be moved to user space, allowing it to extract raw event samples that may be used to create such a blocking pool.
Stephan Müller suggested that his set The Linux Random Number Generator (LRNG) (currently at version 26) can provide true random numbers for applications that require them. LRNG "fully complies with the guidelines of the 'Recommendations for the Entropy Sources Used for Random Bit Generation' SP800-90B," making it a solution for issues concerning government standards.
Matthew Garrett opposed the term 'true random data', noting that selected devices can, in principle, be modeled closely enough to make them predictable: 'we're not sampling quantum events here.'
Müller replied that the term stems from the German standard AIS 31, which describes a random number generator that outputs results 'at the same rate that the underlying noise source produces entropy.'
Apart from terminological discrepancies, having a locking pool, as proposed in the LRNG patches, will simply lead to various problems, at least if it is available without privileges.
As Lutomirski said: "This doesn't solve the problem. If two different users run stupid programs like gnupg, they just deplete each other. I see currently two main issues with /dev/random: it is prone to DoS (i.e., resource exhaustion, malicious impact, or something similar), and since no privileges are required to use it, it is also prone to abuse. Gnupg is wrong — it's a complete collapse. If we introduce a new unprivileged interface that gnupg and similar programs will use, we'll lose again."
Müller noted that adding getrandom() will now allow GnuPG to use this interface, as it will provide the necessary guarantee that the pool has been initialized. Based on discussions with GnuPG developer Werner Koch, Müller believes that the guarantee is the only reason GnuPG currently reads directly from /dev/random. However, if there is an unprivileged interface that is subject to denial of service (like /dev/random today), then according to Lutomirski, it will be misused by some applications.
Theodore Yue Tak Ts'o, the developer of the Linux random number subsystem, apparently changed his mind about the need for a blocking pool. He stated that removing this pool would effectively eliminate the idea that Linux has a true random number generator (TRNG): "This is not nonsense, as it is precisely what *BSD has always done."
He is also concerned that providing a TRNG mechanism would simply serve as bait for application developers and believes that, given the various types of hardware supported by Linux, it is impossible to guarantee TRNG in the kernel. The issue won't be resolved even with the possibility of functioning only with root privileges: "Application developers indicate that for their application to be secure, it must be installed as root, as only then can you access 'truly good' random numbers."
Mueller asked if Ts'o had abandoned the implementation of the blocking pool that he himself had proposed long ago. Ts'o replied that he plans to adopt Lutomirski's patches and is actively opposed to adding the blocking interface back into the kernel.
"The kernel cannot guarantee whether the noise source has been characterized properly. The only thing a GPG or OpenSSL developer can get is a vague feeling that TRUERANDOM is 'better,' and since they want more security, they will undoubtedly try to use it. At some point, it will become blocked, and when some other savvy user (possibly a distribution release specialist) incorporates it into the init script and systems stop working, users will have no choice but to complain to Linus Torvalds himself."
Ts'o also advocates for providing cryptographers and those who truly need TRNG a way to collect their own entropy in user space to use as they see fit. He states that collecting entropy is not a process that can be performed by the kernel across all supported hardware; moreover, the kernel itself cannot assess the amount of entropy provided by various sources.
The core should not mix different noise sources together, and it certainly should not claim to know how many bits of entropy it is receiving when attempting to play a "jerky entropy game" on a ridiculously simple CPU architecture for IoT/Embedded use cases, when everything is desynchronized with a single master generator, where there is no CPU instruction to reorder or rename registers, etc.
One can talk about providing tools that try to make these calculations, but such things should be done on each user's hardware, which is simply impractical for most users of the distribution. If this is intended only for cryptographers, then let it be done in their user space. And let's not simplify GPG, OpenSSL, etc., so that everyone says, "we want 'true randomness' and will not settle for less." We can discuss how we provide interfaces for cryptographers to obtain the necessary information through access to primary noise sources, separated and named, and perhaps in some way the noise source can authenticate itself in the library or application of user space.
There was a small discussion about what such an interface might look like, since, for example, some events could have security implications. Cao noted that keyboard scan codes (i.e., key presses) are mixed into the pool as part of the entropy collection: "Moving this to user space, even through a privileged system call, would be, at the very least, unwise." It is quite possible that other event timings could create some information leakage through side channels.
Thus, it seems that the long-standing issue of the Linux random number subsystem is on its way to being resolved. The changes that the random number subsystem has undergone recently have only resulted in DoS issues during its usage. Now, effective methods have emerged to obtain the best random numbers that the kernel can provide. If a TRNG is still desired for Linux, this shortcoming will need to be addressed in the future, but most likely, it will not be accomplished within the kernel itself.
A little advertisement 🙂
Thank you for staying with us. Do you enjoy our articles? Want to see more interesting content? Support us by placing an order or recommending us to your friends, , a unique entry-level server alternative that we have created for you: (options available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd at half the price in the Equinix Tier IV data center in Amsterdam? Only with us in the Netherlands! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — from $99! Read about how
Source: habr.com
