Evil certificate authority in public-key-infrastructure

Question

Alice goes to the certificate authority (CA) and registers her public key for signature verification. She gets a certificate for this from the CA. Bob requests Alice' public signature verification key from CA. CA returns Alice' key, certified by CA's signature.

Now imagine CA sends a fake public key to Bob which not belongs to Alice (instead of sending Alice' real public key). CA also sends a message to Bob, signed with the corresponding fake private key, claiming this message comes from Alice. At a later time Bob will probably notice that the message is weird and ask Alice if the public key he got from CA really belongs to her. Then both can go to a judge, show the two different certified public keys and the CA can be convicted.

Is my understand correct so far?

My question: What if Alice never registered a public key at CA but the CA claims so (probably fakes the registration procedure and fakes Alice' handwritten signature)? Since then there are no two contradictory certificates from CA, how can the CA be convicted? Am I missing something, or does than an (probably effortful) analysis of Alice original handwritten signature and the faked one has to take place?

Answer 1

As Rook said, the statement "Bob requests Alice' public signature verification key from CA. CA returns Alice' key..." is incorrect.

Public Key Infrastructure does not require a CA to serve as a public key server.

What would actually happen is that Bob would ask Alice for her public key. Alice would send her public key directly to Bob, signed by the CA. Bob would use the CA's public key to verify the CA's signature and Alice's public key.

Yes, it is possible for a CA to issue a certificate in error. This could be deliberate or accidental. A government agency could compel such an action (or in some places, CAs are run by the government), or an identity thief could perhaps achieve that outcome.

This is a design "function" of PKI (I'm avoiding the use of the terms "flaw" or "feature"!) - it allows a third party to confirm identity for people who haven't previously met, at the cost of having to trust a third party.

Carl Ellison and Bruce Schneier identify this as the #1 problem in their article from 2000 - "Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure"

Risk #1: "Who do we trust, and for what?" There's a risk from an imprecise use of the word "trust." A CA is often defined as "trusted."

In the cryptographic literature, this only means that it handles its own private keys well. This doesn't mean you can necessarily trust a certificate from that CA for a particular purpose: making a micropayment or signing a million-dollar purchase order.

Who gave the CA the authority to grant such authorizations? Who made it trusted?

A CA can do a superb job of writing a detailed Certificate Practice Statement, or CPS -- all the ones we've read disclaim all liability and any meaning to the certificate -- and then do a great job following that CPS, but that doesn't mean you can trust a certificate for your application. Many CAs sidestep the question of having no authority to delegate authorizations by issuing ID certificates. Anyone can assign names. We each do that all the time. This leaves the risk in the hands of the verifier of the certificate, if he uses an ID certificate as if it implied some kind of authorization.

There are those who even try to induce a PKI customer to do just that. Their logic goes: (1) you have an ID certificate, (2) that gives you the keyholder's name, (3) that means you know who the keyholder is, (4) that's what you needed to know. Of course, that's not what you needed to know. In addition, the logical links from 1 to 2, 2 to 3 and 3 to 4 are individually flawed. [We leave finding those as an exercise for the reader.]

Answer 2

In your scenario, the CA is granting a certificate to Bad Guy who is impersonating Alice. The certificate says Alice on it. You asked several questions which I cover below.

A different issue is how can a CA give a certificate for Alice to someone other than Alice. There are multiple possibilities:

1. The CA could make a mistake when they should have checked the credentials of Bad Guy.
2. The CA could have been compelled by the government to issue the certificate.
3. The CA's private key could have been stolen, allowing the thief to impersonate the CA.
4. Someday it may be possible for governments or other large rich organizations to reverse-engineer the CA's private key. Guarding against this are the standards groups who periodically decide that keys should be lengthened.

Convincing a judge that the certificate was not Alice's IANAL, but from my experience, there are two different reasons why a judge would care: Civil suits and criminal cases.

Possible criminal charges: Larceny (Bad guy stealing from Bob by pretending to be Alice), and Forgery (Bad guy submitting forged paperwork to the CA that "proves" to the CA that Bad guy was Alice.) In a criminal case, the government has many tools for exposing the truth and convicting the bad guy. Handwritten signature analysis is just one small example a tool that the prosecutor can use.

A civil suit would be against Bad Guy to recover losses suffered by Alice or Bob. But thieves usually don't have many assets, so they are poor targets (heh) for suits.

Presumably, as soon as Alice presents creditable evidence to Bob that Bob should not be relying on the forged certificate from Bad Guy, Bob will put everything on hold until the situation is clarified.

How can the CA be convinced they issued the certificate incorrectly Alice would present her credentials (proving that she is Alice) to the CA and tell them that they made a mistake. The CA would open an investigation. If Alice makes her case creditably, then the CA would revoke the certificate granted to Bad Guy. From that point forward, anyone who checks the CA's CRL would be able to automatically reject Bad Guy's further attempts to use the cert to impersonate Alice.

Unknown thefts You raise the idea that Alice may not even know that Bad guy is impersonating her to Bob (and to others). This is a very real issue, it's Identity Theft.

It's the reason why you should check your credit record periodically.

Answer 3

A few new thoughts:

1 - Certificates are typically delivered with the message that they protect.

The other answers covered this. There is typically no case of Bob getting Alice's certificate ahead of time. Alice (or fake Alice) will send her message, her signature and her certificate.

In a low-risk transaction, Bob will accept that the signature is properly verifiable with the public key of the certificate, that the certificate was signed by a trusted CA, and that the certificate is currently valid.

In a higher-risk transaction, Bob will also ask the CA whether or not there has been any change to Alice's status since Alice's certificate was issued. If Alice lost her key or became untrustworthy, her certificate would be revoked, and this can be verified several different ways.

Yes, it's technically possible that a malicious CA (or a malicious human with the right privileges within the entity providing the CA service) could: - create a fake-Alice public key and certificate - mail Bob a misleading mail that was properly signed with the fake-Alice credential, along with the fake-Alice credentials - verify with Bob that the fake Alice credentials are trustworthy.

In fact, it would even be possible to revoke real-Alice's credentials in case Bob was wondering why Alice seemed to have 2 certificates.

2 - Why this is unlikely

As other folks said - PKI is built upon the idea that you defer your trust to the CA, and allow it to guide you trust in the credentials of the individual end entities. Alice is Alice because the CA says she is.

A CA builds it's customer base by building a solid reputation. For various capabilities of higher risk (and greater income!) a CA must pass a series of checks and verifications of both it's technical capabilities and also its internal infrastructure. Various types of 3rd parties will make sure that the protection mechanisms of the CA system and software are up to a certain standard, and that the processes of how certificates are made, how end user identities are verified and how revocation actions are performed are safe from tampering by even a malicious insider. There are audit controls and other subpoena-worthy artifacts inside the CA provider that are not able to be modified by a single rogue employee.

Such qualities are table stakes for high end certificate provisioning purposes.

So... it's possible for Crazy Eve's House of Signature Certificates to go into business with a CA infrastructure that provides NONE of these guarantees. And Crazy Eve could certainly mess with Alice's credentials as described. But the major browsers aren't going to provide Crazy Eve's Root CA as a trusted CA certificate. Major transaction systems are not going to qualify Crazy Eve's CA for issuing certs for any high end business communication... Crazy Eve will be providing certs for a cheap or free certificate offering and Bob and Alice got what they paid for.

The real tradeoff is that once Crazy Eve's CA gets a reputation for underhanded business dealings, any one who used this CA as a trusted issuer SHOULD remove them from the trusted CAs list. This will cause what little credibility the CA had to tank. If Certificate Provisioning wasn't a big part of the business, then it's not a major loss.

But any CA provider that went through the considerable time and money to be recognized and certified may find that it's not worth the risk to mess with a single communication between Bob and Alice.

3 - Any certificate is only as good as the means of verification

Getting a certificate issued by a CA can be as easy as clicking through a form and using PayPal or as hard as a serious background check, a mountain of paperwork, and signoff from legal witnesses. It all has to do with the risks of the transaction that the given entity will be performing with this credential.

Hopefully Bob mandated that if he was giving Alice $1 Million Dollars - that she didn't use a free cert from a cheap place. The money would justify the couple of hundred dollars that a high end certificate would cost.

4 - Legal stuff

If it comes to a court case, all evidence of identity provided by Alice and fake Alice will be called into question. I'd also expect that Alice's lawyers will request insight into the CA's transaction histories and audit records - in this day and age, failure to keep tamperproof audit records would be a serious lack of due diligence in an entity this important.

One might also start asking questions of any systems that certified the CA - did they know that such a breach of trust was possible? What controls do they require to prevent this sort of issue?

From there we get into the details specific to the area of jurisdiction - there's usually some relationship to the harm done and the degree of negligence or willful malice involved, but this is getting into legal territory.

If we're talking about the case where Alice has never had a transaction with the CA, the CA would be asked to provide proof of Alice's enrollment and it would come down to proving that the credentials were faked. But I'd think there would be more evidence than just Alice's signature. Did she buy this certificate? What was the method of payment? When did she procure it? How did she provide the public key, and what transactions has it performed since? From what location?

This gets into law, but there are more potential points of evidence that there may initially seem. From there we get into what's admissible in court and how must evidence be collected? But when a corporation's integrity is in question, a lot of things can be fair game - email records, log files, etc.

Answer 4

Is my understand correct so far?

The CA doesn't "provide the key", it issues a certificate for the key. However, the general understanding is correct and the security semantics of "providing the key" vs. issuing the cert is the same.

You are pointing out a valid problem.

What will happen is:

• There is a fake cert issued by CA saying "evilkey belongs to Alice"
• Alice says "evilkey is not mine, and the CA issued a fake cert"
• The CA says "Alice sent me evilkey and it was really her who asked for it to be certified"

Now it turns into a game of "he said, she said". Luckily, usually Alice is called Google or PayPal, and the CA usually reacts by saying "oh, sorry, we made a mistake", not "it was really PayPal who asked for the key".

If the CA claimed that verification was performed correctly, and the subscriber claimed that the certificate was fake, the CA would have to revoke the certificate, but whatever would happen afterwards would depend on who can prove what (most importantly on who the browser vendors believe). If the CA can convince Mozilla, Google, Microsoft and Apple that Alice is lying (or doesn't have any proof), nothing will happen. If Alice can convince Mozilla, Google, Microsoft and Apple that the CA is lying and knows it, the vendors will likely remove the CA from the trust list (this kills the CA).

If Alice can prove the CA misissued the certificate, and the CA manages to provide reasonable evidence that they did verify the identity (e.g. because they have a piece of paper with a reasonably convincing fake signature), nothing besides revocation of the cert will happen since the CA did not violate its duties.

The CA also has to have an independent third party, an auditor, verify and confirm every one or two years that they work proplerly. I think a determined CA would easily manage to cheat such an audit, but in theory, the audit is supposed to stop the CA from misbehaving.

In practice, CAs misissuing get often caught by Google, because Google Chrome detects and reports misissued Google certificates. As soon as Google has the fake certificate, the CA cannot really deny it - if they walked up to Google telling them "you asked us for it", and Google said "no", then Google is most likely going to trust itself and remove the CA.