Comment by tveita | Hacker News Reader

Comment by tveita | Hacker News Reader

Parent Full thread

PCs can and do include hardware support for entropy gathering, see RDSEED [1]

Linux is aware of RDSEED and uses it to provide additional randomness when available. You do need to trust the implementation to be free from backdoors and bugs - some CPUs are known to be buggy. [2]

Randomness seeding issues largely does not concern desktop PCs or smartphones (although you can easily catch early booting programs like systemd reading randomness before it has been fully seeded) [3].

It is a much bigger issue on either small embedded devices or VMs, both of which may have very few peripherals to gather entropy from. They can be provided randomness through dedicated hardware support, or from the host, and they probably should be, but that still leaves many real-world systems currently running Linux out in the cold. This is not just a theoretical problem, as has been shown by looking at indicators like RSA keys with colliding primes, which should never happen when generated with good RNG. [4]

[1] https://en.wikipedia.org/wiki/RDRAND

[2] https://github.com/systemd/systemd/issues/18184

[3] https://github.com/systemd/systemd/issues/4167

[4] https://freedom-to-tinker.com/2012/02/15/new-research-theres...

I can't agree on embedded devices.

They have plenty of peripherals that can act as sensors, where you can draw entropy seeds from.

You can even leave an empty pin with a PCB trace to act as a crude antenna and pick up garbage RF.

You can use the built in RC oscillator as a crude temperature sensor.

My point is, if you're creative, embedded systems offer you so many options without any added cost.

You don't even need sensors. STMicroelectronics has a TRNG block [1] that "passes" NIST SP 800-22 statistical analysis [2]. I used quotes because the 800-22 is an analysis test suite and the notion of passing is based on your hypothesis parameters, but the suite itself is considered the de-facto analysis mechanism.

I don't follow where the confusion is coming from?

[1] https://www.st.com/resource/en/application_note/dm00073853-s...

[2] https://csrc.nist.gov/Projects/Random-Bit-Generation/Documen...

The problem with using pins to pick up 'garbage' RF is that an attacker can transmit some actual RF and make your entropy a lot more predictable.

A real randomness source would be really great to have in pretty much every computing device these days, considering the widespread use of encryption.

Agreed, but my example was for very low cost embedded systems where that makes sense like super cheap IoT sensors where every fraction of a cent is accounted for.

If your security threat profile has to account for actors with the resources to perform reverse engineering of your hardware, side channel analysis and RF injection, then we're already way out of the realm of low cost devices.

You're probably right, the issue might be that there's no standard way for an OS to hook into that.

The embedded systems that GP is referring to generally don't have a full-stack OS; hardware access is performed by directly reading to/writing from registers.

Hmm good points, but you also ignore the power costs here - using oscillators, open pins as thermometers and rf antennas requires additional power draw, not to mention modifying these devices may be nearly impossible due to their embedded nature.

Even presuming you modify the hardware/firmware, the additional cycles to handle and process the sensor data mean additional power draw compared to normal operation (embedded devices may frequently power down to wake from some interrupt to save power, additionally not all instructions turn on the same number of transistors - floating point ops require more power than simple branch instructions) - something again that prohibits doing this easily.

So "without any added cost" is simply untrue.

The reality is that randomness is relatively expensive, whether via hardware or software. Phones have more sensors - they also have massively complex SoCs and large batteries, which still are drained often over the course of a single day. They also tend to cost 1k+ USD, at least for flagship models (prices go as low as 50$ these days, but this is more from economies of scale and resale value economics than because phone hardware/software is suddenly cheap to manufacture)

None of that is at all expensive.

Reading from RF trace does not take any more power than any other analog pin voltage measurement.

Running a few more instructions to "process" (not as if there's much processing needed) the sensor readings is also hardly measurable.

For KVM VMs, please use virtio-rng! If you have virtio (which most VMs do) then adding a virtio-rng virtual device costs nothing and gives the VM access to the host's entropy. systemd etc in the VM should then have no problem at all consuming as much entropy as it likes as early in the boot as it needs.

https://wiki.qemu.org/Features/VirtIORNG

Could timing be used to seed a cpu? ie, not all cpus are built the same, and similarly for all powersupplies, could the two be used together to bootstrap seeding i.e. by measuring voltage or voltage differences?

Tha'ts effectively how a lot of the jitter sourced entropy ends up working, sometimes in a more round about way though.

Yes! I went to a talk given by a security researcher who proposed using the difference in clocks between north bridge and south bridge to generate randomness.

this article mentions timing of hardware interrupts as an entropy source. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72...

another possible entropy source: the sequence of different kinds of hardware interrupts should be very hard to predict.

Reply on news.ycombinator.com