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

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

On Thu, 17 Aug 2000, Eric Knight wrote:

> This is depending on the requirements by the issuer, and I hadn't even
> considered the legal progress made by countries other than the United
> States.  "Governement Guaranteed", for example, might be easier in some
> countries than others.  Because of the Privacy Act, the United States is
> even more pressued to use substitutes than other countries.

  I have to admit I don't know the full extend of this act. Does it state
that the user is not permited to give out his full credentials when he
wants to conduct business?

> These particular Root-CAs only want an e-mail address, a credit card, and a
> password for future authentication.  Everything else -- name, address,
> phone, etc. will go unverified when the certificate is issued.  Some places
> will do additional checks (as shown by the GlobalSign example) but are
> somewhat inconsequential to the forgery process I've described.  I'll dig a
> bit more into authentication techniques as we address your other issues.

  Then I have to apologize to you, I've only been getting server serts
from them and we had to send in a few letter of authorisation. In paper
not fax.

> >   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?
>
> Please clarify a bit more on this point.  I'll give it a crack though.  A
> server and a client can verify that they both have keys generated by a

  They don't need to have keys signed by the same CA. Only the party with
the signed cert is able to "proof" h** identity, o'course.

> Root-CA through the signature process, this creates the condition of
> "implied trust" betwen the Server and the Client.  You are saying that a
> Server with the public key of the Client doesn't need the Root-CA to verify
> the identity as long as the Server accepts the public key of Client, which
> is "absolute trust".

  He needs only the public key of the CA that has signed the cert of the
other party.

> True, the attack I outlined cannot bypass this, its an
> attack based on the implied trust levels only.  I hope I'm following what
> you were saying, however.  Even a revoked/replaced certificate cannot
> automatically reestablish an absolute trust situation.

  What is you understanding of "absolute trust" here?

> >   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.
>
> When I signed up to most of those services, I didn't have a choice.  The
> certificate ID does not establish a relationship between an e-mail address
> and a certificate that is available to the public (as stated earlier,
> certificates are issued to e-mail in my example by the firms that I gave
> examples for, not to people.)

  So the service states there is only one cert for one email-adress and
trust can be build up. Like you have conducted business with this guuy who
used this cert, the thing went OK for you. Next time the anonym entity
that is in the possesion of this cert will get a little more trusted until
you know h** for so long you trust him to lend you car.
  Sounds like rebuilding a second identy based on email-adresses. Hmm,
what if the same email-adress get's another cert from another signer
(CA) and you also trust this signer, then the one who trusted is in
trouble. Here your sendmail thingy applies quite well.

> If I wanted to revoke/replace a key for anyone at a site, first I
> would have to know who at the site already has one.  Just picking
> random certificate IDs doesn't allow me to discover who at a specific
> site has a certificate.  However, query by email address at the
> Root-CA does -- and allows the attacker to gain a list of potential
> victims quickly.  At this point, all that needs to be done is guess
> the passwords of the victims -- which I've shown has no restrictions
> on how easy the password is to guess.

  This is a true weaknes, the passwords should be assigned by the CA. BTW,
this certs are something that would pass as a signature after clinton has
signed this funny act?

> >   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.
>
> Verisign's example was the same for all the companies I've listed, they all
> have the same weak re-authentication requirements.

  So we were both bashing at the same thing, weak authentication.

> Let me see if I can explain it the way I understood it -- the
> revokation/reissue is most common for people who have had laptops wiped and
> their certificates completely lost and so forth.  The private key is lost
> forever in this case, but the person wants their key back because they paid
> for it (treat the Root-CA as a one-year service agreement.)  So they connect
> to the Root-CA's web site, enter their password, and request a replacement
> because a copy won't work (because they lost the private key.)  The reissued
> certificate is completely based on a new key pair generated by whatever
> browser is talking with the site at the time (which is the forger's
> browser.)  The link is required to complete the generation of the new
> certificate -- forcing authentication through e-mail to verify the identity
> of the owner.  If the email can be intercepted and the link sent is
> followed, it will complete the revokation process and create the new
> certificate with the new keys on the forger's browser.  This key isn't an
> exact copy -- as stated earlier it matches "implied trust" that the key was
> authenticated by the Root-CA but doesn't match "absolute trust" in that it
> was authenticated to be specifically valid by a particular server.

  OK, if the attacker gets to know the password of the old cert and
breaks the MTU of either the CA or the recipient.

  But there is one thing more, if I get a signed thing from the
impersonator, and I send my reply to the email-adress in the cert, the
impersonator has to be able to answer this too. Maybe only marginaly
interessting, as the wrong news item yesterday has shown.

  BTW, I havn't seen an artikel where they asked for important stuff to be
signed ...

> What I've done is bypassed PKI's (at least, these companys' versions of PKI)
> ability to accurately grant implied trust, and then can use that for other
> causes.  If "implied trust" is violated, I'd say thats a significant breach
> of PKI.  Once again, I've created a forged certificate, bearing someone
> else's identity, with a valid (but not identical to the original)

  You did it, or is this hypothetical? Anyhow, I'll apologize. You have
show serious weaknesses in their setup, especialy the password thing. But
still I don't find a real live exploit in you statements.

  Gruss

  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       */