Part III: Protocols

Part 3

Protocols

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

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 Recent IE implementation of SSL

Not

Part 3

easy to get protocols right

Protocols

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

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

Secure Entry to NSA

1.
2.
3.

Insert badge into reader

Enter PIN
Correct PIN?

Yes? Enter
No? Get shot by security guard

Part 3

Protocols

ATM Machine Protocol

1.
2.
3.

Insert ATM card

Enter PIN
Correct PIN?

Yes? Conduct your transaction(s)

No? Machine (eventually) eats card

Part 3

Protocols

Identify Friend or Foe (IFF)

Russian
MIG

Angola

2.

SAAF
Impala

Part 3

1.

Protocols

E(N,K)
Namibia
K
8

MIG in the Middle

3.
SAAF
Impala

4.

E(N,K)

2.

5.
6.

Russian
MiG

Part 3

1.

Protocols

Angola

N
E(N,K)

E(N,K)
Namibia
K
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 hes Bob

(mutual authentication)
Probably need to establish a session key
May have other requirements, such as

o
o
o
o
Part 3

Use public keys

Use symmetric keys
Use hash functions
Anonymity, plausible deniability, etc., etc.
Protocols

11

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

12

Simple Authentication
Im 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 Alices password

Part 3

Protocols

13

Authentication Attack
Im Alice
Prove it
My password is frank
Bob

Alice

Trudy
Part 3

Protocols

14

Authentication Attack
Im 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

15

Simple Authentication
Im Alice, my password is frank
Alice

Bob

More efficient, but

same problem as previous version

Part 3

Protocols

16

Better Authentication
Im Alice
Prove it
h(Alices password)
Alice

Bob

Better since it hides Alices password

o From both Bob and Trudy

But still subject to replay

Part 3

Protocols

17

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

18

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

19

Challenge-Response
Im Alice
Nonce
h(Alices 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 Alices pwd to verify

Part 3

Protocols

20

Generic Challenge-Response
Im Alice
Nonce
Alice

Something that could only be

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

21

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

22

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

23

Authentication with
Symmetric Key
Im Alice
R
Alice, K

E(R,K)

Bob, K

Secure method for Bob to authenticate Alice

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

Part 3

Protocols

24

Mutual Authentication?
Im Alice, R
E(R,K)
Alice, K

E(R,K)

Bob, K

Whats wrong with this picture?

Alice could be Trudy (or anybody else)!

Part 3

Protocols

25

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

Part 3

has got to work

Protocols

26

Mutual Authentication
Im Alice, RA
RB, E(RA, K)
Alice, K

E(RB, K)

Bob, K

This provides mutual authentication

or does it? See the next slide

Part 3

Protocols

27

Mutual Authentication Attack

1. Im Alice, RA
2. RB, E(RA, K)
Trudy

5. E(RB, K)

Bob, K

3. Im Alice, RB
4. RC, E(RB, K)
Trudy
Part 3

Protocols

Bob, K
28

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

29

Symmetric Key Mutual

Authentication
Im Alice, RA
RB, E(Bob,RA,K)
E(Alice,RB,K)
Alice, K

Bob, K

Do these insignificant changes help?

Yes!

Part 3

Protocols

30

Public Key Notation

Encrypt M with Alices public key: {M}Alice

Sign M with Alices private key: [M]Alice

Then
o [{M}Alice ]Alice = M
o {[M]Alice }Alice = M

Anybody can use Alices public key

Only Alice can use her private key

Part 3

Protocols

31

Public Key Authentication

Im 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

32

Public Key Authentication

Im Alice
R
[R]Alice
Bob

Alice

Is this secure?
Trudy can get Alice to sign anything!

o Same a previous

Part 3

Protocols

should have two key pairs

33

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

34

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

35

Authentication & Session Key

Im Alice, R
{R,K}Alice
Alice

{R +1,K}Bob

Bob

Is this secure?

o Alice is authenticated and session key is secure

o Alices nonce, R, useless to authenticate Bob
o The key K is acting as Bobs nonce to Alice

No mutual authentication

Part 3

Protocols

36

Public Key Authentication

and Session Key
Im 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

37

Public Key Authentication

and Session Key
Im Alice, R
{[R,K]Bob}Alice
Alice

{[R +1,K]Alice}Bob

Bob

Is this secure?
Seems to be OK
Mutual authentication and session key!

Part 3

Protocols

38

Public Key Authentication

and Session Key
Im 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

39

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
Alices (or Bobs) 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

40

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 its used
Can Alice and Bob agree on session key KS in
a way that ensures PFS?

Part 3

Protocols

41

Nave 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

42

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

43

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

44

Mutual Authentication,
Session Key and PFS
Im Alice, RA
RB, [{RA, gb mod p}Alice]Bob
[{RB, ga mod p}Bob]Alice
Alice

Bob

Session key is K = gab mod p

Alice forgets a and Bob forgets b
If Trudy later gets Bobs and Alices secrets,
she cannot recover session key K

Part 3

Protocols

45

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

46

Public Key Authentication

with Timestamp T
Im Alice, {[T, K]Alice}Bob
{[T +1, K]Bob}Alice
Alice

Bob

Secure mutual authentication?

Session key?
Seems to be OK

Part 3

Protocols

47

Public Key Authentication

with Timestamp T
Im Alice, [{T, K}Bob]Alice
[{T +1, K}Alice]Bob
Alice

Bob

Secure authentication and session key?

Trudy can use Alices public key to find
{T, K}Bob and then

Part 3

Protocols

48

Public Key Authentication

with Timestamp T
Im 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

49

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

50

Public Key Authentication

with Timestamp T
Im 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

51

Authentication and TCP

Part 3

Protocols

52

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

53

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

54

TCP Authentication Attack

1. SYN, SEQ = t (as

Trudy)
2. SYN, ACK = t+1, SEQ =
b1

3. SYN, SEQ = t (as

Alice)
5. ACK = b2+1, data

Trudy

Bob

5.
5.
5.
5.
Part 3

Protocols

Alice

Y
S
4.

=
K
C
,A

SE
,
1
t+

b2

55

TCP Authentication Attack

Random SEQ numbers

Initial 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

56

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 Bobs
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

57

Zero Knowledge Proofs

Part 3

Protocols

58

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

59

Bobs Cave
Alice knows secret
phrase to open path
between R and S
(open sarsaparilla)
Can she convince
Bob that she knows
the secret without
revealing phrase?

Part 3

Protocols

Q
R

60

Bobs Cave

Bob: Alice come out on S side

Alice (quietly):
Open sarsaparilla

If Alice does not

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

61

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

62

Fiat-Shamir
x = r2 mod N
e {0,1}
y = r Se mod N
Alice
secret S
random r

Bob
random e

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

Protocols
mod
N

Part 3

63

Fiat-Shamir: e = 1
x = r2 mod N
e=1
y = r S mod N
Alice
secret S
random r

Bob
random e

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

64

Fiat-Shamir: e = 0
x = r2 mod N
e=0
Alice
secret S
random r

y = r mod N
Bob
random e

Public: Modulus N and v = S2 mod N

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

Part 3

Protocols

65

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

66

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 v1 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

67

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 Bobs cave!

Bobs 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

68

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

69

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 MSs Next Generation
Secure Computing Base (NGSCB), where

o ZKP used to authenticate software without

revealing machine identifying data

ZKP is not just pointless mathematics!

Part 3

Protocols

70

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

71

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

72

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

73

Secure Shell (SSH)

Part 3

Protocols

74

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
Part 3

is a relatively simple protocol

Protocols

75

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
Part 3

consider slightly simplified SSH

Protocols

76

Simplified SSH

Alice

Alice, CP, RA
CS, RB
ga mod p
gb mod p, certificateB, SB
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

ab
Part=
3 gProtocols
K
mod p

77

MiM Attack on SSH?

Alice, RA

Alice, RA

RB
ga mod p

RB
gt mod p

gt mod p, certB, SB

Alice E(Alice,certA,SA,K)

Trudy

gb mod p, certB, SB
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

78

Secure Socket Layer

Part 3

Protocols

79

Socket layer
Socket layer
lives between
application
and transport
layers
SSL usually
between HTTP
and TCP

Part 3

Protocols

Socket
layer

application

User

transport

OS

network
link

NIC

physical
80

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

81

Simple SSL-like Protocol

Id like to talk to you securely
Heres my certificate
{K}Bob
Alice

protected HTTP

Bob

Is Alice sure shes talking to Bob?

Is Bob sure hes talking to Alice?

Part 3

Protocols

82

Simplified SSL Protocol

Can we talk?, cipher list, RA
certificate, cipher, RB
{S}Bob, E(h(msgs,CLNT,K),K)
Alice

h(msgs,SRVR,K)
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

83

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

84

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

85

SSL MiM Attack?

RA
certificateT, RB
{S1}Trudy,E(X1,K1)
h(Y1,K1)
E(data,K1)
Alice

Trudy

RA
certificateB, RB
{S2}Bob,E(X2,K2)
h(Y2,K2)
E(data,K2)

Bob

Q: What prevents this MiM attack?

A: Bobs 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

86

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

87

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

88

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

89

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

90

IPSec

Part 3

Protocols

91

IPSec and SSL

IPSec lives at
the network
layer
IPSec is
transparent to
applications

SSL

IPSec

application

User

transport

OS

network
link

NIC

physical
Part 3

Protocols

92

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, its complex?

Part 3

Protocols

93

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

94

IKE

Part 3

Protocols

95

IKE

IKE has 2 phases

o Phase 1
o Phase 2

IKE security association (SA)

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 2s do not occur, then it
is more costly to have two phases!

Part 3

Protocols

96

IKE Phase 1

Four different key options

o
o
o
o

Public key encryption (original version)

Public key encryption (improved version)
Public key signature
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 its over-engineered?

Part 3

Protocols

97

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 sides public key

Part 3

Protocols

98

IKE Phase 1

Uses ephemeral Diffie-Hellman to

establish session key
o Provides perfect forward secrecy (PFS)

Let a be Alices Diffie-Hellman exponent

Let b be Bobs Diffie-Hellman exponent
Let g be generator and p prime
Recall that p and g are public

Part 3

Protocols

99

IKE Phase 1: Digital Signature

(Main Mode)
IC, CP
IC,RC, CS
IC,RC, ga mod p, RA

Alice

IC,RC, gb mod p, RB
IC,RC, E(Alice, proofA, K)
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
Part
3 Protocols
100
p,IC,RC,CP,Alice)]
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 difference from main mode

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

Part 3

Protocols

101

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 Alices and Bobs
identity in main mode
Part 3

Protocols

102

IKE Phase 1: Symmetric Key

(Main Mode)
IC, CP
IC,RC, CS
IC,RC, ga mod p, RA
Alice
KAB

IC,RC, gb mod p, RB
IC,RC, E(Alice, proofA, K)
IC,RC, E(Bob, proofB, K)

Bob
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

Part 3

Protocols

p,IC,RC,CP,Alice)

103

Problems with Symmetric

Key (Main Mode)

Catch-22

o Alice sends her ID in message 5

o Alices ID encrypted with K
o To find K Bob must know KAB

o To get KAB Bob must know hes talking to Alice!

Result: Alices 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

104

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

105

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

Alice

IC,RC, E(proofA, K)
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 mod p,gb mod
Part 3 Protocols
106
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

107

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

108

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
as Alice

IC,RC, proofA

Trudy
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

109

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

110

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

111

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

112

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, its not!

Part 3

Protocols

113

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

114

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

115

IP Review

IP datagram is of the form

IP header

data

Where IP header is

Part 3

Protocols

116

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
Part 3

data includes TCP header, etc.

Protocols

117

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

118

IPSec: Host-to-Host
IPSec

transport mode

There

may be firewalls in between

o If so, is that a problem?

Part 3

Protocols

119

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

120

IPSec: Firewall-to-Firewall
IPSec

tunnel mode

Local

networks not protected

Is there any advantage here?
Part 3

Protocols

121

Comparison of IPSec Modes

Transport

Mode

IP header data

IP header data
new IP hdr
Part 3

ESP/AH
Protocols

Tunnel Mode
o Firewall-to-

data

Mode

Transport Mode
o Host-to-host

IP header ESP/AH

Tunnel

firewall

Transport Mode
not necessary
but its more
efficient

IP header data
122

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

123

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

124

ESPs NULL Encryption

According to RFC 2410

o NULL encryption is a block cipher the origins of

o
o
o
o
o

which appear to be lost in antiquity

Despite rumors, there is no evidence that NSA
suppressed publication of this algorithm
Evidence suggests it was developed in Roman
times as exportable version of Caesars cipher
Can make use of keys of varying length
No IV is required
Null(P,K) = P for any P and any key K

Bottom line: Security people can be strange

Part 3

Protocols

125

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

126

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

127

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. Hes right, and we hate AH
also, but if it annoys Microsoft lets leave
it in since we hate Microsoft more than we
hate AH.
Part 3

Protocols

128

Kerberos

Part 3

Protocols

129

Kerberos

In Greek mythology, Kerberos is 3-headed

dog that guards entrance to Hades

o Wouldnt 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

130

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

131

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

o Session key for confidentiality and integrity

In practice, crypto algorithm is DES

Part 3

Protocols

132

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 Users ID
o Expiration time

Every TGT is encrypted with KKDC

o So, TGT can only be read by the KDC

Part 3

Protocols

133

Kerberized Login
Alice enters her password
Then Alices computer does following:

o Derives KA from Alices 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
its trusted!

Part 3

Protocols

134

Kerberized Login
Alice wants
a TGT

Alices
password

E(SA,TGT,KA)

Computer

Alice

KDC

Key KA = h(Alices password)

KDC creates session key SA
Alices computer decrypts SA and TGT

o Then it forgets KA

TGT = E(Alice, SA, KKDC)

Part 3

Protocols

135

Alice Requests Ticket to Bob

I want to
talk to Bob
REQUEST

Talk to Bob

REPLY

Computer

Alice

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

136

Alice Uses Ticket to Bob

ticket to Bob, authenticator
E(timestamp + 1, KAB)
Alices
Computer

ticket to Bob = E(Alice, KAB, KB)

authenticator = E(timestamp, KAB)

Bob

Bob decrypts ticket to Bob to get KAB which

he then uses to verify timestamp

Part 3

Protocols

137

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

138

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 Alices Kerberized login to Bob, why

can Alice remain anonymous?

Why is ticket to Bob sent to Alice?

o Why doesnt KDC send it directly to Bob?

Part 3

Protocols

139

Kerberos Alternatives

Could have Alices 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

140

Kerberos Keys
In Kerberos, KA = h(Alices password)
Could instead generate random KA

o Compute Kh = h(Alices password)

o And Alices 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

141

WEP

Part 3

Protocols

142

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

143

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

144

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

145

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 Trudys 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

146

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 = Trudys IP address keystream

And change the CRC so no error detected!

o Then what happens??

Moral: Big problem when integrity fails

Part 3

Protocols

147

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

148

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

149

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

150

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

151

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

152

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

153

Cryptanalytic Attack
3-byte IV pre-pended to key
Denote the RC4 key bytes
o asK0,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
o
o
o
Part 3

Regardless of the length of the key!

Provided Trudy knows first keystream byte
Known plaintext attack (1st byte of each packet)
Prevent by discarding first 256 keystream bytes
Protocols

154

WEP Conclusions
Many attacks are practical
Attacks have been used to recover keys
and break real WEP traffic
How to prevent WEP attacks?

o Dont use WEP

o Good alternatives: WPA, WPA2, etc.

How to make WEP a little better?

o Restrict MAC addresses, dont broadcast ID,

Part 3

Protocols

155

GSM (In)Security

Part 3

Protocols

156

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

157

GSM System Overview

air
interface
Mobile

Base
Station

Part 3

land line
Base
Station
Controller

Visited
Network

Protocols

AuC

VLR
PSTN
Internet
etc.

HLR
Home
Network

158

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)
o Tamper resistant (smart card)
o PIN activated (usually not used)

Part 3

Protocols

SIM

159

GSM System Components

Visited network
currently located

network where mobile is

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

160

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

161

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

162

GSM: Anonymity
IMSI used to initially identify caller
Then TMSI (Temporary Mobile Subscriber
ID) used

o TMSI changed frequently

o TMSIs encrypted when sent

Not a strong form of anonymity

But probably sufficient for most uses

Part 3

Protocols

163

GSM: Authentication
Caller is authenticated to base station
Authentication is not mutual
Authentication via challenge-response

o Home network generates RAND and computes

o
o
o
o

XRES = A3(RAND, Ki) where A3 is a hash

Then (RAND,XRES) sent to base station
Base station sends challenge RAND to mobile
Mobiles response is SRES = A3(RAND, Ki)
Base station verifies SRES = XRES

Note: Ki never leaves home network!

Part 3

Protocols

164

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

165

GSM Security
1. IMSI

2. IMSI

4. RAND
Mobile

5. SRES
6. Encrypt with Kc

3. (RAND,XRES,Kc)

Base
Station

Home
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 RANDs

Part 3

Protocols

166

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

Encryption between mobile and base

station but no encryption from base
station to base station controller
o Often transmitted over microwave link

Base
Station
VLR

Encryption algorithm A5/1

o Broken with 2 seconds of known plaintext

Part 3

Protocols

Base
Station
Controller
167

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

168

GSM Insecurity (3)

Fake base station exploits two flaws

o Encryption not automatic
o Base station not authenticated
RAND
SRES

Mobile

No
encryption

Call to
destination
Fake
Base Station

Base Station

Note: GSM bill goes to fake base station!

Part 3

Protocols

169

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

170

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

171

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
o
o
o
o

Part 3

encryption command)
Keys (encryption/integrity) cannot be reused
Triples cannot be replayed
Strong encryption algorithm (KASUMI)
Encryption extended to base station controller
Protocols

172

Protocols Summary
Generic

authentication protocols

o Protocols are subtle!

SSH
SSL
IPSec
Kerberos
Wireless:
Part 3

Protocols

GSM and WEP

173

Coming Attractions
Software

o
o
o
o
o

Part 3

and security

Software flaws buffer overflow, etc.

Malware viruses, worms, etc.
Software reverse engineering
Digital rights management
OS and security/NGSCB

Protocols

174