Welome to the Internet, here's your private key

[Peter Gutmann]

Jaap-Henk Hoepman <hoepman at cs.utwente.nl> writes:

>It's worse: it's even accepted practice among certain security specialists.
>One of them involved in the development of a CA service once told me that they
>intended the CA to generate the key pair. After regaining consciousness I
>asked him why he thought violating one of the main principles of public key
>cryptography was a good idea. His answer basically ran as follows: if the CA
>is going to be liable, they want to be sure the key is strong and not
>compromised. He said that the PC platform of an ordinary user simply wasn't
>secure/trusted enough to generate keys on. The system might not generate `good
>enough' randomness, or might have been compromised by a trojan.

I've seen similar things.  The CAs are so worried about key security that they
insist on generating the things themselves, but then hand them over in PKCS #12
format from which they're shared by, and easily accessible to, every single app
running on the machine, are copied across other machines (because it's valuable
enough that you don't want to have to get a new one for each machine), etc etc
(again, I go into this in some detail in my paper in the section titled
"Private keys aren't").

Some of the, uh, logic applied by CAs for cert management can lead to really
bizarre situations.  For example there's a public CA which password-protects
access to its CRLs, using the reasoning that anyone who can get access to a CRL
can determine which keys have been compromised, and that's a bad thing (isn't
that what a CRL is for?).  As a result, anyone can get access to the certs the
CA issues, but only a tiny, select few can check whether they've been revoked
or not (given that most apps just ignore revocation checking, this probably
isn't as serious as it sounds).  There's a list of silliness as long as a very
long thing when it comes to working with certs...

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com