1. Prof. Reuven Aviv, Nov 2013 Public Key Infrastructure1 Prof. Reuven Aviv Tel Hai Academic College Department of Computer Science Public Key Infrastructure

2. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI2 OUTLINE 1. Secure Distribution of public keys: Certificates 2. Authenticated Data Exchange 3. Public Key Infrastructure Literature: W. Stallings, Network Security Essentials, 4 th Ed, Ch. 4.3-4.5

3. Secure Distribution of Public Keys: Certificates Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI3

4. Prof. Reuven Aviv, Nov 2006 4 Fast creation + distribution of session key, K s 1. A  B: (public key KUa, IDa) – B generates a random Session key K s 2. B encrypts by KUa, transmits to A –A decrypts K s with its private key KRa M.I.M can impersonate the parties What is the problem?

5. X.509 Certificate: Who owns a public key Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI5 Certificate: Who owns a public key

6. X.509 Certificate Certificate: A link between a named subject (person, process, organization) and a public key Assuring that the Subject knows the private key Cannot be tampered 6

7. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI7 Certificate: Issuer and Subject (certmgr.msc)

8. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI8 Pre-installed Certificate in Windows 7s

9. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI9 Issuing a certificate Certificates are text files, not encrypted Before issuing a certificate, the CA checks: –that the owner (‘subject”) ID is correct –Subject knows the corresponding private key –E.g. by encrypting a “challenge”, that the subject should decrypt Certificates include user ID, Public key, time stamp, signing algorithm, …

10. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI10 Creating a certificate At the authority

11. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI11 Simple Validation of a certificate by a receiver B receives A’s certificate, say by email B decrypts the signature by CA’s public key, revealing the original hash. Then calculate the hash of the certificate, compares If match, the certificate is authentic, so a subject named A knows the private key listed in the Cert Note: To authenticate the sender (prove that the sender is A), the sender needs to provide a proof that he knows the private key. How?

12. List of certificates installed in Windows 7 Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI12

13. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI13 Revocation of Certificates Reasons for revocation: –secret key is assumed to be compromised. –The user is no longer certified by this CA. –CA’s certificate is assumed compromised. CA issues a Certificate Revocation List (CRL) –cert identified by its issuer and the serial num User that gets a certificate should consult that list –User maintains cache of certificates and CRLs how the integrity of list is kept?

14. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI14 Certificate Revocation List

15. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI15 Revocation List

16. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI16 Authenticated Data Exchange

17. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI17 1. Receiving certificates and exchanging them

18. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI18 2. Authenticated Data Exchange authenticating data and users during data communication assume that parties previously obtained X.509 certificates of each other 2 procedures –Three way (3 messages) authentication –One-time session key usage scenario

19. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI19 3 way message exchange with authentication Message: Data, time-stamp, nonce, receiver id Option: session key (K ab ) encrypted by public keys of receiver Messages signed by sender’s private key: A  B: A{t A, r A, B id, Data, E KUB [K ab ]} B  A: B{t B, r B, A id, r A, Data, E KUB [K ba ]} A  B: A{r B } –B: Verifying sender’s signature proves that sender knows the private key of A –Echoing signed nonces (r A, r B ): no replay

20. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI20 X.509 Three-way authentication Establishing –Integrity and originality of both messages –Identities of senders are indeed A, B –Messages intended to be received by B, A –No replay of any of the messages

21. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI21 A one-time session key usage scenario A encrypts message (AES) with a new session key, encrypts session key by B public key, appends this to message, adds her signature A send to B the 3 parts message –By verifying A’s signature, B knows that A sent this to him B, and Only B, can decrypt correctly the session key, because it is encrypted by his public key –A knows that only B will be able to decrypt the session key and decrypt the message

22. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI22 Public Key Infrastructure Original Slides Henric Johnson

23. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI23 The Monopoly Trust Model All use one, trusted CA, know its public key –How do they know it? User can send certificates directly to others User B can verify authenticity of A’s certificate by decrypting the signature of the CA What are the problems? There is no single trusted organization all OS must include with CA’s KU – hard to change –The CA can charge anything it wants

24. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI24 Registration Authority How a CA can validate a far away user identity? –Registration Authorities (RAs) in charge of mapping names to KU Alternative: several CA’s What is the problem? Assume A Communicates with B, and: A obtained certificate issued by X1 B obtained certificate issued signed by X2 X1, X2 obtained certificates issued by each other

25. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI25 Chains of certificates X1, X2 are CAs. They also have certificates X1 > X2 > X1 > X2 > A got the X2 > certificate (from B) A must get the X1 > certificate (from X2) –A extracts from X1 > the X2 public key –A extracts from X2 > the public key of B Summarizing: A must get the chain of certificates X1 > X2 > More generally, a receiver must get a chain of certs: X 1 > X 2 > …X N > How A (and B) find the chains?

26. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI26 Certificate Path A wants to get B public key. He gets the following certificates (right to left) X > W > V > Y > Z Is this structure Fixed?

27. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI27 Monopoly with delegated CAs Trust Model One root CA issues certificates to other CAs –Certificates must authorize holders to issue certificates to other CAs –A tree of CAs –Each user cert is the end of a chain of certs –Root CA also called trust anchor –Who issues the certificate of the trust anchor? Problems?

28. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI28 Oligarchy Trust model OS preconfigured with a list of trusted root CAs –Their self issued certificates added to the OS OS also include list of certs of intermediaries –All certificates form a forest User can add or delete entries from lists Very common in practice –Browser rely on these lists

29. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI29 Pre-configured Certificate Paths in Windows

30. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI30 Trusted Root Certificates in my computer Tool: certmgr.msc

31. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI31 oligarchy more secure than monopoly? Monopoly: corruption  risks world security Oligarchy: Corruption in one root CA  same –More likely to happen in oligarchy! Oligarchy: CAs chosen by vendor, so what? Easy to trick users to add new “trusted” CAs Malicious users can change lists in a public host –Hardly noticeable in long lists

32. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI32 Anarchy Trust Model users responsible for configuring root CAs –People he/she trusts – then anyone can issue certificates Volunteers keep certificates in a database To find a cert: search for a chain in the DB –Can we really trust a chain of certificates? –Not scalable idea: several chains lead to cert  trusted cert Used in Pretty Good Privacy (PGP) software