Certificates

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

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 • 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 spped • 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 a. Issue of CRL 1 b. Key Compromise d. Revocation Time e. Issue of CRL2 c. Revocation Request 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 Alice encrypts a message to Bob. Will use public key if certificate is in valid period certificate not revoked Certificate validity: Public key usage: Private key usage: Encryption Decryption

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 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 Cert validity: Cert usage: Public key usage: Private key usage: Validation Signing

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 Install Cert validity: Public key usage: Private key usage: Sign

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