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

[Eric Knight <deceased1 () HOME COM>]

Mr Puppe:

Thank you for your well thought out reply.  Let me address these issues and
make certain I'm on the right track.  If I've got something wrong, don't
hesistate to correct 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.

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.

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.

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

Sendmail is only used as verification of the identity of the user.  A key is
registered to an e-mail address for "uniqueness" reasons, not to a person in
particular.  By intercepting the e-mail, and guessing the password of the
original certificate holder, they can revoke and replace without any
additional verification, proof of credential, or otherwise.

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

Just a term I'm more familiar with.  The documentation I had to become
familiar with used the term "Source of Authority" often.  I'll use Root-CA
if it is the accepted term.

>   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
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".  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.

>   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.)  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.

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

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

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.

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

I agree, searches by Key-ID are valid and need to be done.  I needed to
clarify that people shouldn't have been able to look up certificates by
email address...  And I should also state (and this is frustrating to me)
that at least one person has pointed out that not being able to look up
certificates by email address prevents people from getting public keys to
send them e-mail, for example.  Looks like this part isn't going away -- but
doesn't disprove my contention it makes things easier.

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

Credit card authentication is merely an additional authentication, not a
solid means of authentication.  If payment were required for each
revokation, it would certainly complicate the matter considerably but
wouldn't prevent it.  I listed it as what the companies being inspected were
offering, not because I endorse it.  I agree with you wholeheartedly.

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

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)
pubic/private key pair, and any server I connect to will immediately
recognize the key as valid and identity verified by the Root-CA.  What makes
this different than a trojan attack is that its done in liu of direct
interaction with the victim, and can be prevented by the Root-CAs.  The
burdon of prevention is not on the end user (although the trojan horse
works, its a different attack with a different person who has the burdon of
prevention.)

However, I'll also concede that PKI (as implemented in other conditions) is
immune to this attack entirely, but I never stated that this applied to
anything but commercial PKI (and should have stated United States
commerical).  I probably should just say its a flaw inherant with the
services I've examined, maybe thats a better choice of words.

Thank you for your feedback,

Eric Knight
knight () securityparadigm com