[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

global names are a security flaw


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 

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

Version: PGP for Personal Privacy 5.5.3


|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: