1. Protocols
Part 3  Protocols

2. 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.
Security protocol  the (communication) rules followed in a security application
Examples: SSL, IPSec, Kerberos, etc.
We will deal with the security issues related to the messages that must be sent for authentication to occur
Part 3  Protocols

3. Protocols Protocol flaws can be very subtle
Several well-known security protocols have serious flaws
Including IPSec, GSM and WEP
Common to find implementation errors
Such as IE implementation of SSL
Difficult to get protocols right…
Often, a seemingly innocuous change can make a significant difference
Security protocols are particularly subtle
Part 3  Protocols

4. Ideal Security Protocol
Satisfies security requirements
Requirements must be precise
Efficient
Minimize computational requirement  in particular, costly public key operations
Minimize delays/bandwidth
Not fragile
Must work when attacker tries to break it
Works even if environment changes
Easy to use and implement, flexible, etc.
Very difficult to satisfy all of these!
It is difficult to anticipate all possible events, but protocol developers can build in some protections
Some of the most serious security challenges is that protocols are being used in environments for which they were not originally developed
Part 3  Protocols

5. Simple Security Protocols
Part 3  Protocols

6. Secure Entry to NSA Insert badge into reader Enter PIN Correct PIN?
Yes? Enter
No? Get shot by security guard
Employees are given a badge
They must wear it at all times
Part 3  Protocols

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

8. Identify Friend or Foe (IFF)
Russian
MIG
Angola
Used during war between southafrica forces and angola-based cubans
All saaf aircrafts had a key K to encrypt challenge N with
2. E(N,K)
SAAF
Impala
1. N
Namibia
Part 3  Protocols

9. MIG in the Middle Angola Namibia 3. N SAAF Impala 4. E(N,K) 2. N
The problem is that the saaf impala doesn’t know it is receiving the challenge N from an enemy radar
It then provides the “right” answer
The enemy routes the right answer to the radar station
Now foe “looks” like friendly
6. E(N,K)
Russian
MiG
1. N
Namibia
Part 3  Protocols

10. Authentication Protocols
Part 3  Protocols

11. Authentication Alice must prove her identity to Bob
Alice and Bob can be humans or computers
May also require Bob to prove he’s Bob (mutual authentication)
May also need to establish a session key
May have other requirements, such as
Use only public keys
Use only symmetric keys
Use only a hash function
Anonymity, plausible deniability, etc., etc.
The fact that Alice successfully uses a mechanism to prove her identity to Bob doesn’t mean that the same mechanism will work for the symmetric case.
In security protocols the obvious approach is often not secure
Part 3  Protocols

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

13. Simple Authentication
“I’m Alice”
Prove it
My password is “frank”
Alice
Bob
Simple and may be OK for standalone system
But insecure for networked system
Subject to a replay attack (next 2 slides)
Bob must know Alice’s password
3-message protocol
Requires Alice’s password is sent in the clear
Part 3  Protocols

14. Authentication Attack
“I’m Alice”
Prove it
My password is “frank”
Alice
Bob
Trudy gets the piece of information that authenticates Alice to Bob
Trudy
Part 3  Protocols

15. Authentication Attack
“I’m Alice”
Prove it
My password is “frank”
Trudy
Bob
All Trudy has to do is play the information again
Known as replay attack
And trudy can use this password for other servers, given that Alice has reused it
This is a replay attack
How can we prevent a replay?
Part 3  Protocols

16. Simple Authentication
I’m Alice, My password is “frank”
Alice
Bob
This protocol is more efficient because only one message is needed
It is still too simple
More efficient…
But same problem as previous version
Part 3  Protocols

17. Better Authentication
“I’m Alice”
Prove it
h(Alice’s password)
Alice
Bob
Trudy won’t obtain the clear text of the password
But she can still obtain the “piece of information” that will authenticate her to Bob
Better since it hides Alice’s password
From both Bob and attackers
But still subject to replay
Part 3  Protocols

18. Challenge-Response To prevent replay, challenge-response used
Suppose Bob wants to authenticate Alice
Challenge sent from Bob to Alice
Only Alice can provide the correct response
Challenge chosen so that replay is not possible
How to accomplish this?
Password is something only Alice should know…
For freshness, a “number used once” or nonce
Bob needs to send some unique information each time
And this unique info needs to be used in the calculation of the response
This will differentiate responses sent at different times
Part 3  Protocols

19. Challenge-Response Nonce is the challenge The hash is the response
“I’m Alice”
Nonce
h(Alice’s password, Nonce)
Alice
Bob
Nonce is the challenge
The hash is the response
Nonce prevents replay, insures freshness
Password is something Alice knows
Note that Bob must know Alice’s password
How can we avoid that Bob knows Alice’s password
Part 3  Protocols

20. Challenge-Response What can we use to achieve this?
“I’m Alice”
Nonce
Something that could only be
Alice
from Alice (and Bob can verify)
Bob
What about symmetric key crypto?
What can we use to achieve this?
Hashed pwd works, crypto might be better
Part 3  Protocols

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

22. Real-World Protocols Next, we’ll look at specific protocols
SSL  security on the Web
IPSec  security at the IP layer
Kerberos  symmetric key system
GSM  mobile phone (in)security
GSM is interesting due to the large number of attacks that are known
Part 3  Protocols

23. Secure Socket Layer
Part 3  Protocols

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

25. What is SSL?
SSL is the protocol used for most secure transactions over the Internet
For example, if you want to buy a book at amazon.com…
You want to be sure you are dealing with Amazon (authentication)
Your credit card information must be protected in transit (confidentiality and/or integrity)
As long as you have money, Amazon doesn’t care who you are (authentication need not be mutual)
Part 3  Protocols

26. Simple SSL-like Protocol
I’d like to talk to you securely
Here’s my certificate
{KAB}Bob
protected HTTP
Bob
Alice
Alice has to wait to decrypt some data correctly to check that Bob is actually Bob
Alice is not authenticated to Bob at all
Is Alice sure she’s talking to Bob?
Is Bob sure he’s talking to Alice?
Part 3  Protocols

27. Simplified SSL Protocol
Can we talk?, cipher list, RA
certificate, cipher, RB
{S}Bob, E(h(msgs,CLNT,K),K)
h(msgs,SRVR,K)
Data protected with key K
Bob
Alice
S is pre-master secret
K = h(S,RA,RB)
msgs = all previous messages
CLNT and SRVR are constants
In particular, CLNT and SRVR are literal strings
The hash includes previous messages to verify that they were received correctly
Part 3  Protocols

28. SSL Keys 6 “keys” derived from K = hash(S,RA,RB)
2 encryption keys: send and receive
2 integrity keys: send and receive
2 IVs: send and receive
Why different keys in each direction?
Different keys in each direction may help prevent replay attacks
The answer in red can be expanded saying that it can be considered a small flaw in the protocol
Part 3  Protocols

29. SSL Authentication Alice authenticates Bob, not vice-versa
How does client authenticate server?
Why does server not authenticate client?
Mutual authentication is possible: Bob sends certificate request in message 2
This requires client to have certificate
If server wants to authenticate client, server could instead require (encrypted) password
It is very uncommon that users have a certificate to send back to the server
Sending a password back to the server would be separate from the SSL protocol
Part 3  Protocols

30. SSL MiM Attack RA RA certificateT, RB certificateB, RB
{S1}Trudy,E(X1,K1)
{S2}Bob,E(X2,K2)
h(Y1,K1)
h(Y2,K2)
Trudy
E(data,K1)
E(data,K2)
Alice
Bob
Q: What prevents this MiM attack?
A: Bob’s certificate must be signed by a certificate authority (such as Verisign)
What does Web browser do if sig. not valid?
What does user do if signature is not valid?
Web browser pops up a warning
User will probably ignore the warning
Then MIM successful!
Part 3  Protocols

31. SSL Sessions vs Connections
SSL session is established as shown on previous slides
SSL designed for use with HTTP 1.0
HTTP 1.0 usually opens multiple simultaneous (parallel) connections
SSL session establishment is costly
Due to public key operations
SSL has an efficient protocol for opening new connections given an existing session
SSL originally developed by Netscape, for web browsing
Each connection would need to establish a new key, using costly public key crypto
Part 3  Protocols

32. SSL Connection session-ID, cipher list, RA session-ID, cipher, RB,
h(msgs,SRVR,K)
h(msgs,CLNT,K)
Protected data
Bob
Alice
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)
Alice and bob share the symmetric key S
Use it to establish new connections
Avoids expensive public key operations
No public key operations! (relies on known S)
Part 3  Protocols

33. SSL vs IPSec IPSec  discussed in next section
Lives at the network layer (part of the OS)
Has encryption, integrity, authentication, etc.
Is overly complex (including serious flaws)
SSL (and IEEE standard known as TLS)
Lives at socket layer (part of user space)
Has a simpler specification
Very important: SSL -> USER SPACE while IPSec -> OS level
Part 3  Protocols

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

35. IPSec
Part 3  Protocols

36. IPSec and SSL IPSec lives at the network layer
IPSec is transparent to applications
application
transport
network
link
physical
User
SSL OS
IPSec
Major advantage of IPSec: it is transparent to applications
NIC
Part 3  Protocols

37. IPSec and Complexity IPSec is a complex protocol Over-engineered
Lots of generally useless extra features
Flawed
Some serious security flaws
Interoperability is serious challenge
Defeats the purpose of having a standard!
Complex
Did I mention, it’s complex?
Even the specification documents were written by disjoint sets of authors
Part 3  Protocols

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

39. IKE
Part 3  Protocols

40. IKE IKE has 2 phases Phase 1 is comparable to SSL session
Phase 1  IKE security association (SA)
Phase 2  AH/ESP security association
Phase 1 is comparable to SSL session
Phase 2 is comparable to SSL connection
Not an obvious need for two phases in IKE
If multiple Phase 2’s do not occur, then it is more expensive to have two phases!
Phase 1 is the more complex of the two
Phase 1: IKE is established
Part 3  Protocols

41. IKE Phase 1 Four different “key” options
Public key encryption (original version)
Public key encryption (improved version)
Public key signature
Symmetric key
For each of these, two different “modes”
Main mode
Aggressive mode
There are 8 versions of IKE Phase 1!
Evidence that IPSec is over-engineered?
Why is there a public key encryption and a digital signature option?
Alice always knows her own private secret key, but she may not know Bob’s public key, at the beginning
With the signature version, she doesn’t need Bob’s public key beforehand
Part 3  Protocols

42. IKE Phase 2 Phase 1 establishes IKE SA Phase 2 establishes IPSec SA
Comparison to SSL
SSL session is comparable to IKE Phase 1
SSL connections are like IKE Phase 2
IKE could be used for lots of things
But in practice, it’s not!
Part 3  Protocols