Certificates

1. Certificates Tyler Moore The University of Tulsa Many slides adapted in part or whole from John Hale, TU

2. Recall: Certificates How does Alice (browser) obtain PKBob? BrowserAlice CA Server Bob choose (SK,PK) PK and proof “I am Bob” check proof SKCA PKCA PKCA Verify cert issue Cert with SKCA : Bob’s key is PK Bob’s key is PK Bob uses Cert for an extended period (e.g. one year)

3. Recall: Certificates Important fields:

4. Associates public-key value w/ person, device or entity Signed by a Certification Authority (CA) Subject must trust the CA CA must confirm the identity of the holder of the corresponding private key Core assumption: Everyone knows how to verify the CA’s digital signature (i.e., everyone knows CA’s public key) Each user in secure communication system must contain (at least) one certificate from a CA Each certificate contains a public-key value and information that uniquely identifies the certificate’s subject (a.k.a. a “subscriber” of the CA) Public Key Certificates

5. Certificates can be distributed without needing to be protected: No confidentiality needed The certificate is self-protecting: the certificate contains a digital signature which provides authentication and integrity Certificate is useful only if public-key user trusts the CA Certificate user inherit trust from CA Scalability A large population of users can participate in the public key certification system All only need to know CA’s public key Characteristics of Certificates

6. There is normally more than one Certification Authority Each CA manages its own ‘subscribers’ How to make a CA1 subscriber trust a CA2 subscriber? Solution 1: Make it so every user knows every CA’s public key (hard to do – won’t scale) Solution 2: Engender trust between CAs (CA2’s public key signed by CA1) A model where more than two CAs are involved Hierarchical trust model root CA: start point of the certificate chain, all parties trust the root CA Transitivity: CA1 trusts CA2 trusts CA3, etc. A certificate chain or certification path is a chain from the root CA to another CA or subscriber Web of trust Decentralized control In the large = PKI Certification Path

7. A Certificate has a lifetime (just like keys) A Certificate contains start date/time and expiration date/time Expired Certificate are only used to verify signature on a old document (e.g. for auditing purpose) In event of suspected key compromise, a new certificate should be issued, and the old certificate should be “revoked” prior to its expiry date A new certificate should be issued to the subscriber when his/her old certificate is expired Secure revocation schemes are needed for a robust public key certification system But these have been poorly implemented in browsers Validity Periods and Revocation

8. Key-pair generation generation of private and public key archiving/back-up of private key sending of public key for certification Where a key pair is generated? Key-pair holder system private key owner performs the generation (in hardware token or software module) private key never sent out from system best for non-repudiation (i.e., non-deniability for signatures made with private key) Public key value has to be transported to CA securely, for example, in a self-signed certificate Central system key-pair generated in central site associated with CA private key has to be transported to the owner through a secure channel Public-Private Key-Pair Management

9. Private-key protection Methods Stored in a tamper-resistant hardware token e.g. smart card, PCMCIA card Stored in encrypted data file The data file is protected by a password Ex. The data file is encrypted by symmetric key that derived from a password Stored in a credentials server Key access: the server authenticates user Pros and cons Hardware token is more expensive and more secure Software solution is vulnerable to Password-guessing attack Attacks on the server Public-Private Key-pair Management

10. Specialized key-pairs differentiate management based on implications of key use on requirements Digital signature key-pairs No party other than the holder of private key should be able to access the private key ANSI X9.57 requires the private key NEVER leave the device it is created, used, destroyed No backup or archiving is needed for a digital signature private key (should be destroyed at end of lifetime) Digital signature public key (or its certificate) should be properly archived Key Management Requirements

11. Encryption key-pairs Encryption private key should be properly backed up, archived, and escrowed (if so desired) A encryption private key does not have to be securely destroyed at the end of its lifetime Other reasons for separate key pairs Encryption software is generally subjected to more strict export controls than those used in digital signature They may have different crypto-periods Some digital signature schemes (e.g. DSA) cannot support encryption Requirement of mandated key escrow system Key Management Requirements

12. Certificate accompanying digital signature One drawback is it wastes bandwidth (consider A sends 50 messages to B; A’s certificate will be submitted 50 times) If certification path is unknown, this method cannot be used properly Distribution via Directory Services Directory is a database of (valid and updated) certificates ISO X.500 standard (originally aimed at, say, looking up of email address from a person’s name), specialized as X.509 for public-key certificates Proprietary directory service such as Microsoft Active Directory, Lotus Notes, Novell NDS Internet Lightweight Directory Access Protocol (LDAP) : an X.500 compatible access protocol that is more implementer-friendly Adopted by MS Outlook, VeriSign, others Certificate Distribution Methods

13. Certificate fields: Version: 1, 2, 3. (version 4 in 2000, but V3 what is used) Serial number: assigned by the issuing CA Signature: signing algorithm used by CA Issuer: X.500 name of issuing CA Validity: start/expiry date and time Subject: X.500 name of the holder of the private key Subject public-key information: value and algorithm of the public key being certified Issuer (and subject) unique identifier : optional bit string to make the issuer (subject) name unambiguous X.509 Certificate Format

14. X.509 V3 Certificates

15. X.500 names is a way to specify a subject in X.500 directories, which uses a public key certificate A subject can be a person, organization, or device. X.500 name is a distinguished name (DN) It is a global unambiguous name for a subject X.500 names are created from Directory Information Tree (DIT) DIT is logical organization of entries in a X.500 directory Each non-root vertex is a directory entry and has a DN DN is the path name of DIT e.g. DN={C=US, O=DePaul University, CN=John Smith} X.500 Names

16. Is DN really unique? DN={C=US,O=DePaul University, CN=John Smith} Problem: what happens if John Smith leaves, and another John Smith joins DePaul one year later and was assigned the same DN? In Version 2 of X.509 Certificate, issuer/subject unique identifier solves this problem issuer/subject unique identifier assigned a different value if DN reused Difficult to manage A better way is to use some unambiguous identifier in a part of RDN DN={C=US, O=DePaul University, CN=John Smith, Email=jsmith@depaul.edu} DN={C=US, O=DePaul University, CN=John Smith, Employee Number=0012345} X.500 Names

17. Canceling a certificate before the end of its original validity period. Why revoke? Key Compromise Forgotten Passphrase Lost Private Key Revocation

18. Who revokes? the subject the CA an authorized third party e.g. the organization with an employee quitting Source of revocation request must be authenticated Who Can Revoke?

19. A CRL is a time-stamped list of revoked certificates that has been digitally signed by a CA and made available to certificate users. Each revoked certificate is identified in a CRL by its certificate serial number – generated by the issuing CA. Core elements Issuer name CRL Issue Time/Date Entry (1 per revoked certificate) Certificate Serial Number Revocation Time Issuer’s Digital Signature Certificate Revocation Lists (CRL)

20. The user of a public key must check the CRL every time the key is used not enough to check when the certificate is originally accepted CAs Must accept and judge revocation requests Must keep a revoked certificate in the CRL until it expires List could get large Using CRLs

21. X.509 CRL

22. X.509 CRL Example Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority Last Update: Jan 22 11:00:36 2014 GMT Next Update: Feb 5 11:00:36 2014 GMT Revoked Certificates: Serial Number: 010199E0F79E9034FDD3D176DBB83A05 Revocation Date: Apr 2 15:03:51 2013 GMT Serial Number: 01048336716E434C44813CFCA5A829BF Revocation Date: Sep 17 23:48:52 2012 GMT Serial Number: 0104C6A0285798B92A015D641010279F Revocation Date: May 15 22:03:54 2013 GMT

23. Issuing CRLs regularly such as hourly, daily or weekly Decision of CA. Can be distributed easily using the communications and server systems which do not need much security – as these are digitally signed. Push vs. pull Limitation: Time granularity of revocation is limited to the CRL issue period Off cycle CRL generation Immediate issuance of CRLs How would you know if one went missing? Alternative: OCSP (Online Certificate Status Protocol) When user requests certificate, also asks if cert is valid The OCSP response is digitally signed, contains the identifier of the responder, time of response, status Now supported in modern browsers Pro: user only learns about certificates she needs Con: CA must respond to every request (huge overhead for popular sites) Con: only checked for EV certificates Distributing CRLs

24. Certificate valid for 1 day at a time re-requested each day possibly the same public key Revocation not necessary client stops asking for a new certificate Suitable for limited resource systems e.g. mobile wireless systems Assumes efficient certificate generation Revocation alternative: Short-Lived Certificates

25. Who bears the risk of key compromise depends on the time the wrong verification is carried out. time b to c : subscriber time c to d : probably CA time d to e : depends, either CA or the certificate user With periodic CRLs, it may be the best interests of the certificate user to wait until CRL 2 is issued With online status checking, the certificate user would know about the revocation during this period time after e : the certificate user Who Bears the Risk of Key Compromise? a. Issue of CRL 1 b. Key Compromise d. Revocation Time e. Issue of CRL2 c. Revocation Request Time

26. Revocation Issues in Practice • DDoS risk if CRLs must be checked before accepting certificate (CRLs are much bigger than one cert) • Relies on certificate holders to revoke, CAs to implement, browsers to support • Many chances for coordination failure • http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html • http://news.netcraft.com/archives/2014/04/24/certificate-revocation-why-browsers-remain-affected-by-heartbleed.html • https://www.imperialviolet.org/2012/02/05/crlsets.html

27. Revocation Issues in Practice • Most browsers do not fully support CRLs or OCSP • CAs may not be reachable even if website is • Refusing to connect to a website because the CA is unreachable would produce many false positives • So browsers that cannot verify a certificate’s validity will “soft-fail” and allow the connection to complete • Chrome, IE, and Firefox now deal with certificate revocation by issuing browser updates • Only catches major (i.e., newsworthy) revocations • Relies on users to install updates to be protected

28. Certificate Revocation and Heartbleed • Heartbleed was a major vulnerability in OpenSSL • Allows attacker to read keys from memory of vulnerable systems running OpenSSL • For more info see heartbleed.com and Duc’s upcoming talk • Because OpenSSL is so pervasive and the vulnerability so high-profile, many certificates needed to be revoked and reissued • “Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed”, Zhang et al., IMC 2014 • http://www.ccs.neu.edu/home/cbw/pdf/imc254-zhang.pdf • Selected graphs from this paper on subsequent slides

29. # Domains Issuing Revocations Per Day

30. Time between CRL posting by CA and downloaded

31. Certificate Revocation and Reissue by Website Popularity

32. Few vulnerable websites reissued certificates, even fewer revoked old ones

33. Vulnerable, reissued but not revoked certificates remain valid for years

34. Economics of CA Market • We have previously noted a number of high-profile breaches at CAs • DigiNotar (2011): 531 false certificates created, including for *.google.com, *.facebook.com, *.cia.gov, update.windows.com • Comodo, Verisign (2010, discovered in 2012), • Trustwave let companies issue false certs to monitor employees • For more examples see Roosa, S.B., Schultze, S. 2010. The “Certificate Authority” trust model for SSL: a defective foundation for encrypted Web traffic and a legal quagmire. Intellectual Property & Technology Law Journal 22(11): 3-8. • Why the market hasn’t rewarded secure CA practices? • Arnbak et al. “Security in the HTTPS market” provides answers http://queue.acm.org/detail.cfm?id=2673311

35. Systemic Vulnerabilities in HTTPS Authentication (Arnbak et al) • Weakest link design • Any CA can sign certificates for any hostname • One CA breach can undermine security for all • Information asymmetries • Very hard for browser makers, website owners, end users to observe the security of CAs • Liability dumping causes negative externalities • CAs shift harm of breaches toward users and away from CAs • CAs routinely disclaim liability for losses stemming from incorrectly issued certificates

36. CA Marketplace (Arnbak et al) • 1-2K browser-trusted CAs (root+intermediate CAs) • Normally a good thing but recall the weakest-link problem • High concentration (75% of certs issued by 3 companies) • Weak price competition

37. Price inversely related to market share (Arnbak et al)

38. Price inversely related to market share (Arnbak et al)

39. What actually drives the HTTPS market (Arnbak et al.) • Bundled security services (e.g., website malware scans) • Enterprise certificate management services • Brand reputation as a liability shield against shareholders, regulators • Trust or security signals aimed at third parties and end users such as site seals • Higher continuity in case of security failures at the CA, because of the too-big-to-fail dynamic of market-leading CAs