Linux 4.19 lets you declare your trust in AMD, IBM and Intel Linux v4.19-rc1, release candidate code published on Sunday, allows those building their own kernel or Linux distribution to choose whether or not to trust the CPU hardware random number generator, a decision that has become complicated in the wake of the revelations about government surveillance over the past five years. When …
No, not really that useful.
At issue is that for most tasks the regular random number generator is random enough.
For tasks that require a better random number generator, they will use alternative that are already available.
So sure it moves the issue to vendor, (e.g. RH, SuSE, etc ...) but it really is attempting to solve a problem that is solved thru other means. I guess you could say it reduces the burden on the other apps to supply their own random number generator. Thats about it...
The alien because one of the best sources for entropy (randomness) comes from listening to background radiation/noise from space...
> You have a Yes/No decision at kernel build time.
Only if you build your own kernel.
> Why would you want to disable it?
Because you are using a kernel provided by a Linux distro, not compiling your own. In this case, the distro may want to choose a default value for this flag, but the user may want to change the flag.
There are usually good reasons for using a distro rather than building your own Linux distro from scratch: it's a lot less hassle, it gives you software binaries that have been tested, and it makes it easy to get security patches. All those arguments apply to the kernel as much as the rest of the software in the distro. Of course, there are times when people have specific non-standard requirements, and have to compile a kernel themselves, but those are rare.
And yes, most of the people reading this thread are likely part of the rare group with non-standard requirements, but that's because this is a thread about a kernel patch on a tech news website...
"no - not every system has a need for it - my media server as example."
What makes you think a malcontent can't usurp your media server and use it as a springboard to other parts of your network...or even as part of a botnet to attack the greater Internet (in which case it doesn't matter if it has secrets or not, just oomph and access).
Because if you can't trust the CPU's RNG, you can't trust ANY RNG. There's no telling where it's been, certification or no, plus the CPU or mobo can undo any effort you make by tampering with the communications channels. The main reason you want a hardware RNG is because you need a high-throughput TRNG, such as running a key-generating server.
As for trusting the CPU's RNG, this is usually mitigated by employing multiple entropy sources so that the worst case is that a bad source adds no entropy. AFAIK, there's no practical way for the CPU to know enough about any alternate sources to actually negate entropy.
There's one place where the CPU and ONLY the CPU can be used: bootstrap. At that point, no other buses are open, including those you'd need to access another RNG. How does one propose to secure the bootstrap procedure without access to any other RNG?
"Because if you can't trust the CPU's RNG, you can't trust ANY RNG."
I don't follow that logic. Can you explain?
"The main reason you want a hardware RNG is because you need a high-throughput TRNG, such as running a key-generating server."
Absolutely. I wasn't arguing against hardware RNGs. I was talking about the RNGs that are included in some CPUs.
"How does one propose to secure the bootstrap procedure without access to any other RNG?"
There are a few ways to do this, depending on the CPU in question, but that's a discussion that can't be effectively had in a comment section. But I wasn't addressing securing the bootstrap procedure, I was really talking about using it for crypto in the more general case. If you're stuck with the CPU RNG for boot-time, then that's what you use. But that doesn't mean you should keep using it for crypto after the boot process completes.
"Because if you can't trust the CPU's RNG, you can't trust ANY RNG."I don't follow that logic. Can you explain?
Because any other source of RNG would have to be accessed via a communications interface in the same computer that has a compromised CPU RNG. The PCIe, USB, thunderbolt, serial, parallel, PS/2, or any other communications interface is controlled by the same source as the CPU. Therefore if the manufacturer of the CPU is going to compromise the CPU's RNG, they are full capable of intercepting, and modifying, any other data traffic in in the computer.
That hardware RNG you plugged into the USB port? Pity the number being used in the encryption software running on the CPU isn't the one from that USB attached RNG, as the CPU substituted the RNG from the USB port with its own dodgy RNG.
@aldakka: purely in theory, yes
but there are quite a few people that de-lid and de-cap Intel CPUs to look what they actually do on the silicon level, then there's the thing of CPU having very well defined outputs for given inputs, again, something that quite a few people verify before using the CPU in question
and then we have the RNG, circuit that *by design* produces inscrutable and unpredictable outputs for all inputs. Does it do that by encrypting a counter with AES and a key a TLA knows? or does it do that by getting the data from some quantum process? can't really tell (and believe me, people have looked at it, there are plenty of papers on the topic)
so while, yes, one single person can't be certain that the CPU doesn't switch completely predictable bytes in place where the USB provided random bytes should be, as a community we can be reasonably sure it doesn't do that; can't say the same of the built-in RNG
"so while, yes, one single person can't be certain that the CPU doesn't switch completely predictable bytes in place where the USB provided random bytes should be, as a community we can be reasonably sure it doesn't do that; can't say the same of the built-in RNG"
HOW? Particularly against something of state-level resources like a TLA? If they can hide corrupt RNGs in a CPU beyond the ability to detect even via things like x-rays, can't the same technique be used to corrupt any other I/O stream? After all, things like heartbleed and shellshock got past "the community" for a long time, too. For all we know, something like this has been a black project since before it was even a concern to us.
"If they can hide corrupt RNGs in a CPU beyond the ability to detect even via things like x-rays, can't the same technique be used to corrupt any other I/O stream?"
because to turn an RNG to a biased one requires changing the amount of doping in a single transistor (oh, and that counter mode for AES? that's what the Intel design document says how its RNG works; which means there is very little that needs to change to make the counter or the key predictable (and thus RNG's output) to certain people and still completely unpredictable to me and you)
detecting when the USB dongle connected is a custom RNG or just a RS232 bridge or a LHC muon detector requires likely hundreds of transistors or hundreds of cycles
and sure, it's technically possible for a TLA to create such a CPU and plant it in your computer, but if they are interested in you to this degree, the RNG of Intel CPU would be the last thing on my mind
I don't know why you bring shellshock – it was a documented feature with unintended consequences. Regarding heartbleed – because we know that the RNG is the important part, we know that Intel sometimes screws up implementation (fdiv bug for most well known example) and people are specifically looking for problems in it. Nobody was looking for bugs in heartbeat implementation before heartbleed.
"why is there even a random number generator in a cpu's microcode?"
Convenience. It's cheaper and easier to have it there than to have to include RNG hardware externally.
"It would make more sense to me for OS or better yet the security software to have an RNG."
Software cannot produce random numbers, only pseudorandom numbers. In practice, with the proper pRNG algorithm, that can be good enough -- but you still want at least one actual random number to seed the pRNG.
"This could tend to make it more difficult for unwanteds to gain access to the device."
That would make it easier, really.
A few reasons:
1) The CPU's random number generator can be random, based upon provably random phenomena rather than a pseudo-random number based upon mathematical manipulation.
2) There are some sources of actually-random data in a computer, although they are usually not the same strength as "provably random". An example is the jitter from disk drive events. But these sources are rapidly disappearing as physical devices towards silicon. This is the operational problem with not enough 'entropy' (aka real randomness) being available as a machine starts.
3) It's "too easy" for these actually-random sources of data in a computer to be influenced from outside the computer. Since they are not built as cryptographic devices. Whereas the random instructions within the CPU can include tamper detectors (such as for high EM fields).
4) Timing and other covert channel attacks are simpler against software than against hardware. Those attacks are also simpler against hardware not intended to be cryptographic devices than against hardware designed with covert channels in mind. It is easier in hardware to build a black box where all instances of the instruction take the same time to complete, use the same power, and so on. (As an aside the current issue with CPUs is that the care of design needed to defeat covert channels done for the RDRAND instruction needs to be repeated throughout the CPU design for other instructions.)
These reasons explain the last line of Ted's LKML e-mail: "Note: I trust [Intel's hardware instruction] RDRAND more than I do Jitter Entropy [from the computer's hardware devices]".
"(As an aside the current issue with CPUs is that the care of design needed to defeat covert channels done for the RDRAND instruction needs to be repeated throughout the CPU design for other instructions.)"
Well, one problem with that approach is that these CPUs are more often being put into portable applications where power isn't a given. In which case efficiency trumps security unless you can achieve both (which last I checked, you can't; efficiency inevitably leaves tells).
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
