2. Part 3 Protocols 2
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.
3. Part 3 Protocols 3
Protocols
Protocol flaws can be very subtle
Several well-known security protocols
have significant flaws
o Including WEP, GSM, and IPSec
Implementation errors can also occur
o Recently, IE implementation of SSL
Not easy to get protocols right…
4. Part 3 Protocols 4
Ideal Security Protocol
Must satisfy security requirements
o Requirements need to be precise
Efficient
o Minimize computational requirement
o Minimize bandwidth usage, delays…
Robust
o Works when attacker tries to break it
o Works if environment changes (slightly)
Easy to implement, easy to use, flexible…
Difficult to satisfy all of these!
5. 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
6. Part 3 Protocols 6
Secure Entry to NSA
1. Insert badge into reader
2. Enter PIN
3. Correct PIN?
Yes? Enter
No? Get shot by security guard
7. Part 3 Protocols 7
ATM Machine Protocol
1. Insert ATM card
2. Enter PIN
3. Correct PIN?
Yes? Conduct your transaction(s)
No? Machine (eventually) eats card
8. Part 3 Protocols 8
Identify Friend or Foe (IFF)
Namibia
K
Angola
1. N
2. E(N,K)
SAAF
Impala
K
Russian
MIG
9. Part 3 Protocols 9
MIG in the Middle
Namibia
K
Angola
1. N
2. N
3. N
4. E(N,K)
5. E(N,K)
6. E(N,K)
SAAF
Impala
K
Russian
MiG
10. Part 3 Protocols 10
Authentication Protocols
11. 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 Public keys, symmetric keys, hash functions, …
o Anonymity, plausible deniability, perfect
forward secrecy, etc.
12. Part 3 Protocols 12
Authentication
Authentication on a stand-alone computer is
relatively simple
o For example, hash a password with a 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)
13. Part 3 Protocols 13
Simple Authentication
Alice Bob
“I’m Alice”
Prove it
My password is “frank”
Simple and may be OK for standalone system
But highly insecure for networked system
o Subject to a replay attack (next 2 slides)
o Also, Bob must know Alice’s password
14. Part 3 Protocols 14
Authentication Attack
Alice Bob
“I’m Alice”
Prove it
My password is “frank”
Trudy
15. Part 3 Protocols 15
Authentication Attack
Bob
“I’m Alice”
Prove it
My password is “frank”
Trudy
This is an example of a replay attack
How can we prevent a replay?
16. Part 3 Protocols 16
Simple Authentication
Alice Bob
I’m Alice, my password is “frank”
More efficient, but…
… same problem as previous version
17. Part 3 Protocols 17
Better Authentication
Alice Bob
“I’m Alice”
Prove it
h(Alice’s password)
This approach hides Alice’s password
o From both Bob and Trudy
But still subject to replay attack
18. 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
19. 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 use passwords or keys?
20. Part 3 Protocols 20
Challenge-Response
Bob
“I’m Alice”
Nonce
h(Alice’s password, Nonce)
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
Alice
21. Part 3 Protocols 21
Generic Challenge-Response
Bob
“I’m Alice”
Nonce
Something that could only be
Alice from Alice, and Bob can verify
In practice, how to achieve this?
Hashed password works, but…
…encryption is much better here (why?)
22. 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 cryptography
o So, we assume crypto algorithms are secure
23. 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, …
24. Part 3 Protocols 24
Authenticate Alice Using
Symmetric Key
Alice, K Bob, K
“I’m Alice”
E(R,K)
Secure method for Bob to authenticate Alice
But, Alice does not authenticate Bob
So, can we achieve mutual authentication?
R
25. Part 3 Protocols 25
Mutual Authentication?
Alice, K Bob, K
“I’m Alice”, R
E(R,K)
E(R,K)
What’s wrong with this picture?
“Alice” could be Trudy (or anybody else)!
26. 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…
27. Part 3 Protocols 27
Mutual Authentication
Alice, K Bob, K
“I’m Alice”, RA
RB, E(RA, K)
E(RB, K)
This provides mutual authentication…
…or does it? Subject to reflection attack
o Next slide
28. Part 3 Protocols 28
Mutual Authentication Attack
Bob, K
1. “I’m Alice”, RA
2. RB, E(RA, K)
Trudy
Bob, K
3. “I’m Alice”, RB
4. RC, E(RB, K)
Trudy
29. Part 3 Protocols 29
Mutual Authentication
Our one-way authentication protocol is
not secure for mutual authentication
o Protocols are subtle!
o In this case, “obvious” solution is not 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
30. Part 3 Protocols 30
Symmetric Key Mutual
Authentication
Alice, K Bob, K
“I’m Alice”, RA
RB, E(“Bob”,RA,K)
E(“Alice”,RB,K)
Do these “insignificant” changes help?
Yes!
31. 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
32. Part 3 Protocols 32
Public Key Authentication
Alice Bob
“I’m Alice”
{R}Alice
R
Is this secure?
Trudy can get Alice to decrypt anything!
Prevent this by having two key pairs
33. Part 3 Protocols 33
Public Key Authentication
Alice Bob
“I’m Alice”
R
[R]Alice
Is this secure?
Trudy can get Alice to sign anything!
o Same a previous should have two key pairs
34. 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
and signing/verifying signatures…
o …and a different key pair for
authentication
35. Part 3 Protocols 35
Session Key
Usually, a session key is required
o A symmetric key for current 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, Alice and Bob
share a session key
o Trudy cannot break the authentication…
o …and Trudy cannot determine the session key
36. Part 3 Protocols 36
Authentication & Session Key
Alice Bob
“I’m Alice”, R
{R, K}Alice
{R +1, K}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
37. Part 3 Protocols 37
Public Key Authentication
and Session Key
Alice Bob
“I’m Alice”, R
[R, K]Bob
[R +1, K]Alice
Is this secure?
o Mutual authentication (good), but…
o … session key is not protected (very bad)
38. Part 3 Protocols 38
Public Key Authentication
and Session Key
Alice Bob
“I’m Alice”, R
{[R, K]Bob}Alice
{[R +1, K]Alice}Bob
Is this secure?
No! It’s subject to subtle MiM attack
o See the next slide…
39. Part 3 Protocols 39
Public Key Authentication
and Session Key
Alice Bob
1. “I’m Alice”, R
4. { }Alice
5. {[R +1, K]Alice}Bob
Trudy can get [R, K]Bob and K from 3.
Alice uses this same key K
And Alice thinks she’s talking to Bob
Trudy
2. “I’m Trudy”, R
3. {[R, K]Bob}Trudy
6. time out
40. Part 3 Protocols 40
Public Key Authentication
and Session Key
Alice Bob
“I’m Alice”, R
[{R, K}Alice]Bob
[{R +1, K}Bob]Alice
Is this secure?
Seems to be OK
o Anyone can see {R, K}Alice and {R +1, K}Bob
41. Part 3 Protocols 41
Timestamps
A timestamp T is derived from current time
Timestamps can be used to prevent replay
o Used in Kerberos, for example
Timestamps reduce number of msgs (good)
o A challenge that both sides know in advance
“Time” is a security-critical parameter (bad)
o Clocks not same and/or network delays, so must
allow for clock skew creates risk of replay
o How much clock skew is enough?
42. Part 3 Protocols 42
Public Key Authentication
with Timestamp T
Bob
“I’m Alice”, {[T, K]Alice}Bob
{[T +1, K]Bob}Alice
Alice
Secure mutual authentication?
Session key secure?
Seems to be OK
43. Part 3 Protocols 43
Public Key Authentication
with Timestamp T
Bob
“I’m Alice”, [{T, K}Bob]Alice
[{T +1, K}Alice]Bob
Alice
Secure authentication and session key?
Trudy can use Alice’s public key to find
{T, K}Bob and then…
44. Part 3 Protocols 44
Public Key Authentication
with Timestamp T
Bob
“I’m Trudy”, [{T, K}Bob]Trudy
[{T +1, K}Trudy]Bob
Trudy
Trudy obtains Alice-Bob session key K
Note: Trudy must act within clock skew
45. Part 3 Protocols 45
Public Key Authentication
Sign and encrypt with nonce…
o Insecure
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!
46. Part 3 Protocols 46
Public Key Authentication
with Timestamp T
Bob
“I’m Alice”, [{T, K}Bob]Alice
[{T +1}Alice]Bob
Alice
Is this “encrypt and sign” secure?
o Yes, seems to be OK
Does “sign and encrypt” also work here?
47. Part 3 Protocols 47
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?
48. Part 3 Protocols 48
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 provides PFS?
49. Part 3 Protocols 49
Naïve Session Key Protocol
Trudy could record E(KS, K)
If Trudy later gets K then she can get KS
o Then Trudy can decrypt recorded messages
No perfect forward secrecy in this case
Alice, K Bob, K
E(KS, K)
E(messages, KS)
50. Part 3 Protocols 50
Perfect Forward Secrecy
We can use Diffie-Hellman for PFS
Recall: public g and p
But Diffie-Hellman is subject to MiM
How to get PFS and prevent MiM?
Alice, a Bob, b
ga mod p
gb mod p
51. Part 3 Protocols 51
Perfect Forward Secrecy
Session key KS = gab mod p
Alice forgets a, Bob forgets b
This is known as Ephemeral Diffie-Hellman
Neither Alice nor Bob can later recover KS
Are there other ways to achieve PFS?
Alice: K, a Bob: K, b
E(ga mod p, K)
E(gb mod p, K)
52. Part 3 Protocols 52
Mutual Authentication,
Session Key and PFS
Alice Bob
“I’m Alice”, RA
RB, [RA, gb mod p]Bob
[RB, ga mod p]Alice
Session key is K = gab mod p
Alice forgets a and Bob forgets b
If Trudy later gets Bob’s and Alice’s secrets,
she cannot recover session key K
54. Part 3 Protocols 54
TCP-based Authentication
TCP not intended for use as an
authentication protocol
But IP address in TCP connection may
be (mis)used for authentication
Also, one mode of IPSec relies on IP
address for authentication
55. Part 3 Protocols 55
TCP 3-way Handshake
Alice Bob
SYN, SEQ a
SYN, ACK a+1, SEQ b
ACK b+1, data
Initial sequence numbers: SEQ a and SEQ b
o Supposed to be selected at random
If not, might have problems…
56. Part 3 Protocols 56
TCP Authentication Attack
Alice
Bob
Trudy
5.
5.
5.
5.
57. Part 3 Protocols 57
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
58. Part 3 Protocols 58
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
response (or else connection will terminate)
If password (or other authentication) required,
this attack fails
If TCP connection is relied on for authentication,
then attack might succeed
Bad idea to rely on TCP for authentication
60. Part 3 Protocols 60
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 information about the secret
Process is probabilistic
o Bob can verify that Alice knows the secret to
an arbitrarily high probability
An “interactive proof system”
61. Part 3 Protocols 61
Bob’s 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?
P
Q
R S
62. Part 3 Protocols 62
Bob: “Alice, come out on S side”
Alice (quietly):
“Open sarsaparilla”
If Alice does not
know the secret…
If Bob repeats this n times and Alice does not know
secret, she can only fool Bob with probability 1/2n
…then Alice could come out from the correct side
with probability 1/2
P
Q
R S
Bob’s Cave
63. Part 3 Protocols 63
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
64. Part 3 Protocols 64
Fiat-Shamir
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 Note that y2 = r2 S2e = r2 (S2)e = x ve mod N
Alice
secret S
random r
Bob
random e
x = r2 mod N
e {0,1}
y = r Se mod N
65. Part 3 Protocols 65
Fiat-Shamir: e = 1
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 And Alice passes this iteration of the protocol
Note that Alice must know S in this case
Alice
secret S
random r
Bob
random e
x = r2 mod N
e = 1
y = r S mod N
66. Part 3 Protocols 66
Fiat-Shamir: e = 0
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!
Alice
secret S
random r
Bob
random e
x = r2 mod N
e = 0
y = r mod N
67. Part 3 Protocols 67
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?
68. Part 3 Protocols 68
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 follows the
protocol: send x = r2 in msg 1 and y = r in msg 3
o If Trudy expects e = 1, she 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
69. Part 3 Protocols 69
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
70. Part 3 Protocols 70
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, she gets
S
o But that requires modular square root calculation
o If Trudy could find modular square roots, she
could get S from public v
Protocol does not seem to “help” to find S
71. Part 3 Protocols 71
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”
ZKP is not just pointless mathematics!
72. Part 3 Protocols 72
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
73. 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
74. Part 3 Protocols 74
Real-World Protocols
Next, we look at real protocols
o SSH relatively simple & useful protocol
o SSL practical security on the Web
o IPSec security at the IP layer
o Kerberos symmetric key, single sign-on
o WEP “Swiss cheese” of security protocols
o GSM mobile phone (in)security
76. 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
77. SSH
SSH authentication can be based on:
o Public keys, or
o Digital certificates, or
o Passwords
Here, we consider certificate mode
o Other modes in homework problems
We consider slightly simplified SSH…
Part 3 Protocols 77
78. Simplified SSH
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
Alice Bob
Alice, CP, RA
CS, RB
ga mod p
gb mod p, certificateB, SB
E(Alice, certificateA, SA, K)
79. MiM Attack on SSH?
Where does this attack fail?
Alice computes
Ha = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gt mod p,gat mod p)
But Bob signs
Hb = h(Alice,Bob,CP,CS,RA,RB,gt mod p,gb mod p,gbt mod p)
Part 3 Protocols 79
Alice Bob
Alice, RA
RB
ga mod p
gb mod p, certB, SB
E(Alice,certA,SA,K)
Alice, RA
RB
gt mod p
gt mod p, certB, SB
E(Alice,certA,SA,K)
Trudy
81. Part 3 Protocols 81
Socket layer
“Socket layer”
lives between
application
and transport
layers
SSL usually
between HTTP
and TCP
application
transport
network
link
physical
Socket
“layer”
OS
User
NIC
82. Part 3 Protocols 82
What is SSL?
SSL is the protocol used for majority of
secure Internet transactions today
For example, if you want to buy a book at
amazon.com…
o You want to be sure you are dealing with Amazon
(authentication)
o Your credit card information must be protected
in transit (confidentiality and/or integrity)
o As long as you have money, Amazon does not
really care who you are…
o …so, no need for mutual authentication
83. Part 3 Protocols 83
Simple SSL-like Protocol
Alice Bob
I’d like to talk to you securely
Here’s my certificate
{K}Bob
protected HTTP
Is Alice sure she’s talking to Bob?
Is Bob sure he’s talking to Alice?
84. Part 3 Protocols 84
Simplified SSL Protocol
Alice Bob
Can we talk?, cipher list, RA
certificate, cipher, RB
{S}Bob, E(h(msgs,CLNT,K),K)
Data protected with key K
h(msgs,SRVR,K)
S is the so-called pre-master secret
K = h(S,RA,RB)
“msgs” means all previous messages
CLNT and SRVR are constants
85. Part 3 Protocols 85
SSL Keys
6 “keys” derived from K = h(S,RA,RB)
o 2 encryption keys: client and server
o 2 integrity keys: client and server
o 2 IVs: client and server
o Why different keys in each direction?
Q: Why is h(msgs,CLNT,K) encrypted?
A: Apparently, it adds no security…
86. Part 3 Protocols 86
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
87. Part 3 Protocols 87
SSL MiM Attack?
Alice Bob
RA
certificateT, RB
{S1}Trudy,E(X1,K1)
E(data,K1)
h(Y1,K1)
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?
Trudy
RA
certificateB, RB
{S2}Bob,E(X2,K2)
E(data,K2)
h(Y2,K2)
88. Part 3 Protocols 88
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
89. Part 3 Protocols 89
SSL Connection
Alice Bob
session-ID, cipher list, RA
session-ID, cipher, RB,
h(msgs,SRVR,K)
h(msgs,CLNT,K)
Protected data
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)
90. Part 3 Protocols 90
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
91. Part 3 Protocols 91
SSL vs IPSec
IPSec: OS must be aware, but not apps
SSL: Apps must be aware, but not OS
SSL built into Web early-on (Netscape)
IPSec often used in VPNs (secure tunnel)
Reluctance to retrofit applications for SSL
IPSec not widely deployed (complexity, etc.)
The bottom line?
Internet less secure than it could be!
93. Part 3 Protocols 93
IPSec and SSL
IPSec lives at
the network
layer
IPSec is
transparent to
applications
application
transport
network
link
physical
SSL
OS
User
NIC
IPSec
94. Part 3 Protocols 94
IPSec and Complexity
IPSec is a complex protocol
Over-engineered
o Lots of (generally useless) features
Flawed Some significant security issues
Interoperability is serious challenge
o Defeats the purpose of having a standard!
Complex
And, did I mention, it’s complex?
95. Part 3 Protocols 95
IKE and ESP/AH
Two parts to IPSec…
IKE: Internet Key Exchange
o Mutual authentication
o Establish session key
o Two “phases” like SSL session/connection
ESP/AH
o ESP: Encapsulating Security Payload for
confidentiality and/or integrity
o AH: Authentication Header integrity only
97. Part 3 Protocols 97
IKE
IKE has 2 phases
o Phase 1 IKE security association (SA)
o Phase 2 AH/ESP security association
Phase 1 is comparable to SSL session
Phase 2 is comparable to SSL connection
Not an obvious need for two phases in IKE
o In the context of IPSec, that is
If multiple Phase 2’s do not occur, then it is
more costly to have two phases!
98. Part 3 Protocols 98
IKE Phase 1
4 different “key options”
o Public key encryption (original version)
o Public key encryption (improved version)
o Public key signature
o Symmetric key
For each of these, 2 different “modes”
o Main mode and aggressive mode
There are 8 versions of IKE Phase 1!
Need more evidence it’s over-engineered?
99. Part 3 Protocols 99
IKE Phase 1
We discuss 6 of the 8 Phase 1 variants
o Public key signatures (main & aggressive modes)
o Symmetric key (main and aggressive modes)
o Public key encryption (main and aggressive)
Why public key encryption and public key
signatures?
o Always know your own private key
o May not (initially) know other side’s public key
100. Part 3 Protocols 100
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
101. Part 3 Protocols 101
IKE Phase 1: Digital Signature
(Main Mode)
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
Alice Bob
IC, CP
IC,RC, CS
IC,RC, ga mod p, RA
IC,RC, E(“Alice”, proofA, K)
IC,RC, gb mod p, RB
IC,RC, E(“Bob”, proofB, K)
102. Part 3 Protocols 102
IKE Phase 1: Public Key
Signature (Aggressive Mode)
Main differences from main mode
o Not trying to hide identities
o Cannot negotiate g or p
Alice Bob
IC, “Alice”, ga mod p, RA, CP
IC,RC, “Bob”, RB,
gb mod p, CS, proofB
IC,RC, proofA
103. Part 3 Protocols 103
Main vs Aggressive Modes
Main mode MUST be implemented
Aggressive mode SHOULD be implemented
o So, if aggressive mode is not implemented, “you
should feel guilty about it”
Might create interoperability issues
For public key signature authentication
o Passive attacker knows identities of Alice and
Bob in aggressive mode, but not in main mode
o Active attacker can determine Alice’s and Bob’s
identity in main mode
104. Part 3 Protocols 104
IKE Phase 1: Symmetric Key
(Main Mode)
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”)
Alice
KAB
Bob
KAB
IC, CP
IC,RC, CS
IC,RC, ga mod p, RA
IC,RC, E(“Alice”, proofA, K)
IC,RC, gb mod p, RB
IC,RC, E(“Bob”, proofB, K)
105. Part 3 Protocols 105
Problems with Symmetric
Key (Main Mode)
Catch-22
o Alice sends her ID in message 5
o Alice’s ID encrypted with K
o To find K Bob must know KAB
o To get KAB Bob must know he’s talking to Alice!
Result: Alice’s IP address used as ID!
Useless mode for the “road warrior”
Why go to all of the trouble of trying to
hide identities in 6 message protocol?
106. Part 3 Protocols 106
IKE Phase 1: Symmetric Key
(Aggressive Mode)
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
Alice Bob
IC, “Alice”, ga mod p, RA, CP
IC,RC, “Bob”, RB,
gb mod p, CS, proofB
IC,RC, proofA
107. Part 3 Protocols 107
IKE Phase 1: Public Key
Encryption (Main Mode)
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 Bob
IC, CP
IC,RC, CS
IC,RC, ga mod p, {RA}Bob, {“Alice”}Bob
IC,RC, E(proofA, K)
IC,RC, gb mod p, {RB}Alice, {“Bob”}Alice
IC,RC, E(proofB, K)
108. Part 3 Protocols 108
IKE Phase 1: Public Key
Encryption (Aggressive Mode)
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?
Alice Bob
IC, CP, ga mod p,
{“Alice”}Bob, {RA}Bob
IC,RC, CS, gb mod p,
{“Bob”}Alice, {RB}Alice, proofB
IC,RC, proofA
109. Part 3 Protocols 109
Public Key Encryption Issue?
In public key encryption, aggressive mode…
Suppose Trudy generates
o Exponents a and b
o Nonces RA and RB
Trudy can compute “valid” keys and proofs:
gab mod p, K, SKEYID, proofA and proofB
All of this also works in main mode
110. Part 3 Protocols 110
Public Key Encryption Issue?
Trudy
(as Alice)
Trudy
(as Bob)
Trudy can create messages that appears to
be between Alice and Bob
Appears valid to any observer, including
Alice and Bob!
IC,RC, CS, gb mod p,
{“Bob”}Alice, {RB}Alice, proofB
IC,RC, proofA
IC, CP, ga mod p,
{“Alice”}Bob, {RA}Bob
111. Part 3 Protocols 111
Plausible Deniability
Trudy can create fake “conversation” that
appears to be between Alice and Bob
o Appears valid, even to Alice and Bob!
A security failure?
In IPSec public key option, it is a feature…
o Plausible deniability: Alice and Bob can deny
that any conversation took place!
In some cases it might create a problem
o E.g., if Alice makes a purchase from Bob, she
could later repudiate it (unless she had signed)
112. Part 3 Protocols 112
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
113. Part 3 Protocols 113
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…
114. Part 3 Protocols 114
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!
115. Part 3 Protocols 115
IKE Phase 2
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)
Alice Bob
IC, RC, CP, E(hash1,SA,RA,K)
IC, RC, CS, E(hash2,SA,RB,K)
IC, RC, E(hash3,K)
116. Part 3 Protocols 116
IPSec
After IKE Phase 1, we have an IKE SA
After IKE Phase 2, we have an IPSec SA
Authentication completed and have a
shared symmetric key (session key)
Now what?
o We want to protect IP datagrams
o But what is an IP datagram?
o From the perspective of IPSec…
117. Part 3 Protocols 117
IP Review
Where IP header is
IP header data
IP datagram is of the form
118. Part 3 Protocols 118
IP and TCP
Consider Web traffic, for example
o IP encapsulates TCP and…
o …TCP encapsulates HTTP
IP header TCP hdr HTTP hdr app data
IP header data
IP data includes TCP header, etc.
119. Part 3 Protocols 119
IPSec Transport Mode
IPSec Transport Mode
IP header data
IP header IPSec header data
Transport mode designed for host-to-host
Transport mode is efficient
o Adds minimal amount of extra header
The original header remains
o Passive attacker can see who is talking
120. IPSec: Host-to-Host
IPSec transport mode used here
Part 3 Protocols 120
There may be firewalls in between
o If so, is that a problem?
121. Part 3 Protocols 121
IPSec Tunnel Mode
IPSec Tunnel Mode
IP header data
new IP hdr IPSec hdr IP header data
Tunnel mode for firewall-to-firewall traffic
Original IP packet encapsulated in IPSec
Original IP header not visible to attacker
o New IP header from firewall to firewall
o Attacker does not know which hosts are talking
122. IPSec: Firewall-to-Firewall
IPSec tunnel mode used here
Part 3 Protocols 122
Note: Local networks not protected
Is there any advantage here?
123. Part 3 Protocols 123
Comparison of IPSec Modes
Transport Mode
Tunnel Mode
IP header data
IP header IPSec header data
IP header data
new IP hdr IPSec hdr IP header data
Transport Mode
o Host-to-host
Tunnel Mode
o Firewall-to-
firewall
Transport Mode
not necessary…
…but it’s more
efficient
124. Part 3 Protocols 124
IPSec Security
What kind of protection?
o Confidentiality?
o Integrity?
o Both?
What to protect?
o Data?
o Header?
o Both?
ESP/AH allow some combinations of these
125. Part 3 Protocols 125
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
126. Part 3 Protocols 126
ESP NULL Encryption
According to RFC 2410
o NULL encryption “is a block cipher the origins of
which appear to be lost in antiquity”
o “Despite rumors”, there is no evidence that NSA
“suppressed publication of this algorithm”
o Evidence suggests it was developed in Roman
times as exportable version of Caesar’s cipher
o Can make use of keys of varying length
o No IV is required
o Null(P,K) = P for any P and any key K
Is ESP with NULL encryption same as AH ?
127. Part 3 Protocols 127
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
128. Part 3 Protocols 128
Why Does AH Exist? (2)
ESP encrypts everything beyond the IP
header (if non-null encryption)
If ESP-encrypted, firewall cannot look at
TCP header in host-to-host case
Why not use ESP with NULL encryption?
o Firewall sees ESP header, but does not know
whether null encryption is used
o End systems know, but not the firewalls
129. Part 3 Protocols 129
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.’ ”
131. Part 3 Protocols 131
Kerberos
In Greek mythology, Kerberos is 3-headed
dog that guards entrance to Hades
o “Wouldn’t it make more sense to guard the exit?”
In security, Kerberos is an authentication
protocol based on symmetric key crypto
o Originated at MIT
o Based on Needham and Schroeder protocol
o Relies on a Trusted Third Party (TTP)
132. Part 3 Protocols 132
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
133. Part 3 Protocols 133
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
134. Part 3 Protocols 134
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
135. Part 3 Protocols 135
Kerberized Login
Alice enters her password
Then Alice’s computer does following:
o Derives KA from Alice’s password
o Uses KA to get TGT for Alice from KDC
Alice then uses her TGT (credentials) to
securely access network resources
Plus: Security is transparent to Alice
Minus: KDC must be secure it’s trusted!
136. Part 3 Protocols 136
Kerberized Login
Alice
Alice’s
Alice wants
password
a TGT
E(SA,TGT,KA)
KDC
Key KA = h(Alice’s password)
KDC creates session key SA
Alice’s computer decrypts SA and TGT
o Then it forgets KA
TGT = E(“Alice”, SA, KKDC)
Computer
137. Part 3 Protocols 137
Alice Requests “Ticket to Bob”
Alice
Talk to Bob
I want to
talk to Bob
REQUEST
REPLY
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
Computer
138. Part 3 Protocols 138
Alice Uses Ticket to Bob
ticket to Bob, authenticator
E(timestamp + 1, KAB)
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
Alice’s
Computer
Bob
139. Part 3 Protocols 139
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
140. Part 3 Protocols 140
Questions about Kerberos
When Alice logs in, KDC sends E(SA, TGT, KA)
where TGT = E(“Alice”, SA, KKDC)
Q: Why is TGT encrypted with KA?
A: Enables Alice to be anonymous when she later
uses her TGT to request a ticket
In Alice’s “Kerberized” login to Bob, why
can Alice remain anonymous?
Why is “ticket to Bob” sent to Alice?
o Why doesn’t KDC send it directly to Bob?
141. Part 3 Protocols 141
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
142. Part 3 Protocols 142
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
144. 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
145. WEP Authentication
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
Alice, K Bob, K
Authentication Request
R
E(R, K)
146. WEP Issues
WEP uses RC4 cipher for confidentiality
o RC4 can be a strong cipher
o But WEP introduces a subtle flaw…
o …making cryptanalytic attacks feasible
WEP uses CRC for “integrity”
o Should have used a MAC, HMAC, or similar
o CRC is for error detection, not crypto integrity
o Everyone should know NOT to use CRC here…
Part 3 Protocols 146
147. WEP Integrity Problems
WEP “integrity” gives no crypto integrity
o CRC is linear, so is stream cipher (XOR)
o Trudy can change ciphertext and CRC so that
checksum on plaintext remains valid
o Then Trudy’s introduced changes go undetected
o Requires no knowledge of the plaintext!
CRC does not provide a cryptographic
integrity check
o CRC designed to detect random errors
o Not to detect intelligent changes
Part 3 Protocols 147
148. More WEP Integrity Issues
Suppose Trudy knows destination IP
Then Trudy also knows keystream used to
encrypt IP address, since
C = destination IP address keystream
Then Trudy can replace C with
C = Trudy’s IP address keystream
And change the CRC so no error detected
o Then what happens??
Moral: Big problems when integrity fails
Part 3 Protocols 148
149. WEP Key
Recall WEP uses a long-term key K
RC4 is a stream cipher, so each packet
must be encrypted using a different key
o Initialization Vector (IV) sent with packet
o Sent in the clear, that is, IV is not secret
o Note: IV similar to MI in WWII ciphers
Actual RC4 key for packet is (IV,K)
o That is, IV is pre-pended to long-term key K
Part 3 Protocols 149
150. WEP Encryption
KIV = (IV,K)
o That is, RC4 key is K with 3-byte IV pre-pended
The IV is known to Trudy
Part 3 Protocols 150
Alice, K Bob, K
IV, E(packet,KIV)
151. WEP IV Issues
WEP uses 24-bit (3 byte) IV
o Each packet gets its own IV
o Key: IV pre-pended to long-term key, K
Long term key K seldom changes
If long-term key and IV are same,
then same keystream is used
o This is bad, bad, really really bad!
o Why?
Part 3 Protocols 151
152. WEP IV Issues
Assume 1500 byte packets, 11 Mbps link
Suppose IVs generated in sequence
o Since 1500 8/(11 106) 224 = 18,000 seconds,
an IV repeat in about 5 hours of traffic
Suppose IVs generated at random
o By birthday problem, some IV repeats in
seconds
Again, repeated IV (with same K) is bad
Part 3 Protocols 152
153. Another Active Attack
Suppose Trudy can insert traffic and
observe corresponding ciphertext
o Then she knows the keystream for some IV
o She can decrypt any packet that uses that IV
If Trudy does this many times, she can
then decrypt data for lots of IVs
o Remember, IV is sent in the clear
Is such an attack feasible?
Part 3 Protocols 153
154. Cryptanalytic Attack
WEP data encrypted using RC4
o Packet key is IV with long-term key K
o 3-byte IV is pre-pended to K
o Packet key is (IV,K)
Recall IV is sent in the clear (not secret)
o New IV sent with every packet
o Long-term key K seldom changes (maybe never)
So Trudy always knows IV and ciphertext
o Trudy wants to find the key K
Part 3 Protocols 154
155. 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 easily find key K
o Regardless of the length of the key
o Provided Trudy knows first keystream byte
o Known plaintext attack (1st byte of each packet)
o Prevent by discarding first 256 keystream bytes
Part 3 Protocols 155
156. WEP Conclusions
Many attacks are practical
Attacks have been used to recover keys
and break real WEP traffic
How to prevent these attacks?
o Don’t use WEP
o Good alternatives: WPA, WPA2, etc.
How to make WEP a little better?
o Restrict MAC addresses, don’t broadcast ID, …
Part 3 Protocols 156
158. Part 3 Protocols 158
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)
159. Part 3 Protocols 159
GSM System Overview
Mobile
Home
Network
“land line”
air
interface
Base
Station
Base
Station
Controller
PSTN
Internet
etc.
Visited
Network
VLR
HLR
AuC
160. Part 3 Protocols 160
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 (often not used)
SIM
161. Part 3 Protocols 161
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
162. Part 3 Protocols 162
GSM Security Goals
Primary design goals
o Make GSM as secure as ordinary telephone
o Prevent phone cloning
Not designed to resist an active attacks
o At the time this seemed infeasible
o Today such an attacks are clearly feasible…
Designers considered biggest threats to be
o Insecure billing
o Corruption
o Other low-tech attacks
163. Part 3 Protocols 163
GSM Security Features
Anonymity
o Intercepted traffic does not identify user
o Not so important to phone company
Authentication
o Necessary for proper billing
o Very, very important to phone company!
Confidentiality
o Confidentiality of calls over the air interface
o Not important to phone company…
o …except for marketing
164. Part 3 Protocols 164
GSM: Anonymity
IMSI used to initially identify caller
Then TMSI (Temporary Mobile Subscriber
ID) used
o TMSI changed frequently
o TMSI’s encrypted when sent
Not a strong form of anonymity
But probably useful in many cases
165. Part 3 Protocols 165
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
166. Part 3 Protocols 166
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
167. Part 3 Protocols 167
GSM Security
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
Mobile Base
Station
4. RAND
5. SRES
6. Encrypt with Kc
1. IMSI
Home
Network
3. (RAND,XRES,Kc)
2. IMSI
168. Part 3 Protocols 168
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
Encryption algorithm A5/1
o Broken with 2 seconds of known plaintext
Base
Station
Base
Station
Controller
VLR
169. Part 3 Protocols 169
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
170. Part 3 Protocols 170
GSM Insecurity (3)
Fake base station exploits two flaws
1. Encryption not automatic
2. Base station not authenticated
Mobile
Base Station
RAND
SRES
Fake
Base Station
No
encryption
Call to
destination
Note: GSM bill goes to fake base station!
171. Part 3 Protocols 171
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
172. Part 3 Protocols 172
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?
173. Part 3 Protocols 173
3rd Generation Partnership
Project (3GPP)
3G security built on GSM (in)security
3G fixed known GSM security problems
o Mutual authentication
o Integrity-protect signaling (such as “start
encryption” command)
o Keys (encryption/integrity) cannot be reused
o Triples cannot be replayed
o Strong encryption algorithm (KASUMI)
o Encryption extended to base station controller
174. Part 3 Protocols 174
Protocols Summary
Generic authentication protocols
o Protocols are subtle!
SSH
SSL
IPSec
Kerberos
Wireless: GSM and WEP
175. Part 3 Protocols 175
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
Editor's Notes
Note that encryption is not required in this protocol. Signing the DH values prevents the MiM attack, while signing the nonces prevents a replay.
KDC is playing a role comparable to a certificate authority (CA).
Encrypting the TGT does prevent Trudy from knowing who the TGT belongs to---in subsequent use, Alice does not identify herself. So, that is probably worth the encryption; otherwise Alice would not really be anonymous in the “Kerberized” login to Bob.