1. Computer Security Key Management

2. Introduction We distinguish between a session key and an
interchange key (long term key).
The session key is a cryptographic key associated with a communication session.
The interchange key is associated with a principal to a communication.

3. Basic key exchange -- problems
With whom is Bob sharing a key?
A key cannot be transmitted in the clear
Replay attacks: Eve may highjack a session.
Alice and Bob may decide to trust a third party
Classical cryptosystems (symmetric key) and public key cryptosystems use different algorithms.

4. Classical cryptographic key exchange
C = trusted third party
C shares secret keys kA and kB with Alice and Bob
A  C: {request for ksession for Bob}kA
C  A: {ksession}kA, {ksession}kB
A  B: {ksession}kB
Now Alice and Bob share ksession .

5. Classical cryptographic key exchange –Replay attacks
Does Bob know who he is talking to?
A Replay attack
Suppose A  B: {Pay Dan $500}ksession
Then later Eve may send Bob:
E  B: {ksession}kB
E  B: {Pay Dan $500}ksession

6. Classical cryptography key exchange (Needham-Schroeder)
C = trusted third party
A  C: { A||B|| rand1 }
C  A: { A||B||rand1||ksession , {A ||ksession}kB } kA
A  B: {A ||ksession}kB
B  A: {rand2}ksession
A  B: {rand2-1}ksession
rand1 and rand2 are called nonces.

7. Classical cryptography key exchange
C = trusted third party
Eve  B: {A ||ksession}kB (replay)
B  A: {rand3}ksession (intercepted by Eve)
Eve  B: {rand3-1}ksession (intercepted reply)
Bob thinks he is talking to Alice, but he is really talking
to Eve

8. Classical cryptography key exchange (Denning-Sacco, timestamps)
C = trusted third party
A  C: { A||B|| rand1 }
C  A: { A||B||rand1||ksession , {A ||T||ksession}kB } kA
A  B: {A ||T||ksession}kB
B  A: {rand2}ksession
A  B: {rand2-1}ksession
This requires synchronized clocks.

9. Classical cryptography key exchange (Ottway-Rees)
C = trusted third party
A  B: sn,A, B, {rand1,sn,A,B}kA
B  C: sn, A, B, {rand1,sn,A,B}kA ,{rand2,sn,A,B}kB
C  B: sn, {rand1, ksession}kA , {rand2, ksession}kB
A  B: sn, {rand2, ksession}kA

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

11. Basic Kerberos A  C: A || B || NA C  A: {kAB ,B,NA}kAT || TAB
Ticket : TAB = B || {A||A’s address||valid time tA||shared key kAB}kB
tA is a timestamp from A’s clock,
kB is a key that B shares with an authentication server,
NA a nonce chosen by A,
AuthA = { A|| tA}kAB is an authenticator for A,
kAB a session key for A,B.
A  C: A || B || NA
C  A: {kAB ,B,NA}kAT || TAB
A  B: AuthA || TAB
B  A: A || {tA}kAB

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

13. Key exchange with Public Key Cryptography
First try.
A  B: { ksession }eB
This is flawed:
Eve can forge the message
In fact Bob does not know from whom this message came

14. A man-in-the-middle attack
The attacker E succeeds in convincing A that B’s
public key is eE and not eB..
A  B: request for B’s public key –intercepted by E
E  B: request for B’s public key
B  E: eB
E  A: eE
A  B: {ksession}eE -- intercepted by E
E  B: {ksession}eB

15. Key exchange with Public Key Cryptography
A fix
A  B: A, { { ksession }dA }eB
where dA is the private key of A.
Bob decrypts the received and uses the public key
of A to obtain ksession from { ksession }dA.
But how does B get to know A’s public key?
A trusted public server is needed.

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

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

18. Public Key Infrastructures Certificate signature chains
A certificate chain:
X1<< X2 >> || X2<< X3 >> || || Xn-1<< Xn >>
represents the implicit trust of X1 in Xn:
X1 trusts X2, who in turn trusts X3, who in turn trusts X3, ,
and Xn-1 trusts Xn.
PKI’s are based on implicit trust.

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

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

21. Trust graphs Root CA With a tree-graphs we have Scalable solutions
David
Bob
Carol
Alice
With a tree-graphs we have
Scalable solutions
Single point of failures

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

23. 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 <<B>>PGP
Suppose we have the following chain:
A,J <<J>>PGP || K,J,E <<E>>PGP || E,H <<H>>PGP ||
I,H,G <<G>>PGP || E,F,G,B <<B>>PGP ||
Then A PGP-trust B.
For more details see:

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

25. Merkle Authentication Tree
Let
Yi 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 (Yi ,Yij) otherwise.

26. Merkle Authenticatiomn TreeY1 Y2 Y3 Y4
The root value h(1,4) must be known and the file publicly available.

27. Merkle Authenticatiomn Tree
Suppose that Y1,Y2 ,…,Yn are items in a file, and that user 3 wants to validate Y3.
Compute:
h(3,3) = f (Y3,Y3),
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 thenY3 can be validated
(time-stamped).

28. Merkle Authentication Tree
The hashes needed to validate a certificate for Yi are
called the authentication path of that certificate.
The authentication path for Y3 is:
C3 = {Y3, h(4,4),h(1,2))}.