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
serious flaws
o Including IPSec, GSM and WEP
 Common to find implementation errors
o Such as IE implementation of SSL
 Difficult to get protocols right…

Part 3  Protocols 3
 Ideal Security Protocol
 Satisfies security requirements
o Requirements must be precise
 Efficient
o Minimize computational requirement  in
particular, costly public key operations
o Minimize delays/bandwidth
 Not fragile
o Must work when attacker tries to break it
o Works even if environment changes
 Easy to use and implement, flexible, etc.
 Very difficult to satisfy all of these!

Part 3  Protocols 4
 Simple Security Protocols

Part 3  Protocols 5
 Secure Entry to NSA
1. Insert badge into reader
2. Enter PIN
3. Correct PIN?
Yes? Enter
No? Get shot by security guard

Part 3  Protocols 6
 ATM Machine Protocol
1. Insert ATM card
2. Enter PIN
3. Correct PIN?
Yes? Conduct your transaction(s)
No? Machine eats card

Part 3  Protocols 7
Identify Friend or Foe (IFF)

Russian
MIG
Angola

SAAF 2. E(N,K)
Impala
1. N
Namibia

Part 3  Protocols 8
 MIG in the Middle
3. N
SAAF
Impala 4. E(N,K)
Angola
2. N

5. E(N,K)

6. E(N,K)
Russian
MiG
1. N
Namibia

Part 3  Protocols 9
 Authentication Protocols

Part 3  Protocols 10
 Authentication
 Alice must prove her identity to Bob
o Alice and Bob can be humans or computers
 May also require Bob to prove he’s Bob
(mutual authentication)
 May also need to establish a session key
 May have other requirements, such as
o Use only public keys
o Use only symmetric keys
o Use only a hash function
o Anonymity, plausible deniability, etc., etc.

Part 3  Protocols 11
 Authentication
 Authentication on a stand-alone computer is
relatively simple
o “Secure path” is the primary issue
o Main concern is an attack on authentication
software (we discuss software attacks later)
 Authentication over a network is much more
complex
o Attacker can passively observe messages
o Attacker can replay messages
o Active attacks may be possible (insert, delete,
change messages)
Part 3  Protocols 12
 Simple Authentication
“I’m Alice”

Prove it

My password is “frank”
Alice Bob
 Simple and may be OK for standalone system
 But insecure for networked system
o Subject to a replay attack (next 2 slides)
o Bob must know Alice’s password

Part 3  Protocols 13
 Authentication Attack
“I’m Alice”

Prove it
My password is “frank”
Alice Bob

Trudy
Part 3  Protocols 14
 Authentication Attack

“I’m Alice”

Prove it
My password is “frank”
Trudy Bob

 This is a replay attack

 How can we prevent a replay?

Part 3  Protocols 15
 Simple Authentication

I’m Alice, My password is “frank”

Alice Bob

 More efficient…
 But same problem as previous version

Part 3  Protocols 16
 Better Authentication
“I’m Alice”

Prove it

h(Alice’s password)
Alice Bob

 Better since it hides Alice’s password

o From both Bob and attackers
 But still subject to replay
Part 3  Protocols 17
 Challenge-Response
 To prevent replay, challenge-response used
 Suppose Bob wants to authenticate Alice
o Challenge sent from Bob to Alice
o Only Alice can provide the correct response
o Challenge chosen so that replay is not possible
 How to accomplish this?
o Password is something only Alice should know…
o For freshness, a “number used once” or nonce

Part 3  Protocols 18
 Challenge-Response
“I’m Alice”

Nonce

h(Alice’s password, Nonce)

Alice Bob
 Nonce is the challenge
 The hash is the response
 Nonce prevents replay, insures freshness
 Password is something Alice knows
 Note that Bob must know Alice’s password
Part 3  Protocols 19
 Challenge-Response

“I’m Alice”

Nonce

Something that could only be

Alice from Alice (and Bob can verify) Bob

 What can we use to achieve this?

 Hashed pwd works, crypto might be better

Part 3  Protocols 20
 Symmetric Key Notation
 Encrypt plaintext P with key K
C = E(P,K)
 Decrypt ciphertext C with key K

P = D(C,K)
 Here, we are concerned with attacks on
protocols, not directly on the crypto
 We assume that crypto algorithm is secure

Part 3  Protocols 21
Symmetric Key Authentication
 Alice and Bob share symmetric key KAB
 Key KAB known only to Alice and Bob
 Authenticateby proving knowledge of
shared symmetric key
 How to accomplish this?
o Must not reveal key
o Must not allow replay attack

Part 3  Protocols 22
 Authentication and TCP

Part 3  Protocols 23
 TCP-based Authentication
 TCP not intended for use as an
authentication protocol
 But IP address in TCP connection
often used for authentication
 One mode of IPSec uses IP address
for authentication
 This can cause problems

Part 3  Protocols 24
 TCP 3-way Handshake

SYN, SEQ a
SYN, ACK a+1, SEQ b
ACK b+1, data
Alice Bob

 Recall the TCP three way handshake

 Initial SEQ number must be random
 Why?

Part 3  Protocols 25
 TCP Authentication Attack
1. SYN, SEQ = t (as Trudy)
2. SYN, ACK = t+1, SEQ = b1

3. SYN, SEQ = t (as Alice)

Trudy 5. ACK = b2+1, data Bob

5. = b2
E Q
5. , S
= t +1
5. K
, AC
N
Alice . SY
5. 4

Part 3  Protocols 26
 TCP Authentication Attack

Initial SEQ numbers

Random SEQ numbers Mac OS X
 If initial SEQ numbers not very random…
 …possible to guess initial SEQ number…
 …and previous attack will succeed
Part 3  Protocols 27
 TCP Authentication Attack
 Trudy cannot see what Bob sends, but she can
send packets to server Bob, while posing as Alice
 Trudy must prevent Alice from receiving Bob’s
packets (or else connection will terminate)
 If password (or other authentication) required,
this attack fails
 If TCP connection is relied on for authentication,
then attack succeeds
 Bad idea to rely on TCP for authentication

Part 3  Protocols 28
 Zero Knowledge Proofs

Part 3  Protocols 29
Zero Knowledge Proof (ZKP)
 Alice wants to prove that she knows a
secret without revealing any info about it
 Bob must verify that Alice knows secret
o Even though he gains no info about the secret
 Process is probabilistic
o Bob can verify that Alice knows the secret to
an arbitrarily high probability
 An “interactive proof system”

Part 3  Protocols 30
 Bob’s Cave
 Alice claims to
know secret phrase P
to open path
between R and S
(“open sarsparilla”) Q
 Can she convince
R S
Bob that she knows
the secret without
revealing phrase?

Part 3  Protocols 31
 Bob’s Cave
 Bob: “Alice come out on S side”
P

 Alice (quietly):
“Open sarsparilla”
Q
 If Alice does not R S
know secret…

 …then Alice could come out from the correct side

with probability 1/2
 If Bob repeats this n times, then Alice (who does not
know secret) can only fool Bob with probability 1/2n
Part 3  Protocols 32
 Fiat-Shamir Protocol
 Cave-based protocols are inconvenient
o Can we achieve same effect without a cave?
 It is known that finding square roots
modulo N is difficult (like factoring)
 Suppose N = pq, where p and q prime
 Alice has a secret S
 N and v = S2 mod N are public, S is secret
 Alice must convince Bob that she knows S
without revealing any information about S
Part 3  Protocols 33
 Fiat-Shamir
x = r2 mod N
e  {0,1}
y = rSe mod N
Alice Bob
secret S
random r
 Public: Modulus N and v = S2 mod N
 Alice selects random r
 Bob chooses e  {0,1}
 Bob verifies that y2 = r2S2e = r2(S2)e = xve mod N
Part 3  Protocols 34
 Fiat-Shamir: e = 1
x = r2 mod N
e=1

y = rS mod N
Alice Bob
secret S
random r
 Public: Modulus N and v = S2 mod N
 Alice selects random r
 Suppose Bob chooses e =1
 Bob must verify that y2 = xv mod N
 Alice must know S in this case

Part 3  Protocols 35
 Fiat-Shamir: e = 0
x = r2 mod N
e=0

y = r mod N
Alice
Bob
secret S
random r
 Public: Modulus N and v = S2 mod N
 Alice selects random r
 Suppose Bob chooses e = 0
 Bob must verify that y2 = x mod N
 Alice does not need to know S in this case!
Part 3  Protocols 36
 Fiat-Shamir
 Public: modulus N and v = S2 mod N
 Secret: Alice knows S
 Alice selects random r and commits to r by
sending x = r2 mod N to Bob
 Bob sends challenge e  {0,1} to Alice
 Alice responds with y = rSe mod N
 Bob checks that y2 = xve mod N
 Does this prove response is from Alice?

Part 3  Protocols 37
 Does Fiat-Shamir Work?
 The math works since
o Public: v = S2
o Alice to Bob: x = r2 and y = rSe
o Bob verifies y2 = xve mod N
 Can Trudy convince Bob she is Alice?
o If Trudy expects e = 0, she can send x = r2 in msg
1 and y = r in msg 3 (i.e., follow protocol)
o If Trudy expects Bob to send e = 1, she can send
x = r2v1 in msg 1 and y = r in msg 3
 If Bob chooses e  {0,1} at random, Trudy
can only fool Bob with probability 1/2
Part 3  Protocols 38
 Fiat-Shamir Facts
 Trudy can fool Bob with prob 1/2, but…
 …after n iterations, the probability that Trudy
can fool Bob is only 1/2n
 Just like Bob’s cave!
 Bob’s e  {0,1} must be unpredictable
 Alice must use new r each iteration or else
o If e = 0, Alice sends r in message 3
o If e = 1, Alice sends rS in message 3
o Anyone can find S given both r and rS

Part 3  Protocols 39
Fiat-Shamir Zero Knowledge?
 Zero knowledge means that Bob learns
nothing about the secret S
o Public: v = S2 mod N
o Bob sees r2 mod N in message 1
o Bob sees rS mod N in message 3 (if e = 1)
o If Bob can find r from r2 mod N, he gets S
o But that requires modular square root
o If Bob can find modular square roots, he can get
S from public v
 The protocol does not “help” Bob to find S
Part 3  Protocols 40
 ZKP in the Real World
 Public key certificates identify users
o No anonymity if certificates transmitted
 ZKP offers a way to authenticate without
revealing identities
 ZKP supported in Microsoft’s Next
Generation Secure Computing Base (NGSCB)
o ZKP used to authenticate software “without
revealing machine identifying data”
o ZKP not just fun and games for mathematicians!

Part 3  Protocols 41
Best Authentication Protocol?
 What is best depends on many factors…
 The sensitivity of the application
 The delay that is tolerable
 The cost (computation) that is tolerable
 What crypto is supported
o Public key, symmetric key, hash functions
 Is mutual authentication required?
 Is a session key required?
 Is PFS a concern?
 Is anonymity a concern?, etc.

Part 3  Protocols 42
 Real-World Protocols
 Next, we’ll look at specific protocols
o SSL  security on the Web
o IPSec  security at the IP layer
o Kerberos  symmetric key system
o GSM  mobile phone (in)security

Part 3  Protocols 43
 Secure Socket Layer

Part 3  Protocols 44
 Socket layer
 “Socket layer”
lives between Socket application User
application and “layer”
transport transport
OS
layers
network
 SSL usually
lies between link
NIC
HTTP and TCP
physical

Part 3  Protocols 45
 What is SSL?
 SSL is the protocol used for most secure
transactions over the Internet
 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 doesn’t care
who you are (authentication need not be mutual)

Part 3  Protocols 46
 Simple SSL-like Protocol
I’d like to talk to you securely
Here’s my certificate
{KAB}Bob

Alice protected HTTP Bob

 Is Alice sure she’s talking to Bob?

 Is Bob sure he’s talking to Alice?

Part 3  Protocols 47
 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 pre-master secret
 K = h(S,RA,RB)
 msgs = all previous messages
 CLNT and SRVR are constants
Part 3  Protocols 48
 SSL Keys
 6 “keys” derived from K = hash(S,RA,RB)
o 2 encryption keys: send and receive
o 2 integrity keys: send and receive
o 2 IVs: send and receive
o Why different keys in each direction?
 Q: Why is h(msgs,CLNT,K) encrypted (and
integrity protected)?
 A: It adds no security…

Part 3  Protocols 49
 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 (such as Verisign)
 What does Web browser do if sig. not valid?
 What does user do if signature is not valid?
Part 3  Protocols 50
SSL Sessions vs Connections
 SSL session is established as shown on
previous slides
 SSL designed for use with HTTP 1.0
 HTTP 1.0 usually opens multiple
simultaneous (parallel) connections
 SSL session establishment is costly
o Due to public key operations
 SSL has an efficient protocol for opening
new connections given an existing session
Part 3  Protocols 51
 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 known S)
Part 3  Protocols 52
 SSL vs IPSec
 IPSec  discussed in next section
o Lives at the network layer (part of the OS)
o Has encryption, integrity, authentication, etc.
o Is overly complex (including serious flaws)
 SSL (and IEEE standard known as TLS)
o Lives at socket layer (part of user space)
o Has encryption, integrity, authentication, etc.
o Has a simpler specification

Part 3  Protocols 53
 SSL vs IPSec
 IPSec implementation
o Requires changes to OS, but no changes to applications
 SSL implementation
o Requires changes to applications, but no changes to OS
 SSL built into Web application early on (Netscape)
 IPSec used in VPN applications (secure tunnel)
 Reluctance to retrofit applications for SSL
 Reluctance to use IPSec due to complexity and
interoperability issues
 Result? Internet less secure than it should be!

Part 3  Protocols 54
 IPSec

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

physical

Part 3  Protocols 56
 IPSec and Complexity
 IPSec is a complex protocol
 Over-engineered
o Lots of generally useless extra features
 Flawed
o Some serious security flaws
 Interoperability is serious challenge
o Defeats the purpose of having a standard!
 Complex

Part 3  Protocols 57
 IKE and ESP/AH
 Two parts to IPSec
 IKE: Internet Key Exchange
o Mutual authentication
o Establish shared symmetric key
o Two “phases”  like SSL session/connection
 ESP/AH
o ESP: Encapsulating Security Payload  for
encryption and/or integrity of IP packets
o AH: Authentication Header  integrity only
Part 3  Protocols 58
 IKE

Part 3  Protocols 59
 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
 If multiple Phase 2’s do not occur, then it
is more expensive to have two phases!

Part 3  Protocols 60
 IKE Phase 1
 Four 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, two different “modes”
o Main mode
o Aggressive mode
 There are 8 versions of IKE Phase 1!
 Evidence that IPSec is over-engineered

Part 3  Protocols 61
 IKE Phase 1
 We’ll discuss 6 of 8 phase 1 variants
o Public key signatures (main and 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 key

Part 3  Protocols 62
 IKE Phase 1
 Uses ephemeral Diffie-Hellman to
establish session key
o Achieves 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 p and g are public

Part 3  Protocols 63
 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,RA,RB)
 SKEYID = h(RA, RB, gab mod p)
 proofA = [h(SKEYID,ga,gb,IC,RC,CP,“Alice”)]Alice
Part 3  Protocols 64
 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 difference from main mode

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

Part 3  Protocols 65
 Main vs Aggressive Modes
 Main mode MUST be implemented
 Aggressive mode SHOULD be implemented
o In other words, 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
o Active attacker can determine Alice’s and Bob’s
identity in main mode
Part 3  Protocols 66
 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
IC,RC, E(“Bob”, proofB, K)
 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,gb,IC,RC,CP,“Alice”)
Part 3  Protocols 67
 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 ID must be IP address!
 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 68
 IKE Phase 1: SymmetricKey
(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
 But does not (pretend to) hide identities
Part 3  Protocols 69
 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,RA,RB)
 SKEYID = h(RA, RB, gab mod p)
 proofA = h(SKEYID,ga,gb,IC,RC,CP,“Alice”)
Part 3  Protocols 70
 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 Then why have main mode?
Part 3  Protocols 71
 Public Key Encryption Issue?
 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
 Also true of main mode

Part 3  Protocols 72
 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 exchange that appears to be

between Alice and Bob
 Appears valid to any observer, including Alice
and Bob!
Part 3  Protocols 73
 Plausible Deniability
 Trudy can create “conversation” that
appears to be between Alice and Bob
 Appears valid, even to Alice and Bob!
 A security failure?
 In this mode of IPSec, it is a feature
o Plausible deniability: Alice and Bob can deny
that any conversation took place!
 In some cases it might be a security failure
o If Alice makes a purchase from Bob, she could
later repudiate it (unless she had signed)
Part 3  Protocols 74
 IKE Phase 1 Cookies
 Cookies (or “anti-clogging tokens”) supposed
to make denial of service more difficult
 No relation to Web cookies
 To reduce DoS, 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!
 These cookies offer little DoS protection!

Part 3  Protocols 75
 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 (in public key
and/or main mode cases)
 Developers of IKE thought it would be used
for lots of things  not just IPSec
 Partly explains over-engineering…

Part 3  Protocols 76
 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 77
 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 78
 IPSec
 After IKE Phase 1, we have an IKE SA
 After IKE Phase 2, we have an IPSec SA
 Both sides have a shared symmetric key
 Now what?
o We want to protect IP datagrams
 But what is an IP datagram?
o From the perspective of IPSec…

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

IP header data

 Where IP header is

Part 3  Protocols 80
 IP and TCP
 Consider HTTP traffic (over TCP)
 IP encapsulates TCP
 TCP encapsulates HTTP

IP header data

IP header TCP hdr HTTP hdr app data

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

IP header ESP/AH 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 82
 IPSec Tunnel Mode
 IPSec Tunnel Mode
IP header data

new IP hdr ESP/AH 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 header from firewall to firewall
o Attacker does not know which hosts are talking

Part 3  Protocols 83
 Comparison of IPSec Modes
 Transport Mode  Transport Mode
o Host-to-host
IP header data
 Tunnel Mode
o Firewall-to-
IP header ESP/AH data firewall
 Tunnel Mode  Transport mode
not necessary
IP header data
 Transport mode
is more efficient
new IP hdr ESP/AH IP header data

Part 3  Protocols 84
 IPSec Security
 What kind of protection?
o Confidentiality?
o Integrity?
o Both?
 What to protect?
o Data?
o Header?
o Both?
 ESP/AH do some combinations of these

Part 3  Protocols 85
 AH vs ESP
 AH
o Authentication Header
o Integrity only (no confidentiality)
o Integrity-protect everything beyond IP header
and some fields of header (why not all fields?)
 ESP
o Encapsulating Security Payload
o Integrity and confidentiality
o Protects everything beyond IP header
o Integrity only by using NULL encryption

Part 3  Protocols 86
 ESP’s 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
 Security people have a strange sense of humor!

Part 3  Protocols 87
 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, must change
 ESP does not protect IP header at all

Part 3  Protocols 88
 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 (e.g., port numbers)
 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 firewalls
 Aside 1: Do firewalls reduce security?
 Aside 2: Is IPSec compatible with NAT?

Part 3  Protocols 89
 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 90
 Kerberos

Part 3  Protocols 91
 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
system based on symmetric key crypto
o Originated at MIT
o Based on work by Needham and Schroeder
o Relies on a trusted third party (TTP)

Part 3  Protocols 92
 Motivation for Kerberos
 Authentication using public keys
o N users  N key pairs
 Authentication using symmetric keys
o N users requires about N2 keys
 Symmetric key case does not scale!
 Kerberos based on symmetric keys but only
requires N keys for N users
o But must rely on TTP
o Advantage is that no PKI is required

Part 3  Protocols 93
 Kerberos KDC
 Kerberos Key Distribution Center or KDC
o Acts as a TTP
o TTP must not be compromised!
o KDC shares symmetric key KA with Alice, key KB
with Bob, key KC with Carol, etc.
o Master key KKDC known only to KDC
o KDC enables authentication and session keys
o Keys for confidentiality and integrity
o In practice, the crypto algorithm used is DES

Part 3  Protocols 94
 Kerberos Tickets
 KDC issues a ticket containing info needed
to access a network resource
 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 TGT can only be read by the KDC
Part 3  Protocols 95
 Kerberized Login
 Alice enters her password
 Alice’s workstation
o Derives KA from Alice’s password
o Uses KA to get TGT for Alice from the KDC
 Alice can then use 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 96
 Kerberized Login
Alice wants
Alice’s a TGT
password E(SA,TGT,KA)

Alice Computer KDC

 Key KA derived from Alice’s password

 KDC creates session key SA
 Workstation decrypts SA, TGT, forgets KA
 TGT = E(“Alice”,SA, KKDC)
Part 3  Protocols 97
 Alice Requests Ticket to Bob
I want to
talk to Bob
Talk to Bob REQUEST

REPLY

Alice Computer KDC

 REQUEST = (TGT, authenticator) where
authenticator = E(timestamp,SA)
 REPLY = E(“Bob”,KAB,ticket to Bob, SA)
 ticket to Bob = E(“Alice”,KAB,KB)
 KDC gets SA from TGT to verify timestamp
Part 3  Protocols 98
 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 99
 Kerberos
 Session key SA used for authentication
 Can also be used for confidentiality/integrity
 Timestamps used for mutual authentication
 Recall that timestamps reduce number of
messages
o Acts like a nonce that is known to both sides
o Note: time is a security-critical parameter!

Part 3  Protocols 100

 GSM Security

Part 3  Protocols 101

 Cell Phones
 First generation cell phones
o 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 102

 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 103

 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 (usually not used)

Part 3  Protocols 104

 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)  contains IMSI/Ki

Part 3  Protocols 105

 GSM Security Goals
 Primary design goals
o Make GSM as secure as ordinary telephone
o Prevent phone cloning
 Not designed to resist an active attack!
o At the time this seemed infeasible
o Today such an attack is very feasible…
 Designers considered biggest threats
o Insecure billing
o Corruption
o Other low-tech attacks
Part 3  Protocols 106
 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 important to phone company!
 Confidentiality
o Confidentiality of calls over the air interface
o Not important to phone company
o May be very important for marketing!
Part 3  Protocols 107
 GSM: Anonymity
 IMSI used to initially identify caller
 Then TMSI (Temporary Mobile Subscriber
ID) used
 TMSI changed frequently
 TMSI’s encrypted when sent
 Not a strong form of anonymity
 But probably sufficient for most uses

Part 3  Protocols 108

 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
 Note: Ki never leaves home network!
Part 3  Protocols 109
 GSM: Confidentiality
 Data encrypted with stream cipher
 Error rate estimated at about 1/1000
o Error rate too 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 110
 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 111
 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
VLR
station to base station controller
o Often transmitted over microwave link
 Encryption algorithm A5/1 Base
Station
o Broken with 2 seconds of known plaintext Controller

Part 3  Protocols 112

 GSM Insecurity (2)
 Attacks on SIM card
o Optical Fault Induction  can attack SIM with
a flashbulb to recover Ki
o Partitioning Attacks  using timing and power
consumption, can recover Ki with only 8
adaptively chosen “plaintexts”
 With possession of SIM, attacker can
recover Ki in seconds

Part 3  Protocols 113

 GSM Insecurity (3)
 Fake base station exploits two flaws
o Encryption not automatic
o Base station not authenticated

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

 Note: The bill goes to fake base station!

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

Part 3  Protocols 115

 GSM Conclusion
 Did GSM achieve its goals?
o Eliminate cloning? Yes
o Make air interface as secure as PSTN? Perhaps…
o 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.
 GSM a (modest) security success?

Part 3  Protocols 116

 Protocols Summary
 Generic authentication protocols
o Protocols can be very subtle!
 SSL
 IPSec
 Kerberos
 GSM

Part 3  Protocols 117