1. Computer Security Key Management

2. Introduction We distinguish between a session key and a interchange key ( long term key ). The session key is associated with a session ; the long term key with a principal.

3. Basic key exchange C = trusted third party A  C: {request for k session for Bob}k A C  A: {k session }k A, {k session }k B A  B: {k session }k B Now A and B share k session.

4. Basic key exchange -- problems With whom is Bob sharing a key? Replay attacks: Eve may highjack a session.

5. Classical cryptography key exchange C = trusted third party A  C: { A||B|| rand 1 } C  A: { A||B||rand 1 ||k session, {A ||k session }k B } k A A  B: {A ||k session }k B B  A: {rand 2 }k session A  B: {rand 2 -1}k session rand 1 and rand 2 are called nonces.

6. Classical cryptography key exchange Discussion on attacks. Intercept & highjack sessions, Use of Timestamps.

7. Kerberos Ticket : T AB = B || { A||A’s address||valid time||k AB ||t}k B t is a timestamp, k B is a key that B shares with an authentication server, A AB = { A||generation time}k AB is an authenticator for A. 1.A  C: A || B 2.C  A: {k AB }k A || T AB 3.A  B: G || A AB || T AB 4.B  A: A || {k AG }k AB || T AG 5.A  G: A AG ||T AG 6.G  A: {t+1}k AG

8. Kerberos Discussion. How are principals (Alice,Bob) authenticated?

9. Key exchange with Public Key Cryptography First try.  A  B: { k session }e B

10. Key exchange with Public Key Cryptography A fix  A  B: A, { { k session }d A }e B where d A is the private key of A. Bob decrypts the received and uses the public key of A to obtain k session from { k session }d A. But how does B get to know A’s key?

11. A man-in-the-middle attack The attacker E succeeds in convincing A that B’s public key is e E and not e B.. 1.A  C: request for B’s public key –intercepted by E 2.E  C: request for B’s public key 3.C  E: e B 4.E  A: e E 5.A  B: {k session }e E -- intercepted by E 6.E  B: {k session }e B (we did this attack in our Midterm 2)

12. Public Key Infrastructures the X.509 Authentication Framework X.509 is based on certificate signature chains. Certificates are digitally signed by Certifying authorities and link a Public key to its owner. See textbook for details on X.509v3 certificates.

13. Public Key Infrastructures Certificate signature chains Let X > represent a certificate that X generated for the subject Y, eg X authenticated (digitally signed) the Public Key of Y. X > represents the explicit trust that X has in (the public key of) Y (he wouldn’t otherwise certify it!).

14. Public Key Infrastructures Certificate signature chains A certificate chain: X 1 > || X 2 > ||... || X n-1 > represents the implicit trust of X 1 in X n : X 1 trusts X 2, who in turn trusts X 3, who in turn trusts X 3,..., and X n-1 trusts X n. PKI’s are based on implicit trust.

15. The structure of a PKI trust graphs A PKI is determined by its:  Certifying Authorities (CAs)  Subjects  Implicit trust relationships. The trust graph of a PKI is the graph whose nodes are the CAs and the subjects and whose edges are the explicit trust relationships. Implicit trust relationships are represented by paths in the trust graph.

16. The structure of a PKI Trust graphs  The trust graph for the X.509 PKI is essentially a graph tree, with leafs the subjects.  The root CA is called the Root of the PKI.  The X.509 PKI is scalable : the length of a trust certificate chain is logarithmic in the size of the graph.

17. Trust graphs C1 David Carol C2 Alice Bob Root CA With a tree-graphs we have 1.Scalable solutions 2.Single point of failures

18. PKIs  Forest – cross-certifying Root CAs  Other graph solutions  PGPs  Merkle Authentication Tree

19. PGP certificate chains Provides privacy for electronic mail. The public key of an entity B is certified by “friends” who know him, say E,F,G. PGP certificate for A: E,F,G > PGP Suppose we have the following chain: A,J > PGP || K,J,E > PGP || E,H > PGP || I,H,G > PGP || E,F,G,B > PGP || Then A  PGP-trust B. For more details see: http://www.cs.fsu.edu/~burmeste/ACM11temp.pdf

20. Merkle Authentication Tree Time stamping  Certificates can be kept as data in files,  This reduces the problem of forging certificates to the problem of data integrity.

21. Merkle Authentication Tree Let  Y i be an identifier and its associated public key.  f : D  D  D a function that maps pairs of bit strings to a bit string, where D is the set of bit strings.  h : N  N  D be a cryptographic hash function, where N is the set of natural numbers.  h ( i,j ) = f ( h ( i,  i+j /2  ), h (  i+j /2  +1, j ) if i < j f ( Y i, Y ij ) otherwise.

22. Merkle Authenticatiomn Tree h (1,4) Y4Y4 h (4,4) h (3,3) h (2,2) h (1,1) h (3,4) h (1,2) Y2Y2 Y3Y3 Y1Y1 The root value h (1,4) must be known and the file publicly available.

23. Merkle Authenticatiomn Tree Suppose that Y 1,Y 2,…,Y n are in a file, and that user 3 wants to validate Y 3. Compute: h (3,3) = f ( Y 3, Y 3 ), h (3,4) = f ( h (3,3), h (4,4)), (assume that h (4,4) is available) h (1,4) = f ( h (1,2), h (3,4)). (assume that h (1,2) is available) If h (1,4) is stored in a public file then Y 3 can be validated (time-stamped).

24. Merkle Authentication Tree The hashes needed to validate a certificate for Y i are called the authentication path of that certificate. The authentication path for Y 3 is: C 3 = { Y 3, h (4,4), h (1,2))}.