cns2010handout 12 :: crypto protocols1 elec5616 computer and network security matt barrie...
Post on 01-Apr-2015
225 Views
Preview:
TRANSCRIPT
CNS2010 handout 12 :: crypto protocols 1
ELEC5616computer and network
securitymatt barrie
mattb@ee.usyd.edu.au
CNS2009 handout 12 :: crypto protocols 2
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
“hello I’m Alice”
gb mod p
gx mod p
Session key = h(gbx mod p)
Eve owns the channel!
CNS2009 handout 12 :: crypto protocols 3
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”)
Eve owns the channel!
CNS2009 handout 12 :: crypto protocols 4
session hijacking
• Problem:
Eve owns the channel!
Alice Bob
“hello I’m Alice”
nonce r
signA(r) verify signature
pick random r
Eve
“thanks guys, I’ll take it from here”
CNS2009 handout 12 :: crypto protocols 5
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)
CNS2009 handout 12 :: crypto protocols 6
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)
CNS2009 handout 12 :: crypto protocols 7
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
CNS2009 handout 12 :: crypto protocols 8
needham-schroeder protocol
• 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
CNS2009 handout 12 :: crypto protocols 9
needham-schroeder protocol
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).
CNS2009 handout 12 :: crypto protocols 10
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
CNS2009 handout 12 :: crypto protocols 11
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
CNS2009 handout 12 :: crypto protocols 12
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)
CNS2009 handout 12 :: crypto protocols 13
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
CNS2009 handout 12 :: crypto protocols 14
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
CNS2009 handout 12 :: crypto protocols 15
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
CNS2009 handout 12 :: crypto protocols 16
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)
CNS2009 handout 12 :: crypto protocols 17
references
• Handbook of Applied Cryptography– Read § 12 - 12.3.2 (ii)
• Stallings– §11
top related