PKI Flashcards
X509
Defines Structure for public key certificates
Trust Root model
monopoly model: single root of trust
oligarchy model: numerous roots of trust
SCION: Per-domain trust root configuration
Approaches to improve TLS
- Let’s Encrypt
- Extended Validation
- HTTP Strict Transport Security (HSTS)
- Certificate Revocation List (CRL)
- Online Certificate Status Protocol (OCSP)
- DNS Based Authentication of Named Entities (DANE)
- HTTP Public-Key Pinning
- Certificate Transparency (CT)
Let’s Encrypt
provide free cer1ficates with automatic domain validation, issuance, and renewal
ISSUE: prefix hijacking
HSTS
HTTP Strict Transport Security: allows servers to declare that their clients should only use HTTPS (for a specified period)
HPKP
The server sends a set of public keys to the client. These keys should be the only ones used for connections to this domain.
ISSUES:
- Trust on First use
- Lost keys
- Pinning renewal before max age is reached can end up in self DoS
Certificate Revocation
- After a private key is disclosed
- Trusted employee / administrator leaves corporation
- Certificate expiration time is usually chosen too long (updating certificates is a lot of work)
ISSUE: CAP theorem Consistency, Availability and Partition tolerance not all possible.
OCSP
Online Certificate Status Protocol to verify certificate status, ensure certificate is valid and has not been revoked. ISSUES: - Optimistic treatment of OCSP failure - OCSP can leak browsing information Solution: OCSP stapling
OCSP Stapling:
Server gets signed-timestamped OCSP response from CA and verifies the validity of the cert to the client
DANE
DNS-Based Authentication of Named Entities, Use DNS Sec to bind certificates to names
1. CA constraints: clients should only accept certs by these CAs
2. Cert constraints: clients should only accept this cert
3. Trust anchor assertion: clients should use domain-provided trust anchor to validate certificates for that domain
ISSUE: heavy reliance on dnssec
Certificate Transparency CT
make cert public knowledge and hold CAs accountable. CT log is add only (Merkle Tree)
- log can be cryptographically verified (Merkle Tree)
ARPKI
- Domains obtain cert with mult signatures from different CAs
Integrity Log Server(ILS) logs domains certificates
SCT
Signed certificate timestamp
- issued by log server as promise to add cert to the log
- is used by domain owner to show validity of cert, before cert is added to log
problems of SCT with malicious log and CA
- log can issue SCT without adding it to the log, and therefore convince client that cert is valid.
- can be detected by client or CA by checking in retrospect if cert was added
branched log attack
log server adds cert to log view 1 but not log view 2. the log server replies with view 1 to client but with view 2 to CA. CA will not detect any forged certs and client accepts cert as valid.