1. Certificates Robin Burke ECT 582

2. Last class Public key cryptography Solves what problem? New problem public key  identity

3. Man-in-the-middle attack Eve intercepts all communications Masquerades as both Bob and Alice Bob thinks he has Alice's public key but he doesn't How can Bob know for sure?

4. Complex This issue highlights the problems of trust in the digital world A lot of infrastructure needs to be in place Digital certificates Multiple collaborating certification authorities Registration authorities Certificate directories Certificate revocation servers

5. Trust We can't trust the public key associated with a message We might trust an authoritative source to vouch for Alice

6. Trusted third party Certification authority (CA) CA can meet with Alice look at her driver's license / birth certificate / etc take her fingerprints CA will then sign her public key

7. Man-in-the-middle? When Eve tries to substitute her public key for Alice's Bob will either notice that the key isn't certified, or Notice that it is certified but not for Alice, for someone else

8. Masquerading as CA? Eve could falsely issue a certificate and sign the certificate pretending to be the CA But the CA is a big institution strong interest in making its correct public key well known Multiple sources to access the CA's public key Some public keys are actually bundled with IE

9. Public key certificate A public key An identifier whose key? The whole package signed by the CA

10. Benefits of certification Alice and Bob can exchange certificates directly no need for a separate way to communicate public keys certificate is self-protecting Many users can participate only need to know CA's public key

11. Issues Trust in the CA issuance policies Security of the CA's private key very important!!!

12. Multiple CAs If there is only one CA all is simple Multiple CAs Alice's public key is signed by C1 Bob's public key is signed by C2 How can Bob be confident? maybe C1 is really Eve in disguise

13. Solutions Full distribution every user has the public key for every CA impractical Cross certification Suppose Alice presents Bob with C1's public key Signed by C2 Bob can verify the certificate C1's public key can be trusted Therefore Alice's public key can be trusted

14. Hierarchical trust model Root CA a generally-trusted CA Federal Reserve Bank all parties trust root Non-root CAs have certificates signed by root CA, or signed by another non-root CA closer to the root CA Certification path the chain of certifications from the root to a particular public key certificate More about this next week

15. CA relationships Intra-organization communication Bank ATM network Organization can be its own CA Open communication CA is an independent entity third party CA The third party CA is like a notary public is evaluating the truth of a person's representation may be liable if due diligence is not performed

16. Validity Public key is not valid forever limits risk associated with key compromise 1 year is typical Certificates have a valid period expired certificate may still be useful (non- repudiation) new certificate issued when old one expires Possibly the same key re-certified

17. Certificate assumptions During the valid period public key is valid for use association with identity assumed correct revocation notifications will be published

18. Revocation What if Eve hacks into Bob's computer and steals his private key? Alice will still be sending encrypted messages, but now Eve can read Certificate must be revoked can no longer be trusted new certificate issued how does Alice find this out?

19. Revoking a certificate Reasons for revocation Detected or suspected compromise Change of data e.g. subject name Change of relationship between subject and CA e.g. employee quitting a job from an organization which uses the current CA

20. Who can revoke? who revokes? the subject the CA an authorized third party e.g. the organization with an employee quitting Authentication of the source of revocation request is needed.

21. What happens? The CA determines that the revocation request is valid Then adds the certificate to its "certificate revocation list" CRL

22. CRL is a time-stamped list of revoked certificates, digitally signed by the CA available to all users Each revoked cert is identified by a certificate serial number CRL contains digital signatures, thus can be sent via unprotected channels Users of public key certificates should check a suitably-recent CRL

23. Note 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 CA must keep a revoked certificate in the CRL until it expires list could get large

24. Suitably recent? Question of risk what is the risk associated with a possibly out-of-date CRL CRLs are distributed regularly e.g. hourly, daily, biweekly, etc “off-cycle” CRL can be issued how to detect missing off-cycle CRL?

25. Example Eve steals Bob's private key Bob discovers break-in requests certificate revocation Eve sends a forged message to Alice Alice verifies message checks CRL no problems with Bob's public key CA publishes CRL with Bob's revocation too late

26. CRL Distribution Pull method CA periodically updates CRL depository users check when using a public key Push method broadcast new CRL when it changes Both subject to denial of service attacks

27. Online status checking Online Certificate Status Protocol Alice checks Bob's public key directly with the CA most effective most costly Costs handling traffic for every public key use handling cryptographic operations at high speed maintaining high security in Internet environment Also subject to denial of service attack

28. 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

29. Liability Who gets sued? depends on the timeline depends on legal framework b. Key Compromise a. Issue of CRL 1 c. Revocation Request d. Revocation Time e. Issue of CRL2 Time

30. Key pair management Public and private keys are generated together Afterwards, different lives Private key some kind of secure storage Public key self-signed certificate certification then public distribution

31. Generation Local generation private key never leaves the environment where it is used required by ANSI security standards Central generation private key must be communicated to user

32. Protecting the private key Smart card more secure but more expensive less portable Encrypted data file PGP's key ring Centralized credentials server digital wallet

33. Key pair management Public key functions encryption digital signature Different requirements

34. Encryption Encrypted files and messages may be stored indefinitely If private key is lost the data is effectively garbage Private key may need to archived more or less permanently

35. Key life cycle: encryption Encryption Decryption Certificate validity: Public key usage: Private key usage: Alice encrypts a message to Bob. Will use public key if certificate is in valid period certificate not revoked

36. Signature Key compromise extremely hazardous even for historical documents non-repudiation lost A lost signature key can always be replaced for signing the next document Private key must be securely destroyed

37. Key life cycle: signature Signing Validation Cert validity: Cert usage: Public key usage: Private key usage: Alice validates a signed message from Bob. Will use public key if valid period and certificate not revoked Will keep public key for historical validation

38. Key life cycle: real-time validation Alice installs software sold by Bob Bob's signature verifies uncorrupted code Will use software if certificate is valid at installation time Private key may have short life Sign Install Cert validity: Public key usage: Private key usage:

39. Also Different constraints on signature vs encryption encryption may be regulated different algorithms may be preferred DSA doesn't support encryption reason for development

40. Solution Multiple key pairs Encryption Signing PGP allows generation of either an encryption or signing key

41. Issuing a certificate Alice generates a key pair private key stored on hardware device public key self-signed Alice sends the self-signed public key to who? Possibly the CA more likely an intermediary for the CA

42. Registration authority An agent for the CA Deals with people Frees the CA to deal with bits May be internal to an organization even if CA is external

43. RA's responsibility Gets Alice's certificate request public key Verify Alice's identity testimonial email ping documents personal presence etc. Forward request to CA Handle all of Alice's other key management needs revocation expiry updated information

44. CA's responsibility Verification of identity or requisite trust in RA (Very) Secure signing operation Certificate returned to requestor possibly archived possibly made available to public Transaction recorded in audit journal

45. CA's key management CA keys have many uses signing (real-time validation) historical validation Short-use private keys better security But a signed certificate can't have a valid period beyond the signer's certificate CA will need multiple keys for different purposes

46. Break

47. Certificate distribution Alice sends Bob a two line signed email signature ≈ message size certificate > message size Alice's public key + CA's signature certificate for each CA in certification path Certification info could easily be 10x the message size What if Bob already has Alice's public key?

48. Certificate + Signature Inefficient Not practical in network environment Different users might need different certification paths can't predict which certificates to include Doesn't work for encryption

49. Directory services General case for public key discovery Online access to a directory request a public key certificate for a given user In this case Alice sends only the signed message Bob is responsible for getting Alice's certificate

50. Directory services Proprietary Novell MS Active Directory Lotus Notes Older standard X.500 Newer LDAP

51. X.500 Developed by the international standards bodies Extremely general look up by name browse available entities representing people, devices, applications, etc. Extension for public key certificates X.509

52. LDAP Useful subset of X.500 Easier to implement than X.500 Widely available Uses X.509 certificates

53. X.509 A certificate is a data structure Typically communicated in a binary format ASN.1 If we were starting over today we'd use XML XML didn't exist in 1988

54. Certificate format

55. Certificate fields Version 1,2,3 or 4 3 is the most widely used Serial no assigned by CA Signature algorithm id for CA's signature CA id Subject id Subject algorithm id Public key Some other stuff CA's digital signature

56. IDs Many things need to be identified what algorithm? who is the CA? whose key are we signing? X.500 Names every unique individual must have a unique name hierarchical naming scheme X.500 Object Identifiers for things like algorithms also hierarchical but with integer components

57. Directory Information Tree Country C=US, Canada, Mexico, etc. Organization O=DePaul University, UIC, Northwestern University, etc. Organizational uint OU=CTI, LA&S, Commerce, Theater, etc. Common Name CN=Robin Burke, Yonghe Yan, etc.

58. Distinguished name A collection of choices at each level of the DIT leading to an individual Not necessarily a person printer, router, application, web server DN {C=US, O=DePaul University, OU=CTI, CN=Robin Burke}

59. Name collision Typically we augment the common name with some other identifier employee / student id email address

60. Object identifiers Problem different organization may want their own "objects" impossible to create a list of legal values in advance Like DIT tree but with integers Used to label algorithms certificate types

61. Example 1.2.840.113549.1.1.5 this is a digital signature algorithm SHA-1 from RSA Labs How do we know this? 1 = ISO 2 = Indicates a member of the organization 840 = the USA 113549 = RSA's organizational id RSA chooses the rest of the identifiers

62. Id tree

63. X.509 Version 3 Versions 1 and 2 of X.509 did not work well for public key management Problems multiple public keys per user additional required information for some purposes all certificates not created equal

64. X.509 Extensions Instead of fixing all the fields in v. 3 an "extension mechanism" allow organizations to define their own certificate components Extensions must be registered (object identifier) criticality indicator

65. Standard extensions Authority key id CA's may have multiple signing keys helps to build certification path Key usage what the certified key is for Certificate policies under what policy was the certificate issued degree of authentication Path constraints what is a legal certification path from this certificate

66. Version 3 naming Much more flexible naming scheme X.500 names OK Others email address domain name IP address URL

67. X.509 CRL format Similar to certificate itself Also date/time of issue of this CRL date/time of issue of next CRL List of revoked certs: user certificate: cert serial number revocation date CRL extensions

68. Java and X.509 Certificate Java provides a standard API for X.509 certificate version 3 X509Certificate class is in java.security.cert

69. Java Certificate Management JRE provides a keystore of trusted certificate authorities It is in directory $JREHOME/lib/security/cacerts Access via "keytool" part of Java Development Kit

70. Keytool Allows many certificate management functions create self-signed certificate import / export certificates generate Certificate Signing Requests, etc.

71. Example keytool -certreq -file mycert.csr Generates a certificate signing request for your public key can send to CA to be turned into a certificate

72. Example Printing a certificate