Protocols Part 3  Protocols 1

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 2

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 3

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 4

Simple Security Protocols Part 3  Protocols 5

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 6

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

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 8

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 9

Authentication Protocols Part 3  Protocols 10

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 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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 21

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 22

Secure Socket Layer Part 3  Protocols 23

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 24

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 25

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 26

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 27

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 28

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 29

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 30

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 31

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 32

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 33

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 34

IPSec Part 3  Protocols 35

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 36

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 37

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 38

IKE Part 3  Protocols 39

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 40

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 41

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 42