Fixing getrandom()

Posted Oct 1, 2019 17:05 UTC (Tue) by zlynx (guest, #2285)
In reply to: Fixing getrandom() by ceplm
Parent article: Fixing getrandom()

What do you do about the fact that IoT devices built with identical hardware and identical software boot up and produce one of *maybe* 4,000 or so *identical* /dev/urandom streams. It's pretty much based on temperature which can *slightly* modify the interrupt rates vs clock cycles.

At any rate, it's a real problem. Because if they do something during boot such as generate their own SSH or SSL certificates the attacker only has to guess a few possibilities.

Fixing getrandom()

Posted Oct 1, 2019 19:02 UTC (Tue) by ceplm (subscriber, #41334) [Link]

Hold on! I haven’t said it cannot be real problem (although, couldn’t that first start of ssh daemon be a bit dealyed after whole system is up; systemd should be able to do something like that, shoudln’t it?). I just said a) there is something wrong with getrandom() defaults to the blocking version (sshd is certainly minority here, so it should be calling getrandom() with some specific options to make sure it gets lovely perfect random number), b) there is something wrong with gdm, when it doesn’t expect to be run rather early with possibly not enough entropy for something which really doesn’t require super-random numbers (it should certainly call getrandom(0) because it really doesn’t matter that much how superspecial those random numbers are). c) well, those IoT devices should know about this situation and somehow collect more enthropy themselves (mixing in MAC addresses, some their serial numbers; yes, it is predictable for the given device, but possibly less predictable for anonymous device in general? Not sure.)