Part III: Protocols

Part 3  Protocols
1
 Protocol
 Human protocols  the rules followed in
human interactions
o Example: Asking a question in class
 Networking protocols  rules followed in
networked communication systems
o Examples: HTTP, FTP, etc.
 Security protocol  the
(communication) rules followed in a
security application
o Examples: SSL, IPSec, Kerberos, etc.
Part 3  Protocols
2
 Protocols
 Protocol flaws can be very subtle
 Several well-known security
protocols have significant flaws
o Including WEP,WPA2/3, GSM, and
IPSec
 Implementation errors can also
occur
o Recently, IE implementation of SSL
 Not easy to get protocols right…
Part 3  Protocols
3
 Ideal Security Protocol
 Must satisfy security requirements
o Requirements need to be precise
 Efficient
o Minimize computational requirement
o Minimize bandwidth usage, delays…
 Robust
o Works when attacker tries to break it
o Works if environment changes (slightly)
 Easy to implement, easy to use,
flexible…
 Difficult to satisfy all of these!
Part 3  Protocols
4
 Chapter 10:
Real-World Protocols
The wire protocol guys don't worry about security because that's really
a network protocol problem. The network protocol guys don't
worry about it because, really, it's an application problem.
The application guys don't worry about it because, after all,
they can just use the IP address and trust the network.
 Marcus J. Ranum

In the real world, nothing happens at the right place at the right time.
It is the job of journalists and historians to correct that.
 Mark Twain

Part 2  Access Control

5
 Real-World Protocols
 Next, we look at real protocols
o SSH  relatively simple & useful protocol
o SSL  practical security on the Web
o IPSec  security at the IP layer
o Kerberos  symmetric key, single sign-on
o WEP  “Swiss cheese” of security
protocols
o GSM  mobile phone (in)security
Part 3  Protocols
6
 Secure Shell (SSH)

Part 3  Protocols
7
 SSH
 Creates a “secure tunnel”
 Insecure command sent thru SSH
“tunnel” are then secure
 SSH used with things like rlogin
o Why is rlogin insecure without SSH?
o Why is rlogin secure with SSH?
 SSH is a relatively simple protocol

Part 3  Protocols
8
 SSH
 SSH authentication can be based
on:
o Public keys, or
o Digital certificates, or
o Passwords
 Here, we consider certificate
mode
o Other modes in homework problems
 We consider slightly simplified
Part 3  Protocols
9
 Simplified SSH
Alice, CP, RA
CS, RB
ga mod p
gb mod p, certificateB, SB
Alice E(Alice, certificateA, SA, K) Bob

 CP = “crypto proposed”, and CS = “crypto selected”

 H = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gb mod p,gab
mod p)
 SB = [H]Bob
 SA = [H, Alice, certificateA]Alice
 KPart=
10
3 gProtocols
ab
mod p
 MiM Attack on SSH?
Alice, RA Alice, RA
RB RB
ga mod p gt mod p
gt mod p, certB, SB gb mod p, certB, SB
Alice E(Alice,certA,SA,K) Trudy E(Alice,certA,SA,K) Bob

 Where does this attack fail?

 Alice computes
Ha = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gt mod p,gat mod p)
 But Bob signs
Hb = h(Alice,Bob,CP,CS,RA,RB,gt mod p,gb mod p,gbt mod p)

Part 3  Protocols
11
 Secure Socket Layer

Part 3  Protocols
12
 Socket layer
 “Socket
layer” lives Socket application User
between “layer”
application transport
OS
and transport
network
layers
 SSL usually link
NIC
between
physical
HTTP and
TCP
Part 3  Protocols
13
 What is SSL?
 SSL is the protocol used for majority of
secure Internet transactions today
 For example, if you want to buy a book
at amazon.com…
o You want to be sure you are dealing with
Amazon (authentication)
o Your credit card information must be
protected in transit (confidentiality and/or
integrity)
o As long as you have money, Amazon does
not really care who you are…
o …so, no need for mutual authentication
Part 3  Protocols
14
 Simple SSL-like Protocol
I’d like to talk to you securely

Here’s my certificate
{K}Bob

Alice protected HTTP Bob

 Is Alice sure she’s talking to Bob?

 Is Bob sure he’s talking to Alice?

Part 3  Protocols
15
 Simplified SSL Protocol
Can we talk?, cipher list, RA
certificate, cipher, RB
{S}Bob, E(h(msgs,CLNT,K),K)
h(msgs,SRVR,K)
Alice Data protected with key K Bob

 S is the so-called pre-master secret

 K = h(S,R ,R )
A B
 “msgs” means all previous messages
 CLNT and SRVR are constants

Part 3  Protocols
16
 SSL Keys
6 “keys” derived from K = h(S,RA,RB)
o 2 encryption keys: client and server
o 2 integrity keys: client and server
o 2 IVs: client and server
o Why different keys in each direction?
 Q: Why is h(msgs,CLNT,K) encrypted?
 A: Apparently, it adds no security…

Part 3  Protocols
17
 SSL Authentication
 Alice authenticates Bob, not vice-versa
o How does client authenticate server?
o Why would server not authenticate client?
 Mutual authentication is possible: Bob
sends certificate request in message
2
o Then client must have a valid certificate
o But, if server wants to authenticate client,
server could instead require password
Part 3  Protocols
18
 SSL MiM Attack?
RA RA
certificateT, RB certificateB, RB
{S1}Trudy,E(X1,K1) {S2}Bob,E(X2,K2)
h(Y1,K1) h(Y2,K2)
Alice E(data,K1) Trudy E(data,K2) Bob
 Q: What prevents this MiM “attack”?
 A: Bob’s certificate must be signed by a
certificate authority (CA)
 What does browser do if signature not valid?
 What does user do when browser complains?
Part 3  Protocols
19
 SSL Sessions vs
Connections
 SSL session is established as shown on
previous slides
 SSL designed for use with HTTP 1.0
 HTTP 1.0 often opens multiple
simultaneous (parallel) connections
o Multiple connections per session
 SSL session is costly, public key
operations
 SSL has an efficient protocol for opening
new connections given an existing
Partsession
3  Protocols
20
 SSL Connection
session-ID, cipher list, RA
session-ID, cipher, RB,
h(msgs,SRVR,K)
h(msgs,CLNT,K)

Alice Protected data Bob

 Assuming SSL session exists
 So, S is already known to Alice and Bob
 Both sides must remember session-ID
 Again, K = h(S,RA,RB)
No public key operations! (relies on
Part 3known
 Protocols S)
21
 SSL vs IPSec
 IPSec  discussed in next section
o Lives at the network layer (part of the OS)
o Encryption, integrity, authentication, etc.
o Is overly complex, has some security “issues”
 SSL (and IEEE standard known as TLS)
o Lives at socket layer (part of user space)
o Encryption, integrity, authentication, etc.
o Relatively simple and elegant specification

Part 3  Protocols
22
 SSL vs IPSec
 IPSec: OS must be aware, but not apps
 SSL: Apps must be aware, but not OS
 SSL built into Web early-on (Netscape)
 IPSec often used in VPNs (secure tunnel)
 Reluctance to retrofit applications for SSL
 IPSec not widely deployed (complexity,
etc.)
 The bottom line?
 Internet less secure than it could be!
Part 3  Protocols
23
 IPSec

Part 3  Protocols
24
 IPSec and SSL
 IPSec lives at
the network application User
layer SSL
 IPSec is transport
OS
transparent IPSec network
to
applications link
NIC

physical

Part 3  Protocols
25
 IPSec and Complexity
 IPSec is a complex protocol
 Over-engineered
o Lots of (generally useless) features
 Flawed  Some significant security issues
 Interoperability is serious challenge
o Defeats the purpose of having a standard!
 Complex
 And, did I mention, it’s complex?

Part 3  Protocols
26
 IKE and ESP/AH
 Two parts to IPSec…
 IKE: Internet Key Exchange
o Mutual authentication
o Establish session key
o Two “phases”  like SSL session/connection
 ESP/AH
o ESP: Encapsulating Security Payload  for
confidentiality and/or integrity
o AH: Authentication Header  integrity only

Part 3  Protocols
27
 IKE

Part 3  Protocols
28
 IKE
 IKE has 2 phases
o Phase 1  IKE security association (SA)
o Phase 2  AH/ESP security association
 Phase 1 is comparable to SSL session
 Phase 2 is comparable to SSL
connection
 Not an obvious need for two phases in
IKE
o In the context of IPSec, that is
 If multiple Phase 2’s do not occur, then
Partit
3 is more costly to have two phases!
Protocols
29
 IKE Phase 1
 4 different “key options”
o Public key encryption (original version)
o Public key encryption (improved version)
o Public key signature
o Symmetric key
 For each of these, 2 different “modes”
o Main mode and aggressive mode
 There are 8 versions of IKE Phase
1!
 Need more evidence it’s over-
Partengineered?
3  Protocols
30
 IKE Phase 1
 We discuss 6 of the 8 Phase 1 variants
o Public key signatures (main & aggressive
modes)
o Symmetric key (main and aggressive
modes)
o Public key encryption (main and aggressive)
 Why public key encryption and public
key signatures?
o Always know your own private key
o May not (initially) know other side’s public
Part 3  Protocols
31
key
 IKE Phase 1
 Uses ephemeral Diffie-Hellman to
establish session key
o Provides perfect forward secrecy (PFS)
 Let a be Alice’s Diffie-Hellman exponent
 Let b be Bob’s Diffie-Hellman exponent
 Let g be generator and p prime
 Recall that p and g are public

Part 3  Protocols
32
 IKE Phase 1: Digital Signature
(Main Mode)
IC, CP
IC,RC, CS
IC,RC, ga mod p, RA
IC,RC, gb mod p, RB
IC,RC, E(“Alice”, proofA, K)
Alice IC,RC, E(“Bob”, proofB, K) Bob

 CP = crypto proposed, CS = crypto selected

 IC = initiator “cookie”, RC = responder “cookie”
 K = h(IC,RC,gab mod p,R ,R )
A B
 SKEYID = h(R , R , gab mod p)
A B
 proof = [h(SKEYID,ga mod p,gb mod
A

33
p,IC,RC,CP,“Alice”)]
Part 3  Protocols
Alice
 IKE Phase 1: Public Key
Signature (Aggressive Mode)
IC, “Alice”, ga mod p, RA, CP
IC,RC, “Bob”, RB,
gb mod p, CS, proofB
IC,RC, proofA
Alice Bob

 Main differences from main mode

o Not trying to hide identities
o Cannot negotiate g or p

Part 3  Protocols
34
 Main vs Aggressive Modes
 Main mode MUST be implemented
 Aggressive mode SHOULD be
implemented
o So, if aggressive mode is not implemented,
“you should feel guilty about it”
 Might create interoperability issues
 For public key signature authentication
o Passive attacker knows identities of Alice
and Bob in aggressive mode, but not in main
mode
o Active attacker can determine Alice’s and
Bob’s identity in main mode
Part 3  Protocols
35
 IKE Phase 1: Symmetric Key
(Main Mode)
IC, CP
IC,RC, CS
IC,RC, ga mod p, RA
IC,RC, gb mod p, RB
IC,RC, E(“Alice”, proofA, K)
Alice Bob
KAB IC,RC, E(“Bob”, proofB, K) KAB
 Same as signature mode except
o KAB = symmetric key shared in advance
o K = h(IC,RC,gab mod p,RA,RB,KAB)
o SKEYID = h(K, gab mod p)
o proofA = h(SKEYID,ga mod p,gb mod
p,IC,RC,CP,“Alice”)
Part 3  Protocols
36
 Problems with Symmetric
Key (Main Mode)
 Catch-22
o Alice sends her ID in message 5
o Alice’s ID encrypted with K
o To find K Bob must know KAB
o To get KAB Bob must know he’s talking to
Alice!
 Result: Alice’s IP address used as ID!
 Useless mode for the “road warrior”
 Why go to all of the trouble of trying to
hide identities in 6 message protocol?
Part 3  Protocols
37
 IKE Phase 1: Symmetric Key
(Aggressive Mode)
IC, “Alice”, ga mod p, RA, CP

IC,RC, “Bob”, RB,

gb mod p, CS, proofB
IC,RC, proofA
Alice Bob

 Same format as digital signature aggressive

mode
 Not trying to hide identities…
 As a result, does not have problems of main
mode
Part 3  Protocols
38 But does not (pretend to) hide identities

 IKE Phase 1: Public Key
Encryption (Main Mode)
IC, CP
IC,RC, CS
IC,RC, ga mod p, {RA}Bob, {“Alice”}Bob

IC,RC, gb mod p, {RB}Alice, {“Bob”}Alice

IC,RC, E(proofA, K)
Alice IC,RC, E(proofB, K) Bob

 CP = crypto proposed, CS = crypto selected

 IC = initiator “cookie”, RC = responder “cookie”
 K = h(IC,RC,gab mod p,R ,R )
A B
 SKEYID = h(R , R , gab mod p)
A B
 proof = h(SKEYID,ga mod p,gb mod
A
Part 3  Protocols
39 p,IC,RC,CP,“Alice”)
 IKE Phase 1: Public Key
Encryption (Aggressive
Mode)
IC, CP, ga mod p,
{“Alice”}Bob, {RA}Bob
IC,RC, CS, gb mod p,
{“Bob”}Alice, {RB}Alice, proofB

IC,RC, proofA
Alice Bob
 K, proofA, proofB computed as in main
mode
 Note that identities are hidden
o The only aggressive mode to hide identities
o So, why have a main mode?
Part 3  Protocols
40
 Public Key Encryption
Issue?
 In public key encryption, aggressive
mode…
 Suppose Trudy generates
o Exponents a and b
o Nonces RA and RB
 Trudy can compute “valid” keys and
proofs: gab mod p, K, SKEYID, proofA
and proofB
 All of this also works in main mode
Part 3  Protocols
41
 Public Key Encryption
Issue?
IC, CP, ga mod p,
{“Alice”}Bob, {RA}Bob
IC,RC, CS, gb mod p,
{“Bob”}Alice, {RB}Alice, proofB
Trudy IC,RC, proofA Trudy
(as Alice) (as Bob)

 Trudy can create messages that appears

to be between Alice and Bob
 Appears valid to any observer,
including Alice and Bob!
Part 3  Protocols
42
 Plausible Deniability
 Trudy can create fake “conversation”
that appears to be between Alice and
Bob
o Appears valid, even to Alice and Bob!
 A security failure?
 In IPSec public key option, it is a
feature…
o Plausible deniability: Alice and Bob can
deny that any conversation took place!
 In some cases it might create a problem
o E.g., if Alice makes a purchase from Bob,
she could later repudiate it (unless she had
Part 3  Protocols
43
signed)
 IKE Phase 1 “Cookies”
 IC and RC  cookies (or “anti-clogging
tokens”) supposed to prevent DoS attacks
o No relation to Web cookies
 To reduce DoS threats, Bob wants to
remain stateless as long as possible
 But Bob must remember CP from
message 1 (required for proof of identity
in message 6)
 Bob must keep state from 1st message on
o So, these “cookies” offer little DoS protection
Part 3  Protocols
44
 IKE Phase 1 Summary
 Result of IKE phase 1 is
o Mutual authentication
o Shared symmetric key
o IKE Security Association (SA)
 But phase 1 is expensive
o Especially in public key and/or main mode
 Developers of IKE thought it would be
used for lots of things  not just IPSec
o Partly explains the over-engineering…

Part 3  Protocols
45
 IKE Phase 2
 Phase 1 establishes IKE SA
 Phase 2 establishes IPSec SA
 Comparison to SSL…
o SSL session is comparable to IKE Phase 1
o SSL connections are like IKE Phase 2
 IKE could be used for lots of things, but
in practice, it’s not!

Part 3  Protocols
46
 IKE Phase 2
IC, RC, CP, E(hash1,SA,RA,K)

IC, RC, CS, E(hash2,SA,RB,K)

IC, RC, E(hash3,K)

Alice Bob
 Key K, IC, RC and SA known from Phase 1
 Proposal CP includes ESP and/or AH
 Hashes 1,2,3 depend on SKEYID, SA, RA and RB
 Keys derived from KEYMAT = h(SKEYID,RA,RB,junk)
 Recall SKEYID depends on phase 1 key method
 Optional PFS (ephemeral Diffie-Hellman exchange)
Part 3  Protocols
47
 IPSec
 After IKE Phase 1, we have an IKE SA
 After IKE Phase 2, we have an IPSec SA
 Authentication completed and have a
shared symmetric key (session key)
 Now what?
o We want to protect IP datagrams
o But what is an IP datagram?
o From the perspective of IPSec…

Part 3  Protocols
48
 IP Review
 IP datagram is of the form

IP header data

 Where IP header is

Part 3  Protocols
49
 IP and TCP
 Consider Web traffic, for example
o IP encapsulates TCP and…
o …TCP encapsulates HTTP

IP header data

IP header TCP hdr HTTP hdr app data

 IP data includes TCP header, etc.
Part 3  Protocols
50
 IPSec Transport Mode
 IPSec Transport Mode
IP header data

IP header IPSec header data

 Transport mode designed for host-to-

host
 Transport mode is efficient
o Adds minimal amount of extra header
 The original header remains
o Passive attacker can see who is talking
Part 3  Protocols
51
 IPSec: Host-to-Host
 IPSec transport mode used here

 There may be firewalls in between

o If so, is that a problem?
Part 3  Protocols
52
 IPSec Tunnel Mode
 IPSec Tunnel Mode
IP header data

new IP hdr IPSec hdr IP header data

 Tunnel mode for firewall-to-firewall

traffic
 Original IP packet encapsulated in IPSec
 Original IP header not visible to attacker
o New IP header from firewall to firewall
o Protocols
Part 3 Attacker does not know which hosts are talking
53
 IPSec: Firewall-to-Firewall
 IPSec tunnel mode used here

 Note: Local networks not protected

 Is there any advantage here?

Part 3  Protocols
54
 Comparison of IPSec
Modes
 Transport Mode  Transport Mode
o Host-to-host
IP header data
 Tunnel Mode
IP header IPSec header data
o Firewall-to-
firewall
 Tunnel Mode  Transport Mode
IP header data not necessary…
 …but it’s more
new IP hdr IPSec hdr IP header data efficient
Part 3  Protocols
55
 IPSec Security
 What kind of protection?
o Confidentiality?
o Integrity?
o Both?
 What to protect?
o Data?
o Header?
o Both?
 ESP/AH allow some combinations of
these
Part 3  Protocols
56
 AH vs ESP
 AH  Authentication Header
o Integrity only (no confidentiality)
o Integrity-protect everything beyond IP
header and some fields of header (why not
all fields?)
 ESP  Encapsulating Security Payload
o Integrity and confidentiality both required
o Protects everything beyond IP header
o Integrity-only by using NULL encryption
Part 3  Protocols
57
 ESP NULL Encryption
 According to RFC 2410
o NULL encryption “is a block cipher the origins
of which appear to be lost in antiquity”
o “Despite rumors”, there is no evidence that
NSA “suppressed publication of this
algorithm”
o Evidence suggests it was developed in
Roman times as exportable version of
Caesar’s cipher
o Can make use of keys of varying length
o No IV is required
o Null(P,K) = P for any P and any key K
Is3 ESP
Part with
Protocols NULL encryption same as
58
AH ?
 Why Does AH Exist? (1)
 Cannot encrypt IP header
o Routers must look at the IP header
o IP addresses, TTL, etc.
o IP header exists to route packets!
 AH protects immutable fields in IP
header
o Cannot integrity protect all header fields
o TTL, for example, will change
 ESP does not protect IP header at all
Part 3  Protocols
59
 Why Does AH Exist? (2)
 ESP encrypts everything beyond the IP
header (if non-null encryption)
 If ESP-encrypted, firewall cannot look at
TCP header in host-to-host case
 Why not use ESP with NULL encryption?
o Firewall sees ESP header, but does not know
whether null encryption is used
o End systems know, but not the firewalls

Part 3  Protocols
60
 Why Does AH Exist? (3)
 The real reason why AH exists:
o At one IETF meeting “someone from
Microsoft gave an impassioned speech
about how AH was useless…”
o “…everyone in the room looked around
and said `Hmm. He’s right, and we hate
AH also, but if it annoys Microsoft let’s
leave it in since we hate Microsoft more
than we hate AH.’ ”

Part 3  Protocols
61
 Kerberos

Part 3  Protocols
62
 Kerberos
 In Greek mythology, Kerberos is 3-
headed dog that guards entrance to
Hades
o “Wouldn’t it make more sense to guard the
exit?”
 In security, Kerberos is an authentication
protocol based on symmetric key crypto
o Originated at MIT
o Based on Needham and Schroeder protocol
o Relies on a Trusted Third Party (TTP)
Part 3  Protocols
63
 Motivation for Kerberos
 Authentication using public keys
o N users  N key pairs
 Authentication using symmetric keys
o N users requires (on the order of) N2 keys
 Symmetric key case does not scale
 Kerberos based on symmetric keys but
only requires N keys for N users
- Security depends on TTP
+ No PKI is needed

Part 3  Protocols
64
 Kerberos KDC
 Kerberos Key Distribution Center or
KDC
o KDC acts as the TTP
o 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
Part 3  Protocols
65 o Session key for confidentiality and integrity
 Kerberos Tickets
 KDC issue tickets containing info
needed to access network resources
 KDC also issues Ticket-Granting
Tickets or TGTs that are used to obtain
tickets
 Each TGT contains
o Session key
o User’s ID
o Expiration time
 Every TGT is encrypted with KKDC
o So, TGT can only be read by the KDC
Part 3  Protocols
66
 Kerberized Login
 Alice enters her password
 Then Alice’s computer does following:
o Derives KA from Alice’s password
o Uses KA to get TGT for Alice from KDC
 Alice then uses her TGT (credentials) to
securely access network resources
 Plus: Security is transparent to Alice
 Minus: KDC must be secure  it’s
trusted!
Part 3  Protocols
67
 Kerberized Login
Alice wants
Alice’s a TGT
password
E(SA,TGT,KA)

Alice Computer KDC

 Key KA = h(Alice’s password)
 KDC creates session key SA
 Alice’s computer decrypts SA and TGT
o Then it forgets K
A

 TGT = E(“Alice”, SA, KKDC)

Part 3  Protocols
68
 Alice Requests “Ticket to
Bob”I want to
talk to Bob
Talk to Bob REQUEST

REPLY

Alice Computer KDC

 REQUEST = (TGT, authenticator)
o authenticator = E(timestamp, SA)
 REPLY = E(“Bob”, KAB, ticket to Bob, SA)
o ticket to Bob = E(“Alice”, KAB, KB)
 KDC gets SA from TGT to verify timestamp
Part 3  Protocols
69
 Alice Uses Ticket to Bob

ticket to Bob, authenticator

E(timestamp + 1, KAB)

Alice’s Bob
Computer

 ticket to Bob = E(“Alice”, KAB, KB)

 authenticator = E(timestamp, KAB)
 Bob decrypts “ticket to Bob” to get KAB
which he then uses to verify timestamp
Part 3  Protocols
70
 Kerberos
 Key SA used in authentication
o For confidentiality/integrity
 Timestamps for authentication and
replay protection
 Recall, that timestamps…
o Reduce the number of messages  like
a nonce that is known in advance
o But, “time” is a security-critical
parameter
Part 3  Protocols
71
 Questions about Kerberos
 When Alice logs in, KDC sends E(SA, TGT,
KA) where TGT = E(“Alice”, SA, KKDC)
Q: Why is TGT encrypted with KA?
A: Enables Alice to be anonymous when she
later uses her TGT to request a ticket
 In Alice’s “Kerberized” login to Bob, why
can Alice remain anonymous?
 Why is “ticket to Bob” sent to Alice?
o Why doesn’t KDC send it directly to Bob?

Part 3  Protocols
72
 Kerberos Alternatives
 Could have Alice’s computer remember
password and use that for authentication
o Then no KDC required
o But hard to protect passwords
o Also, does not scale
 Could have KDC remember session key
instead of putting it in a TGT
o Then no need for TGT
o But stateless KDC is major feature of
Kerberos
Part 3  Protocols
73
 Kerberos Keys
 In Kerberos, KA = h(Alice’s password)
 Could instead generate random KA
o Compute Kh = h(Alice’s password)
o And Alice’s computer stores E(KA, Kh)
 Then KA need not change when Alice
changes her password
o But E(KA, Kh) must be stored on computer
 This alternative approach is often used
o But not in Kerberos
Part 3  Protocols
74
 WEP

Part 3  Protocols
75
 WEP
 WEP  Wired Equivalent Privacy
 The stated goal of WEP is to make
wireless LAN as secure as a wired
LAN
 According to Tanenbaum:
o “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
Part 3  Protocols
76 shall see.”
 WEP Authentication
Authentication Request
R

E(R, K)
Alice, K Bob, K

 Bob is wireless access point

 Key K shared by access point and all
users
o Key K seldom (if ever) changes
 WEP has many, many, many security
77 flaws
Part 3  Protocols
 WEP Issues
 WEP uses RC4 cipher for confidentiality
o RC4 can be a strong cipher
o But WEP introduces a subtle flaw…
o …making cryptanalytic attacks feasible
 WEP uses CRC for “integrity”
o Should have used a MAC, HMAC, or similar
o CRC is for error detection, not crypto
integrity
o Everyone should know NOT to use CRC
here…
Part 3  Protocols
78
 WEP Integrity Problems
 WEP “integrity” gives no crypto integrity
o CRC is linear, so is stream cipher (XOR)
o Trudy can change ciphertext and CRC so
that checksum on plaintext remains valid
o Then Trudy’s introduced changes go
undetected
o Requires no knowledge of the plaintext!
 CRC does not provide a cryptographic
integrity check
o CRC designed to detect random errors
o Not to detect intelligent changes
Part 3  Protocols
79
 More WEP Integrity Issues
 Suppose Trudy knows destination IP
 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
o Then what happens??
 Moral: Big problems when integrity fails
Part 3  Protocols
80
 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
o Initialization Vector (IV) sent with packet
o Sent in the clear, that is, IV is not secret
o Note: IV similar to MI in WWII ciphers
 Actual RC4 key for packet is (IV,K)
o That is, IV is pre-pended to long-term key
K
Part 3  Protocols
81
 WEP Encryption

IV, E(packet,KIV)

Alice, K Bob, K

 KIV = (IV,K)
o That is, RC4 key is K with 3-byte IV pre-
pended
 The IV is known to Trudy
Part 3  Protocols
82
 WEP IV Issues
 WEP uses 24-bit (3 byte) IV
o Each packet gets its own IV
o 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
o This is bad, bad, really really bad!
o Why?

Part 3  Protocols
83
 WEP IV Issues
 Assume 1500 byte packets, 11 Mbps
link
 Suppose IVs generated in sequence
o Since 1500  8/(11  106)  224 = 18,000
seconds, an IV repeat in about 5 hours of
traffic
 Suppose IVs generated at random
o By birthday problem, some IV repeats in
seconds
PartAgain,
 3  Protocolsrepeated IV (with same K) is bad
84
 Another Active Attack
 Suppose Trudy can insert traffic and
observe corresponding ciphertext
o Then she knows the keystream for some IV
o She can decrypt any packet that uses that
IV
 If Trudy does this many times, she can
then decrypt data for lots of IVs
o Remember, IV is sent in the clear
 Is such an attack feasible?
Part 3  Protocols
85
 Cryptanalytic Attack
 WEP data encrypted using RC4
o Packet key is IV with long-term key K
o 3-byte IV is pre-pended to K
o Packet key is (IV,K)
 Recall IV is sent in the clear (not secret)
o New IV sent with every packet
o Long-term key K seldom changes (maybe
never)
 So Trudy always knows IV and
ciphertext
o Trudy wants to find the key K
Part 3  Protocols
86
 Cryptanalytic Attack
 3-byte IV pre-pended to key
 Denote the RC4 key bytes …
o … as K ,K ,K ,K ,K ,K , …
0 1 2 3 4 5
o Where IV = (K ,K ,K ) , which Trudy knows
0 1 2
o Trudy wants to find K = (K ,K ,K , …)
3 4 5
 Given enough IVs, Trudy can easily find
key K
o Regardless of the length of the key
o Provided Trudy knows first keystream byte
o Known plaintext attack (1st byte of each
packet)
Part 3  Protocols
87 o Prevent by discarding first 256 keystream
 WEP Conclusions
 Many attacks are practical
 Attacks have been used to recover keys
and break real WEP traffic
 How to prevent these attacks?
o Don’t use WEP
o Good alternatives: WPA, WPA2, etc.
 How to make WEP a little better?
o Restrict MAC addresses, don’t broadcast ID,
…

Part 3  Protocols
88
 GSM (In)Security

Part 3  Protocols
89
 Cell Phones
 First generation cell phones
o Brick-sized, analog, few standards
o Little or no security
o Susceptible to cloning
 Second generation cell phones: GSM
o Began in 1982 as “Groupe Speciale Mobile”
o Now, Global System for Mobile
Communications
 Third generation?
o 3rd Generation Partnership Project (3GPP)
Part 3  Protocols
90
 GSM System Overview

air
interface

Mobile
Base AuC
VLR
Station
“land line”
HLR
PSTN
Base Internet
etc. Home
Visited Station Network
Network Controller

Part 3  Protocols
91
 GSM System Components
 Mobile phone
o Contains SIM (Subscriber
Identity Module)
 SIM is the security module
o IMSI (International Mobile
Subscriber ID)
o User key: Ki (128 bits)
SIM
o Tamper resistant (smart card)
o PIN activated (often not used)

Part 3  Protocols
92
 GSM System Components
 Visited network  network where
mobile is currently located
o Base station  one “cell”
o Base station controller  manages many cells
o VLR (Visitor Location Register)  info on all
visiting mobiles currently in the network
 Home network  “home” of the mobile
o HLR (Home Location Register)  keeps track
of most recent location of mobile
o AuC (Authentication Center)  has IMSI and
Ki
Part 3  Protocols
93
 GSM Security Goals
 Primary design goals
o Make GSM as secure as ordinary
telephone
o Prevent phone cloning
 Not designed to resist an active attacks
o At the time this seemed infeasible
o Today such an attacks are clearly feasible…
 Designers considered biggest threats to
be
o Insecure billing
o Corruption
o Other low-tech attacks
Part 3  Protocols
94
 GSM Security Features
 Anonymity
o Intercepted traffic does not identify user
o Not so important to phone company
 Authentication
o Necessary for proper billing
o Very, very important to phone company!
 Confidentiality
o Confidentiality of calls over the air interface
o Not important to phone company…
o …except for marketing

Part 3  Protocols
95
 GSM: Anonymity
 IMSI used to initially identify caller
 Then TMSI (Temporary Mobile
Subscriber ID) used
o TMSI changed frequently
o TMSI’s encrypted when sent
 Not a strong form of anonymity
 But probably useful in many cases

Part 3  Protocols
96
 GSM: Authentication
 Caller is authenticated to base station
 Authentication is not mutual
 Authentication via challenge-response
o Home network generates RAND and
computes XRES = A3(RAND, Ki) where A3 is
a hash
o Then (RAND,XRES) sent to base station
o Base station sends challenge RAND to
mobile
o Mobile’s response is SRES = A3(RAND, Ki)
o Base station verifies SRES = XRES
PartNote:
 Ki
3  Protocols never leaves home network
97
 GSM: Confidentiality
 Data encrypted with stream cipher
 Error rate estimated at about 1/1000
o Error rate is high for a block cipher
 Encryption key Kc
o Home network computes Kc = A8(RAND, Ki)
where A8 is a hash
o Then Kc sent to base station with
(RAND,XRES)
o Mobile computes Kc = A8(RAND, Ki)
o Keystream generated from A5(Kc)
 Note: Ki never leaves home network
Part 3  Protocols
98
 GSM Security
1. IMSI
2. IMSI
4. RAND
3. (RAND,XRES,Kc)
5. SRES
Mobile Base Home
6. Encrypt with Kc Station Network

 SRES and Kc must be uncorrelated

o Even though both are derived from RAND and Ki
 Must not be possible to deduce Ki from known
RAND/SRES pairs (known plaintext attack)
 Must not be possible to deduce Ki from chosen
RAND/SRES pairs (chosen plaintext attack)
o With possession of SIM, attacker can choose RAND’s

Part 3  Protocols
99
 GSM Insecurity (1)
 Hash used for A3/A8 is COMP128
o Broken by 160,000 chosen plaintexts
o With SIM, can get Ki in 2 to 10 hours Base
Station
 Encryption between mobile and
base station but no encryption
from base station to base station VLR
controller
o Often transmitted over microwave link
Base
 Encryption algorithm A5/1 Station
Controller
o Broken with 2 seconds of known
plaintext
Part 3  Protocols
100
 GSM Insecurity (2)
 Attacks on SIM card
o Optical Fault Induction  could attack
SIM with a flashbulb to recover Ki
o Partitioning Attacks  using timing and
power consumption, could recover Ki with
only 8 adaptively chosen “plaintexts”
 With possession of SIM, attacker could
recover Ki in seconds

Part 3  Protocols
101
 GSM Insecurity (3)
 Fake base station exploits two flaws
1. Encryption not automatic
2. Base station not authenticated

RAND
SRES Call to
destination
No
Mobile Fake
encryption Base Station Base Station

 Note: GSM bill goes to fake base

station!
Part 3  Protocols
102
 GSM Insecurity (4)
 Denial of service is possible
o Jamming (always an issue in wireless)
 Can replay triple: (RAND,XRES,Kc)
o One compromised triple gives attacker
a key Kc that is valid forever
o No replay protection here

Part 3  Protocols
103
 GSM Conclusion
 Did GSM achieve its goals?
o Eliminate cloning? Yes, as a practical
matter
o Make air interface as secure as PSTN?
Perhaps…
 But design goals were clearly too limited
 GSM insecurities  weak crypto, SIM
issues, fake base station, replay, etc.
 PSTN insecurities  tapping, active
attack, passive attack (e.g., cordless
phones), etc.
Part 3  Protocols

104
GSM a (modest) security success?
 3rd Generation
Partnership Project (3GPP)
 3G security built on GSM (in)security
 3G fixed known GSM security problems
o Mutual authentication
o Integrity-protect signaling (such as “start
encryption” command)
o Keys (encryption/integrity) cannot be reused
o Triples cannot be replayed
o Strong encryption algorithm (KASUMI)
o Encryption extended to base station
controller
Part 3  Protocols
105
 Protocols Summary
 Generic authentication protocols
o Protocols are subtle!
 SSH
 SSL
 IPSec
 Kerberos
 Wireless: next lecture…

Part 3  Protocols
106
 Coming Attractions…
 Software and security
o Software flaws  buffer overflow, etc.
o Malware  viruses, worms, etc.
o Software reverse engineering
o Digital rights management
o OS and security/NGSCB

Part 3  Protocols
107