Re: Non-Mathmatical Forging of PKI Digital Certificates / Throwing Rocks at the PKI

["Timothy J. Miller" <cerebus () SACKHEADS ORG>]

Pluto <pluto () DEFCOM-SEC COM> writes:

>   Page 2, 4 paragraph: An CA can authenticate an user. Why do you think
> this should not be possible? Checking valid, gov. guaranteed credentials
> for example. If the user want's a sig under his X.509, he has to give some
> information, I'd think. I havn't found advice on how to social engeneer a
> CA into believing you are someone else.

So I steal your state-issued driver's license and mail a photocopy to the
CA manager, and he issues me a cert that is, as legislation begins to
get passed, non-repudiable by you.  Hope you don't mind paying for my
new Mercedes...

>   Page 4: Not more than a privacy problem, if you don't want to be called,
> don't list in the yellow pages. A directory service or searchable list of
> customers is not necessary for operations, to check if a cert is revoced
> you submit the ID to the CA and wait for an answer.

This gets me thinking.

I don't know if any of y'all remember the little black books the store
clerk used to use to look up your credit card number, but I do.  CC
companies used to publish paper listings of all invalid CC#s.  If you
were in the book, you lost your card.  If you weren't, you got the
sale.

This is the same function as a CRL.  Note that this is not a positive
statement of validity, but a negative statement of validity-- which is
weaker.

However, most of this is moot.  There are several popular PKI enabled
producted that *don't bother to check the CRL even if it's present on
the local system*.

So in actual practice, you need to go further than just offering
validity checking.  There needs to be some mechanism whereby the
source of authority can guarantee that for some arbitrary PKI
transaction, the parties engaged actually performed a validity check.

To return to the credit card analogy, you cannot complete a CC
transaction without receiving an approval code from the issuer.  Even
if I manually frank your card and send you on your merry way, the CC
issuer won't honor the receipt if I don't have an authorization code
on it.  The issuer (the SOA) has mandated that I have to perform a
validity check (swipe it / call it in) and issues me a token (the
authorization code) that they can use to make sure I do what I'm
supposed to do.  I can't forge the token since it won't exist in their
system when they receive the paper receipt.

We don't have this for PKI transactions.  Now I know a little about
OCSP (Online Certificate Status Protocol), but does OCSP provide a
mechanism to force a participant to validate the certificate, and
invalidates the transaction if not completed?

>   Page 5, 2 para.: Same as above, when a key is lost, it get's revoced and
> has to be applied for again. Again using some means to authenticate the
> applyee before signing the stuff. The example from verisign is not best
> practice, you're right.

Not always.  Many PKI sites, particulary private CAs internal to
corporations, will escrow your private key at issuance.  For instance,
if you're fired the private key needs to be recovered so they can
decrypt company data on your system.  Or again if you're working in a
smartcard-enabled company, when the CEO forgets his smartcard at home
are *you* going to tell him that he *must* drive home and get it, or
are you simply going to snatch his private key from escrow and issue
him a temporary card?

Food for more thought.