Part III Protocols Widely Used RealWorld Security Protocols

Part III: Protocols Widely Used Real-World Security Protocols q We look at Real-World Protocols 1. Secure Shell (SSH) relatively simple & useful protocol 1. Used for a variety of purposes 2. Secure Sockets Layer (SSL) / Transport Layer Security (TLS, the updates of SSL) practical security on the Web 1. Currently the most widely used security protocol for Internet transactions? 3. Internet Protocol Security (IPSec) security at the IP layer 1. A complex protocol with some significant security issues 4. Kerberos symmetric key, single sign-on 1. A popular authentication protocol based on symmetric key cryptography and timestamps. 5. Wired Equivalent Privacy (WEP) “Swiss cheese” of security protocols § A seriously flawed security protocols, and we'll consider several well-known attacks. Part 3 Protocols 1

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 2

Secure Shell (SSH) q SSH is a relatively simple protocol o Creates a “secure tunnel” o Insecure command sent through SSH “tunnel” are then secure o For Example: SSH used with things like UNIX rlogin command § Used to log into a remote machine over a network § Why is rlogin insecure without SSH? Why is rlogin secure with SSH? Ø Ø Ø q Typically rlogin simply sends the password in the clear. By first establishing an SSH session, then confidentiality and integrity are protected thereby eliminating Trudy's ability to obtain passwords and other confidential information that would otherwise be sent unprotected SSH authentication can be based on: o Public keys, or Digital Certificates, or Passwords q Here, we give a slightly simplified version of SSH using digital certificates. o In this simplified version, a few parameters have been omitted and a couple of bookkeeping messages have been eliminated Part 3 Protocols 3

Simplified SSH 1. Alice, CP, RA 2. CS, RB 3. ga mod p 4. gb mod p, certificate. B, SB Alice, a q q q 5. E(Alice, certificate. A, SA, K) Bob, b certificate. A = Alice's certificate. B = Bob's certificate CP = “crypto proposed”, and CS = “crypto selected” ga mod p = Diffie-Hellman value H = h(Alice, Bob, CP, CS, RA, RB, ga mod p, gb mod p, gab mod p) SB = [H]Bob SA = [H, Alice, certificate. A]Alice K = gab mod p RA = nonce from Alice Rb = nonce from Bob Part 3 Protocols 4

Mi. M Attack on SSH? Alice, RA RB RB ga mod p Alice, a q q gt mod p, cert. B, SB gb mod p, cert. B, SB E(Alice, cert. A, SA, K) Trudy, t Bob, b Where does this attack fail? Alice computes Ha = h(Alice, Bob, CP, CS, RA, RB, ga mod p, gt mod p, gat mod p) q But Bob signs Hb = h(Alice, Bob, CP, CS, RA, RB, gt mod p, gbt mod p) q Where it is supposed to be H = h(Alice, Bob, CP, CS, RA, RB, ga mod p, gb mod p, gab mod p) Part 3 Protocols 5

Secure Socket Layer (SSL) & Transport Layer Security (TLS) (TLS is the updates of SSL) Part 3 Protocols 6

Socket layer q q Socket “layer” In practice, “Socket layer” (SSL) most often deals with Web browsing Thus, SSL lives between application (i. e. HTTP) and transport (i. e. TCP) layers application transport network link physical q User OS NIC What is SSL? o SSL is the protocol used for majority of secure Internet transactions today o For example, if you want to buy a book at www. amazon. com … § You want to be sure you are dealing with Amazon Ø Authentication § Your credit card information must be protected in transit Ø Confidentiality: to protect your privacy, and/or Ø Integrity: to assure the transaction is received correctly § As long as you have money, Amazon does not really care who you are… § …so, no need for mutual authentication

Simple SSL-like Protocol 1. I’d like to talk to you securely (the client) 2. Here’s my certificate 3. {KAB}Bob Alice q q q 4. protected HTTP Bob (the server) Is Alice sure she’s talking to Bob? o In 3, Alice is trying to verify the signature on the certificate, but she is still not certain o Bob is not explicitly authenticated; she can check to see that the encrypted data decrypts correctly !(only) Is Bob sure he’s talking to Alice? No! but it is maybe reasonable for some transactions! Simplified SSL Protocol (actual SSL protocol is more complex) 1. Can we talk? , cipher list, RA 2. certificate, cipher, RB 3. {S}Bob, E(h(msgs, CLNT, K) Alice q q 4. h(msgs, SRVR, K) 5. Data protected with key K Bob S is the so-called pre-master secret (randomly generated, S used as a base to form the session key K) K = h(S, RA, RB), shared session key K, msgs = means all previous messages (hash is the integrity check on previous msg. ) CLNT and SRVR are constants (literal string)

SSL Keys q q In reality, more than one key is derived from the hash h(S, RA, RB) 6 “keys” derived from K = h(S, RA, RB) o o 2 encryption keys: one for client-to-server & another for server-to-client 2 integrity keys: client and server; (used in the same way as the encryption keys) 2 IVs: client and server In short, different keys are used in each direction, but why? § Reduce attacks where Trudy tricks Bob into doing something that Alice should have done, or vice versa q Q: In 3, why is h(msgs, CLNT, K)encrypted, is it extra work & no added value? q SSL Authentication o Note: Alice authenticates Bob, not vice-versa § How does client authenticate server? Ø certificate request § Why would server not authenticate client? o Mutual authentication is possible: Bob sends certificate request in message 2 § Then client must have a valid certificate, bad for e-commerce situations § But, if server wants to authenticate client, server could instead require password Part 3 Protocols 9

SSL and the Mi. M Attack? RA RA certificate. T, RB certificate. B, RB {S 1}Trudy, E(X 1, K 1) {S 2}Bob, E(X 2, K 2) h(Y 1, K 1) h(Y 2, K 2) E(data, K 1) E(data, K 2) Alice Trudy q Q: What prevents this Mi. M “attack”? q A: Bob’s certificate must be signed by a certificate authority (CA) Bob o But what mechanism in SSL prevents this attack? o If Trudy sends her own certificate instead of Bob's (or a bogus one), the attack will fail when Alice attempts to verify the signature on the certificate q But, SSL is used in a Web browsing session, and browsers validate certificate not Alice o What does browser do if signature not valid? (warnings!!!) o What does user do when browser complains? § Often, ignores the warning, which may allow the connection to proceed Ø This opens the door to the Mi. M attack Ø Note: if this is to happen, then it is due to a flaw in human nature, not SSL protocol

q SSL Connection SSL Sessions vs. Connections o SSL session is established when the session key K is established (using public key crypto) o SSL designed/developed by Netscape for use with HTTP 1. 0; (later HTTP 1. 1 and HTTP 2. 0) o SSL session is costly, public key operations § Overhead, if a new SSL session is to be established for each connection o So, common for a Web browser to open multiple parallel connections (shared SSL session K) § Multiple connections per session (to improve performance) o Thus, SSL is efficient when opening new connections given an existing session § one (expensive) session is required, but then we can create any number of (cheap) connections session-ID, cipher list, RA session-ID, cipher, RB, h(msgs, SRVR, K) h(msgs, CLNT, K) Alice Protected data q Assuming SSL session exists q So, S is already known to Alice and Bob q Both sides must remember session-ID q Again, K = h(S, RA, RB) q No public key operations! (relies on known (previously established) S) Bob

Internet Protocol Security (IPSec) Part 3 Protocols 12

IPSec and SSL/TLS q IPSec lives at the network layer IPSec is transparent to applications q The two main parts to IPSec are q q User application transport IPSec q The Internet Key Exchange, or IKE, which provides for mutual authentication and a session key. q The Encapsulating Security Payload and Authentication Header, or ESP/AH, which together make up the second part of IPSec. OS network link NIC physical IPSec and Complexity o IPSec is a complex protocol o Complex and Over-engineered § Lots of (generally useless) features o Flawed Some significant security issues o Interoperability is serious challenge § Defeats the purpose of having a standard! Part 3 Protocols 13

SSL vs IPSec q SSL (and IEEE standard known as TLS) q IPSec o Lives at socket layer (part of user space) o Lives at the network layer (part of the OS) o Encryption, integrity, authentication, etc. o Relatively simple and elegant specification o Overly complex, has some security “issues” q Both SSL and IPSec provide encryption, integrity protection, and authentication. q SSL is relatively simple and well designed, whereas IPSec is complex and, as a result, includes some significant flaws. q IPSec: OS must be aware, but not apps, therefore not directly accessible from user space q SSL: resides in user space; Apps must be aware, but not OS q SSL built into Web early-on (Netscape) q IPSec often used in Virtual Private Networks (VPNs) o an application that creates a secure tunnel between the endpoints. q IPSec not widely deployed (complexity, etc. ), but q IPSec is required in IP version 6 (IPv 6), q The bottom line? Internet less secure than it could be! Part 3 Protocols 14

Kerberos In security, Kerberos is a popular authentication protocol that uses symmetric key cryptography and timestamps Kerberos is designed for a smaller scale, such as on a Local Area Network (LAN) or within a corporation Kerberos is used for authentication and to establish a session key that can subsequently be used for confidentiality and integrity. Part 3 Protocols 15

Kerberos q In Greek mythology, Kerberos is 3 -headed dog that guards entrance to Hades q Kerberos is an authentication protocol Originated at MIT o SSL and IPSec are designed for the Internet, Kerberos is designed for a smaller scale § such as on a local area network (LAN) or within a corporation o Suppose N users, where each pair needs to be able to authenticate each other o Relies on a Trusted Third Party (TTP): (plays a similar role as a certificate authority). q Motivation for Kerberos o If authentication is using public keys, then § N users each user requires a public-private key pair N key pairs o If authentication is using symmetric keys, then § N users each pair of users must share a symmetric key requires N(N-1)/2 ≈ N 2 keys § Thus, authentication based on Symmetric key does not scale o Kerberos based on symmetric keys but only requires N keys for N users - Security depends on a Trusted Third Party (TTP) known as Key Distribution Center or (KDC ) - Kerberos only requires N symmetric keys for N users + No public key infrastructure (PKI) is needed, only KDC

Kerberos KDC q Kerberos Key Distribution Center or KDC o TTP is trusted, so it must not be compromised o TTP plays a similar role as a certificate authority in a public key system (PKI). q Kerberos only requires N symmetric keys for N users. o Users do not share keys with each other o Instead each user shares one key with the KDC, § § Alice and KDC share KA, Bob and KDC share KB and so on; & master key KKDC known only to KDC o KKDC allows the KDC to remain stateless, which eliminates most Do. S attacks o KDC enables authentication, session keys which are used for confidentiality and integrity q The bottom line is that Kerberos uses symmetric keys in a way that does scale. o The used crypto algorithm is DES

Kerberos Tickets q A ticket contains the keys and other information required to access network resource o KDC issue tickets containing info needed to access network resources o KDC also issues Ticket-Granting Tickets or TGTs that are used to obtain tickets o A TGT is issued when a user initially logs into the system; acts as the user's credentials o Then the TGT is used to obtain (ordinary) tickets that enable access to network resources q Each TGT contains 1. Session key, 2. User’s ID, 3. Expiration time (TGTs don't last forever) q Every TGT is encrypted with KKDC o So, TGT can only be read by the KDC. Why? o Otherwise, the KDS would have to maintain state Part 3 Protocols 18

Kerberized Login q q Alice enters her username & password Then Alice’s computer does the following: o Derives KA from Alice’s password o Uses KA to get TGT for Alice from KDC q Alice then uses her TGT (credentials) to securely access network resources o Once Alice has logged in, all of the security is automatic and takes place behind the scenes Alice wants Alice’s a TGT E(SA, TGT, KA) password Alice q q Computer KDC Key KA = h(Alice’s password) KDC creates session key SA Alice's computer uses KA to obtain SA and the TGT; then Alice's computer forgets KA TGT = E(“Alice”, SA, KKDC) Plus: entire security process (beyond the password entry) Minus: KDC must be secure it’s trusted!

Kerberos Ticket q Once Alice's computer receives its TGT, o it can then use the TGT to request access to network resources q For example, suppose that Alice wants to talk to Bob o Alice's computer presents its TGT to the KDC, o Along with an authenticator § The authenticator is an encrypted timestamp that serves to avoid a replay § Then, the KDC verifies Alice's authenticator, it responds with a "ticket to Bob“ § Then, Alice's computer uses this “ticket to Bob” to securely communicate directly with Bob's computer. authenticator = E(timestamp, KAB). § Note that Bob decrypts "ticket to Bob" with his key KB to obtain KAB, then uses to verify the timestamp from the authenticator § KAB is also used to protect the confidentiality and integrity of the subsequent conversation between Alice and Bob. Part 3 Protocols 20

Alice Requests “Ticket to Bob” I want to talk to Bob Talk to Bob REQUEST REPLY Alice Computer KDC q REQUEST = (TGT, authenticator); q REPLY = E(“Bob”, KAB, “ticket to Bob”, SA); “ticket to Bob” = E(“Alice”, KAB, KB) KDC gets SA from TGT to verify timestamp q q authenticator = E(timestamp, SA) Alice Uses Ticket to Bob “ticket to Bob”, authenticator Alice’s Computer E(timestamp + 1, KAB) Bob q ticket to Bob = E(“Alice”, KAB, KB) q authenticator = E(timestamp, KAB) Bob decrypts “ticket to Bob” to get KAB which he then uses to verify timestamp q

q Kerberos Summary Key SA used in authentication o For confidentiality/integrity q q 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 q Questions about Kerberos o 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 o In Alice’s “Kerberized” login to Bob, why can Alice remain anonymous? o Why is “ticket to Bob” sent to Alice? Why doesn’t KDC send it directly to Bob? q Kerberos Alternatives o Could have Alice’s computer remember password and use that for authentication § Then no KDC required, But hard to protect passwords, Also, does not scale o Could have KDC remember session key instead of putting it in a TGT § Then no need for TGT, But stateless KDC is major feature of Kerberos

Wired Equivalent Privacy (WEP) A security protocol that was designed to make a wireless local area network (LAN) as secure as a wired LAN Part 3 Protocols 23

WEP q q q 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. ” q WEP Authentication Request R Alice, K q q E(R, K) Bob is wireless access point Key K shared by access point and all users o Key K seldom (if ever) changes q WEP has many, many security flaws ? ? ? Bob, K

More WEP Integrity Issues q q Suppose Trudy knows the destination IP Then Trudy also knows keystream used to encrypt IP address, since C = destination IP address keystream q Then Trudy can replace C with C = Trudy’s IP address keystream q And change the CRC so no error detected o Then what happens? ? q Moral: Big problems when integrity fails q WEP Key o Recall WEP uses a long-term key K o RC 4 is stream cipher, so each packet must be encrypted using a different K § Initialization Vector (IV) sent with packet in the clear, that is, IV is not secret o Actual RC 4 key for packet is (IV, K) § That is, IV is pre-pended to long-term key K Part 3 Protocols 25

Cryptanalytic Attack q WEP Conclusions o Many attacks are practical o Attacks have been used to recover keys and break real WEP traffic o How to prevent these attacks? § Don’t use WEP § Good alternatives: Wi-Fi Protected Access (WPA), & WPA 2, etc. o How to make WEP a little better? § Restrict MAC addresses, don’t broadcast ID, … Part 3 Protocols 26

Protocols Summary q Generic authentication protocols o Protocols are subtle! q SSH SSL IPSec Kerberos Wireless: GSM and WEP q Coming Attractions… q q o Software and security § Software flaws buffer overflow, etc. § Malware viruses, worms, etc. § Software reverse engineering § Digital rights management § OS and security/NGSCB Part 3 Protocols 27