part iii: protocols
DESCRIPTION
Part III: Protocols. Protocol. Human protocols the rules followed in human interactions Example: Asking a question in class Networking protocols rules followed in networked communication systems Examples: HTTP, FTP, etc. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/1.jpg)
Part 3 Protocols 1
Part III: Protocols
![Page 2: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/2.jpg)
Part 3 Protocols 2
Protocol Human protocols the rules followed in
human interactionso Example: Asking a question in class
Networking protocols rules followed in networked communication systemso Examples: HTTP, FTP, etc.
Security protocol the (communication) rules followed in a security applicationo Examples: SSL, IPSec, Kerberos, etc.
![Page 3: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/3.jpg)
Part 3 Protocols 3
Protocols Protocol flaws can be very subtle Several well-known security
protocols have significant flawso Including WEP, GSM, and IPSec
Implementation errors can also occuro Recently, IE implementation of SSL
Not easy to get protocols right…
![Page 4: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/4.jpg)
Part 3 Protocols 4
Ideal Security Protocol Must satisfy security requirements
o Requirements need to be precise Efficient
o Minimize computational requiremento Minimize bandwidth usage, delays…
Robusto Works when attacker tries to break ito Works if environment changes (slightly)
Easy to implement, easy to use, flexible…
Difficult to satisfy all of these!
![Page 5: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/5.jpg)
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 beotherwise 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
![Page 6: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/6.jpg)
Part 3 Protocols 6
Secure Entry to NSA1. Insert badge into reader2. Enter PIN3. Correct PIN?
Yes? EnterNo? Get shot by security guard
![Page 7: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/7.jpg)
Part 3 Protocols 7
ATM Machine Protocol1. Insert ATM card2. Enter PIN3. Correct PIN?
Yes? Conduct your transaction(s)No? Machine (eventually) eats card
![Page 8: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/8.jpg)
Part 3 Protocols 8
Identify Friend or Foe (IFF)
NamibiaK
Angola
1. N
2. E(N,K)SAAFImpala
K
RussianMIG
![Page 9: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/9.jpg)
Part 3 Protocols 9
MIG in the Middle
NamibiaK
Angola
1. N
2. N
3. N
4. E(N,K)
5. E(N,K)
6. E(N,K)
SAAFImpala
K
RussianMiG
![Page 10: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/10.jpg)
Part 3 Protocols 10
Authentication Protocols
![Page 11: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/11.jpg)
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.
![Page 12: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/12.jpg)
Part 3 Protocols 12
Authentication Authentication on a stand-alone
computer is relatively simpleo For example, hash a password with a salto “Secure path,” attacks on authentication
software, keystroke logging, etc., can be issues
Authentication over a network is challengingo Attacker can passively observe messageso Attacker can replay messageso Active attacks possible (insert, delete,
change)
![Page 13: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/13.jpg)
Part 3 Protocols 13
Simple Authentication
Alice Bob
“I’m Alice”
Prove itMy password is “frank”
Simple and may be OK for standalone system
But highly insecure for networked systemo Subject to a replay attack (next 2 slides)o Also, Bob must know Alice’s password
![Page 14: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/14.jpg)
Part 3 Protocols 14
Authentication Attack
Alice Bob
“I’m Alice”
Prove itMy password is “frank”
Trudy
![Page 15: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/15.jpg)
Part 3 Protocols 15
Authentication Attack
Bob
“I’m Alice”
Prove itMy password is “frank”
Trudy
This is an example of a replay attack How can we prevent a replay?
![Page 16: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/16.jpg)
Part 3 Protocols 16
Simple Authentication
Alice Bob
I’m Alice, my password is “frank”
More efficient, but… … same problem as previous version
![Page 17: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/17.jpg)
Part 3 Protocols 17
Better Authentication
Alice Bob
“I’m Alice”
Prove ith(Alice’s password)
This approach hides Alice’s passwordo From both Bob and Trudy
But still subject to replay attack
![Page 18: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/18.jpg)
Part 3 Protocols 18
Challenge-Response To prevent replay, use challenge-
responseo Goal is to ensure “freshness”
Suppose Bob wants to authenticate Aliceo Challenge sent from Bob to Alice
Challenge is chosen so that… o Replay is not possibleo Only Alice can provide the correct
responseo Bob can verify the response
![Page 19: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/19.jpg)
Part 3 Protocols 19
Nonce To ensure freshness, can employ a
nonceo 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?
![Page 20: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/20.jpg)
Part 3 Protocols 20
Challenge-Response
Bob
“I’m Alice”
Nonceh(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
![Page 21: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/21.jpg)
Part 3 Protocols 21
Generic Challenge-Response
Bob
“I’m Alice”
NonceSomething 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?)
![Page 22: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/22.jpg)
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 cryptographyo So, we assume crypto algorithms are secure
![Page 23: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/23.jpg)
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, …
![Page 24: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/24.jpg)
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
![Page 25: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/25.jpg)
Part 3 Protocols 25
Mutual Authentication?
Alice, K Bob, K
“I’m Alice”, RE(R,K)
E(R,K)
What’s wrong with this picture? “Alice” could be Trudy (or anybody
else)!
![Page 26: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/26.jpg)
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 twiceo Once for Bob to authenticate Aliceo Once for Alice to authenticate Bob
This has got to work…
![Page 27: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/27.jpg)
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
attacko Next slide
![Page 28: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/28.jpg)
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
5. E(RB, K)
![Page 29: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/29.jpg)
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 secureo This is a common source of security
failureo For example, Internet protocols
![Page 30: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/30.jpg)
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!
![Page 31: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/31.jpg)
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
Theno [{M}Alice ]Alice = Mo {[M]Alice }Alice = M
Anybody can use Alice’s public key Only Alice can use her private key
![Page 32: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/32.jpg)
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
![Page 33: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/33.jpg)
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
![Page 34: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/34.jpg)
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
![Page 35: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/35.jpg)
Part 3 Protocols 35
Session Key Usually, a session key is required
o A symmetric key for current sessiono 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 keyo Trudy cannot break the authentication…o …and Trudy cannot determine the session
key
![Page 36: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/36.jpg)
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
secureo Alice’s “nonce”, R, useless to authenticate
Bobo The key K is acting as Bob’s nonce to Alice
No mutual authentication
![Page 37: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/37.jpg)
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)
![Page 38: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/38.jpg)
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…
![Page 39: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/39.jpg)
Part 3 Protocols 39
Public Key Authentication and Session Key
Alice Bob
1. “I’m Alice”, R4. {[R, K]Bob}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”, R3. {[R, K]Bob}Trudy
6. time out
![Page 40: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/40.jpg)
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
![Page 41: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/41.jpg)
Part 3 Protocols 41
Timestamps A timestamp T is derived from current
time Timestamps can be used to prevent
replayo 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?
![Page 42: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/42.jpg)
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
![Page 43: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/43.jpg)
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…
![Page 44: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/44.jpg)
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
![Page 45: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/45.jpg)
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!
![Page 46: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/46.jpg)
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?
![Page 47: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/47.jpg)
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 ciphertexto Even if Trudy gets key K or other secret(s)
Is PFS possible?
![Page 48: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/48.jpg)
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?
![Page 49: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/49.jpg)
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)
![Page 50: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/50.jpg)
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 pgb mod p
![Page 51: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/51.jpg)
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)
![Page 52: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/52.jpg)
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
![Page 53: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/53.jpg)
Part 3 Protocols 53
Authentication and TCP
![Page 54: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/54.jpg)
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
![Page 55: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/55.jpg)
Part 3 Protocols 55
TCP 3-way Handshake
Alice Bob
SYN, SEQ aSYN, 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…
![Page 56: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/56.jpg)
Part 3 Protocols 56
TCP Authentication Attack
Alice
BobTrudy
1. SYN, SEQ = t (as Trudy)2. SYN, ACK = t+1, SEQ = b1
3. SYN, SEQ = t (as Alice)
4. SYN, ACK = t+1, SEQ = b 2
5. ACK = b2+1, data
5.5.
5.
5.
…
![Page 57: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/57.jpg)
Part 3 Protocols 57
TCP Authentication Attack
Random SEQ numbers Initial SEQ numbersMac OS X
If initial SEQ numbers not very random… …possible to guess initial SEQ number… …and previous attack will succeed
![Page 58: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/58.jpg)
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
![Page 59: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/59.jpg)
Part 3 Protocols 59
Zero Knowledge Proofs
![Page 60: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/60.jpg)
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 secreto 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”
![Page 61: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/61.jpg)
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
QR S
![Page 62: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/62.jpg)
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
QR S
Bob’s Cave
![Page 63: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/63.jpg)
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 difficulto 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
![Page 64: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/64.jpg)
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
Alicesecret Srandom r
Bobrandom e
x = r2 mod Ne {0,1}
y = r Se mod N
![Page 65: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/65.jpg)
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
Alicesecret Srandom r
Bobrandom e
x = r2 mod Ne = 1
y = r S mod N
![Page 66: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/66.jpg)
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!
Alicesecret Srandom r
Bobrandom e
x = r2 mod Ne = 0
y = r mod N
![Page 67: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/67.jpg)
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?
![Page 68: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/68.jpg)
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
![Page 69: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/69.jpg)
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 3o If e = 1, Alice sends r S mod N in message 3o Anyone can find S given r mod N and r S mod
N
![Page 70: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/70.jpg)
Part 3 Protocols 70
Fiat-Shamir Zero Knowledge?
Zero knowledge means that nobody learns anything about the secret So Public: v = S2 mod No Trudy sees r2 mod N in message 1o Trudy sees r S mod N in message 3 (if e =
1) If Trudy can find r from r2 mod N, she
gets So But that requires modular square root
calculationo If Trudy could find modular square roots, she
could get S from public v Protocol does not seem to “help” to find
S
![Page 71: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/71.jpg)
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!
![Page 72: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/72.jpg)
Part 3 Protocols 72
Best Authentication Protocol?
It depends on…o The sensitivity of the application/datao The delay that is tolerableo The cost (computation) that is tolerableo What crypto is supported (public key,
symmetric key, …)o Whether mutual authentication is requiredo Whether PFS, anonymity, etc., are concern
…and possibly other factors
![Page 73: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/73.jpg)
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
![Page 74: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/74.jpg)
Part 3 Protocols 74
Real-World Protocols Next, we look at real protocols
o SSH relatively simple & useful protocolo SSL practical security on the Webo IPSec security at the IP layero Kerberos symmetric key, single sign-ono WEP “Swiss cheese” of security
protocolso GSM mobile phone (in)security
![Page 75: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/75.jpg)
Secure Shell (SSH)
Part 3 Protocols 75
![Page 76: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/76.jpg)
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
![Page 77: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/77.jpg)
SSH SSH authentication can be based
on:o Public keys, oro Digital certificates, oro Passwords
Here, we consider certificate modeo Other modes in homework problems
We consider slightly simplified SSH…
Part 3 Protocols 77
![Page 78: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/78.jpg)
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 pgb mod p, certificateB, SB
E(Alice, certificateA, SA, K)
![Page 79: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/79.jpg)
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 pgb mod p, certB, SB
E(Alice,certA,SA,K)
Alice, RA
RB
gt mod pgt mod p, certB, SB
E(Alice,certA,SA,K)Trudy
![Page 80: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/80.jpg)
Part 3 Protocols 80
Secure Socket Layer
![Page 81: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/81.jpg)
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
![Page 82: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/82.jpg)
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
![Page 83: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/83.jpg)
Part 3 Protocols 83
Simple SSL-like Protocol
Alice Bob
I’d like to talk to you securelyHere’s my certificate
{K}Bob
protected HTTP
Is Alice sure she’s talking to Bob? Is Bob sure he’s talking to Alice?
![Page 84: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/84.jpg)
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 Kh(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
![Page 85: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/85.jpg)
Part 3 Protocols 85
SSL Keys 6 “keys” derived from K = h(S,RA,RB)
o 2 encryption keys: client and servero 2 integrity keys: client and servero 2 IVs: client and servero Why different keys in each direction?
Q: Why is h(msgs,CLNT,K) encrypted? A: Apparently, it adds no security…
![Page 86: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/86.jpg)
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 2o Then client must have a valid certificateo But, if server wants to authenticate client,
server could instead require password
![Page 87: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/87.jpg)
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)
![Page 88: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/88.jpg)
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) connectionso Multiple connections per session
SSL session is costly, public key operations
SSL has an efficient protocol for opening new connections given an existing session
![Page 89: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/89.jpg)
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)
![Page 90: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/90.jpg)
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
![Page 91: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/91.jpg)
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!
![Page 92: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/92.jpg)
Part 3 Protocols 92
IPSec
![Page 93: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/93.jpg)
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
![Page 94: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/94.jpg)
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?
![Page 95: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/95.jpg)
Part 3 Protocols 95
IKE and ESP/AH Two parts to IPSec… IKE: Internet Key Exchange
o Mutual authenticationo Establish session keyo Two “phases” like SSL session/connection
ESP/AHo ESP: Encapsulating Security Payload for
confidentiality and/or integrityo AH: Authentication Header integrity only
![Page 96: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/96.jpg)
Part 3 Protocols 96
IKE
![Page 97: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/97.jpg)
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
IKEo In the context of IPSec, that is
If multiple Phase 2’s do not occur, then it is more costly to have two phases!
![Page 98: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/98.jpg)
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 signatureo 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?
![Page 99: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/99.jpg)
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 keyo May not (initially) know other side’s public
key
![Page 100: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/100.jpg)
Part 3 Protocols 100
IKE Phase 1 Uses ephemeral Diffie-Hellman to
establish session keyo 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
![Page 101: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/101.jpg)
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, CPIC,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)
![Page 102: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/102.jpg)
Part 3 Protocols 102
IKE Phase 1: Public Key Signature (Aggressive Mode)
Main differences from main modeo Not trying to hide identitieso Cannot negotiate g or p
Alice Bob
IC, “Alice”, ga mod p, RA, CPIC,RC, “Bob”, RB,
gb mod p, CS, proofB
IC,RC, proofA
![Page 103: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/103.jpg)
Part 3 Protocols 103
Main vs Aggressive Modes Main mode MUST be implemented Aggressive mode SHOULD be
implementedo 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
![Page 104: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/104.jpg)
Part 3 Protocols 104
IKE Phase 1: Symmetric Key (Main Mode)
Same as signature mode excepto 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”)
AliceKAB
BobKAB
IC, CPIC,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)
![Page 105: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/105.jpg)
Part 3 Protocols 105
Problems with Symmetric Key (Main Mode)
Catch-22o Alice sends her ID in message 5o Alice’s ID encrypted with Ko To find K Bob must know KABo 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?
![Page 106: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/106.jpg)
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, CPIC,RC, “Bob”, RB,
gb mod p, CS, proofB
IC,RC, proofA
![Page 107: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/107.jpg)
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, CPIC,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)
![Page 108: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/108.jpg)
Part 3 Protocols 108
IKE Phase 1: Public Key Encryption (Aggressive
Mode)
K, proofA, proofB computed as in main mode
Note that identities are hiddeno The only aggressive mode to hide identitieso 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
![Page 109: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/109.jpg)
Part 3 Protocols 109
Public Key Encryption Issue?
In public key encryption, aggressive mode…
Suppose Trudy generateso Exponents a and bo 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
![Page 110: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/110.jpg)
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
![Page 111: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/111.jpg)
Part 3 Protocols 111
Plausible Deniability Trudy can create fake “conversation”
that appears to be between Alice and Bobo 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)
![Page 112: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/112.jpg)
Part 3 Protocols 112
IKE Phase 1 “Cookies” IC and RC cookies (or “anti-clogging
tokens”) supposed to prevent DoS attackso 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 ono So, these “cookies” offer little DoS protection
![Page 113: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/113.jpg)
Part 3 Protocols 113
IKE Phase 1 Summary Result of IKE phase 1 is
o Mutual authenticationo Shared symmetric keyo IKE Security Association (SA)
But phase 1 is expensiveo Especially in public key and/or main mode
Developers of IKE thought it would be used for lots of things not just IPSeco Partly explains the over-engineering…
![Page 114: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/114.jpg)
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 1o SSL connections are like IKE Phase 2
IKE could be used for lots of things, but in practice, it’s not!
![Page 115: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/115.jpg)
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)
![Page 116: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/116.jpg)
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 datagramso But what is an IP datagram?o From the perspective of IPSec…
![Page 117: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/117.jpg)
Part 3 Protocols 117
IP Review
Where IP header is
IP header data
IP datagram is of the form
![Page 118: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/118.jpg)
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.
![Page 119: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/119.jpg)
Part 3 Protocols 119
IPSec Transport Mode IPSec Transport Mode
IP header data
IP header IPSec headerdata
Transport mode designed for host-to-host
Transport mode is efficiento Adds minimal amount of extra header
The original header remainso Passive attacker can see who is talking
![Page 120: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/120.jpg)
IPSec: Host-to-Host IPSec transport mode used here
Part 3 Protocols 120
There may be firewalls in betweeno If so, is that a problem?
![Page 121: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/121.jpg)
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 firewallo Attacker does not know which hosts are talking
![Page 122: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/122.jpg)
IPSec: Firewall-to-Firewall IPSec tunnel mode used here
Part 3 Protocols 122
Note: Local networks not protected Is there any advantage here?
![Page 123: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/123.jpg)
Part 3 Protocols 123
Comparison of IPSec Modes
Transport Mode
Tunnel Mode
IP header data
IP header IPSec headerdata
IP header data
new IP hdr IPSec hdr IP header data
Transport Modeo Host-to-host
Tunnel Modeo Firewall-to-
firewall Transport Mode
not necessary… …but it’s more
efficient
![Page 124: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/124.jpg)
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
![Page 125: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/125.jpg)
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 Payloado Integrity and confidentiality both requiredo Protects everything beyond IP headero Integrity-only by using NULL encryption
![Page 126: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/126.jpg)
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 lengtho No IV is requiredo Null(P,K) = P for any P and any key K
Is ESP with NULL encryption same as AH ?
![Page 127: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/127.jpg)
Part 3 Protocols 127
Why Does AH Exist? (1) Cannot encrypt IP header
o Routers must look at the IP headero IP addresses, TTL, etc.o IP header exists to route packets!
AH protects immutable fields in IP headero Cannot integrity protect all header fieldso TTL, for example, will change
ESP does not protect IP header at all
![Page 128: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/128.jpg)
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
![Page 129: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/129.jpg)
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.’ ”
![Page 130: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/130.jpg)
Part 3 Protocols 130
Kerberos
![Page 131: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/131.jpg)
Part 3 Protocols 131
Kerberos In Greek mythology, Kerberos is 3-
headed dog that guards entrance to Hadeso “Wouldn’t it make more sense to guard the
exit?” In security, Kerberos is an authentication
protocol based on symmetric key cryptoo Originated at MITo Based on Needham and Schroeder protocolo Relies on a Trusted Third Party (TTP)
![Page 132: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/132.jpg)
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
![Page 133: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/133.jpg)
Part 3 Protocols 133
Kerberos KDC Kerberos Key Distribution Center or
KDCo KDC acts as the TTPo 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
keyso Session key for confidentiality and integrity
In practice, crypto algorithm is DES
![Page 134: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/134.jpg)
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 containso Session keyo User’s IDo Expiration time
Every TGT is encrypted with KKDCo So, TGT can only be read by the KDC
![Page 135: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/135.jpg)
Part 3 Protocols 135
Kerberized Login Alice enters her password Then Alice’s computer does following:
o Derives KA from Alice’s passwordo 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!
![Page 136: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/136.jpg)
Part 3 Protocols 136
Kerberized Login
Alice
Alice’sAlice wants
password a TGTE(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
![Page 137: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/137.jpg)
Part 3 Protocols 137
Alice Requests “Ticket to Bob”
Alice
Talk to Bob
I want totalk to BobREQUEST
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
![Page 138: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/138.jpg)
Part 3 Protocols 138
Alice Uses Ticket to Bobticket 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
![Page 139: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/139.jpg)
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
![Page 140: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/140.jpg)
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?
![Page 141: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/141.jpg)
Part 3 Protocols 141
Kerberos Alternatives Could have Alice’s computer remember
password and use that for authenticationo Then no KDC requiredo But hard to protect passwordso Also, does not scale
Could have KDC remember session key instead of putting it in a TGTo Then no need for TGTo But stateless KDC is major feature of
Kerberos
![Page 142: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/142.jpg)
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 passwordo But E(KA, Kh) must be stored on computer
This alternative approach is often usedo But not in Kerberos
![Page 143: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/143.jpg)
WEP
Part 3 Protocols 143
![Page 144: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/144.jpg)
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
![Page 145: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/145.jpg)
WEP Authentication
Bob is wireless access point Key K shared by access point and all
userso Key K seldom (if ever) changes
WEP has many, many, many security flaws Part 3 Protocols
145
Alice, K Bob, K
Authentication RequestR
E(R, K)
![Page 146: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/146.jpg)
WEP Issues WEP uses RC4 cipher for confidentiality
o RC4 can be a strong ciphero But WEP introduces a subtle flaw…o …making cryptanalytic attacks feasible
WEP uses CRC for “integrity”o Should have used a MAC, HMAC, or similaro CRC is for error detection, not crypto
integrityo Everyone should know NOT to use CRC
here… Part 3 Protocols 146
![Page 147: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/147.jpg)
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 valido Then Trudy’s introduced changes go
undetectedo Requires no knowledge of the plaintext!
CRC does not provide a cryptographic integrity checko CRC designed to detect random errorso Not to detect intelligent changes
Part 3 Protocols 147
![Page 148: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/148.jpg)
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 detectedo Then what happens??
Moral: Big problems when integrity fails Part 3 Protocols 148
![Page 149: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/149.jpg)
WEP Key Recall WEP uses a long-term key K RC4 is a stream cipher, so each packet
must be encrypted using a different keyo Initialization Vector (IV) sent with packeto Sent in the clear, that is, IV is not secreto 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
![Page 150: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/150.jpg)
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)
![Page 151: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/151.jpg)
WEP IV Issues WEP uses 24-bit (3 byte) IV
o Each packet gets its own IVo 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 usedo This is bad, bad, really really bad! o Why?
Part 3 Protocols 151
![Page 152: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/152.jpg)
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 randomo By birthday problem, some IV repeats in
seconds Again, repeated IV (with same K) is bad Part 3 Protocols 152
![Page 153: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/153.jpg)
Another Active Attack Suppose Trudy can insert traffic and
observe corresponding ciphertexto Then she knows the keystream for some IVo She can decrypt any packet that uses that
IV If Trudy does this many times, she can
then decrypt data for lots of IVso Remember, IV is sent in the clear
Is such an attack feasible? Part 3 Protocols 153
![Page 154: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/154.jpg)
Cryptanalytic Attack WEP data encrypted using RC4
o Packet key is IV with long-term key Ko 3-byte IV is pre-pended to Ko Packet key is (IV,K)
Recall IV is sent in the clear (not secret)o New IV sent with every packeto Long-term key K seldom changes (maybe
never) So Trudy always knows IV and
ciphertexto Trudy wants to find the key K Part 3 Protocols
154
![Page 155: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/155.jpg)
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 knowso Trudy wants to find K = (K3,K4,K5, …)
Given enough IVs, Trudy can easily find key Ko Regardless of the length of the keyo Provided Trudy knows first keystream byteo Known plaintext attack (1st byte of each
packet)o Prevent by discarding first 256 keystream
bytes Part 3 Protocols 155
![Page 156: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/156.jpg)
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 WEPo Good alternatives: WPA, WPA2, etc.
How to make WEP a little better?o Restrict MAC addresses, don’t broadcast ID,
…
Part 3 Protocols 156
![Page 157: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/157.jpg)
Part 3 Protocols 157
GSM (In)Security
![Page 158: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/158.jpg)
Part 3 Protocols 158
Cell Phones First generation cell phones
o Brick-sized, analog, few standardso Little or no securityo Susceptible to cloning
Second generation cell phones: GSMo Began in 1982 as “Groupe Speciale Mobile”o Now, Global System for Mobile
Communications Third generation?
o 3rd Generation Partnership Project (3GPP)
![Page 159: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/159.jpg)
Part 3 Protocols 159
GSM System Overview
Mobile
HomeNetwork
“land line”
air interface
BaseStation
BaseStation
Controller
PSTNInternet
etc.Visited Network
VLR
HLR
AuC
![Page 160: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/160.jpg)
Part 3 Protocols 160
GSM System Components Mobile phone
o Contains SIM (Subscriber Identity Module)
SIM is the security moduleo IMSI (International Mobile
Subscriber ID)o User key: Ki (128 bits)o Tamper resistant (smart card)o PIN activated (often not used)
SIM
![Page 161: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/161.jpg)
Part 3 Protocols 161
GSM System Components Visited network network where
mobile is currently locatedo Base station one “cell”o Base station controller manages many cellso 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
![Page 162: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/162.jpg)
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 infeasibleo Today such an attacks are clearly feasible…
Designers considered biggest threats to beo Insecure billingo Corruptiono Other low-tech attacks
![Page 163: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/163.jpg)
Part 3 Protocols 163
GSM Security Features Anonymity
o Intercepted traffic does not identify usero Not so important to phone company
Authenticationo Necessary for proper billingo Very, very important to phone company!
Confidentialityo Confidentiality of calls over the air interfaceo Not important to phone company…o …except for marketing
![Page 164: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/164.jpg)
Part 3 Protocols 164
GSM: Anonymity IMSI used to initially identify caller Then TMSI (Temporary Mobile
Subscriber ID) usedo TMSI changed frequentlyo TMSI’s encrypted when sent
Not a strong form of anonymity But probably useful in many cases
![Page 165: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/165.jpg)
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 stationo Base station sends challenge RAND to
mobileo Mobile’s response is SRES = A3(RAND, Ki)o Base station verifies SRES = XRES
Note: Ki never leaves home network
![Page 166: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/166.jpg)
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
![Page 167: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/167.jpg)
Part 3 Protocols 167
GSM Security
SRES and Kc must be uncorrelatedo 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. RAND5. SRES
6. Encrypt with Kc
1. IMSI
HomeNetwork
3. (RAND,XRES,Kc)2. IMSI
![Page 168: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/168.jpg)
Part 3 Protocols 168
GSM Insecurity (1) Hash used for A3/A8 is COMP128
o Broken by 160,000 chosen plaintextso 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 controllero Often transmitted over microwave link
Encryption algorithm A5/1o Broken with 2 seconds of known
plaintext
BaseStation
BaseStation
Controller
VLR
![Page 169: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/169.jpg)
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
![Page 170: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/170.jpg)
Part 3 Protocols 170
GSM Insecurity (3) Fake base station exploits two flaws
1. Encryption not automatic2. Base station not authenticated
Mobile Base Station
RANDSRES
Fake Base Station
Noencryption
Call todestination
Note: GSM bill goes to fake base station!
![Page 171: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/171.jpg)
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
![Page 172: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/172.jpg)
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?
![Page 173: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/173.jpg)
Part 3 Protocols 173
3rd Generation Partnership Project (3GPP)
3G security built on GSM (in)security 3G fixed known GSM security problems
o Mutual authenticationo Integrity-protect signaling (such as “start
encryption” command)o Keys (encryption/integrity) cannot be reusedo Triples cannot be replayedo Strong encryption algorithm (KASUMI)o Encryption extended to base station
controller
![Page 174: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/174.jpg)
Part 3 Protocols 174
Protocols Summary Generic authentication protocols
o Protocols are subtle! SSH SSL IPSec Kerberos Wireless: GSM and WEP
![Page 175: Part III: Protocols](https://reader035.vdocument.in/reader035/viewer/2022081520/568168b5550346895ddf8b2d/html5/thumbnails/175.jpg)
Part 3 Protocols 175
Coming Attractions… Software and security
o Software flaws buffer overflow, etc.o Malware viruses, worms, etc.o Software reverse engineeringo Digital rights managemento OS and security/NGSCB