Linux: removing the lock pool / dev / random

As you know, / dev / random, a cryptographically strong pseudo random number generator (CSPRNG), has one unpleasant problem – blocking. This article describes how to solve it.

Over the past few months, the means of generating random numbers in the kernel have been slightly reworked, but problems in this subsystem have been resolved over wider time frame. The most last changes were made to prevent the getrandom () system call from being blocked for a long time at boot, but the underlying reason for this was the behavior of the blocking random pool. A recent patch would remove this pool, and it was to be expected that it would go to the main core.

Andy Lutomirski released the third version of the patch in late December. He brings “Two main semantic changes in random Linux APIs”. The patch adds the new GRND_INSECURE flag to the getrandom () system call (although Lutomirsky refers to it as getentropy (), which is implemented in glibc using getrandom () with fixed flags); this flag forces the call to always return the amount of data requested, but without guaranteeing that the data is random. The kernel will simply do its best to give the best random data that it has at a given time. “Probably the best thing to do is call him“ INSECURE “ (unsafe) to prevent the use of this API for things that need security. ”

Patches also remove the blocking pool. Currently, the kernel supports two pools of random data, one of which corresponds to / dev / random, and the other to / dev / urandom, as described in this article 2015 year. A blocking pool is a pool for / dev / random; reading for this device will be blocked (meaning its name) until “sufficient” 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 the flags value set to zero (and turns the GRND_RANDOM flag into 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.

Lutomir says: “I believe that the Linux blocking pool has become obsolete. CRNG Linux generates output that is good enough to use even for key generation. The 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 aim of ensuring that existing programs do not really suffer, and in fact, problems with the long wait for things such as generating GnuPG keys will become smaller.

“These series should not violate any existing programs. / dev / urandom remains unchanged. / dev / random still blocks immediately after loading, but it blocks less than before. getentropy () with existing flags will return a result that will be just as practical for the purpose as before. ”

Lutomirsky noted that the question remains open whether the core should provide the so-called “true random numbers”, which to some extent should have been done by the blocking core. He sees only one reason for this: “compliance with state standards.” Lutomirsky suggested that if the kernel should provide this, then this should be done through a completely different interface or should be transferred to the user space, allowing it to retrieve unprocessed event patterns that can be used to create such a lock pool.

Stephan Müller suggested that his set patches for Linux random number generator (LRNG) (version 26 is currently released) there may be a way to provide true random numbers for applications that need it. LRNG “fully complies with the requirements of the” Recommendations on the sources of entropy used to generate random bits “SP800-90B”, which makes it a solution to the problem of state standards.
Matthew Garrett objected to the term “true random data,” noting that selectable devices can, in principle, be modeled accurately enough to make them predictable: “we are not taking quantum events here.”

Muller replied that the term comes from the German standard AIS 31 to describe a random number generator that only produces the result “at the same speed as the underlying noise source produces entropy”.

In addition to the misunderstandings of the terminology, the presence of a lock pool, as suggested by the LRNG patches, will simply lead to various problems, at least if it is available without privileges.

As Lutomirsky said: “This does not solve the problem. If two different users run stupid programs such as gnupg, they simply 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 something similar), and since it does not require any privileges to use it, it also prone to abuse. Gnupg is wrong, it is a complete collapse. If we add a new unprivileged interface that gnupg and similar programs will use, we will lose again. ”

Muller 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, Muller believes that warranty is the only reason GnuPG currently reads directly from / dev / random. But if there is an unprivileged interface that is subject to a denial of service (as of today / dev / random), then according to Lutomirsky, it will be misused by some applications.

Theodore Yue Tak Ts’o, the 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 the TRNG mechanism will simply serve as a decoy for application developers and believes that in reality, 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 based on root privileges will not solve the problem: “Application developers point out that their application is installed as root for security reasons, which is the only way you can access” really good “random numbers.”

Muller asked if Cao had refused to implement the blocking pool, which he himself had long proposed. Cao replied that he planned to take the Lutomirsky patches and actively objected to adding a blocking interface back to the kernel.

“The kernel cannot give any guarantees as to whether the noise source has been properly characterized. The only thing a GPG or OpenSSL developer can get is the vague feeling that TRUERANDOM is “better,” and since they want more security, they will no doubt try to use it. At some point, it will be blocked, and when some other smart user (perhaps a distribution specialist) inserts it into the init script and the systems stop working, users will only have to complain to Linus Torvalds himself. ”

Cao also advocates providing cryptographers and those who really need TRNG with a way to collect their own entropy in user space so that they can use it as they see fit. He says that entropy collection is not a process that can be performed by the kernel on all kinds of hardware supported by it, in addition, the kernel itself cannot estimate the amount of entropy provided by various sources.

“The kernel should not mix different noise sources together, and of course, it should not try to claim that it knows how many bits of entropy it receives when it tries to play some kind of“ jerky game of entropy ”on a CPU architecture simple for the ugly user “IOT / Embedded cases, when everything is out of sync with a single master generator, when there is no CPU instruction to reorder or rename the register, etc.”

“We can talk about providing tools that try to make these calculations, but such things should be carried out on the equipment of each user, which for most users of the distribution kit is simply impractical. 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 don’t agree on anything less.” We can talk about how we provide interfaces to cryptographers so that they can get the necessary information through access to primary noise sources, separated and named, and, possibly, somehow noise source can authenticate itself in a library or user space application. ”

There was a little discussion about how such an interface might look, because, for example, for some events there may be security implications. Cao noted that keyboard scan codes (that is, keystrokes) are mixed into the pool as part of entropy collection: “Transferring this to user space, even through a privileged system call, would be at least unreasonable.” It is possible that other event timings can create some kind of leakage of information through side channels.

Thus, there is a feeling that the long-standing problem of Linux random number subsystem is on the way to a solution. The changes that the random number subsystem has undergone recently, in fact, led only to DoS problems in the process of its use. Now there are effective 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 it will not be done inside the kernel itself.

A bit of advertising 🙂

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to your friends, cloud VPS for developers from $ 4.99, A unique analogue of entry-level servers that was invented by us for you: The whole truth about VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps from $ 19 or how to divide the server correctly? (options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

Dell R730xd 2 times cheaper at the Equinix Tier IV data center in Amsterdam? Only here 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – from $ 99! Read about How to Build Infrastructure Bldg. class using Dell R730xd E5-2650 v4 servers costing 9,000 euros for a penny?

Similar Posts

Leave a Reply