Computer Security
Key Management
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.
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.
Classical cryptographic key
exchange
C = trusted third party
C shares secret keys kA and kB with Alice and Bob
1. A  C: {request for ksession for Bob}kA
2. C  A: {ksession}kA, {ksession}kB
3. A  B: {ksession}kB
Now Alice and Bob share ksession .
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:
1. E  B: {ksession}kB
2. E  B: {Pay Dan $500}ksession
Classical cryptography key
exchange (Needham-Schroeder)
C = trusted third party
1. A  C: { A||B|| rand1 }
2. C  A: { A||B||rand1||ksession , {A ||ksession}kB } kA
3. A  B: {A ||ksession}kB
4. B  A: {rand2}ksession
5. A  B: {rand2-1}ksession
rand1 and rand2 are called nonces.
Classical cryptography key
exchange
C = trusted third party
1. Eve  B: {A ||ksession}kB (replay)
2. B  A: {rand3}ksession (intercepted by Eve)
3. Eve  B: {rand3-1}ksession (intercepted reply)
Bob thinks he is talking to Alice, but he is really talking
to Eve
Classical cryptography key exchange
(Denning-Sacco, timestamps)
C = trusted third party
1. A  C: { A||B|| rand1 }
2. C  A: { A||B||rand1||ksession , {A ||T||ksession}kB } kA
3. A  B: {A ||T||ksession}kB
4. B  A: {rand2}ksession
5. A  B: {rand2-1}ksession
This requires synchronized clocks.
Classical cryptography key exchange
(Ottway-Rees)
C = trusted third party
1. A  B: sn,A, B, {rand1,sn,A,B}kA
2. B  C: sn, A, B, {rand1,sn,A,B}kA ,{rand2,sn,A,B}kB
3. C  B: sn, {rand1, ksession}kA , {rand2, ksession}kB
4. A  B: sn, {rand2, ksession}kA
Classical cryptography key
exchange
Discussion on attacks.
Intercept & highjack sessions,
Use of Timestamps.
Basic Kerberos
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.
1.
2.
3.
4.
A  C:
C  A:
A  B:
B  A:
A || B || NA
{kAB ,B,NA}kAT || TAB
AuthA || TAB
A || {tA}kAB
Kerberos
Discussion.
How are principals (Alice,Bob) authenticated?
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
A man-in-the-middle attack
The attacker E succeeds in convincing A that B’s
public key is eE and not eB..
1.
2.
3.
4.
5.
6.
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
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.
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.
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!).
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.
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.
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.
Trust graphs
Root CA
C2
C1
Alice
Bob Carol
With a tree-graphs we have
1. Scalable solutions
2. Single point of failures
David
PKIs
 Forest – cross-certifying Root CAs
 Other graph solutions
 PGPs
 Merkle Authentication Tree
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: http://www.cs.fsu.edu/~burmeste/ACM11temp.pdf
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.
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.

Merkle Authenticatiomn Tree
h(1,4)
h(1,2)
h(1,1)
Y1
The root value
h(3,4)
h(2,2) h(3,3)
Y2
Y3
h(4,4)
Y4
h(1,4) must be known and the file publicly available.
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).
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))}.