Certificate authority

In cryptography, a certificate authority, or certification authority, (CA) is an entity that issues digital certificates. The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate. CAs are characteristic of many public key infrastructure (PKI) schemes.

Commercial CAs charge to issue certificates that will automatically be trusted by most web browsers (Mozilla maintains a list of at least 36 trusted root CAs, though multiple commercial CAs or their resellers may share the same trusted root).^[1] The number of web browsers and other devices and applications that trust a particular certificate authority is referred to as ubiquity.

Aside from commercial CAs, some providers issue digital certificates to the public at no cost. Large institutions or government entities may have their own CAs.

Domain Validation

The commercial CAs that issue the bulk of certificates that clients trust for email servers and public HTTPS servers typically use a technique called "domain validation" to authenticate the recipient of the certificate. Domain validation involves sending an email containing an authentication token or link, to an email address that is known to be administratively responsible for the domain. This could be the technical contact email address listed in the domain's WHOIS entry, or an administrative email like postmaster@ or root@ the domain. The theory behind domain validation is that only the legitimate owner of a domain would be able to read emails sent to these administrative addresses.

Domain validation suffers from certain structural security limitations. In particular, it is always vulnerable to attacks that allow an adversary to observe the domain validation emails that CAs send. These can include attacks against the DNS, TCP, or BGP protocols (which lack the cryptographic protections of TLS/SSL), or the compromise of routers. Such attacks are possible either on the network near a CA, or near the victim domain itself.

Some Certificate Authorities offer Extended Validation (EV) certificates as a more rigorous alternative to domain validated certificates. One limitation of EV as solution to the weaknesses of domain validation is that attackers could still obtain a domain validated certificate for the victim domain, and deploy it during an attack; if that occurred, the only difference observable to the victim user would be a blue HTTPS address bar rather than a green one. Few users would be likely to recognise this difference as indicative of an attack being in progress.

Domain validation implementations have also sometimes been a source of security vulnerabilities. In one instance, security researchers showed that attackers could obtain certificates for webmail sites because a CA was willing to use an email address like [e-mail] for domain.com, but not all webmail systems had reserved the "SSLCertificates" username to prevent attackers from registering it [1].

Issuing a certificate

A CA issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the CA's certificates. CAs use a variety of standards and tests to do so. In essence, the Certificate Authority is responsible for saying "yes, this person is who they say they are, and we, the CA, verify that".

If the user trusts the CA and can verify the CA's signature, then he can also verify that a certain public key does indeed belong to whoever is identified in the certificate.

Example

Public-key cryptography can be used to encrypt data communicated between two parties. This can typically happen when a user logs on to any site that implements the HTTP Secure protocol. In this example let us suppose that the user logs on to his bank's homepage www.bank.example to do online banking. When the user opens www.bank.example homepage, he receives a public key along with all the data that his web-browser displays. When the user enters some information to the bank's page and submits the page (sends the information back to the bank) then the data the user has entered to the page will be encrypted by his web browser using the public key that was issued by www.bank.example. The key that can be used to decrypt the information is called the private key and it is only known to the bank. Therefore, even if someone can access the (encrypted) data that was communicated from the user to www.bank.example, the (unencrypted) data that the user has entered can only be decrypted by the bank, as only the bank knows the private key.

This mechanism is only safe if the user can be sure that it is the bank that he sees in his web browser. If the user types in www.bank.example, but his communication is hi-jacked and a fake web-site (that pretends to be the bank web-site) sends the page information back to the user's browser, the fake web-page can send a fake public key to the user. The user will fill the form with his personal data and will submit the page which will be encrypted by the fake public key. The fake web-page will get access to the user's data since the fake web-page owns the fake private key.

A certificate authority is an organization that stores public keys and their owners and every party in a communication trusts this organization. When the user's web browser receives the public key from www.bank.example it can contact the certificate authority to ask whether the public key does really belong to www.bank.example. Since www.bank.example uses a public key that the certification authority certifies, a fake www.bank.example can only use the same public key. Since the fake www.bank.example does not know the corresponding private key, it cannot decrypt the user's answer.

Subversion of CA

If the CA can be subverted, then the security of the entire system is lost for each user for whom the CA is attesting a link between a public key and an identity.

For example, suppose an attacker, Eve, manages to get a CA to issue to her a certificate that claims to represent Alice. That is, the certificate would publicly state that it represents Alice, and might include other information about Alice. Some of the information about Alice, such as her employer name, might be true, increasing the certificate's credibility. Eve, however, would have the all-important private key associated with the certificate. Eve could then use the certificate to send digitally signed email to Bob, tricking Bob into believing that the email was from Alice. Bob might even respond with encrypted email, believing that it could only be read by Alice, when Eve is actually able to decrypt it using the private key.

A notable case of CA subversion like this occurred in 2001, when the certificate authority VeriSign issued two certificates to a person claiming to represent Microsoft. The certificates have the name "Microsoft Corporation", so could be used to spoof someone into believing that updates to Microsoft software came from Microsoft when they actually did not. The fraud was detected in early 2001. Microsoft and VeriSign took steps to limit the impact of the problem.^[2][3]

In 2011 fraudulent certificates were obtained from Comodo and DigiNotar^[4][5], allegedly by Iranian hackers. There is evidence that the fraudulent DigiNotar certificates were used in a man-in-the-middle attack in Iran.^[6]

Security

The problem of assuring correctness of match between data and entity when the data are presented to the CA (perhaps over an electronic network), and when the credentials of the person/company/program asking for a certificate are likewise presented, is difficult. This is why commercial CAs often use a combination of authentication techniques including leveraging government bureaus, the payment infrastructure, third parties' databases and services, and custom heuristics. In some enterprise systems, local forms of authentication such as Kerberos can be used to obtain a certificate which can in turn be used by external relying parties. Notaries are required in some cases to personally know the party whose signature is being notarized; this is a higher standard than is reached by many CAs. According to the American Bar Association outline on Online Transaction Management, the primary points of US Federal and State statutes enacted regarding digital signatures has been to "prevent conflicting and overly burdensome local regulation and to establish that electronic writings satisfy the traditional requirements associated with paper documents." Further the US E-Sign statute and the suggested UETA code help ensure that:

1. a signature, contract or other record relating to such transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form; and
2. a contract relating to such transaction may not be denied legal effect, validity or enforceability solely because an electronic signature or electronic record was used in its formation.

In large-scale deployments, Alice may not be familiar with Bob's certificate authority (perhaps they each have a different CA server), so Bob's certificate may also include his CA's public key signed by a different CA₂, which is presumably recognizable by Alice. This process typically leads to a hierarchy or mesh of CAs and CA certificates.

Providers

Worldwide, the certificate authority business is fragmented, with national or regional providers dominating their home market. This is because many uses of digital certificates, such as for legally binding digital signatures, are linked to local law, regulations, and accreditation schemes for certificate authorities.

However, the market for SSL certificates, a kind of certificate used for website security, is largely held by a small number of multinational companies. This market has significant barriers to entry since new providers must undergo annual security audits (such as WebTrust for Certification Authorities) to be included in the list of web browser trusted authorities. More than 50 root certificates are trusted in the most popular web browser versions. A 2009 market share report from Net Craft as of January of that year determined that VeriSign and its acquisitions (which include Thawte and Geotrust) have a 47.5% share of the certification services provider market, followed by GoDaddy (23.4%), and Comodo (15.44%).

Open source implementations

There exist several open source implementations of certificate authority software. Common to all is that they provide the necessary services to issue, revoke and manage digital certificates.

Some well known open source implementations are:

• EJBCA
• OpenCA
• OpenSSL, which is really an SSL/TLS library, but comes with tools allowing its use as a simple certificate authority.
• gnoMint
• DogTag
• XCA

See also

Cryptography portal

• Certificate revocation list
• Certificate server
• Robot certificate authority
• Intermediate certificate authorities
• Self-signed_certificate
• Web of trust
• X.509
• Server gated cryptography
• Comparison of SSL certificates for web servers
• Extended Validation Certificate
• CAcert
• SAFE-BioPharma Association
• Root Key Ceremony

References

1. ^ https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html, List of Trusted Root Certificate Authorities, 2/10/2010.
2. ^ Verisign, Inc. (31 January 2001). "Jan 2001 - Advisory from VeriSign, Inc.". http://www.verisign.com/support/advisories/authenticodefraud.html. Retrieved 2008-12-02. 
3. ^ Microsoft, Inc. (February 21, 2007). "Microsoft Security Bulletin MS01-017: Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard". http://support.microsoft.com/kb/293818. Retrieved 2011-Nov-09. 
4. ^ Bright, Peter (28 March 2011). "Independent Iranian hacker claims responsibility for Comodo hack". Ars Technica. http://arstechnica.com/security/news/2011/03/independent-iranian-hacker-claims-responsibility-for-comodo-hack.ars. Retrieved 1 September 2011. 
5. ^ Bright, Peter (30 August 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. http://arstechnica.com/security/news/2011/08/earlier-this-year-an-iranian.ars. Retrieved 1 September 2011. 
6. ^ Fraudulent DigiNotar Certificate Usage Retrieved 7 September 2011.

External links

• Certificate authorities at the Open Directory Project
• Certificate Authority Reviews
• Certificate Authorities by Country