Who is responsible for ensuring the trustworthiness of certificate authorities?

Question

Background

I am a novice in the field of cryptography and cyber-security, and while studying asymmetric-key encryption, I learned about the potential of a man-in-the-middle attack.

To mitigate this threat, people came up with certificate authorities that essentially "vouches" for the trust of 3rd parties by supplying you their respective public keys signed with the CA's own private keys.

Question

Here is where I am getting confused.

Can't we just use the same logic to intercept and compromise the transfer of information between the user and the CA (certificate authority)?

If the Certificate authority vouches for the Generic Website to ensure trust and safety, who vouches for the Certificate authority?

Answer 1

Maarten Bodewes answer is correct but I think the heart of your question is a major hurdle people face in understanding certificates and CAs. I think it's worth elaborating on the part of how this works that I think you are missing.

As stated in Maarten's answer, your computer/browser has been preconfigured with a set of trusted CAs. If you are running Windows you can see what these are by running certmgr.msc (you must type the entire name in search). In that application, you will see a number of folders. One of these is named "Trusted Root Certification Authorities". If you expand "Certificates" under that folder, you will see a long list of certificates for various CAs.

When you go to a website and you get a 'trusted' lock icon, that means that the certificate they are presenting has a parentage that includes a certificate in this store. I'm oversimplifying slightly here but this is the core idea. For example, if I look at the certificates at google.com, the grandparent certificate has the friendly name of "Google Trust Services - GlobalSign Root CA-R2". I look at my store and I see that exact certificate which I can verify by looking at the 'thumbprint'.

So the reason that no one can MiTM the root certificates is that you are not going out to the CA to get your trusted CAs, you already have them on your machine. If you browse a website with a CA cert that don't have in your trusted CA store, your browser should throw a lot of warnings at you that the site is not trusted.

I hope this helps. A side note is that this should also help you to understand how much risk there is in importing a new trusted root certificate. For example, let's say you are doing some experimentation and generate your own 'CA' certificate. You import this as a trusted CA and voilà! You now can sign certificates that your browser trusts. But consider what could then happen if someone else gets access to the private key you generated for that root CA. They now can create a certificate for any website and unless you check the cert chain on each site you go to, you could become subject to a MiTM attack.

Answer 2

There has to be some point where you trust something. Operating system come with 'root' certificate authorities. Those certificates are either installed when you install the operating system, or could be downloaded over a secure connection from at least one certificate installed with the operating system.

You can (and many developers do) add your own root certificate to your computer's trusted roots. In this case, you can use the certificate to sign other certificates for development and your browser and apps on your computer or another computer with your certificate installed as a trusted root certificate will happily show the connection as secure.

So you go to https://www.mybank.com in your browser and your browser receives a certificate. This certificate has a chain of trust. In Chrome you can go to the developer console Security tab and view the certificate and the chain of trust, which will lead up to a trusted root certification authority. On windows 10 you can see your computer's certificates with "Manage Computer Certificates".

Notice what mine says for this site:

HDC-PROXY01-1 is a weird address to issue a certificate to stackexchange.com, eh? Turns out my connection is being attacked with a MITM attack by my employer who snoops on everything I do at work. The computer they provided me with has the company's own certificates installed as 'Trusted Root Certification Authorities' for just this purpose. Their proxies can intercept secure connections and provide their certificates instead of the ones belonging to the site you are going to, proxy the data over a secure connection to the site using the site's actual certificate, and re-encrypt the data with the proxy certificate before sending it back to me. My browser trusts the proxy's certificate because it was signed with the company's certificate in my trusted store.

Answer 3

No because the browser that you use has a build in security store, so it is perfectly possible to create a secure connection to the CA.

Generally you can only request certs for your specific domain, e.g. by using a domain specific mail address. Generally you should also pay for the services which provider a small amount if traceability.

Of course you should do this from a secure address with a trusted network connection, not from a public wifi hotspot.

---

For digital signing certificates usually you require some kind of proof that you are in control of an organization. See for instance a list of documents that you could provide here. Kind of obviously, many CA's don't care all that much and the system could definitely be considered broken in many ways. That same list was linked to when asking for a code signing certificate.

---

More secure certs such as Extended Validation (EV) certificates, such as those for banks require more validation of of the identity of the bank. Those secure certs were not necessarily more secure when it comes to cryptography, but in principle they should have added some level of trust into the issuance of the certificates (see the discussion in the comments below).

I've put it in the past tense because obviously the criteria for EV certificates to make the web a safer place have not really been met.

Answer 4

One idea I find useful in this context is looking at cryptographic systems not as absolute ways of achieving guaranteed security, but rather, as ways of reducing bigger problems to other problems that are hopefully smaller but still potentially substantial. Seen from this angle, you're basically grasping the following points:

• Public key cryptography is a way of reducing the problem of establishing a confidential and authenticated channel with another party to the problem of establishing an authenticated channel with that party.
• Public key infrastructure is a way of reducing the problem of establishing authenticated channels with lots of different parties to the problem of establishing an authenticated channel with fewer, trustworthy certificate authorities.

But the difference is this way of formulating the topic foregrounds that what you're left with after you've implemented a purely cryptographic solution is also a problem in its own right, whose solution will likely need non-cryptographic elements. For example, operating system vendors have root certificate programs (e.g., Microsoft, Apple) that decide what root certificates to bundle with their operating systems. But even if we assume those programs are infallible (they're not), that doesn't stop, say, Lenovo from preinstalling adware on its laptops that bundled an easily hackable root certificate to perform a man-in-the-middle attack on the user's SSL connection in order to show them ads. This is a real-life example of exactly the sort of attack you worry about:

Can't we just use the same logic to intercept and compromise the transfer of information between the user and the CA (certificate authority)? If the Certificate authority vouches for the Generic Website to insure trust and safety, who vouches for the Certificate authority?

So the answer is yes, it's possible to compromise the delivery of a root CA bundle, and there's no purely cryptographic solution to it because the tree of trust must come to a root and there the cryptography ends and you're left with the mundane stuff like whether your computer vendor is trustworthy. What reduces the risk beyond that point is non-cryptographic measures to validate that the computers you buy don't have a maliciously configured trust store (e.g., do a fresh operating system install when you first get them, from a copy you've done your best to validate).

Answer 5

This is a very good question.

Public-key certificates have the purpose to authenticate an assertion, namely that you are communicating with the entity that you intend to communicate with. Specifically, guarding against a Man-in-the-Middle attack (MitM) is done by authenticating the key material that is used.

Your issue is the following. Say A and B want to establish a secure channel using their public keys $K^\mathsf{pub}_A$ and $K^\mathsf{pub}_B$. If they haven't yet established a secure key exchange, a plain exchange is prone to a MitM. So you utilize a trusted entity (CA in PKI, KDC in Kerberos) that vouches for authenticity of the exchanged public keys by way of certificates (see below). Asymmetric crypto has the great advantage that a certificate, once issued, can be reused many times for many communication peers. Compare that to the symmetric case where you cannot reuse Kerberos tickets - that's one of the reasons why certificates have a much longer life time than Kerberos tickets. The only problem that remains is how to establish a secure channel between A and CA and B and CA. This cannot happen ad-hoc in a trustworthy way, which is the central point of your question.

So it seems that by utilizing a CA you have just moved the problem around without any progress (even worse, you introduced a new critical dependency), but there is one important difference: You need to establish a secure channel only with one trust anchor - which makes the problem feasible in the first place.

You need to take a special route to establish trust between you and a trust anchor. This can be by meeting in person or other suitable out-of-band mechanisms. In Windows Active Directory environments this is you being authenticated on a computer joined to a domain using your credentials. The trick here is to design the process such that it scales well. However, there are still many leaps of faith to make:

In principle, a public-key certificate works like any other kind of certificate, including the ones in the real world.

1. If some authority A asserts some property $\mathsf{Property}(X)$ for some $X$
2. If A publishes the assertion in a kind-of unforgeable way
3. If some entity Y trusts A

then Y has virtually no choice but to believe that $\mathsf{Property}(X)$ is true.

For public-keys in a X.509-style PKI that means, A is a CA, $\mathsf{Property}(X)$ is a claim along the lines of "the key $K^\mathsf{pub}_X$ herein belongs to entity $X$" and the unforgeable way is via secure digital signatures with adequate key-lengths (for simplicity, I assume that all relevant algorithms are implemented flawlessly...).

Moreover, each of the following conditions are crucial:

4. Y needs to have a genuine copy of CA's public key.
5. CA must be trustworthy, which means, they know what they do and they are not corrupt or being corrupted themselves.
6. All devices involved are trustworthy (i.e. not infested by trojans, backdoors and such)

Each of those is quite tricky and hard to achieve - if at all.

Acquiring a public key in a trustworthy way

I think this is the issue that gave rise to the question. Since anyone can create arbitrary key pairs and from this, create arbitrary certificates, the trick is to distinguish between the wheat and the chaff, i.e. to tell genuine and fake root certificates apart. This can be done by secure channels, but for that you need some kind of trustworthy "seed". For instance, if you consider how the Web Of Trust works, particular the legendary PGP key signing parties, all involved attendees meet in person and mutually check photo IDs (another brand of certificate...). However, that does not scale.

On the other hand, if you consider how root certificates are distributed in web browsers and operating systems, you find that you depend on the software vendors. Now, once upon a time there was the vision of a global PKI with one ultimately trusted root, where a copy of the public key or digital fingerprints thereof would be virtually everywhere posted (e.g. in printed publications). Of course, there was/is no agreement conceivable on who that could be, and thus this position remains vacant. Well, not quite, the software vendors silently filled that vacancy, and this seems to be accepted on the ground that there is nothing better in sight for the moment, and somehow, this seems to work (but see below).

Closed organizations like enterprises and government bodies are a special class of cases - whenever you enter the organization, you get your PC, your accounts, and alongside you get your key pair and the public key of the organization root CA (more precisely, this is typically stored in the Windows Active Directory, where the AD architecture with its protocols like Kerberos provide the secure channel).

CA trustworthiness

Running a root CA properly is not easy, especially since they are very attractive attack targets. You need detailed procedures, background checks of the staff, regular training, suitable rooms, etc. etc. etc. And yes, there are audits by the browser forum and possibly other bodies, but the famous glitches of Commodo and DigiNotar show how hard it is to run a CA properly.

The humorous application of "Honest Ahmad" for a root certificate sheds some light on the weaknesses of the whole construction.

Device trustworthiness

This is another property that is hard to achieve. General-purpose hardware with general-purpose OSes allow you to install any software that you want - and coincidentally, any software that you don't want, including malware. The average textbook describes an encryption process (say) as Alice encrypts message M with her key K or something like that. But who is Alice? If that refers to a person, then the statement is to be read as Alice instructs her computer to ... . Given the Trojan malware that we saw in the past (particularly Trojans for "alternative" online banking) it is easy to conceive that the computer does something quite different than intended or expected while pretending otherwise.

Now what?

To be honest, nobody knows. Bruce Schneier and others have written a lot about that. But as far as I know (I am not closely watching, though) the whole construction was never thoroughly contested in the courts. Until then it holds what I said earlier: The existing architecture somehow works, despite the many leaps of faith you have to make, and alternatives that are widely accepted are not in sight.

Answer 6

I would like to address Maarten Bodewes' answer. Although Extended Validation (EV) certificates, in the past, may have improved the legitimacy of the website you're browsing by requiring further human identity verification, this does not mean that it hasn't been exploited for phishing.

One downside of EV certs is the human verification part: human are prone to make mistakes, a simple less experienced worker may accidentally issue an EV cert meant for phishing a less well-known company.

Another is a law that allow similar names for companies operating in different field of businesses, or similar names for companies operating in different countries/state. This can be prominently seen in Troy Hunt's (creator of Have I Been Pwned) post: Extended Validation Certificates are (Really, Really) Dead. A company in country/state X (example, James Food) may operate a similarly named company in country/state Y (James Foods), or a company operating as a food chain (Ben's) in country/state X may have a similarly named company operating as a hotel (Ben's hotel) in the same country/state. There's no way to solve this problem, except changing the laws nationally or internationally.

Further adding to problem is the cost of EV certs: although EV cert sellers such as Comodo CA lists prices for multiple domains at a flat rate of US\$398/year, the prices increases for each additional domain at US\$139/domain. This is especially costly for large websites that have multiple subdomains, and impossible for websites using a wildcard and offering subdomains as part of their service (for example, userX.wordpress.com or userX.github.io).

Browsers such as Google Chrome, Firefox, Safari and Edge are also removing EV indicators on the browser due to the above problems (giving a false sense of additional security) as given by Firefox's development forum: Intent to Ship: Move Extended Validation Information out of the URL bar

Answer 7

This is an insightful question, and correctly focuses attention on the hard part of the problem.

One part of the answer is that the Certificate Authority can be more stringent than an ordinary user would be in verifying things since that's their whole job.

For the Web PKI (certificates used by web sites and most stuff you use on the Internet) there are agreed rules often called the Ten Blessed Methods for how the Certificate Authority does this. You definitely wouldn't want to be bothered to conduct any of the Ten Blessed Methods every time you visit a web site, even the relatively simple ones like sending an email and then waiting for the site's owner to click a confirmation link so you know it's really them would be impractical if everybody had to do them just to visit a web site.

CAs are allowed to go beyond these rules and be even more thorough. For example the popular Let's Encrypt service has discussed using an approach in which their verifications would happen near simultaneously from multiple perspectives around the world so as to avoid attacks where a bad guy impersonates your web site only as far as the Let's Encrypt servers are concerned on the West coast of the USA.

And some methods can be further protected with cryptography rooted in the DNS system, DNSSEC, so that imposters would need to break into a Domain Name registrar to get certificates for any names registered through it.

But it is certainly true that what a CA is doing is ultimately only a more thorough version of investigations you could do yourself, the main benefit is that every user gets to benefit from the verification happening just once. If bad guys are able to trick the verification process (and it certainly does happen in some cases) then the system is indeed defeated.

For sites at most risk of such an attack, there is one final line of defence these days - the Certificate Transparency system. Browsers including Chrome and Safari won't accept certificates without proof of publication to the CT logs, and those logs are open to public inspection. So for a site that feels it's at risk of impersonation there's the option to monitor those logs for unexpected certificates so that action can be taken urgently if any are seen.

Answer 8

There are several great answers here that give a lot of information about the PKI system and Certificate Authorities in general, but none have specifically answered the question, "who vouches for the Certificate authority?"

The answer to that question is that the Certificate Authority (CA) vouches for itself through a comprehensive annual audit. The audit verifies that the CA meets or exceeds the regulations and standards that are established by the Certificate Authority / Browser Forum (CA/B Forum), which is a collection of CAs, Browsers, and other interested parties. The CA/B Forum works together to establish guidelines for issuing digital certificates for websites, code signing, and other uses.

A Trusted CA will have seals on their website to indicate that they are a SysTrust or WebTrust certified website. To quote the explanation that appears when you click the on the seal, "the applicable SysTrust or WebTrust Seal of assurance symbolizes that [the] site has been examined by an independent accountant. Further, the Seal represents the practitioner's report (see below) on management's assertion(s) that the entity's business being relied upon is in conformity with the applicable Trust Services Principle(s) and Criteria.

"The Trust Services Principles and Criteria is an international set of principles and criteria for systems and electronic commerce developed and managed jointly by the American Institute of Certified Public Accountants and the Canadian Institute of Chartered Accountants. By demonstrating compliance with Trust Services criteria through an examination by an independent practitioner, entities earn the right to display the seal of assurance."

While each operating system, browser, and even hardware/software manufacturers can have their own Trust Store of approved CAs, with their own criteria foe entry into said trust stores, they almost all require that any Certificate Authority that wants to be listed first obtain an unqualified audit report, which indicates that the policy and procedures of the CA are being followed in conformity with the AICPA/CICA WebTrust for Certification Authorities Principles and Criteria, as per CA/B Forum regulation.

TL;DR: There is a set of industry regulations that all CA's must meet. To prove they abide by these regulations the CA undergoes an annual audit, the results of which are available on that CA's website via the WebTrust Seal.

Answer 9

There have been several cases where root-CA had been compromised. But one part of the whole mechanism is that the root-CA work in a network together. Their CA-ability hangs on held certificates of trust, signed by other root-CA. As soon as it became apparent that one of the CA wasn't trustworthy the very same mechanism "kicked" them out, as the certificates signing the trustworthiness of the root-CA in question were declared invalid. Thus in turn the certificates of that special CA became invalid .. problem fixed by self-correcting organization, although it took some time to propagate through the internet.

Answer 10

My answer is: nobody. The various public CA either do not guarantee anything or have a rather limited guarantee. As for the certificates stored in your browser, I don't think it would be too difficult for hackers to install a fake certificate of their own. The public PKI/CA structure is in my opinion "better than the alternatives" but not much more than that. A tightly controlled private PKI, such as is used by banks and other organizations, is much better.

See an article by Carl Ellison and Bruce Schneier.

Answer 11

Yes, as others have explained, there are (essentially) a set of public keys of "trusted" authorities pre-loaded into your browser.

Let me add a couple of points that have not already been discussed.

One important question is: who decides which CAs are "trusted"? The answer is that, for most general users, this is determined by the browser vendor. And the CAs that the browser vendors think should be trusted may not be the same as the CAs that the end user actually wants to trust. So you can review and change the list. Many organizations' IT departments will configure end users' machines with a different set of trusted CAs. This is quite common, for example, in government and military organizations.

Also, your question about MITM attacks is quite valid. In fact, some organizations will configure end users' machines with a trusted CA specifically to enable a MITM inspection of traffic going to and from the internet. This allows them to open and inspect all traffic, even if it's encrypted with TLS. If this is done, the organization should tell their users that their communications is being monitored.

Answer 12

In the scientific community CAs are under scrutiny of the IGTF: Interoperable Global Trust Federation. The IGTF sets the rules for how CAs operate, and CAs that are trustworthy get accredited. Trustworthiness is determined through audits. The IGTF regularly compiles a list with accredited CA's root certificates that you can download and install. Untrustworthy CAs get booted from that list. The IGTF is organized in regional PMAs (Policy Management Authority);

• TAGPMA for North and South America
• EUGridPMA for Europe, Africa, Middle East
• APGridPMA for Asia Pacific region

See also https://www.igtf.net/