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 A  C: {request for ksession for Bob}kA C  A: {ksession}kA, {ksession}kB 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: E  B: {ksession}kB E  B: {Pay Dan $500}ksession

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.

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

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.

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

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

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

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.. 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 With a tree-graphs we have Scalable solutions David Bob Carol Alice With a tree-graphs we have Scalable solutions Single point of failures

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 Y1 Y2 Y3 Y4 The root value 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))}.