cns2010handout 12 :: crypto protocols1 elec5616 computer and network security matt barrie...

CNS2010 handout 12 :: crypto protocols 1

ELEC5616computer and network

securitymatt barrie

[email protected]


man in the middle

• Problem: (Diffie-Hellman)

Alice Bob

“hello I’m Alice”

gx mod p

ga mod p

Session key = h(gax mod p)

Eve


gb mod p

gx mod p

Session key = h(gbx mod p)

Eve owns the channel!


man in the middle

• Problem: (Key Exchange with Public Key Crypto)

Alice Bob

“Alice”, eA

eY(“launch missiles at Eve”)

Eve

“Bob”, eB

“Alice”, eX“Bob”, eY

eB(“disarm missile system”)



session hijacking

• Problem:


Alice Bob


nonce r

signA(r) verify signature

pick random r

Eve

“thanks guys, I’ll take it from here”


EKE - encrypted key exchange

• Alice and Bob share a secret key k

• A (possibly low entropy) shared secret k is used to form a high entropy shared secret h(gxy)

• Prevents eavesdropping• Prevents an active attack on Diffie-Hellman• Forward secrecy• What’s the obvious problem?

Alice Bob

“hello”

Ek[gx mod p]

random y

random x

Ek[gy mod p]

Session key = h(gxy mod p)


definitions

• A protocol is said to have perfect forward secrecy if disclosure of long term keys does not compromise past (short term) session keys.

• A protocol is vulnerable to a known-key attack if disclosure of past session keys allows an attacker to compromise future session keys (including actively impersonating)


needham-schroeder protocol

(key exchange with TTP)• Alice and Bob want to setup a session key for communications.

– We will denote encryption of m by key k as {m}k

• All parties share a key with Trent, a trusted third party.

Alice → Trent: “A”, “B”, rA

– Alice asks Trent to talk to Bob (rA is a nonce)

Trent → Alice: {rA, “B”, KAB, {KAB, “A”}KBT}KAT

– Trent sends Alice a session key and ticket to give Bob

Alice → Bob: {KAB, “A”}KBT, {rA2}KAB

– Alice sends to Bob the ticket (session key)

Bob → Alice: {rA2-1, rB}KAB

– Bob challenges Alice (rB is a nonce)

Alice → Bob: {rB - 1}KAB

– Alice responds



• Question: What happens if Eve gets a hold of KAT somehow?

Alice → Trent: “A”, “B”, rA

Trent → Alice: {rA, “B”, KAB, {KAB, “A”}KBT}KAT

Alice → Bob: {KAB, “A”}KBT, {rA2}KAB

Bob → Alice: {rA2-1, rB}KAB

Alice → Bob: {rB - 1}KAB



Problem:

• Bob has no guarantee KAB is fresh (new)– Old session keys are valuable as they do not expire

• If Eve manages to get KAT she can read all of Alice’s messages and impersonate her to everyone else (e.g Carol).

• Alice informs everyone she has been issued a key for to revoke it.

• Since Alice does not know if Eve impersonated her to someone she has never talked to (e.g. Carol), she has to get Trent to tell everyone “stop using all shared keys with Alice”

• Thus key revocation is a major problem.• Needham-Shroeder’s problem is that it assumes all users of

the system are good guys and the goal is to keep bad guys from getting in (“eggshell model”)– This is the ‘old school’ model of security. It has been realised today that the

most likely threats come from within (knowledgeable insiders).


kerberos (MIT/windows 2000)

• Extension of Needham-Schroeder• Two trusted servers

– Authentication server to which users log on– Ticket granting server issues tickets (timed keys) to resources

• Allows scalable access management– users managed differently to resource access– e.g. university handles enrolments but departments handle access to

facilities• Uses timestamps (T) with a lifetime (L) instead of nonces

– fixes Needham-Schroeder problem with freshness

A and T share key KAT via the authentication server (by password)

Alice → Trent: “A”, “B”Trent → Alice: {TT, L, KAB, “B”, {TT, L, KAB, “A”}KBT

}KAT

Alice → Bob: {TT, L, KAB, “A”}KBT, {“A”, TA}KAB

Bob → Alice: {TA+1}KAB


kerberos

Alice and Trent share key KAT via the authentication server

– Alice asks Trent for a ticket to talk to Bob

Alice → Trent: A, B

– Trent gives Alice a ticket (session key KAB with lifetime L from timestamp TT) and a ticket encrypted for Bob with KBT

Trent → Alice: {TT, L, KAB, B, {TT, L, KAB, A}KBT}KAT

– Alice gives Bob the encrypted ticket and a challenge

Alice → Bob: {TT, L, KAB, A}KBT, {A, TA}KAB

– Bob sends back the timestamp incremented by one to indicate he is alive and managed to decrypt the ticket.

Bob → Alice: {TA+1}KAB


problems with kerberos

Problems:

• The key KAT from the authentication server is protected only by a password– we know humans pick these poorly– facilitates a dictionary attack – packet format from authentication server is in a known format

• makes a dictionary attack easy as we can verify a valid result

• Alice, Bob and Trent’s clocks need to be synchronised– If the sender’s clock is ahead of receiver’s clock, Eve can intercept a

message from the sender and play it later when the timestamp is valid at the receiver (suppress-replay attack)

• Desynchronisation can be used as part of many attacks (including denial-of-service)


public key management using

certification authorities• A public key certificate binds a public key to its owner:

– Alice sends her public key to the CA (Trent)– The CA produces a certificate for Alice– Alice sends her public key and certificate to Bob– Bob verifies the certificate using Alice’s public key– Bob sends encrypted messages to Alice using the key

signCA[X.500: name, organisation, address, public key, expires …]

• Everyone must be able to verify the CA’s public key– shipped with browsers, OS, published in the Australian

• The CA is a trusted party - it can forge keys / signatures.

• An example is the X.509 certificate for X.500 directory services

certificate


trust models

• Symmetric keys– TTP must be online (used every session)– TTP is a juicy target (knows passwords)– No forward secrecy – Fast (e.g. Kerberos)

• Asymmetric keys– TTP is offline (only used in key generation)– TTP only knows public keys– TTP has forward secrecy– Not as fast (e.g. SSL/TLS, PGP, SET)

KDCAlice Bob

Carol

Dave

CAAlice

Bob

CarolDave


public key certificate generation

• Alice generates a public/private key pair• Alice sends the public key to the CA• The CA challenges Alice to see if she knows the private key• The CA generates a certificate and sends it to Alice

Note: • The CA never learns Alice’s private key

– Important for forward secrecy


certificate revocation

• Alice’s certificate may need to be revoked– Her private key is stolen– She changes jobs

• This is a major problem and is done in limited ways:– Through users requiring daily certification-validation information (slow,

cumbersome)– Use expiration date field– Use of a certificate revocation list (CRL) which is circulated (like bad

credit cards)


references

• Handbook of Applied Cryptography– Read § 12 - 12.3.2 (ii)

• Stallings– §11

cns2010handout 12 :: crypto protocols1 elec5616 computer and network security matt barrie...

Documents