1. King Mongkut’s University of Technology Faculty of Information Technology Network Security Prof. Reuven Aviv 6. Public Key Infrastructure Prof. R. Aviv, 2008Public Key Cryptography1

2. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI2 OUTLINE 1. Party Authentication via certificates 2. Models for Public Key Infrastructure 3. Appendix: EFS – file encryption in WinXP

3. 1. Party authentication by certificates Dr. R. Aviv, Nov. 2006Cryptography Short3

4. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI4 Party authentication (X.509) Party A present an X.509 certificates to party B B validated the certificate of A B knows a pair (ID A, KU A ) B learns the identity of A (B authenticates A) –By receiving a proof from A that it knows the private key KR A associated with the public key presented in the certificate Proof: A signs some data; B verifies the signature

5. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI5 X.509 Single message Authentication Single message from A to B, establishing: –Identity of A: message originated from A –Message intended for B; Integrity of message –Originality (no replay) of message Message: valid-period, B id, nonce, Data, sig A –A  B: A{t A, r A, B id, Data} Nonce r A kept by receiver for future use. Why? Message may include session key (K ab ) why? –encrypted by B public key why?

6. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI6 X.509 One Way Authentication How does A knows that B received the message? Why do we have both Timestamp and nonce? Again: How does B knows that the sender is A?

7. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI7 X.509 two way authentication Two messages exchanged between A and B Establishing same as in one-way, and –That message from A received correctly by B –Identity of B; reply originated from B –That reply was intended to A –Integrity and originality of reply 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 ]} What does a M.I.M know or change?

8. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI8 Digital signing of the certificate: Notations Two notations –CA > = CA{V, SN, AI, CA, T A, A, Ap} –LHS: > signed by CA –RHS: {…} signed by CA

9. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI9 X.509 Two-way authentication

10. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI10 X.509 Three-way authentication Echoing signed nonces guarantee no-replay Required if clock synchronization is not good

11. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI11 A one-time session key usage scenario A and B present their certificates to each other A creates a one-time random session key K s A  B 3 parts message –Data encrypted (e.g by AES) using one-time K s –K s encrypted by KU B –sig A B verifies A signature how? –If verified, B knows his party ID is ID A B, and Only B, can decrypt the session key why? –only B can correctly decrypt the message

12. 2. Models for Public Key Infrastructure (PKI) Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI12

13. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI13 How many CAs do we need? Monopoly Trust Model –All use one, trusted CA, know its public key –How do they know it? Parties can send certificates directly to others Party B can verify authenticity of a certificate by decrypting the signature of the CA What are the problems?

14. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI14 Monopoly Trust Model: Problems There is no single trusted organization all OS include with CA’s KU CA – hard to change How a remote CA can validate your identity? –solution: monopoly + Registration Authorities (RAs) in charge of mapping names to KU The monopoly will charge whatever it wants

15. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI15 Chains of certificates A obtained certificate issued/signed by X1 B obtained certificate issued/signed by X2 X1, X2 obtained certificates issued/signed by each other X1 > X2 > A gets the X2 > certificate (from B) A gets the X1 > certificate (from X2) A extracts from X1 > the X2 public key A extracts from X2 > the public key of B Summarizing: A got the chain X1 > X2 > More generally: X 1 > X 2 > …X N > Each pair must have issued certificates for each other How A (and B) find the chains?

16. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI16 Certificate Path

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

18. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI18 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

19. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI19 Trusted Root Certificates in my computer Tool: mmc

20. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI20 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

21. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI21 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

22. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI22 Bottom UP hierarchy Hierarchical namespace –Like A, A/B/X, A/B/X/Y –According to organizational structure Namespace is a forest Each node associated with a CA Each organization node issue its own certificates Each CA signs certs of children and parent –Also cross signature (links) within the forest Each certificate has a root CA A: find a cert of B: go up in forest, look for cross

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

24. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI24 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?

25. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI25 Certificate Revocation List

26. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI26 Revocation List

27. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI27 3. Appendix Storage of Secret Keys by Public Key Encryption in the EFS system of Windows XP

28. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI28 EFS: Encrypting a directory/file in WinXP Users can encrypt file, directories Encryption by DES or 3DES –Key (FEK) created during encryption

29. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI29 File Encryption in WinXP

30. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI30 Encrypting the File Encryption Key (FEK) The Operating System creates for the User a Public and Private keys –using information in the User account, including his/her password –(the keys are created once) The FEK is then encrypted by RSA using the User’s public key

31. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI31 Encrypting The File Encryption Key (FEK) The encrypted FEK is written into to the file header, in the Data Decryption Field (DDF)

32. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI32 Automatic creation of a my cert during encryption Tool: Microsoft Management Console (mmc) Certificate Snap in

33. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI33 Personal certificate

34. Prof. Reuven Aviv, Nov 2006 Public Key Cryptography and PKI34 Data Recovery Agents OS Assign Recovery Agents (e.g. admin) also have (different) private and public keys. For each RA the encrypted FEK is written into the Data Recovery Field (DRF) in the File header