As you know, /dev/random, a cryptographically strong pseudo-random number generator (CSPRNG), has one unpleasant problem - locks. This article explains how you can solve it.
Over the past few months, the random number generation facilities in the kernel have been slightly reworked, but problems in this subsystem have been resolved over a wider ... The most were made to prevent the getrandom() system call from blocking for a long time on system boot, but the underlying reason for this was the behavior of the blocking random pool. A recent patch would have removed this pool, and one would expect it to head towards the main core.
Andy Lutomirski posted the third version of the patch at the end of December. He contributes "two major semantic changes in random Linux APIs". The patch adds a new GRND_INSECURE flag to the getrandom() system call (although Lutomirsky refers to it as getentropy(), which is implemented in glibc with getrandom() with fixed flags); this flag causes the call to always return the amount of data requested, but with no guarantee that the data is random. The kernel will simply do its best to give the best random data it has at the time. "Probably the best thing to do is call it 'INSECURE' (insecure) to prevent this API from being used for things that need to be secure."
The patches also remove the blocking pool. The kernel currently maintains two pools of random data, one for /dev/random and one for /dev/urandom, as described in this 2015. The blocking pool is the pool for /dev/random; reads for this device will block (meaning its name) until "enough" entropy is collected from the system to satisfy the request. Further reads from this file are also blocked if there is not enough entropy in the pool.
Removing the lock pool means that reading from /dev/random behaves like getrandom() with flags set to zero (and turns the GRND_RANDOM flag into noop). Once a cryptographic random number generator (CRNG) has been initialized, reading from /dev/random and calls to getrandom(β¦,0) will not block and will return the requested amount of random data.
Lutomirsky says: βI think the Linux blocking pool has outlived its usefulness. Linux CRNG generates output that is good enough to be used even for key generation. A blocking pool is not stronger in any material sense, and it requires a lot of infrastructure of dubious value to maintain it.β
The changes were made with the intention that existing programs would not really be affected, and in fact there would be fewer problems with long waits for things like GnuPG key generation.
βThese series should not violate any existing programs. /dev/urandom remains unchanged. /dev/random still blocks immediately upon boot, but less blocking than before. getentropy() with the existing flags will return a result that is just as useful for practical purposes as before."
Lutomirsky noted that it is still an open question whether the kernel should provide the so-called "true random numbers", which, to a certain extent, the blocking kernel should have done. He sees only one reason for this: "observance of state standards." Lutomirsky suggested that if the kernel is to provide this, then it must be done through a completely different interface, or it must be moved to user space, giving it the ability to extract raw event samples that can be used to create such a lock pool.
Stephan MΓΌller suggested that his set for the Linux Random Number Generator (LRNG) (currently released version 26) can be a way to provide true random numbers for applications that need it. The LRNG is "fully compliant with the SP800-90B Guidelines for Entropy Sources Used to Generate Random Bits", making it a solution to government standards.
Matthew Garrett objected to the term "true random data", noting that the devices chosen could in principle be modeled accurately enough to make them predictable: "we're not sampling quantum events here."
MΓΌller replied that the term comes from the German AIS 31 standard to describe a random number generator that only produces a result "at the same rate as the underlying noise source produces entropy".
Apart from terminology inconsistencies, having a lock pool as suggested by the LRNG patches will simply lead to various problems, at least if it is accessed without privileges.
As Lutomirsky said: βIt doesn't solve the problem. If two different users run stupid programs like gnupg, they will just exhaust each other. I see that there are currently two main problems with /dev/random: it is prone to DoS (i.e. resource depletion, malicious influence, or the like), and since no privileges are required to use it, it also prone to abuse. Gnupg is wrong, it's a complete collapse. If we add a new non-privileged interface that gnupg and similar programs will use, we will lose again."
Muller noted that the addition of getrandom() will now allow GnuPG to use this interface, as it will provide the necessary assurance 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. But if there is an unprivileged interface that is susceptible to denial of service (like /dev/random today), Lutomirsky argues that it will be misused by some applications.
Theodore Yue Tak Ts'o, developer of the Linux random number subsystem, seems to have changed his mind about the need for a blocking pool. He said that removing this pool would effectively get rid of the idea that Linux has a true random number generator (TRNG): "this is not nonsense, as this is exactly what *BSD has always done."
He is also concerned that providing a TRNG mechanism would simply serve as a lure for application developers, and believes that in fact, given the various types of hardware supported by Linux, it is not possible to guarantee TRNG in the kernel. Even the ability to work with equipment only on the basis of root privileges will not solve the problem: "Application developers specify that their application be installed as root for security reasons, because that's the only way you can get access to "really good" random numbers."
Muller asked if Cao had abandoned the blocking pool implementation he himself had proposed long ago. Cao replied that he planned to take Lutomirsky's patches and strongly objected to adding the blocking interface back to the kernel.
βThe kernel cannot make any guarantees as to whether the noise source has been properly characterized. 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 a certain point, it will block, and when some other smart user (maybe a distribution release engineer) puts it in an init script and systems stop working, users will only have to complain to Linus Torvalds himself.β
Cao also advocates giving cryptographers and those who really need TRNG a way to harvest their own userspace entropy to use as they see fit. He says that entropy collection is not a process that can be performed by the kernel on whatever hardware it supports, and the kernel itself cannot estimate the amount of entropy provided by various sources.
βThe kernel should not mix various noise sources together, and it certainly should not try to claim to know how many bits of entropy it is getting when it tries to play some kind of βjerky entropy gameβ on an outrageously simple CPU architecture for user IOT/Embedded cases, when everything is out of sync with a single master clock, when there is no CPU instruction to reorder or rename a register, etc.β
βYou can talk about providing tools that attempt to do these calculations, but things like this need to be done on every user's hardware, which is simply impractical for most users of the distribution. If it's only for cryptographers, then let it be done in their user space. And let's not oversimplify GPG, OpenSSL, etc. so that everyone says "we want 'true randomness' and won't settle for less". You can talk about how we provide interfaces to cryptographers so that they can get the necessary information by accessing the primary noise sources, separated and named, and perhaps somehow the noise source will be able to authenticate itself in a library or user-space application.
There was some discussion about what such an interface might look like, as there might be security implications for some events, for example. Cao noted that keyboard scan codes (i.e. keystrokes) are pooled as part of entropy collection: "Putting this into user space, even via a privileged system call, would be unwise to say the least." It is quite possible that other event timings can create some kind of information leakage through side channels.
Thus, there is a feeling that the long-standing problem of the Linux random number subsystem is on the way to being solved. The changes that the random number subsystem has undergone recently, in fact, only led to DoS problems in the process of using it. Now there are efficient ways to get the best random numbers that the kernel can provide. If TRNG is still desirable for Linux, then this shortcoming will need to be addressed in the future, but most likely this will not be done within the kernel itself.
Some ads π
Thank you for staying with us. Do you like our articles? Want to see more interesting content? Support us by placing an order or recommending to friends, , a unique analogue of entry-level servers, which was invented by us for you: (available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd 2 times cheaper in Equinix Tier IV data center in Amsterdam? Only here in the Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $99! Read about
Source: habr.com