[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
From ???@??? Sat Jun 22 14:40:14 1996
Return-Path: <owner-spki@c2.org>
Received: from callandor.cybercash.com (callandor1.cybercash.com) by cybercash.com (4.1/SMI-4.1)
id AA04730; Sat, 22 Jun 96 14:36:29 EDT
Received: by callandor.cybercash.com; id OAA05952; Sat, 22 Jun 1996 14:33:00 -0400
Received: from infinity.c2.org(140.174.185.11) by callandor.cybercash.com via smap (V3.1)
id xma005950; Sat, 22 Jun 96 14:32:54 -0400
Received: (from daemon@localhost) by infinity.c2.org (8.7.4/8.6.9)
id LAA18282 for spki-outgoing; Sat, 22 Jun 1996 11:33:30 -0700 (PDT)
Community ConneXion: Privacy & Community: <URL:http://www.c2.net>
Message-Id: <2.2.32.19960622183440.00851718@cybercash.com>
X-Sender: cme@cybercash.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 22 Jun 1996 14:34:40 -0400
To: Bob Jueneman <bjueneman@novell.com>
From: Carl Ellison <cme@cybercash.com>
Subject: Re: Private keys and the emperor's clothes -Reply
Cc: spki@c2.org
Sender: owner-spki@c2.org
Precedence: bulk
At 03:05 PM 6/21/96 -0700, Bob Jueneman wrote:
>>>> "Brian M. Thomas" <bt0008@entropy.sbc.com> 06/21/96 03:01pm >>>
>Well, now, let's think about that. Out of the blue I get sued by someone
who claims to have my
>digital signature on a document, with a certificate signed by a CA I never
heard of. [...]
> "Unfortunately, we had a fire [...]
>Now, how much did you say you were willing to
>spend in legal fees trying to prove that we are wrong?
Yup -- another good scenario arguing against the whole idea of CAs. Thanks.
>(Maybe there is a moral here for e-mail protocol designers. Perhaps both
the name and address of the recipient,
>together with the certificate information (issuer and serial number),
should be included in the signed portion of the
>message, so that this kind of man in the middle attack could be detected.)
Good, if you're relying on a CA's certificate -- or people could use
key-centered certification and not have this problem.
>Best of all in hardware controlled by the user. I'm reasonably security
conscious, but "pond scum"
>would probably be a reasonable representation of my own home computer
security environment,
>and would almost surely be applicable to the vast majority of unsuspecting
users of this brave
>new world of technology.
I agree. My home computers are probably also pond scum, for security.
However, look at it from a hacker's point of view. A potentially insecure
system isn't available unless it's been infiltrated. The percentage of
infiltrated systems is very small. So -- a potentially insecure system
could be secure for the moment.
- 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 |
+--------------------------------------------------------------------------+