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