# Certificates, part 2 Today we continue the discussion of certificates and public-key infrastructure (PKI). Last time we saw with PGP how PKI can be based on a decentralized model; today, we'll see a centralized model: certificate authorities. Certificate authorities (CAs) have been used since early web browsers, such as Netscape's. They seem to have been introduced by Digital (a company) in 1989. as part of the [Digital Distributed System Security Architecture](http://research.microsoft.com/pubs/68218/acrobat.pdf). The philosophy behind CAs is to create principals called *certificate authorities* (CAs) whose purpose is to issue certificates. Everyone has the CA's own self-signed certificate Cert(CA; CA) pre-installed on their system. When machine S wants a certificate for itself, binding id_S to K_S, then S contacts the CA, enrolls, and the CA issues certificate Cert(S; CA) to S. When A wants to authenticate S, then S must present its certificate Cert(S; CA) to A. Immediately we have two problems: (i) no one trusts a single CA anywhere in the world, and even if they did, (ii) the CA would be a single point of failure. So in reality there are many CAs: somewhere around 1500 have been observed on the public internet in recent years. Your university/company/bank could be a CA for its students/employees/customers. And there are commercial CAs that will issue certificates if you pay them enough—for example, Verisign. Your browser and/or your OS actually come with the certificates for those commercial CAs preinstalled. Sometimes if you pay the CA more, they do better verification of attributes at enrollment, and you get an *enhanced* certificate that causes the browser to display their name more prominently. CAs as implemented in practice are hierarchical: a master CA will certify a subordinate CA as Cert(Sub; Master), then the subordinate will issue certificates itself. And subordinates could themselves have sub's, etc. So we have certificate chains again—for example, Cert(Sub1; Master), Cert(Sub2; Sub1), Cert(Alice; Sub2). ### Revocation Regardless of the distribution philosophy, certificates have a substantial problem when it comes to *revocation*: what happens when a certificate needs to be withdrawn. Revocation might happen periodically as a key's cryptoperiod expires, hence old certificates need to be replaced by new. Revocation might be necessary because the subject's private key was compromised and is no longer trustworthy, or maybe because the issuer's was. Here are three strategies for implementing revocation: - **Certificate revocation lists (CRL):** the CA publishes lists of of revoked certificates. Machines download and check that list every time they need to verify a certificate. Downloading the list is expensive, so implementors will naturally cache, leading to TOCTOU attacks. - **Online certificate validation:** the CA stands up *validation servers* that accept certificates as input and determine whether they have been revoked. Machines contact one of these servers every time they need to verify a certificate. The validation servers now become a potential point of attack, and DOS against them leads to the inability to authenticate. - **Fast expiration:** the CA issues certificates only with short validity, e.g., 10 min to 24 hrs. CAs now have to issue certificates with much greater frequency, and machines frequently need to acquire new certificates. Revocation is a serious practical problem. Consider, for example, what happens when an issuer's key is compromised. A large such breach occurred in March 2011. CA Comodo had nine rogue certificates issued through it for Gmail, Hotmail, Google, Yahoo, Skype, Firefox, etc. Whoever got those certificates could impersonate those businesses to anyone who doesn't know they're revoked. Browsers, OSs had to push out updates to revoke the certificates. So we're placing a lot of trust in CAs. Trust is an assumption, and assumptions are vulnerabilities... ## Exercises 1. Create a self-signed certificate using openssl: ``` $ openssl req -x509 -newkey rsa:2048 -keyout private.key -out self-signed.crt ``` You will be prompted for a passphrase; you whatever you like. Install that certificate into your browser. Again, that might mean installing into your OS. (In OS X, for example, use Keychain Access to Import Item into your Login keychain, selecting `self-signed.crt`. It will appear under Certificates.) View the certificate after you've imported it. Why are the subject and issuer the same? Why is Basic Constraint set? **De-install the certificate**. What (perhaps unlikely) attack might be possible if you left the certificate installed? 2. Suppose a CA is malicious. How could the CA abuse the trust placed in it to cause harm? 3. Suppose a system uses a PKI with a CRL. A device in that system is asked to verify a certificate but cannot access the CRL database because of a DoS attack. What are the possible courses of action for the device, and what are the advantages and disadvantages of each course of action? 4. Compare and contrast the advantages and disadvantages of CRLs, fast revocation, and online certificate verification. Describe one example application for which each would be appropriate.