Security Protocols Professor Patrick McDaniel CSE545 - Advanced Network Security Spring 2011 CSE545 - Advanced Network Security - Professor McDaniel 1
Case Study: Host Access The first systems used telnet as the primary utility for accessing systems remotely. Telnet connects across the network on port tcp/23 Remotely allows a user access to the login prompt Username/passwords are supplied, allowed access to shell Everything is sent in cleartext across the network (eavesdropping) even the password! 2
RSH/RCP Remote shell (rsh) was introduced as a means of allowing remote access without having to login. Users would assert their identity implicitly in the call, and could invoke whatever scripts were allowed by that machine. -c <cmd> run whatever scripts were needed The /etc/hosts.equiv file indicates which machines should be allowed to invoke whatever users they want. The ~/.rhosts file allows users to identify trusted hosts 3
Problems? Of course both of these models were terrible from a security standpoint User identity could be asserted Traffic could be eavesdropped Passwords could be guessed Sadly, the standard in remote access until about 2000. 4
SSH Secure shell (ssh) - an alternate to telnet that looks and feels just like telnet! The difference is that it transparently uses cryptographic keys to provide for confidentiality, integrity, and authentication Concepts: Each machine has an identity recorded by each user Ever user has an identity Stored in each user s home directory They perform mutual authentication at startup, negotiate session keys, and use it to secure all the session communication 5
SSH Server Configuration files /etc/ssh/ssh_host_key.pub (pub identifies host) ~/.ssh authorized_keys2 (pub user keys) Client Configuration files ~/.ssh/known_hosts2 (pub keys of known hosts) ~/.ssh/id_dsa (priv key of user) 6
SSH Authentication RFC 4251: The client sends a service request once a secure transport layer connection has been established. A second service request is sent after user authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above. (1) SSH_MSG_USERAUTH_REQUEST (user, service...) Client (2) SSH_MSG_USERAUTH_INFO_REQUEST (user, authtype, prompt, challenge,...) (3) SSH_MSG_USERAUTH_INFO_RESPONSE (user, response,..) Server Note: IETF standards identify the different services of SSH, which define the message formats and semantics of the protocols: (arch RFC 4251, auth 4252). 7
What it means? Security model of ssh: I can configure a.rhosts if you want, but no longer forgable Note: defaults to password if user identity not configured on server You authenticate hosts based on first interaction Build a map of known identities over time, warned when the identity changes (typically upon reinstall, or refresh - most ignore) Can t solve: Password cracking Traffic analysis Covert channels Thus: limited but highly usable way to access hosts. 8
Key Agreement Key negotiation/agreement is the basis for establishing a secure channel (q: what was the key agreement in SSH?) The predominant means of performing this is Diffie- Hellman, which allows two parties to exchange data over an insecure channel. Used as the basis for everything from SSL/TLS to IPsec Incredibly elegant and easy to understand Easy to implement? Side note: an alternate history of DH. Does it matter? 9
Multiplicative Groups Let p be a prime integer: The multiplicative group Z p is the set of integers which are invertable modulo p. The set Z p is a cyclic group of order p 1 for the operation modulo p A generator g of Z p: g Z p such that any h Z p can be uniquely written as h = g x mod p with 0 x p x is called the discrete logarithm of h to base g, and denoted log g h 10
Cyclic Group (p=11, g=6) 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 11
Diffie-Hellman 1. Select prime number n and base generator g 2. Alice chooses a random integer X and sends to Bob c A = g X mod n 3. Bob choose a random large Y and sends to Alice c B = g Y mod n 4. Alice then computes the key k = c X B mod n 5. Bob computes k = c Y A mod n. Note: by convention, n is used to signify prime p in most descriptions of Diffie-Hellman 12
Why DH works For any X and Y : (6 X mod 11) Y mod 11 = (6 Y mod 11) X mod 11 = 6 XY mod 11 or more generally (g X mod n) Y mod n =(g Y mod n) X mod n = g XY mod n 13
The hard part Selecting n and g is hard. g must be generator for multiplicative group of integers modulo n g is a primitive root modulo n Turns out for random prime n, finding g is really hard You need to be able to factor (n-1), which is a known hard problem So, what do you do? Observe: g is a generator for n IFF: g (n 1)/q mod n = 1 for each prime factor q of n 1 Which leads is to the trick for generating n and g... 14
Finding g Assume n = 11 Check g = 5: prime factors of n 1 = 10 = 2, 5, so 5 2 mod 11 = 25 mod 11 = 3, 3 = 1, OK 5 5 mod 11 = 3125 mod 11 = 1, not OK Check g = 6: prime factors of n 1 = 10 = 2, 5, so 6 2 mod 11 = 36 mod 11 = 3, 3 = 1, OK 6 5 mod 11 = 7776 mod 11 = 10, OK 15
Selecting DH Parameters 1. Phase 1: selectn 2. Pick a large candidate prime n 3. Assign q =(n 1)/2 4. Test primality of q. Ifq is not prime, goto step 1. 5. Phase 2: selectg 6. Pick large integer g 7. Check g q mod n = 1and g 2 mod n = 1, otherwise goto step 5. 16
Notes Trick: select n such that finding g is easy Phase1could be slow, phase 2 is fast any g<n is a generator for n with Pr(1/2) Which is why it works!! OK, pull out those calculators!! 17
SSL/TLS The Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols implement security at the application layer Popular for securing the web, but not part of it Is a general purpose secure communication protocol suite Uses certificate authentication HTTP FTP SMTP SSL/TLS TCP Note: throughout we will focus on SSLv3. Assume SSLv3 unless stated otherwise. IP 18
Model Often a one-way authentication mechanism, used to prove the authenticity of a web-server to a client. Server-side certificates Root CA certifications distributed with browser Non-certified (or expired) certificates can be accepted Mutual authentication performed using client-side certificates Less frequently uses (almost never in Web applications) Where used for enterprise internal or as layer for non-web based applications, much more frequently. 19
SSL as protocol suite Data Protocols Record Protocol Control Protocols Handshake Protocol Change Cipher Suite Protocol Alert Protocol Session Connection Connection Alice Connection Note: Sessions can be resumed using lost cost cryptography if both sides retain state. Connection Bob Connection Connection 20
SSL Session State Session ID Peer certificate (sometimes) Cipher Spec Compression algorithm Master Secret K = f(s, R s,r c ) 21
SSL Connection State Server and client random Server integrity key Client integrity key Server write key Client write key (2) Initialization vectors Oddly, referred to by many as keys? 22
Handshake Protocol The purpose of the handshake protocols is to authenticate one or both parties negotiate shared master keys Protocol operates in 4 phases Phase 1: establish security context Phase 2: server publishes certificate and key seeds Phase 3: client completes key exchange Phase 4: complete handshake 23
Phase 1 Client sends and offer (CLIENT_HELLO) including SSL Version (highest supported) Random (RC) - { timestamp, plus 28 random bytes } Session ID - { 0 = new session,!0 = refresh } CipherSuite - algorithm selections for security/compression Server replies with (SERVER_HELLO) response Section of SSL version, crypto and compression algorithms A new session ID (as needed) (SID) A server random number (RS) 24
Phase 2 Server sends a (CERTIFICATE) This contains the public key certificate for the server Ks+ Server sends a (SERVER_KEY_EXCHANGE) This contains the server parameters for the key exchange to be performed (there are many variants) For example, the anonymous Diffie-Hellman sends the prime number and primitive root (n,r) The key exchange parameters are signed using the private key of the server with exchanged random numbers, e.g., sig(k s, [n g X = g x mod n]) = Sig(K s,r c R s n g X) Server sends a completion (SERVER_DONE) 25
Phase 3 Client sends a (CERTIFICATE) - optional This contains the public key certificate for the clients Ks+ Client sends a response (CLIENT_KEY_EXCHANGE) This contains the client s key exchange parameters As before this is the public client Diffie-Hellman parameters Signed if client has signing capability The parties generate the pre_master_secret X = g x mod n Y = g y mod n p ms = Y x mod n = X y mod n 26
Phase 4 Both sides complete the process by computing the 48 byte master secret: M s k = MD5(p ms SHA( A p ms R c R s )) MD5(p ms SHA( BB p ms R c R s )) MD5(p ms SHA( CCC p ms R c R s )) Then generate a key block of secret bytes key block = MD5(M s k SHA( A M s k R c R s )) MD5(M s k SHA( BB M s k R c R s )) MD5(M s k SHA( CCC M s k R c R s )) MD5(M s k SHA( DDDD M s k R c R s ))... 27
Transport Keys Just use the key_block as a PRF to generate enough bytes to generate the keys for clients and servers. key_block Client Write Key Server Write Key Client MAC Key Server MAC Key... Note: this PRF is practically of unlimited length and in practice (although generated differently) is used extensively on TLS. 28
Record Protocol Provides to client (initiator) and server (service) Original Data Confidentiality (via encryption) Integrity (via MAC) Fragmented Data Fragmented Data Fragmented Data Data is fragmented, compressed, and security constructions applied. Compressed Data Compressed Data M A C Encrypted Data H D R Encrypted Data 29
Record Format Seq. No. Header Payload (Integrity Key) HMAC Header Payload HMAC Pad (Write Key) Header Encrypted Payload HMAC Pad 30
RFC 2104 (MAC for TLS) Given: h() = hash function B = input/out byte-length of h K = a secret key pad i = inner pad = 0x35 repeated B times pad o = outer pad = 0x5C repeated B times text = text to MAC Compute the MAC: MAC(K, text) =(H((K pad o ) H((K pad i ) text))
Alert/CCS Protocol Change Cipher Suite Protocol Trigged at end of handshake, causes security association to be enabled Alert Protocols - signals MAC failure No known certificate Handshake failure Bad certificate Close notification 32
Why not SSL v2.0? SSL v2.0 is the real "first" version of the protocol offered by NetScape, replaced with v3.0 in 1996 (and standardized in TLS) Identical keys for authentication and encryption MACs are based on MD5 hash function Truncation attack (forged FIN) Man-in-the-middle downgrade attack ClientHello message specifies the highest supported TLS/SSL protocol version and suggested cipher suites and compression methods. ServerHello, containing the chosen protocol version, cipher suite, and compression method from the choices offered by the client. 33
Export Restrictions Following the cold war, western countries place restrictions on the export/sale of cryptography (and in some cases computers) The release of DES in 1973 started modern age of cryptography... lead to sometimes obtuse regulations on the use of it. The "munitions" clause is probably the most famous. Today: they still exist, largely targeted at military-grade cryptography and rouge states. 34
Export restricted SSL Consequence: SSL v2.0 used MAC and encryption functions that severely reduced the effective key length of the symmetric keys 40-bit MACs (instead of 128) 40-but encryption (instead of 128) Trivially breakable now, within reach then. 1/309485009821345300000000000th (2^88) as hard Browsers were shipped with "international" versions. 35
Why?... does SSL work?... does SSL not work?... is SSL so popular? 36