Matthew Hardeman via dev-security-policy <dev-security-policy@lists.mozilla.org> writes:
>In principle, I support Mr. Sleevi's position, practically I lean toward Mr. >Thayer's and Mr. Hollebeek's position. I probably support at least one of those, if I can figure out who's been quoted as saying what. >Sitting on my desk are not less than 3 reference designs. At least two of >them have decent hardware RNG capabilities. My code runs on a lot (and I mean a *lot*) of embedded, virtually none of which has hardware RNGs. Or an OS, for that matter, at least in the sense of something Unix-like. However, in all cases the RNG system is pretty secure, you preload a fixed seed at manufacture and then get just enough changing data to ensure non-repeating values (almost every RTOS has this, e.g. VxWorks has the very useful taskRegsGet() for which the docs tell you "self-examination is not advisable as results are unpredictable", which is perfect). In all of these cases, the device is going to be a safer place to generate keys than the CA, in particular because (a) the CA is another embedded controller somewhere so probably no better than the target device and (b) there's no easy way to get the key securely from the CA to the device. However, there's also an awful lot of IoS out there that uses shared private keys (thus the term "the lesser-known public key" that was used at one software house some years ago). OTOH those devices are also going to be running decade-old unpatched kernels with every service turned on (also years- old binaries), XSS, hardcoded admin passwords, and all the other stuff that makes the IoS such a joy for attackers. So in that case I think a less-then- good private key would be the least of your worries. So the bits we need to worry about are what falls between "full of security holes anyway" and "things done right". What is that, and does it matter if the private keys aren't perfect? Peter. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
