So my perennial assertion that using the default "self-signed" certs generated by embedded systems when they are installed is a really bad idea is vindicated by this research. Another "told you so" moment I can savour.
Flaws in the way some of EMC's RSA security division encryption keys are generated are down to a weakness in generating random numbers that's restricted to network devices rather than digital certificates on websites, according to both RSA and cryptographic researchers. After analysing 7.1 million keys, cryptography …
Only because the state of the device at that point is in an almost entirely predictable state, indeed (near-)identical to others of the same make and model, or merely type. Should the thing come with a decent hardware random number generator, then suddenly they're fine, really.
If the device doesn't, then make sure you generate any and all certificates elsewhere, with a better RNG, before installing them. Otherwise it still doesn't matter a whit how they're signed. Recall that even when paying for a certificate you end up generating the private key yourself.
In context, RSA is an algorithm, one widely taught (like, highschool math masterclasses), well-known, available. RSA-the-company was founded by the same people that cooked up the algorithm, but that doesn't mean each implementation has their hand in it, or even their blessing. This spat isn't nearly as connected to them as, say, the break-in that compromised their remote login security keyfobs.
Generally you'd want a *good* source of random numbers, and a PRNG almost by definition disqualifies itself (the "pseudo" bit), though with all sorts of clever tricks it is possible to get something less awfully bad than the old "rand()" found in historical libcs, where you need to discard the lower 12 bits to get something vaguely usable even for, say, games. Modern unices, say, will "gather entropy", possibly even keep it across reboots, and provide a reasonable source of random numbers, possibly with hardware assistance if available. You pretty much need OS support (drivers) for that last bit. Some programs bring their own random number generators, especially if the OS isn't known to provide good support.
The problem with these embedded devices is that at first start-up, they haven't been running very long and as such the random numbers they generate then aren't very good at all, even if your PRNG isn't unreasonable. And that's the point at which these certificates tend to be generated.
So, who's responsible? The embedded system designers, basically. Could chalk it down to an oversight, and an object lesson in how tiny details can wreak havoc upon an otherwise perfectly good plan, especially when crypto is involved. This sort of thing is exactly why random numbers are important.
This 2000 char limit (without a char count) is a real PITA in replying to posts like yours so I'll skip most of your information.
Para 1. True, it is taught. However check the copyright notices in the code. If it includes "RSA Data Security" they either wrote it or provided a version that has been adapted internally. So (again) does the PRNG come as part of the RSA code or is this a service provided by the host OS/hardware?
Para 2. Well duh. The P is for "Pseudo" as in not *real*. Note some people *want* an RNG they can set to give a *repeatable* sequence of random #s so they can run different *data* against a simulation and see what effect that has. Knuth has a fair sized section on PRNG, randomness and ways to *get* randomness. It's been an issue with computers since at least the mid 1950's.
Hardware support can be as simple as a CMOS gate input left open circuit to drift up and down depending on the micro environment around the contact and sampled. Depending on sample rate that might be good enough. Might not. The UK premium bond system uses a noisy diode.
"Modern unices" I presume you're talking about OSes derived from Unix? Fair point given the number of embedded network devices that use Linux as a platform. "Gather entropy" well they might, then again they might not.
Para 3. This was one of the vulnerabilities that lead to cracking the Charlie card of the MBTA
http://www.theregister.co.uk/2008/09/26/boston_mta_hack/ The ticketing machines tended to be switched on around the same time of day and that was part of the seed. So instead of a 1 in 86400 chance of hitting that part of the seed (# of secs in a day) for example you're down to say 1 in 600.
Para 4 Again depends who provides the PRNG and what specs were used. I'd agree most of the time it's *likely* to be the hardware suppliers or the OS.
So what is the problem? No need to discuss basic facts, this is not show & tell.
-> If you are on an open-sourced Unix, check the implementation of /dev/random [for random numbers derived from the system state] or /dev/urandom [for random numbers derived from an algorithm]
-> If the random-number generator comes with the package [in whatever form], check that. See also the Debian event: http://www.schneier.com/blog/archives/2008/05/random_number_b.html
-> If you see "RSA Data Security" on the package [in whatever form] and the PRNG is part of said package, ask for a signed statement of the CEO that this PRNG is correctly seeded and passes sundry statistical tests etc.
-> If you have a hardware number generator, use that, but stay away from naive implementations like "as simple as a CMOS gate input left open circuit". See here: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0
I skimmed the paper, and I agree with Kaminsky et al. The authors want us to believe that "single-secret" asymmetric-key systems (eg Diffie-Hellman) are inherently safer than "multiple-secret" ones like (conventional) RSA, because the latter use more data from the CPRNG and so are more vulnerable to flaws in it. (Hence the title of the paper: "Ron" is Ron Rivest of RSA, and "Whit" is Whitfield Diffie of D-H.) That's a bit like saying a car is more vulnerable to potholes than a motorcycle is, because the former has more wheels that can fall into them.
The real story here is that some embedded implementations of RSA have weak CPRNGs, typically due to insufficient entropy gathering protocols. That's just barely news. The vulnerability of cryptosystems to broken CPRNGs is not - that comes up in Crypto 101.
Biting the hand that feeds IT © 1998–2019