4 ms·
This is very interesting. I wonder what key generators were used to create the insecure keys.
by sempron64 8y ago
This is very interesting. I wonder what key generators were used to create the insecure keys.
- schoen 8y agoSee https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf, which includes some identifications of some of the responsible devices. (Two groups of researchers published independently on this issue at nearly the same time.)
- lixtra 8y agoTLDR: Devices that create TLS and SSH keys just after boot when there is not enough entropy.
- loeg 8y agoThat's not a great takeaway. The takeaway is: Linux's /dev/random and /dev/urandom interfaces are both broken, in the sense that neither is reliable for embedded developers during certain early boot conditions. Some of that was maybe worse in 2012 than today, but the fundamental interface properties have not changed. Tl;dr: Use getrandom() instead of /dev/[u]random. Do not use GRND_RANDOM. Do not use GRND_NONBLOCK.
- SEJeff 8y agoI was 1/2 way through reading your comment and was thinking, "Yeah, but they can use the getrandom() that was ported from OpenBSD", but you obviously beat me to it. Take your upvote!
- loeg 8y agoOpenBSD's interface is getentropy(), but yeah, basically the same idea! I believe Linux was the second actor and intentionally made getrandom() a superset of the getentropy interface (i.e., no EINTR below 256 bytes). As a result, writing a getentropy() shim around getrandom is feasible; FreeBSD and Linux (glibc) have done so.
- SEJeff 8y agoYes, it was ported from OpenBSD. Ted literally calls it out in the commit: https://lkml.org/lkml/2014/7/17/145 https://lkml.org/lkml/2014/7/17/145
- pera 8y agoFor keys that are generated during early/first boot conditions, couldn't one wait until /proc/sys/kernel/random/entropy_avail is greater than 256 and then read from urandom? IIRC getrandom still isn't universally available on SoCs kernels.
- Scoundreller 8y agoBut maybe better pre-2009: > Surprisingly, modern Linux systems no longer collect entropy from IRQ timings. The Linux kernel maintainers deprecated the use of this source in 2009 by removing the IRQF_SAMPLE_RANDOM flag, apparently to prevent events controlled or observable by an attacker from contributing to the entropy pools. > Although mailing list discussions suggest the intent to replace it with new collection mech- anisms tailored to each interrupt-driven source [21], as of Linux 3.4.2 no such functions have been added to the ker- nel. > The removal of IRQs as an entropy source has likely exacerbated RNG problems in headless and embedded devices, which often lack human input devices, disks, and multiple cores. If they do, the only source of entropy—if there are any at all—may be the time of boot.
- X6S1x6Okd1st 8y agoRemoving something from an entropy pool because it could be used by an attacker seems really odd to me.
- schoen 8y agoIt may have been inspired by arguments like https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html (although that one was published five years later than the change we're talking about).
- clarry 8y agoThat would be rather misguided though. It's not like a device is going to know the exact time the interrupt handler routine would run, hash it, and go back "whoops, better not fire an interrupt yet because it won't be on the right tick!"
- loeg 8y agoNo. The fundamental problem — random blocks arbitrarily after seeding, and urandom does not block even before seeding — existed prior to the 2009 change.
- Scoundreller 8y agoBottom left of page 9 for RSA and middle left of Page 10 goes through which manufacturers were the mode.