Certificates Tyler Moore CS 7403 University of Tulsa Many slides adapted in part or whole from John Hale, TU 1 Recall: Certificates How does Alice (browser) obtain PK Bob ? CA PK and proof I am Bob Browser Alice SK CA check proof issue Cert with SK CA : Bobs key is PK choose (SK,PK ) Server Bob PK CA Verify cert Bob uses Cert for an extended period (e.g. one year) PK CA 2 Recall: Certificates Important fields: 3 Public Key Certificates 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 certificates subject (a.k.a. a subscriber of the CA) 4 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 5 Certification Path 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 ( CA2s 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 6 Validity Periods and Revocation 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 7 Legal Relationship (CA & Subscriber) Model 1 -- Closed Community All part of a legal entity, e.g., ATMs of a bank, and the EDP department of the bank Third-party CA is not needed. Model 2 -- Open Community CA is an independent legal entity, e.g. Internet service provider, or Post Office as CA. Also known as third-party CA. Some in-between cases: Commercial organization and employees School and students Club and members For third-party CA and its subscribers, there are certain obligations toward each other CA acts as role of notary who may acknowledge a document 8 Public-Private Key-Pair Management Key-pair generation 1.generation of private and public key 2.archiving/back-up of private key 3.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 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 Key Management Requirements 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 ANSI X9.57 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 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 encryptionDSA Requirement of mandated key escrow system Key Management Requirements 12 Registration Authorities RA manages the interactions between a CA and its subscribers Enrolling, de-enrolling, and approving or rejecting changes to the certificate attributes Validating cert application Authorizing request for Key-pair Certificate generation Recovery of backed-up keys Accepting and authorizing request for cert suspension or revocation Physically distributing personal tokens and recovering obsolete tokens from authorized people 13 Certificate generation steps 1.CA is presented with the requisite certificate content info 2.CA verifies the accuracy of the info (in accordance with applicable policies and standards) 3.The certificate is created, and signed by a signing device using CA s private key 4.A copy of the certificate is forwarded to the subscriber. Optionally a confirmation of acceptance of the certificate is given by the subscriber 5.A copy of certificate may be submitted to some directory services 6.Optionally, a copy of certificate is archived by the CA 7.CA records the certificate generation process in audit journal Certificate Issuance 14 Certificate Distribution Methods 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 ofaddress 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 15 X.509 Certificate Format 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 16 X.509 V3 Certificates 17 X.500 Names 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} 18 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, DN={C=US, O=DePaul University, CN=John Smith, Employee Number= } X.500 Names 19 Object Registration in X.509 Object registration is a way to register objects that are used in certificates Objects can be public-key algorithms, organizations, Standard: ISO/IEC Object identifier Object identifier is a unique sequence of numbers that is assigned to a registered object e.g , or represented as {joint-iso-itu-t (2) country (16) us (840) organization (1) sharons (15678) algorithms (1) sharons-super-algorithm (66)} Object identifier for digital signature: RSA with SHA-1 = = {iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) sha-1WithRASEncryption (5)} 20 The object identifier works on the basis of a hierarchical structure of distinct value-assigning authorities ANSI assigns the value to RSA Data Security Inc. RSA Data Security Inc. has the right to assign component values at lower levels for its own purposes Object Registration in X X.509 Version 3 Certificate Format Improvement on V.1, V.2 for various reasons One subject can have several certificates for different public keys (for different purpose, at different time) A certificate often needs to convey additional subject- identifying information beyond an X.500 name E.g. title, job function Some applications need to identify users by application- specific name forms E.g.address Cert users need to know the assurances and practices applied to issuance of each cert e.g. encrypting casual, or authenticating high-value transactions Some CA only cross-certifies a subset of certificates issued by another CA 22 X.509 v3 has additional extensions fields added to implement a general extension mechanism Each extension field contains: a type: which needs to be registered (i.e. assign an object identifier) a criticality indicator: non-critical means the cert can be used by ignoring this extension, if the system cannot recognize it. critical means the system must recognize the extension if it wants to use the cert a value: it can be a complex data structure, format and semantics depends on the type X.509 Version 3 Certificate Format 23 Standard X.509 V3 Cert Extension Key and policy information Subject and Issuer attributes Certification path constraints Extensions related to CRLs (Certificate revocation Lists) 24 Naming in X.509 v3 Subject and issuer can be identified not only by X.500 names but also more names of a variety of different forms. Name formats in X.509 v3 Internetaddress Internet domain name X.400address X.500 directory name EDI party name Web Uniform Resource Identifier (includes URL) Internet IP address (for Internet connection end-points) Registered identifier (an object identifier) Other name (other name form that is registered) 25 Certification Path Constraints Certification Path Constraint is u seful for when CA1 issues a certificate for CA2s public key (cross certification) Three types of constraints Basic constraint Whether the subject is a CA or an end-entity If subject is CA, how long is the certification path length permitted e.g. only cross certify subscribers of CA2 Name constraint Which subset of subscribers of CA2 can be cross certified, by restricting the name of the subscribers Policy constraint More complicated, describing the policy mapping 26 Revocation Canceling a certificate before the end of its original validity period. Why revoke? Key Compromise Forgotten Passphrase Lost Private Key 27 Who Can Revoke? 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 28 Certificate Revocation Lists (CRL) 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 29 Using CRLs 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 30 X.509 CRL 31 X.509 CRL Format Version: Indicator of version 1 or 2 format Sig Algo ID: Indicator of algorithm used to sign CRL Issuer:Name of the authority that issued this CRL This update: Date and time of issue of this CRL Next update: Date and time of issue of next CRL (optional) Certificate Serial Number: Serial number of a revoked or suspended certificate. Revocation date: Effective date of revocation or suspension of a particular certificate. CRL entry extensions: Additional fields CRL extensions: Additional fields that must be attached to the full CRL. 32 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: GMT Next Update: Feb 5 11:00: GMT Revoked Certificates: Serial Number: E0F79E9034FDD3D176DBB83A05 Revocation Date: Apr 2 15:03: GMT Serial Number: E434C44813CFCA5A829BF Revocation Date: Sep 17 23:48: GMT Serial Number: 0104C6A B92A015D F Revocation Date: May 15 22:03: GMT 33 X.509 CRL Format of Extensions General Extensions CRL number incrementing number for each CRL issued in sequence covering the same certificate population Invalidity date: indicates a date when it is known or suspected that a private key was compromised. CRL Distribution Point Identifies the point or points that distribute CRLs on which a revocation notification for this certificate would appear if this certificate were to be revoked. Delta-CRLs A digitally signed list of the changes that occurred since the issuance of the prior base CRL. 34 X.509 CRL Format of Extensions Indirect CRLs : Allows a CRL to be issued by a different authority from the one that issued the certificate. Certificate Suspension: An item may be held on a CRL rather than revoked. It can be specified in the entry-level extensions as certificate hold. Status Referrals: It is a signed and time stamped list of CRLs and their respective CRL scopes that a certification authority currently uses. 35 Distributing CRLs 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 36 Revocation alternative: Short-Lived Certificates 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 37 b. Key Compromise Who Bears the Risk of Key Compromise? 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 a. Issue of CRL 1 c. Revocation Request d. Revocation Time e. Issue of CRL2 Time 38 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 failurecertificate-revocation-doesnt-work-in-practice.htmlhttp://news.netcraft.com/archives/2013/05/13/how- certificate-revocation-doesnt-work-in-practice.htmlrevocation-why-browsers-remain-affected-by- heartbleed.htmlhttp://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 39 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 certificates 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 40 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 Ducs 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 Selected graphs from this paper on subsequent slides 41 # Domains Issuing Revocations Per Day 42 Time between CRL posting by CA and downloaded 43 Certificate Revocation and Reissue by Website Popularity 44 Few vulnerable websites reissued certificates, even fewer revoked old ones 45 Vulnerable, reissued but not revoked certificates remain valid for years 46 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 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 hasnt rewarded secure CA practices? Arnbak et al. Security in the HTTPS market provides answers47 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 48 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 49 Price inversely related to market share (Arnbak et al) 50 Price inversely related to market share (Arnbak et al) 51 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 52