On Sun, Dec 23, 2018 at 05:52:31PM +0100, Stefan Fritsch wrote: > I think some other questions should be considered first. Did Debian protect > from these attacks in the past? The answer is clearly no. Now, should we > break > the systems of those people who keep their random-seed file secret and don't > clone their OS image, in order to offer some protection to other people? This > is really what we need to answer first, and in my opinion, we should try very > hard not to break the systems of those users. And I see no other way than to > credit the random seed file with entropy.
I don't think this line of reasoning is valid. Supposed there was a horrific security hole, such that 10% of publically available SSH hosts had insecurely shared public keys such that were vulnerable to being guessed[1]. Cearly, in the past (before we knew about such a vulnerability) we did not protect those systems against this attack. Does this mean we shouldn't in the future? I don't think it so follows! [1] Mining your p's and q's: Widespread Weak Keys in Network Devices. https://factorable.net There is a balancing test that has to go on here. And quite frankly Rasberry PI's are extremely problematic devices from a security perspective. They use a coarse-grained clock, so it's very hard to get good entropy out of timing events, and very the hardware that they have on them is such that there aren't many events that we can use to generate entropy in the first place. I'm not sure that it's a great idea to weaken *all* Debian systems to the security of Rasberry PI's, including x86 servers and laptops, just because one platform has crappy hardware with respect to getting secure random numbers. So perhaps the right answer is we have one default value for certain architectures, or maybe classes of devices (e.g., a server-class ARM64 device is very different from a IOT-style ARM platform). > > One could also make it harder for an attacker to regenerate key material from > a system where he knows the seed file. For example, if there is a RTC one > could > put the boot time and all serial numbers / MAC addresses that one can find > into > an expensive function like PBKDF2 or bcrypt and feed the result to the random > seed. This way, even if the attacker has an approximate knowledge of most of > that information, he would still need to spend quite a bit of computing power > to get all the possible random seeds that could be used. We mix things like serial numbers and MAC addresses into the random pool already. Unfortunately, if the attacker can snoop the random-seed file, it's likely he or she can simply obtain the MAC addresses or serial numbers of the device. > If the number of rounds in the function depends on timing, like do > as many rounds as possible in 1 second, things like the load of the > VM host and the temperature of the CPU will also play a role in the > result. A sha sum of dmesg would probably also help, because it > contains a lot of timings that also depend on the load of the VM > host. We are already mixing timing information into the entropy pool, and to the extent that there is randomness there, it is cr editedi appropriately. The problem is that the Rasberry Pi doesn't have a fine-grained clock, and there is a lot less entropy from timing events than most people might suppose. As I said, though; it's one thing for this to be added to the entropy pool. It's quite another for it to be reflected in the random seed file. Today, if the system was booted a year ago, the random seed file will not have been updated for the past 12 months. The last time it would have been updated is shortly after the system was first booted. This is **terrible* if you want to assume that we should give full credit to the random-seed file --- because entropy means, "not known to the adversary". The adversary can have access to it, including, say, when ethernet interrupts may have caused timing events because the Rasberry PI only keeps time to 100Hz granularity, and an outside attacker can look at the external timing of packets on the network, assuming that the timing of network interrupts are actually contributing entropy is.... not clear. I understand that having Rasberry Pi's take a long time to boot because they don't have entropy is frustrating. But is silently assuming they have entropy when someone really determined to reverset engineer state of the pool a preferable alternative? If someone is using the prototype and IOT device (remember: 'S' in IOT standards for security), maybe it's fine, since IOT devices are generally wide open to security problems anyway, so what's one more? Just don't put them on *my* home network. :-) But is that *really* the best answer for Debian? My opinion is "no".... At least, let's please not make the security for x86 servers and desktops worse just to please Rasberry Pi IOT developers.... - Ted
