The minor version number is now 18, so let's dig into what is interesting from the security standpoint.
Intro to randomness
This update brings multitudes of improvement to the well-known "random/urandom" device. This device is used by both application and kernel code when it needs some portion of random bytes, or, better to say, pseudo-random bytes, which, in turn, is a fundamental ingredient for most of security operations (encryption, cryptographic signing, etc). No VPN or HTTPS can ever exist without a good random source.
Good randomness
But what does stand for "good" random generator? First, it should be fast. Your HTTPS web server should not slow down serving the internet clients just because it needs to obtain more random bytes. Second, random source should be cryptographically secure, meaning that no algorithm exists that can distinguish the output from our artificial generator from a perfect theoretical random generator in a reasonable time. Finally, our random source must be resistant to various types of attacks, like:
- attacker calculates future random bytes by knowing some previous bytes he got access to
- attacker calculates previous random bytes by knowing some recent random bytes
- attacker got access to the whole machine RAM and is able to find internal data of the random source (also known as "state").
Generic pseudo-random generator (PRNG) design
Very simplified workflow is depicted below.
In the heart of it is a trusted random source, like hardware random generator, usually based on some physical process with random nature. These ideal generators are rather slow, so they cannot be used directly. Instead, their output is hashed (to eliminate occasional imperfectness) and then the product is used as a encrypting key for some strong symmetric cipher. By encrypting more and more new data each time, we obtain more and more pseudo-random bytes. This process can run forever to produce SSH, VPNs or TLS keys. But there are pitfalls. It is not safe to produce too may random material from the same key (the safe boundary is usually from kilobytes to megabytes, depending on the algorithm). So good PRNGs regularly regenerate their keys.
Importance of a key erasure
Recent kernels uses the so-called fast key erasure random generator. It was specifically designed to address the RAM reading attack. Suppose you used a decent PRNG to generate a pair of big asymmetric encryption keys, say, for your SSH session. To prevent from stealing the key and subverting the protection, SSH program erased this base key in memory just after it was used to establish a short-lived session key. If an attacker gets access to the computer memory, he is unlucky to get this key. But there is also a PRNG key stored somewhere! If he is able to read this one, he can effectively restore all subsequent keys produced from it. Fast key erasure principle mandates that the PRNG's key should be overwritten as soon as some small random data was produced from it, i.e. without waiting for kilobytes or megabytes as it was mentioned in the previous section.
Kernel's implementation
The main "building blocks" of recent kernels are:
ChaCha20 cipher
It is a modern, fast and secure stream cipher, it has different encryption "strenght" (denoted as 8, 12 and 20 round depth). Here the strongest variant is used. It has 32 bit keys and 64 bit operating blocks.
Blake2s hash
Modern hash known to be faster than SHA1, SHA2 and SHA3, but as secure as the latter. It takes collected entropy bits (read below) and existing RNG key to produce a new RNG key.
Input pool
Storage of a fixed size (4096 bits) where a lot of different random-looking numbers coming from different places are mixed by the kernel: MAC addresses, serial numbers, input device activity, disk activity, hardware interrupts. These events are very hard to predict by nature (no one knows when a user clicks a mouse) and sometimes called "raw entropy". The kernel can also takes random bits from hardware RNGs if available in the system. Finally, a bootloader can pass additional random material to the kernel, thus contributing to the whole randomness of the system. All those pieces are hashed regularly to form the input pool that is used an input to the encryption function, as well as to update the encryption key itself.
CRNG
The heart of the random generator. It regenerates its key every time it delivers a new chunk of random data. After the system boots up, its state is known as "not ready" or "uninitialized". At this time there is not enough input pool and the kernel uses raw entropy to seed the random generator including its key, and it becomes "initialized", but not fully ready . Later, after enough raw entropy is collected and mixed, the CRNG remains "initialized" and is now considered as fully ready getting its state from the hashed portions of the input pool.
We hope you enjoyed the world of randomness with this short introduction to the kernel random generator!
Useful Links