[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Private keys and the emperor's clothes
Bob:
thank you for this wonderful message! This was a major contribution
to my thinking and valuable to the i-d I'm drafting at the moment.
At 11:19 AM 6/21/96 -0600, Bob Jueneman wrote:
>But let me poke gently at another of your assumptions, that it would be
"clearly undesirable" to have the CA generate
>the private key. This may be a sacred cow, but why is this necessarily so?
>
>Let's consider the threat. Presumably you are concerned about the
possibility that if the CA were involved in generating
>your key they might keep an unauthorized copy, and thus might be able to
decrypt messages intended only
>for your eyes, or alternately, be able to forge your name to a document.
>
>Although most of the legal analysis in the area of public key cryptography
has focussed on the use of digital signatures,
>as opposed to encryption, the draft ABA Digital signature Guidelines make
it clear that the CA has a fiduciary relationship
>with respect to its subscribers. Disclosing or misappropriating a
subscriber's private key would leave them wide
>open for huge civil damages in the case of an encryption key, and for both
civil and criminal (fraud and forgery)
>charges in the case of a signature key.
This is an excellent point.
For digital signature keys on a financial document, there is a clear harm
and the law is available for redress of that injury. Misuse of that key is
bound to get noticed, eventually, and the law can be called in to find the
perpetrator.
However, for confidentiality keys, spy agencies (like the NSA) have a long
tradition of keeping their successes secret so that the party whose privacy
has been invaded doesn't ever learn that. That lesson has been spread
widely among the general public, so I would expect criminals to have learned
it. One can not call in the law to prosecute someone who has swiped a copy
of a private confidentiality key if he or she never learns that the key was
compromised. This is the major flaw with Clipper (I, II or III) or any
other GAK [Government Access to Keys] proposal.
Meanwhile, back to signature keys and financial transactions... This,
according to Ross Anderson, is probably the most important crypto function
in the world today and likely to remain so. However, the *possibility* of a
copy of the private key having gotten out is enough to weaken the case of a
bank trying to prove in a court of law that a given customer actually made a
contested purchase. Therefore, I believe it is in the bank's interest to
make very sure that it is provably impossible for the customer's private key
to have been copied.
Let me propose a far out way, inspired by your suggestion:
A secure central facility generates long random blocks (2048 bits, at least)
and writes one per floppy. These floppies are shipped to CompUSA and other
stores. Each contains not only the unique, random string but also some
software for generating primes, putting two primes together and storing a
private key securely. Each is a boot floppy -- so there is no OS or virus
involved. The result ends up on the boot floppy, encrypted under the user's
passphrase.
The user buys a disk -- from a store or from mail/phone order -- and boots
it, generating a private key. The resulting key has good randomness thanks
to the central facility, good security because no OS is involved -- and, if
the user wants protection *from the facility itself*, he or she adds entropy
at key creation time, ala PGP's methods.
Of course, the bank still can't prove that the user's PC was protected at
all times so that the private key was not subsequently stolen along with the
passphrase. For that, we'd have to replace the floppy with a PCMCIA card --
and give it a H/W ranno generator -- and have it generate both primes
locally, while performing good tests of the quality of the output of the
ranno generator and shutting down in case of failure.
>But suppose you are so careless, naive, or stupid as to select a CA that is
totally ignorant of such issues, and/or one that
>that is deliberately bent on mischief. Such a CA, and in fact any CA,
could impersonate you any time it wished to, just by
>issuing a certificate containing your name and/or other significant
attributes, without your consent or even knowledge! It isn't
>necessary to know your private key, or to attempt to find or create a
duplicate -- since it is the CA that is binding your public key
>to your name, e-mail address, etc., they could issue a false certificate
containing their own public key and bind it to your
>name, any day of the week.
I've been saying for a long time that a globally unique DN is unnecessary
because you already have a unique name in the form of a public key -- and
given the way stuff is added to my common name to make it a DN, I might as
well add a base64 hash of my public key.
However, the key has a strong advantage over a DN, as you point out in the
paragraph above. No one can spoof my key without breaking it.
Of course, the key has a disadvantage compared to a DN in that it carries no
shock of recognition to a human user who encounters it for the first time.
However, I've argued elsewhere (at too great length, according to some
people :) that the DN's recognition value (by containing the user's common
name, at least in PEM days) can be misleading and certainly isn't a
guarantee that the recipient of such a certificate knows who is meant by the
DN. In fact, it carries the danger that the recipient might *believe* he or
she knows who is meant by the DN, but be wrong.
>This is why, back in the PEM days, we wrestled with the need for name
subordination. Although the scheme
>eventually unraveled somewhat, especially in the case of the unaffiliated
residential person, in the case of the
>organizational user it was a darned good way of ensuring that a rogue CA
would only be able to compromise the
>security of those individuals whose certificates were beneath it in the
certificate hierarchy.
This is a valuable historical note.
>I realize that the concept of a global directory is often deprecated on
this list, but without such a directory, it becomes very
>difficult for a subscriber to search all possible certificate repositories
for a certificate containing his name or other attributes.
>And since this group also tends to deprecate the notion of a globally
unambiguous name (smacks too much of X.500), even
>if you found a certificate which contained your name, the CA could say,
"Oh, well, that's not you, that's the other David P. Kemp."
Exactly. Excellent point!
>The X.509/X.500 paradigm provided certain mechanisms that tended to
reinforce the basic trust model. If we are going to
>depart from those paradigms, we have to rethink the entire trust model, and
how to achieve/enforce it.
That is true.
-------------
Thanks again for forwarding this message.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+--------------------------------------------------------------------------+