[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
global names are a security flaw
-----BEGIN PGP SIGNED MESSAGE-----
In Subj: Re: I-D ACTION:draft-ietf-spki-cert-theory-00.txt
At 09:38 AM 12/3/97 -0200, Ed Gerck wrote:
>The SPKI document stresses that global names would mean a "security flaw"
>and I understand you agree that this is incorrect because it is not a
>"security flaw".
I am pressed for time right now, but let me address this one point since it
is central to your messages.
Yes, I wrote that global names of the Distinguished Name form constitute a
security flaw. Those are strong words and I meant them precisely.
Perhaps I should add a section to the theory draft explaining this
carefully, although I thought I had. I'll check back into it and see.
The security flaw shows up if the name is ever used as an identifier of a
flesh and blood person. For example,
imagine that I show up at my bank and want a certificate giving me access to
my checking account and that the bank follows X9.57: demanding an ID cert
and an attribute cert, carrying <name,key> and <name,auth> respectively.
Imagine also that I have my ID cert from some commercial CA. It's on file
in that CA's directory of certificates.
I walk into my bank. I say hi to the bank teller. I prove to her who I am,
by my driver's license and maybe my ATM card. I ask for her to e-mail me an
attribute cert giving me access to my checking account.
She needs to look up my DN. I certainly won't remember it. DNs are too
long and complex for me to bother remembering them, even my own. I'm a
normal computer-phobic customer. So, she looks up my DN in the CA's
database of certificates. I might not even remember which CA I got my cert
from, so she might need to look in several databases. She's a little busy,
so I fill out her request form, say "good day" and leave the bank. My
e-mail address and common name and account number are on that form.
When she gets time, she will scan that DB with her web browser -- searching
for DNs containing my common name. She will get a list of a few hundred of
them. From that list, she needs to find *my* DN. She has to prune the list
down to 1 (assuming she even has pulled her list from the CA I actually
used) and she'll do that by ruling out entries that don't match my personal
information, as far as she knows it. Most of the time, she'll get to my
correct DN. However, the possibility remains for her to get to someone
else's DN. Once she finds the list has one entry, she is likely to assume
success, even when she doesn't have success. She will then issue the
attribute certificate -- binding my bank account to someone else's key.
We as cryptographers talk about key lengths and various obscure attacks on
protocols and take them very seriously, but in the design of attribute
certs, we allowed a human process (such as the one I outlined above) to be
part of the procedure -- and assumed there would be no flaws in it. That's
obvious: we stuck to our own area of expertise. However, the probability of
error in the human link above dwarfs the probability of a cryptanalytic
attack on a 512-bit RSA key.
Therefore, I call this a serious security flaw.
To correct this flaw, one needs to do two things for global names -- both of
which we have done in SPKI by using the hash of the public key as a global
name:
1. make the global name space sparse, so that typos won't get to someone
else's name
2. make sure there is no common name inside such a global name, or anything
else a human clerk might use to guess name ownership.
-------------------
Notice that in this discussion, I am assuming the US with no national ID
card or number. I also assume that the US will never accept the idea of a
national ID number. Therefore, there will be no physical card carried by
the bank customer guaranteed to define him uniquely. OTOH, even in Germany
where there are national ID cards, the person's ID number is not going to be
in a certificate since that ID number is considered private and not to be
released in a public document (like a certificate).
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQCVAwUBNIbK0BN3Wx8QwqUtAQFf9gQAkEL/D31RCEb6COfgLCoIi8Q+j9OTRqBb
X2ccOM72ghTbwvBrM0ItHcDIcwN74a1KbvcZctuD5O2t4Gace4M5DzqNv4jfKbxr
v7caVgZnAOFmByee0m1rI+0vAMX9BkGuTJomJsS+bF1PVlbOe1QptoR3lRdKPUe2
+5BuEH/oT6A=
=d37h
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+------------------------------------------------------------------+
Follow-Ups:
References: