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

[Pluto <pluto () DEFCOM-SEC COM>]

On Tue, 15 Aug 2000, Eric Knight wrote:

> people think of the attack methodology, or any other comments about the
> article that they feel is important toward making a better paper.

  Salve,

  a few items seemed odd to me:

  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.

  A little further down You go about exploiting sendmail, if the signed
cert and the transport protection is delivered by the same means, it's bad
practice and this can get you a 1 M EUR fine in europe.

  Why do you use the DNS term SOA, where most ppl talk about Root-CA?

  Page 3, second last paragraph: An interessted party doesn't have to have
a signature by the CA to check the signature of the dubious party, but it
has to have the public key, and be sure it's the right one. Tricky one
here, had a look at the lifetimes of the browser default Root-CAs?

  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.

  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.

  Page 6, Intercepting mail: Are you sure the user get's the complete
certificate from this link? Most user certificates are generated by a
special tag, so the browser generates the keypair and only the public is
submitted to the CA for signing. (Remember Netscapes failure to generate
good entropy, in '98?) Therefore the interloper can only intercept the
signed public key, not a big gain. DoS maybe. If the CA does generate both
parts of the pair, you're right of course. Would be _very_ bad practice,
didn't tried it on the examples you give.

 Page 7, last para.: Everybody hast to be able to check for the existence
and validity of certs anytime. But not by cleartext search, thats a
phone-book feature, but by Key-ID.

 Page 9, 5 para.: A credit card purchase is _not_ a valid mean of
authentication, IMHO not even on a porn site. In the last 12 months the
reported cases of stolen credit cards was much over 400.000. If this
credit cards could be used to impersonate the unfortunate e-commerce
users, they'd have much greater problems than the 50 $ maximum risk a few
credt-card companies offer.

 To be true, I havn't found a real attack on PKI in you PDF. One example
that is most missing is client security, having a Root-CA-Cert in a safe
with armed guards and double blinded sysadmins is one thing, but the users
keypair is in most cases on a box with no protection at all. If I would
like to impersonate someone, I'd trojan the person and have it send me the
stuff. Weakest point in chain, as you said.

  Cheers

  Christoph Puppe
--
  /* Defcom Security GmbH     ||  Net:    www.defcom-sec.de      */
  /* Arndtstr. 34             ||  Tel:    +49-30-61650-0         */
  /* D-10965 Berlin           ||  Fax:    +49-30-61650-555       */