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, GSM, and IPSec
 Implementation errors can occur
o Recently:
 IE implementation of SSL
 OpenSSL Heartbleed bug
 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 Small computational requirement
o Small bandwidth usage, minimal delays…
 Robust
o Works when attacker tries to break it
o Works even if environment changes
 Easy to use & implement, flexible…
 Difficult to satisfy all of these!
Part 3  Protocols 4
 Chapter 9:
Simple Security Protocols
“I quite agree with you,” said the Duchess; “and the moral of that is
‘Be what you would seem to be’ or
if you'd like it put more simply‘Never imagine yourself not to be
otherwise than what it might appear to others that what you were
or might have been was not otherwise than what you
had been would have appeared to them to be otherwise.’ ”
 Lewis Carroll, Alice in Wonderland

Seek simplicity, and distrust it.

 Alfred North Whitehead

Part 2  Access Control 5

Identify Friend or Foe (IFF) – Case 1

Country 2

Friend E(Friend,K)
K

Country 1
K
6
 (IFF – Case 1) Attack

Country 2

E(Friend,K)
Foe
MiG

Country 1
K
7
Identify Friend or Foe (IFF) – Case 2

Foe
MiG
Country 2

Friend 2. E(N,K)
K
1. N
Country 1
K
8
(IFF – Case 2) “MiG” in the Middle Attack

3. N
Friend
K 4. E(N,K)
Country 2
2. N

5. E(N,K)

6. E(N,K)
Foe
MiG
N
Country 1
1.

K
9
 Authentication Protocol
Requirements
 IFF-Case 1  Must prove freshness of answer
(prevents replay attacks)

 IFF-Case 2  Must prevent one party from

doing the work of the other party

10
 Authentication Protocols

Part 3  Protocols 11
 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)
 Probably need to establish a session key
 May have other requirements, such as
o Use public keys
o Use symmetric keys
o Use hash functions
o Anonymity, plausible deniability, etc., etc.

Part 3  Protocols 12
 Authentication
 Authentication on a stand-alone computer is
relatively simple
o Hash password with salt
o “Secure path,” attacks on authentication
software, keystroke logging, etc., can be issues
 Authentication over a network is challenging
o Attacker can passively observe messages
o Attacker can replay messages
o Active attacks possible (insert, delete, change)
Part 3  Protocols 13
 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 Also, Bob must know Alice’s password
Part 3  Protocols 14
 Authentication Attack
“I’m Alice”

Prove it

My password is “frank”
Alice Bob

Trudy
Part 3  Protocols 15
 Authentication Attack

“I’m Alice”

Prove it

My password is “frank”
Trudy Bob

 This is an example of a replay attack

 How can we prevent a replay?
Part 3  Protocols 16
 Simple Authentication

I’m Alice, my password is “frank”

Alice Bob

 More efficient, but…

 … same problem as previous version
Part 3  Protocols 17
 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 Trudy
 But still subject to replay
Part 3  Protocols 18
 Challenge-Response
 To prevent replay, use challenge-response
o Goal is to ensure “freshness”
 Suppose Bob wants to authenticate Alice
o Challenge sent from Bob to Alice
 Challenge is chosen so that…
o Replay is not possible
o Only Alice can provide the correct response
o Bob can verify the response

Part 3  Protocols 19
 Nonce
 To ensure freshness, can employ a nonce
o Nonce == number used once
 What to use for nonces?
o That is, what is the challenge?
 What should Alice do with the nonce?
o That is, how to compute the response?
 How can Bob verify the response?
 Should we rely on passwords or keys?

Part 3  Protocols 20
 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, ensures freshness
 Password is something Alice knows
 Note: Bob must know Alice’s pwd to verify
Part 3  Protocols 21
 Generic Challenge-Response
“I’m Alice”

Nonce

Something that could only be

Alice from Alice (and Bob can verify) Bob

 In practice, how to achieve this?

 Hashed password works, but…
 Encryption is better here (Why?)
Part 3  Protocols 22
 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 attacks on crypto
o So, we assume crypto algorithms are secure

Part 3  Protocols 23
Authentication: Symmetric Key
 Alice and Bob share symmetric key K
 Key K known only to Alice and Bob
 Authenticate by proving knowledge of
shared symmetric key
 How to accomplish this?
o Cannot reveal key, must not allow replay
(or other) attack, must be verifiable, …

Part 3  Protocols 24
 Authentication with
Symmetric Key
“I’m Alice”
R
E(R,K)
Alice, K Bob, K

 Secure method for Bob to authenticate Alice

 Alice does not authenticate Bob
 So, can we achieve mutual authentication?

Part 3  Protocols 25
 Mutual Authentication?

“I’m Alice”, R

E(R,K)

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

 What’s wrong with this picture?

 “Alice” could be Trudy (or anybody else)!
Part 3  Protocols 26
 Mutual Authentication
 Since we have a secure one-way
authentication protocol…
 The obvious thing to do is to use the
protocol twice
o Once for Bob to authenticate Alice
o Once for Alice to authenticate Bob
 This has got to work…

Part 3  Protocols 27
 Mutual Authentication

“I’m Alice”, RA

RB, E(RA, K)

E(RB, K)
Alice, K Bob, K

 This provides mutual authentication…

 …or does it? See the next slide
Part 3  Protocols 28
Mutual Authentication Attack
1. “I’m Alice”, RA
2. RB, E(RA, K)

Trudy Bob, K

3. “I’m Alice”, RB

4. RC, E(RB, K)

Trudy Bob, K
Part 3  Protocols 29
 Mutual Authentication
 Our one-way authentication protocol is
not secure for mutual authentication
o Protocols are subtle!
o The “obvious” thing may not be secure
 Also, if assumptions or environment
change, protocol may not be secure
o This is a common source of security failure
o For example, Internet protocols

Part 3  Protocols 30
 Symmetric Key Mutual
Authentication
“I’m Alice”, RA

RB, E(“Bob”,RA,K)

E(“Alice”,RB,K)
Alice, K Bob, K

 Do these “insignificant” changes help?

 Yes!
Part 3  Protocols 31
 Public Key Notation
 Encrypt M with Alice’s public key: {M}Alice
 Sign M with Alice’s private key: [M]Alice
 Then
o [{M}Alice ]Alice = M
o {[M]Alice }Alice = M
 Anybody can use Alice’s public key
 Only Alice can use her private key

Part 3  Protocols 32
 Public Key Authentication

“I’m Alice”
{R}Alice

R
Alice Bob
 Is this secure?
 Trudy can get Alice to decrypt anything!
o So, should have two key pairs
Part 3  Protocols 33
 Public Key Authentication

“I’m Alice”

[R]Alice
Alice Bob
 Is this secure?
 Trudy can get Alice to sign anything!
o Same as previous  should have two key pairs
Part 3  Protocols 34
 Public Keys
 Generally, a bad idea to use the same
key pair for encryption and signing
 Instead, should have…
o …one key pair for encryption/decryption…
o …and a different key pair for
signing/verifying signatures

Part 3  Protocols 35
 Session Key
 Usually, a session key is required
o i.e., a symmetric key for a particular session
o Used for confidentiality and/or integrity
 How to authenticate and establish a
session key (i.e., shared symmetric key)?
o When authentication completed, want Alice and
Bob to share a session key
o Trudy cannot break the authentication…
o …and Trudy cannot determine the session key

Part 3  Protocols 36
Authentication & Session Key
“I’m Alice”, R
{R,K}Alice

{R +1,K}Bob
Alice Bob

 Is this secure?
o Alice is authenticated and session key is secure
o Alice’s “nonce”, R, useless to authenticate Bob
o The key K is acting as Bob’s nonce to Alice
 No mutual authentication
Part 3  Protocols 37
 Public Key Authentication
and Session Key
“I’m Alice”, R
[R,K]Bob

[R +1,K]Alice
Alice Bob

 Is this secure?
o Mutual authentication (good), but…
o … session key is not secret (very bad)

Part 3  Protocols 38
 Public Key Authentication
and Session Key
“I’m Alice”, R
{[R,K]Bob}Alice

{[R +1,K]Alice}Bob
Alice Bob

 Is this secure?
 Seems to be OK
 Mutual authentication and session key!
Part 3  Protocols 39
 Public Key Authentication
and Session Key
“I’m Alice”, R
[{R,K}Alice]Bob

[{R +1,K}Bob]Alice
Alice Bob

 Is this secure?
 Seems to be OK
o Anyone can see {R,K}Alice and {R +1,K}Bob
Part 3  Protocols 40
 Timestamps
 A timestamp T is derived from current time
 Timestamps used in some security protocols
o Kerberos, for example
 Timestamps reduce number of msgs (good)
o Like a nonce that both sides know in advance
 “Time” is a security-critical parameter (bad)
 Clocks never exactly the same, so must allow
for clock skew  creates risk of replay
o How much clock skew is enough?

Part 3  Protocols 41
 Public Key Authentication
with Timestamp T
“I’m Alice”, {[T, K]Alice}Bob
{[T +1, K]Bob}Alice

Alice Bob

 Secure mutual authentication?

 Session key?
 Seems to be OK
Part 3  Protocols 42
 Public Key Authentication
with Timestamp T
“I’m Alice”, [{T, K}Bob]Alice
[{T +1, K}Alice]Bob

Alice Bob

 Secure authentication and session key?

 Trudy can use Alice’s public key to find
{T, K}Bob and then…
Part 3  Protocols 43
 Public Key Authentication
with Timestamp T

“I’m Trudy”, [{T, K}Bob]Trudy

[{T +1, K}Trudy]Bob

Trudy Bob

 Trudy obtains Alice-Bob session key K

 Note: Trudy must act within clock skew

Part 3  Protocols 44
 Public Key Authentication
 Sign and encrypt with nonce…
o Secure
 Encrypt and sign with nonce…
o Secure
 Sign and encrypt with timestamp…
o Secure
 Encrypt and sign with timestamp…
o Insecure
 Protocols can be subtle!

Part 3  Protocols 45
 Public Key Authentication
with Timestamp T

“I’m Alice”, [{T, K}Bob]Alice

[{T +1}Alice]Bob

Alice Bob

 Is this “encrypt and sign” secure?

o Yes, seems to be OK
 Does “sign and encrypt” also work here?
Part 3  Protocols 46
 Perfect Forward Secrecy
 Consider this “issue”…
o Alice encrypts message with shared key K and
sends ciphertext to Bob
o Trudy records ciphertext and later attacks
Alice’s (or Bob’s) computer to recover K
o Then Trudy decrypts recorded messages
 Perfect forward secrecy (PFS): Trudy
cannot later decrypt recorded ciphertext
o Even if Trudy gets key K or other secret(s)
 Is PFS possible?
Part 3  Protocols 47
 Perfect Forward Secrecy
 Suppose Alice and Bob share key K
 For perfect forward secrecy, Alice and Bob
cannot use K to encrypt
 Instead they must use a session key KS and
forget it after it’s used
 Can Alice and Bob agree on session key KS
in a way that ensures PFS?
o Real protocols – used in SSH

Part 3  Protocols 48
 Naïve Session Key Protocol

E(KS, K)

E(messages, KS)

Alice, K Bob, K

 Trudy could record E(KS, K)

 If Trudy later gets K then she can get KS
o Then Trudy can decrypt recorded messages
Part 3  Protocols 49
 Perfect Forward Secrecy
 We use Diffie-Hellman for PFS
 Recall: public g and p

ga mod p
gb mod p

Alice, a Bob, b
 But Diffie-Hellman is subject to MiM
 How to get PFS and prevent MiM?

Part 3  Protocols 50
 Perfect Forward Secrecy
E(ga mod p, K)
E(gb mod p, K)

Alice: K, a Bob: K, b

 Session key KS = gab mod p

 Alice forgets a, Bob forgets b
 So-called Ephemeral Diffie-Hellman
 Neither Alice nor Bob can later recover KS
 Are there other ways to achieve PFS?
Part 3  Protocols 51
 Mutual Authentication,
Session Key and PFS
“I’m Alice”, RA
RB, [{RA, gb mod p}Alice]Bob

[{RB, ga mod p}Bob]Alice

Alice, a Bob, b
 Session key is K = gab mod p
 Alice forgets a and Bob forgets b
 If Trudy later gets Bob’s and Alice’s secrets
(i.e. private keys), she cannot recover session
key Ks
Part 3  Protocols 52
 Authentication and TCP

Part 3  Protocols 53
 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 relies on IP
address for authentication

Part 3  Protocols 54
 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 sequence numbers: SEQ a and SEQ b
o Supposed to be selected at random
 If not…
Part 3  Protocols 55
 TCP Authentication Attack

Trudy Bob

5.
5.
5.

5. Alice
Part 3  Protocols 56
 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 57
 TCP Authentication Attack
 Trudy cannot see what Bob sends, but she can
send packets to 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 can succeed
 Bad idea to rely on TCP for authentication

Part 3  Protocols 58
 Zero Knowledge Proofs

Part 3  Protocols 59
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 But, Bob 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 60
 Bob’s Cave
 Alice knows secret
phrase to open path P
between R and S
(“open sesame”)
 Can she convince Q
Bob that she knows R S
the secret without
revealing phrase?

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

 Alice (quietly):
“Open sesame”
Q
 If Alice does not
R S
know the 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 62
 Fiat-Shamir Protocol
 Cave-based protocols are inconvenient
o Can we achieve same effect without the cave?
 Finding square roots modulo N is difficult
o Equivalent to 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 63
 Fiat-Shamir
x = r2 mod N
e  {0,1}
y = r  Se mod N
Alice Bob
secret S random e
random r
 Public: Modulus N and v = S2 mod N
 Alice selects random r, Bob chooses e  {0,1}
 Bob verifies: y2 = x  ve mod N
o Why? Because… y2 = r2  S2e = r2  (S2)e = x  ve mod N
Part 3  Protocols 64
 Fiat-Shamir: e = 1
x = r2 mod N
e=1
y = r  S mod N
Alice Bob
secret S random e
random r
 Public: Modulus N and v = S2 mod N
 Alice selects random r, Bob chooses e =1
 If y2 = x  v mod N then Bob accepts it
o i.e., “Alice” passes this iteration of the protocol
 Note that Alice must know S in this case
Part 3  Protocols 65
 Fiat-Shamir: e = 0
x = r2 mod N
e=0
y = r mod N
Alice Bob
secret S random e
random r

 Public: Modulus N and v = S2 mod N

 Alice selects random r, Bob chooses e = 0
 Bob checks if y2 = x mod N
 Alice does not need to know S in this case!

Part 3  Protocols 66
 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 whether y2 = x  ve mod N
o Does this prove response is from Alice?

Part 3  Protocols 67
 Does Fiat-Shamir Work?
 If everyone follows protocol, math works:
o Public: v = S2 mod N
o Alice to Bob: x = r2 mod N and y = r  Se mod N
o Bob verifies: y2 = x  ve mod N
 Can Trudy convince Bob she is Alice?
o If Trudy expects e = 0, she sends x = r2 in msg 1
and y = r in msg 3 (i.e., follow the protocol)
o If Trudy expects e = 1, sends x = r2  v1 in msg 1
and y = r in msg 3
 If Bob chooses e  {0,1} at random, Trudy
can only trick Bob with probability 1/2
Part 3  Protocols 68
 Fiat-Shamir Facts
 Trudy can trick Bob with probability 1/2, but…
o …after n iterations, the probability that Trudy can
convince Bob that she is Alice is only 1/2n
o 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 mod N in message 3
o If e = 1, Alice sends r  S mod N in message 3
o Anyone can find S given r mod N and r  S mod N

Part 3  Protocols 69
Fiat-Shamir Zero Knowledge?
 Zero knowledge means that nobody learns
anything about the secret S
o Public: v = S2 mod N
o Trudy sees r2 mod N in message 1
o Trudy sees r  S mod N in message 3 (if e = 1)
 If Trudy can find r from r2 mod N, gets S
o But that requires modular square root
o If Trudy could find modular square roots, she
could get S from public v
 Protocol does not seem to “help” to find S
Part 3  Protocols 70
 ZKP in the Real World
 Public key certificates identify users
o No anonymity if certificates sent in plaintext
 ZKP offers a way to authenticate without revealing
identities
 ZKP supported in MS’s Next Generation Secure
Computing Base (NGSCB)*, where…
o … ZKP used to authenticate software “without revealing
machine identifying data”
 Blockchains!
 ZKP is not just pointless mathematics!
* “cancelled software architecture designed by Microsoft which aimed to provide users of the Windows OS with
better privacy, security, and system integrity.” – [ref.]

Part 3  Protocols 71
Best Authentication Protocol?
 It depends on…
o The sensitivity of the application/data
o The delay that is tolerable
o The cost (computation) that is tolerable
o What crypto is supported (public key,
symmetric key, …)
o Whether mutual authentication is required
o Whether PFS, anonymity, etc., are concern
 …and possibly other factors
Part 3  Protocols 72
 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 73

 Real-World Protocols
 Next, we look at real protocols
o SSH  a simple & useful security 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 74
 Secure Shell (SSH)

Part 3  Protocols 75
 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 76
 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, see homework problems
 We consider slightly simplified SSH…

Part 3  Protocols 77
 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
 K = gab mod p
Part 3  Protocols 78
 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:
o Ha = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gt mod p,gat mod p)
 But Bob signs:
o Hb = h(Alice,Bob,CP,CS,RA,RB,gt mod p,gb mod p,gbt mod p)

Part 3  Protocols 79
 Secure Socket Layer

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

Part 3  Protocols 81
 What is SSL?
 SSL is the protocol used for majority of
secure transactions on 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 does not
care who you are
o So, no need for mutual authentication

Part 3  Protocols 82
 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 83
 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 known as pre-master secret

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

Part 3  Protocols 84
 SSL Keys
6 “keys” derived from K = h(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?
 A: Apparently, it adds no security…

Part 3  Protocols 85
 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 86
 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 Trudy
E(data,K1) 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 87
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 session
Part 3  Protocols 88
 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
 Alice chooses session-ID for the connection &
both sides must remember session-ID
 Again, K = h(S,RA,RB)
 No public key operations! (relies on known S)
Part 3  Protocols 89
 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 90
 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 should be!
Part 3  Protocols 91
 IPSec

Part 3  Protocols 92
 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 93
 IPSec and Complexity
 IPSec is a complex protocol
 Over-engineered
o Lots of (generally useless) features
 Flawed
o 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 94
 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
encryption and/or integrity of IP packets
o AH: Authentication Header  integrity only
Part 3  Protocols 95
 IKE

Part 3  Protocols 96
 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 costly to have two phases!

Part 3  Protocols 97
 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 and aggressive mode
 There are 8 versions of IKE Phase 1!
 Need more evidence it’s over-engineered?

Part 3  Protocols 98
 IKE Phase 1
 We discuss 6 of 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 key

Part 3  Protocols 99
 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 100

 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 mod p,gb mod p,IC,RC,CP,“Alice”)]Alice
Part 3  Protocols 101
 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 102

 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 identity
in main mode
Part 3  Protocols 103
 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 104
 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 105
 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
 But does not (pretend to) hide identities
Part 3  Protocols 106
 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 Bob
IC,RC, E(proofB, K)
 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 mod p,gb mod p,IC,RC,CP,“Alice”)
Part 3  Protocols 107
 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 108
 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
 This also works in main mode

Part 3  Protocols 109

 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 110
 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 IPSec 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 signed)
Part 3  Protocols 111
 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 112

 IKE Phase 1 Summary
 Result of IKE phase 1 is
o Mutual authentication
o Shared symmetric key (i.e., session 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 113
 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 114

 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 115
 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 Considered from the perspective of IPSec…

Part 3  Protocols 116

 IP Review
 IP datagram is of the form

IP header data

 Where IP header is

Part 3  Protocols 117

 IP and TCP
 Consider Web traffic
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 118
 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 119
 IPSec: Host-to-Host
 IPSec transport mode

 There may be firewalls in between

o If so, is that a problem?
Part 3  Protocols 120
 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 IP header from firewall to firewall
o Attacker does not know which hosts are talking
Part 3  Protocols 121
 IPSec: Firewall-to-Firewall
 IPSec tunnel mode

 Local networks not protected

 Is there any advantage here?

Part 3  Protocols 122

 Comparison of IPSec Modes
 Transport Mode  Transport Mode
IP header
o Host-to-host
data
 Tunnel Mode
IP header ESP/AH data o Firewall-to-
firewall
 Tunnel Mode  Transport Mode
IP header data not necessary…
 …but it’s more
new IP hdr ESP/AH IP header data efficient
Part 3  Protocols 123
 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 124
 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 125

 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
 Bottom line: Security people can be strange
Part 3  Protocols 126
 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 127
 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 the firewalls

Part 3  Protocols 128

 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 129

 Kerberos

Part 3  Protocols 130

 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 work by Needham and Schroeder
o Relies on a Trusted Third Party (TTP)

Part 3  Protocols 131

 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 132

 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.
o done offline by hashing each user’s password
 And a master key KKDC known only to KDC
 KDC enables authentication, session keys
o Session key for confidentiality and integrity
 Default crypto algorithm is DES
Part 3  Protocols 133
 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 134
 Kerberized Login
 Alice enters her password
 Then Alice’s computer does the 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 135

 Kerberized Login (phase 1)
Alice wants
Alice’s a TGT
password
E(SA,TGT,KA)

Alice Computer KDC

 Key KA = h(Alice’s password)
 TGT = E(“Alice”, SA, KKDC)
 KDC creates session key SA and TGT
 KDC encrypts SA and TGT with KA
 Alice’s computer decrypts ciphertext & obtains SA and TGT
o Then it forgets KA
Part 3  Protocols 136
 Alice Requests “Ticket to Bob”
(phase 2)
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 137
 Alice Uses Ticket to Bob
(phase 3)
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 138
 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 139
 Kerberos Questions
 When Alice logs in, KDC sends E(SA, TGT, KA)
where TGT = E(“Alice”, SA, KKDC)
Q: Why is TGT encrypted with KA?
A: Extra work for no added security!
 In Alice’s “Kerberized” login to access Bob
(phase 2), why can Alice remain anonymous?
o compare with IPSec (symm. key & main mode)
 Why is “ticket to Bob” sent to Alice?
o Why doesn’t KDC send it directly to Bob?
Part 3  Protocols 140
 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 141

 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 142
 WEP

Part 3  Protocols 143

 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 shall see.”
Part 3  Protocols 144
 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 flaws
Part 3  Protocols 145
 WEP Issues
 WEP uses RC4 cipher for confidentiality
o RC4 is considered 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 or HMAC instead
o CRC is for error detection, not crypto integrity
o Everyone knows NOT to use CRC for this…

Part 3  Protocols 146

 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 remains correct
o Then Trudy’s introduced errors 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 able to detect intelligent changes

Part 3  Protocols 147

 More WEP Integrity Issues
 Suppose Trudy knows destination IP
 Then Trudy also knows keystream used to
encrypt IP address, since…
o … C = destination IP address  keystream
 Then Trudy can replace C with…
o … C = Trudy’s IP address  keystream
 And change the CRC so no error detected!
o Then what happens??
 Moral: Big problem when integrity fails
Part 3  Protocols 148
 WEP Key
 Recall WEP uses a long-term secret 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 msg. indicator (“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 149

 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
 Note that the IV is known to Trudy

Part 3  Protocols 150

 WEP IV Issues
 WEP uses 24-bit (3 byte) IV
o Each packet gets a new 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 151
 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…
o …an IV must repeat in about 5 hours
 Suppose IVs generated at random
o By birthday problem, some IV repeats in
seconds
 Again, repeated IV (with same K) is bad!

Part 3  Protocols 152

 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(s) 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 153
 Cryptanalytic Attack
 WEP data encrypted using RC4
o Packet key is IV and 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 IVs and ciphertext
o Trudy wants to find the key K
Part 3  Protocols 154
 Cryptanalytic Attack
 3-byte IV pre-pended to key
 Denote the RC4 key bytes…
o …as K0,K1,K2,K3,K4,K5, …
o Where IV = (K0,K1,K2) , which Trudy knows
o Trudy wants to find K = (K3,K4,K5, …)
 Given enough IVs, Trudy can 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)
o Prevent by discarding first 256 keystream bytes
Part 3  Protocols 155
 WEP Conclusions
 Many attacks are practical
 Attacks have been used to recover keys
and break real WEP traffic
 How to prevent WEP 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 156

 GSM (In)Security

Part 3  Protocols 157

 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 158

 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 159

 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 160

 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 161
 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 feasible…
 Designers considered biggest threats to be
o Insecure billing
o Corruption
o Other low-tech attacks
Part 3  Protocols 162
 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 May be important for marketing
Part 3  Protocols 163
 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 sufficient for most uses

Part 3  Protocols 164

 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 165
 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 166
 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 167

 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 168

 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 169

 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: GSM bill goes to fake base station!

Part 3  Protocols 170

 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 171

 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.
 GSM a (modest) security success?
Part 3  Protocols 172
 3GPP: 3rd Generation
Partnership Project
 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 173
 Protocols Summary
 Generic authentication protocols
o Protocols are subtle!
 SSH
 SSL
 IPSec
 Kerberos
 Wireless: GSM and WEP
Part 3  Protocols 174
 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 175