The (I believe) meritorious point that Mr. Hollebeek raises mainly pertains to embedded devices.
As the IoT craze heats up, I keep seeing platforms ship with unfinished OS stacks, missing drivers, etc. A lot of hardware in the field is shipping with decent dedicated entropy sources on board coupled with OS stacks that don't bother to make use of said entropy. Some of this stuff doesn't even have an RTC or high precision timers. Some of these things try to helpfully generate to-be-used keys and CSRs upon first boot. Unfortunately, they do so in a consistent first boot configuration that creates a ridiculously low amount of true entropy and yields the use of a PRNG over and over by like model devices under like circumstances, significantly increasing the likelihood of "independent" generation of the same small set of key pairs. In a race to ship, quality gets overlooked. The people shipping this stuff respond to issues that cause high return rates. Today, people aren't returning retail product for bad number generation. I don't really think CA generated keys is the right answer in the general case. However, recent events and market trends suggest that more continuous, ongoing key quality analysis needs to become part of the ecosystem. On Mon, Dec 11, 2017 at 9:55 AM, Nick Lamb via dev-security-policy < [email protected]> wrote: > On Sat, 9 Dec 2017 18:20:56 +0000 > Tim Hollebeek via dev-security-policy > <[email protected]> wrote: > > > First, third parties who are *not* CAs can run key generation and > > escrow services, and then the third party service can apply for a > > certificate for the key, and deliver the certificate and the key to a > > customer. I'm not sure how this could be prevented. So if this > > actually did end up being a Mozilla policy, the practical effect > > would be that SSL keys can be generated by third parties and > > escrowed, *UNLESS* that party is trusted by Mozilla. This seems . > > backwards, at best. > > I'm actually astonished that CAs would _want_ to be doing this. > > A CA like Let's Encrypt can confidently say that it didn't lose the > subscriber's private keys, because it never had them, doesn't want them. > If there's an incident where the Let's Encrypt subscriber's keys go > "walk about" we can start by looking at the subscriber - because that's > where the key started. > > In contrast a CA which says "Oh, for convenience and security we've > generated the private keys you should use" can't start from there. We > have to start examining their generation and custody of the keys. Was > generation predictable? Were the keys lost between generation and > sending? Were they mistakenly kept (even though the CA can't possibly > have any use for them) after sending? Were they properly secured during > sending? > > So many questions, all trivially eliminated by just not having "Hold > onto valuable keys that belong to somebody else" as part of your > business model. > > > Second, although I strongly believe that in general, as a best > > practice, keys should be generated by the device/entity it belongs to > > whenever possible, we've seen increasing evidence that key generation > > is difficult and many devices cannot do it securely. > > I do not have any confidence that a CA will do a comprehensively better > job. I don't doubt they'd _try_ but the problem is Debian were trying, > we have every reason to assume Infineon were trying. Trying wasn't > enough. > > If subscribers take responsibility for generating keys we benefit from > heterogeneity, and the subscriber gets to decide directly to choose > better quality implementations versus lower costs. Infineon's "Fast > Prime" was optional, if you were happy with a device using a proven > method that took a few seconds longer to generate a key, they'd sell > you that. Most customers, it seems, wanted faster but more dangerous. > > Aside from the Debian weak keys (which were so few you could usefully > enumerate all the private keys for yourself) these incidents tend to > just make the keys easier to guess. This is bad, and we aim to avoid > it, but it's not instantly fatal. But losing a customer keys to a bug > in your generation, dispatch or archive handling probably _is_ > instantly fatal, and it's unnecessary when you need never have those > keys at all. > > > Nick. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
