Real-World Protocols II
CS 3IS3
Ryszard Janicki
Department of Computing and Software, McMaster University, Hamilton, Ontario, Canada
Acknowledgments: Material based on Information Security by Mark Stamp (Chapters 10.5-10.6)
Ryszard Janicki
Real-World Protocols II 1/21
Kerberos and Its Motivation
In Greek mythology, Kerberos is 3-headed dog that guards entrance to Hades
In security, Kerberos is an authentication protocol based on symmetric key cryptography
Originated at MIT
Based on Needham and Schroeder protocol Relies on a Trusted Third Party (TTP)
Authentication using public keys N users =⇒ N key pairs
Authentication using symmetric keys
N users requires (on the order of) N2 keys
Symmetric key case does not scale
Kerberos is based on symmetric keys but only requires N keys for N users
– Security depends on TTP
+ No PKI (Public Key Infrastructure) is needed
Ryszard Janicki
Real-World Protocols II 2/21
Kerberos KDC
Kerberos Key Distribution Center or KDC KDC acts as the TTP (Trusted Third Party) TTP is trusted, so it must not be compromised
KDC shares symmetric key KA with Alice, key KB with Bob, key KC with Carol, etc.
And a master key KKDC known only to KDC KDC enables authentication, session keys
Session key for confidentiality and integrity
In practice, cryptographic algorithm algorithm is DES (Data Encription Standard)
Ryszard Janicki
Real-World Protocols II 3/21
Kerberos Tickets
KDC issue tickets containing information needed to access network resources
KDC also issues Ticket-Granting Tickets or TGTs that are used to obtain tickets
Each TGT contains
Session key User’s ID Expiration time
Every TGT is encrypted with KKDC
So, TGT can only be read by the KDC
Ryszard Janicki
Real-World Protocols II 4/21
Kerberized Login
Alice enters her password
Then Alice’s computer does following:
Derives KA from Alice’s password
Uses KA to get TGT for Alice from KDC
Alice then uses her TGT (credentials) to securely access
Plus: Security is transparent to Alice Kerberized Login
Minus: KDC must be secure – it is trusted!
network resources
Alice’s password
Alice wants a TGT
E(SA,TGT,KA)
Alice
Computer
KDC
Key K = h(Alice’s password) Key KA = hA(Alice’s password)
KDC KcrDeCatcersesaetsessiosneskseiyonSkey S AA
Alice’s computer decryApts S
Then it forgets K
o Then it forgets K
and TGT
Alice’s computer decrypts S and TGT
TGT=E(“Alice”,S ,K ) A KDC
TGT = E(“Alice”, S , K ) A KDC
AA
A
Part 3 Protocols
Ryszard Janicki
Real-World Protocols II 136 5/21
Alice Requests “Ticket to Bob”
Alice Requests “Ticket to Bob”
Talk to Bob
I want to talk to Bob
REQUEST REPLY
Computer KDC
Alice
REQQUUESETST= =(T(GTTG,Ta,utahuenthtiecantoicr )ator) oaauuththeenntitcicaatotorr=E(tiimestamp,SA)
REPLY = E (“Bob”, K , ticket to Bob, S )
REPLY = E(“Bob”, AKB , ticket to BobA, S )
ticket to Bob = E(“Alice”,K ,K ) AB B
o ticket to Bob = E(“Alice”, K , K ) AB B
A
AB A
KDC gets S from TGT to verify timestamp
KDC getsAS from TGT to verify timestamp
Part 3 Protocols
137
A
Ryszard Janicki
Real-World Protocols II 6/21
Alice Uses Ticket to Bob
Alice Uses Ticket to Bob
ticket to Bob, authenticator E(timestamp + 1, KAB)
Alice’s Computer
Bob
ticket to Bob = E(“Alice”,K ,K ) AB B
ticket to Bob = E(“Alice”, K , K ) AB B
authenticator = E(timestamp,KAB)
authenticator = E(timestamp, KAB)
Bob decrypts “ticket to Bob” to get KAB which he then uses Bobtdoevcerrifyptitmses“tatimcpkettoBob”togetKAB whichhe
then uses to verify timestamp
Part 3 Protocols 138
Ryszard Janicki
Real-World Protocols II 7/21
Kerberized Properties
Key SA is used in authentication For confidentiality/integrity
Timestamps are used for authentication and replay protection Recall, that timestamps. . .
Reduce the number of messages – like a nonce that is known in advance
But, “time” is a security-critical parameter
When Alice logs in, KDC sends E(SA,TGT,KA) where TGT = E (“Alice”, SA , KKDC )
Question: Why is TGTencrypted with KA?
Answer: Enables Alice to be anonymous when she later uses her TGT to request a ticket
Ryszard Janicki
Real-World Protocols II 8/21
Kerberos Alternatives
Could have Alice’s computer remember password and use that for authentication?
Then no KDC required
But hard to protect passwords Also, does not scale
Could have KDC remember session key instead of putting it in a TGT?
Then no need for TGT
But stateless KDC is major feature of Kerberos
Ryszard Janicki
Real-World Protocols II 9/21
Kerberos Keys
In Kerberos, KA = h(Alice’s password) Could instead generate random KA?
Compute Kh = h(Alice’s password) And Alice’s computer stores E(KA,Kh)
Then KA need not change when Alice changes her password! But E(KA,Kh) must be stored on computer
This alternative approach is often used But not in Kerberos
Ryszard Janicki
Real-World Protocols II 10/21
WEP
WEP – Wired Equivalent Privacy
The stated goal of WEP is to make wireless LAN as secure
as a wired LAN
According to Tanenbaum (networks guru):
“The 802.11 standard prescribes a data link-level security
protocol called WEP (Wired Equivalent Privacy), which is designed to make the security of a wireless LAN as good as that of a wired LAN. Since the default for a wired LAN is no security at all, this goal is easy to achieve, and WEP achieves it as we shall see.”
Ryszard Janicki
Real-World Protocols II 11/21
WEP Authentication
WEP Authentication
Bob is wireless access point
Bob is wireless access point
Authentication Request R
E(R, K)
Alice, K
Bob, K
Key K shared by access point and all users
Key K shared by access point and all users
Key K seldom (if ever) changes
o Key K seldom (if ever) changes
WEP has many, many, many security flaws
WEP has many, many, many security flaws Part 3 Protocols 145
Ryszard Janicki
Real-World Protocols II 12/21
WEP Issues
WEP uses RC4 cipher for confidentiality RC4 can be a strong cipher
But WEP introduces a subtle flaw. . .
. . . making cryptanalytic attacks feasible
WEP uses CRC (Clock redundancy Check) for “integrity” Should have used a MAC (Message Authentication Code),
HMAC (Hashed MAC), or similar
CRC is for error detection, not crypto integrity Everyone should know NOT to use CRC here. . .
Ryszard Janicki
Real-World Protocols II 13/21
WEP Integrity Problems
WEP “integrity” gives no cryptographical integrity CRC is linear, so is stream cipher (XOR)
Trudy can change ciphertext and CRC so that checksum on plaintext remains valid
Then Trudy’s introduced changes go undetected
Requires no knowledge of the plaintext!
CRC does not provide a cryptographic integrity check
CRC designed to detect random errors Not to detect intelligent changes
Ryszard Janicki
Real-World Protocols II 14/21
More WEP Integrity Issues
Suppose Trudy knows destination IP (Internet Protocol address)
Then Trudy also knows keystream used to encrypt IP address, since
C = destination IP address ⊕ keystream Then Trudy can replace C with
C’ = Trudy’s IP address ⊕ keystream And change the CRC so no error detected Moral: Big problems when integrity fails
Ryszard Janicki
Real-World Protocols II 15/21
WEP Key
Recall WEP uses a long-term key K
RC4 is a stream cipher, so each packet must be encrypted using a different key
Initialization Vector (IV ) sent with packet Sent in the clear, that is, IV is not secret
Actual RC4 key for packet is (IV,K)
That is, IV is pre-pended to long-term key K
Ryszard Janicki
Real-World Protocols II 16/21
WEP Encryption
K =(IV,K) IV
WEP Encryption
IV, E(packet,KIV)
Alice, K
Bob, K
K =(IV,K)
IV That is, RC4 key is K with 3-byte IV pre-pended
o That is, RC4 key is K with 3-byte IV pre-pended The IV is known to Trudy
The IV is known to Trudy
Part 3 Protocols 150
Ryszard Janicki
Real-World Protocols II 17/21
WEP IV Issues
WEP uses 24-bit (3 byte) IV
Each packet gets its own IV
Key: IV pre-pended to long-term key, K
Long term key K seldom changes
If long-term key and IV are same, then same keystream is used
This is bad, bad, really really bad!
Assume 1500 byte packets, 11 Mbps link
Suppose IV s generated in sequence
Since 1500 · 8/(11 · 106) · 224 = 18000 seconds, an IV
repeat in about 5 hours of traffic Suppose IV s generated at random
By birthday problem, some IV repeats in seconds Again, repeated IV (with same K) is bad
Ryszard Janicki
Real-World Protocols II 18/21
Another Active Attack
Suppose Trudy can insert traffic and observe corresponding ciphertext
Then she knows the keystreamfor some IV She can decrypt any packet that uses that IV
If Trudy does this many times, she can then decrypt data for lots of IVs
Remember,I Vis sent in the clear Not easy but feasible
Ryszard Janicki
Real-World Protocols II 19/21
Cryptanalytic Attack
WEP data encrypted using RC4
Packet key is IV with long-term key K 3-byte IV is pre-pended to K
Packet key is (IV,K)
Recall IV is sent in the clear (not secret)
New IV sent with every packet
Long-term key K seldom changes (maybe never)
So Trudy always knows IV and ciphertext Trudy wants to find the key K
3-byte IV pre-pended to key Denote the RC4 key bytes. . .
… as K0,K1,K2,K3,K4,K5,…
Where IV = (K0, K1, K2), which Trudy knows Trudy wants to find K = (K3,K4,K5,…)
Given enough IV s, Trudy can easily find key K Regardless of the length of the key
Provided Trudy knows first keystreambyte
Known plaintext attack (1st byte of each packet) Prevent by discarding first 256 keystream bytes
Ryszard Janicki
Real-World Protocols II 20/21
WEP Conclusions
Many attacks are practical
Attacks have been used to recover keys and break real WEP traffic
How to prevent these attacks?
Don’t use WEP
Good alternatives: WPA, WPA2, etc.
How to make WEP a little better?
Restrict MAC addresses, don’t broadcast ID, . . . , all rather art than science
Ryszard Janicki
Real-World Protocols II 21/21