EE 418 Network Security and Cryptography Lecture #18

EE 418 Network Security and Cryptography Lecture #18 December 6, 2016 Public Key Infrastructure. Authentication. Internet Security Lecture notes prepared by Professor Radha Poovendran. Tamara Bonaci Department of Electrical Engineering University of Washington, Seattle Outline: 1. Review: Key Distribution and Management 2. Review: Public key infrastructure (PKI) 3. Introduction to Authentication Bellovin-Merritt Encrypted Key Exchange (EKE) Augmented Strong Password Protocols Secure Remote Password (SRP) Protocol 4. Internet Protocol Security (IPsec) 5. Secure Socket Layer (SSL) and Transport Layer Security (TLS) 1 Review: Introduction to Key Distribution and Management Last week, we started our conversation about key distribution and management. We considered two main problems that we need to address in order to ensure CIA security goals: 1. If Alice and rely on symmetric-key cryptography, they have to share the same secret encryptiondecryption key. How to they established that shared secret key over an insecure communication channel? 2. On the other hand, if Alice and rely on public key cryptography, then how do they know that the public key that they obtain somewhere online indeed belongs to the person they are wanting to talk to? On Tuesday, we focused on the first problem, related to symmetric-key cryptography, and we showed that there are two possible approaches that Alice and can take: (a) Alice and can use public key cryptography to establish a shared secret key that they can then use to communicate securely using symmetric-key cryptography. (Diffie-Hellman protocol) (b) Alice and can rely a trusted third party, known as a key distribution center (KDC), to help them establish a shared secret key. (Needham-Schroeder protocol) 2 Needham-Schroeder Protocol The Needham-Schroeder (N-S) is a protocol that allows Alice and to agree on a shared key using a key distribution center (KDC). The steps in N-S are illustrated in Figure 1 and described as follows: 1. Before initiating the protocol, Alice is assumed to share a key with the KDC, denoted K A. Similarly, is assumed to share a key K B with the KDC. Alice and both have unique identifiers ID A and ID B that are known to each other and the KDC. 2. Alice contacts the KDC and requests a shared key to communicate with by generating a random nonce r A and sending a message ID A ID B r A. 3. The KDC generates a shared key K AB and a ticket t B = E KB (K AB ID B ). The KDC sends E KA (r A ID B K AB t B ) to Alice. 4. Alice decrypts the message sent by the KDC and extracts t B and K AB. Alice checks to make sure that the decrypted r A sent by the KDC matches the r A sent by Alice. Alice then transmits ID A t B to. 5. decrypts t B using K B and extracts K AB. generates a random number r B and transmits E KAB (r B ) to Alice. 6. Alice decrypts s transmitted message using K AB. Alice computes E KAB (r B 1) and transmits this message to. By decrypting the message using K AB, verifies that Alice knows the key K AB. 1

KDC IIDD AA IIDD BB rr AA Chooses r A Alice Generates KK AAAA Computes tt BBoooo = ee KKBB (KK AAAA IIDD AA KK AAAA ee KKAA (rr AA IIDD BB tt BBBBBB tt BBBBBB Extracts K AB, t using K A Extracts K AB using K A ee KKAAAA (rr BB Chooses r B ee KKAAAA (rr BB 1 Fig. 1. Establishing a shared key using a KDC with the Needham-Schroeder protocol. 2.1 Replay Attack on Needham-Schroeder The N-S protocol was found to be vulnerable to a replay attack by Denning and Sacco in 1987. The steps of the attack are depicted in Figure 2: 1. An attacker Eve eavesdrops on the N-S protocol and obtains the messages exchanged by Alice,, and the KDC, including the ticket t B. 2. The attacker obtains a key K AB generated during a previous execution of the N-S protocol. 3. The attacker contacts, pretending to be Alice, and transmits ID A t B to. 4. decrypts t B using K B and extracts the key K AB, which is known to the adversary. generates a random number r B and transmits E KAB (r B ) to Alice. 5. Since the attacker knows K AB, (s)he decrypts s transmitted message using K AB. The attacker transmits E KAB (r B 1) to. 2.2 Kerberos Kerberos was developed at MIT in the 1980s to enable the use of a KDC without vulnerability to replay attack. Kerberos is described by IETF RFC 4120. The steps in Kerberos are depicted in Figure 3, and given as follows: 1. Alice generates a random number r A and sends ID A ID B r A to the KDC. 2. The KDC computes t B = E KB (K AB ID A L), where L is the lifetime of the secret key K AB. The KDC transmits y 1 = E KA (r A ID B K AB L) and t B to Alice. 3. Alice decrypts y 1 and obtains K AB. Alice computes y 2 = E KAB (ID A time), where time is Alice s current system time. Alice transmits y 2 t B to. 4. decrypts t B and obtains K AB. If time > L, then the key has expired and discards the key. replies to Alice with E KAB (time + 1). 2

Eve records Eve Obtains old key K AB recorded ttbbbbbb ee KKAAAA (rr BB ee KKAAAA (rr BB 1 Fig. 2. The replay attack on Needham-Schroeder. KDC Generates KK AAAA, chooses lifetime L Computes tt BBBBBB = ee KKBB (KK AAAA IIDD AA LL yy 1 = ee KKAA (rr AA IIDD BB KK AAAA LL IIDD AA IIDD BB rr AA Chooses r A Alice tt BBBBBB yy 1 Computes yy 2 = KK AAAA (IIDD AA tttttttt) tt BBBBBB yy 2 ee KKAAAA (tttttttt + 1 Extracts time Fig. 3. The Kerberos protocol. 3 Review: Public Key Infrastructure On Thursday, we started from an observation that, when Alice and communicate using public key cryptography, both users public keys should be managed to ensure that Alice has s correct public key 3

and vice versa. Otherwise, an attacker Eve could claim to be Alice and publish his/her own public key. Any messages for Alice encrypted by could then be read by the attacker. A standard approach to public key management is the use of Public Key Infrastructure (PKI). A key component of PKI are Certificate Authorities (CAs), which are trusted third-parties used to verify public keys. Alice can verify s public key with the help of a CA through the following procedure, depicted in Figure 4: 1. Alice sends a request to for s public key. 2. sends a certificate C, which contains s public key P K B, s identity, and possibly other information including the expiration time of the key (see Section 3.1). Attached to C is a signature σ = Sig P KCA (C), which is signed using the private key of the certificate authority. 3. Alice verifies the signature σ on certificate C. If the verification is successful, then Alice accepts P K B as s public key. Alice Certificate Authority, PK Alice Stores Sig CA (PK ) Sig CA (PK ) Verifies PK belong to Verifies PK PK, Sig CA (PK ) EE PPKKBBBBBB (mm Fig. 4. Verifying s public key using a certificate authority (CA). Thus, we can think of PKI as a secure system that generates, manages, and updates certificates in order to realize public key cryptography. Such a system consist of several important components: 1. Certificate Issuance: Certificates to users are issued by a Certification Authority (CA) (most of the times there are more than one). Certificates are issued after the user has proven its identity by some conventional means (as we have discussed in the past). 2. Certificate Revocation: Refers to the revocation of a certificate before the normal expiration time. Similar to canceling and reissuing a stolen credit card. 3. Key backup: The private keys of all certified users are stored for the purpose of recovery in case of loss. Recovery can occur in a similar fashion that one recovers a forgotten password (by proving its identity to the CA). 4. Timestamping: The times that certificates and keys are issued are recorded. These times can be used by different services for checking the validity of keys, certificates etc. PKI are used to enable several services involving security, and privacy, and some examples of those services are: 4

Secure email protocols such as Secure Multipurpose Internet Mail Extensions (S-MIME) and Pretty Good Privacy (PGP). Secure web services such as Secure Socket Layer (SSL) and Transport Layer Security (TLS). Secure VPNs employing the IPSec protocol. Access Control: Implementation of privilege management for access to services such as database information, printing, etc. Privacy: Issuance of anonymous or pseudonymous certificates for purpose of access control and preservation of anonymity. For example, when one has access to a service if it belongs ot a group, but the unique member is not identified. 3.1 X.509 Certificates Typically a certificate binds the identity of a user to a public key. X.509 is a standard for public key certificates, and has been adopted by the International Telecommunication Standardization Sector (ITU-T). An illustration of an X.509 certificate is given as Figure 5. An X.509 certificate consists of the following components: Version - The version of X.509 that is used. Serial number - An integer that, together with the CA s name, uniquely identifies the certificate. Signature - The algorithm used to compute the signature on the certificate. Issuer - The name of the issuing CA. Validity - Contains two fields: the time that the certificate becomes valid, and the last time for which it is valid. Subject - The name of the entity whose key is certified. SubjectPublicKeyInfo - The subject s public key, along with the algorithm for which the subject s public key is generated (e.g., RSA or DSA). AlgorithmIdentifier - The algorithm used to compute the signature on the certificate. Contains the same information as the Signature field described above. Encrypted - Contains the signature on all of the above fields except AlgorithmIdentifier. 3.2 Certificate Authorities There are many CAs operating in different countries and under different ownership. Examples include Symantec and GoDaddy, along with smaller CAs run by enterprises and individuals. The PKI must have a mechanism for relating the certificate authorities and determining whether a certificate can be trusted based on the CA that has signed it. A simple PKI organization is shown in Figure 6. In this PKI, a root CA issues certificates for Regional Authorities, which in turn sign the certificates of smaller CAs. The trustworthiness of each signature is derived from the common trust in the root CA. 4 Introduction to Authentication Authentication occurs when Alice and try to verify each other s identities. Typically, Alice authenticates herself to by proving that she has knowledge of a shared secret, such as a cryptographic key K AB. One method for Alice and to verify each other s identities is through a challenge-response protocol, as depicted in Figure 7. A basic challenge-response protocol has the following steps: 1. Alice sends her identity to. responds by sending a random nonce (a random number that is only used once), denoted R B, to Alice. 2. Alice responds to s challenge with E KAB (R B ). Alice then transmits a nonce R A. 3. verifies that the received message Y = E KAB (R B ). If it does, then responds to Alice s challenge with E KAB (R A ). 4. If the value of E KAB (R A ) is correct, Alice authenticates. 5

Certificate: Data: Version: 1 (0x0) Serial Number: 7829 (0x1e95) Signature Algorithm: md5withrsaencryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com Validity Not Before: Jul 9 16:04:02 1998 GMT Not After : Jul 9 16:04:02 1999 GMT Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb: 33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1: 66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66: 70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17: 16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b: c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77: 8 f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3: d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8: e8:35:1c:9e:27:52:7e:41:8f Exponent: 65537 (0x10001) Signature Algorithm: md5withrsaencryption 93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d: 92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92: ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67: d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72: 0 d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1: 5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7: 8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22: 68:9f Fig. 5. An example of an X.509 certificate. A more difficult scenario arises when Alice and do not share a cryptographic key K, but instead share a password pwd. This occurs when Alice is a client (user) and is a server. In this case, if Alice and attempt to use the protocol of Figure 7 using K = f(pwd) as a shared key, where f is a publicly known function, then Eve can mount the following dictionary attack: 1. Eve eavesdrops on a complete protocol interaction, and records s challenge R B and Alice s response E K (R B ). 2. Eve takes a list of possible passwords pwd 1,..., pwd n. For each password, Eve computes K i = f(pwd i ) and E Ki (R B ). If E Ki (R B ) = E K (R B ), then Eve has found the correct password. The dictionary attack is effective because users typically choose passwords that are much easier to guess than cryptographic keys. If Alice and need to authenticate each other using only a shared password, strong password protocols are needed that do not allow an attacker to perform the dictionary attack. 4.1 Bellovin-Merritt Encrypted Key Exchange (EKE) The Bellovin-Merritt Encrypted Key Exchange was developed by Steven Bellovin and Michael Merritt in 1992, and was protected by U.S. Patent 5,241,599 until its expiration in 2011. Bellovin-Merritt assumes that Alice and share a password pwd and can compute W = f(pwd), where f is a publicly known function. Bellovin-Merritt also assumes that Alice and have knowledge of a prime p and generator g, as in the Diffie-Hellman key exchange. The protocol achieves mutual authentication of Alice and, and enables Alice and to generate a stronger key K for further communication. The protocol consists of the following steps: 1. Alice generates a random a. Alice transmits her identity to, along with E W (g a mod p). 2. decrypts Alice s message and obtains g a mod p. generates a random number b and a nonce C 1, and computes K = g ab mod p. 6

Root RA 1 RA 2 RA 2 is approved. Its public key is 47383AE349 Root s signature CA 4 is approved. Its public key is 542EA34149 RA 2 s signature CA 1 CA 2 CA 3 CA 4 Fig. 6. A hierarchial PKI. Alice Knows K AB I am Alice Knows K AB I am, R B EE KKAAAA (RR BB R A EE KKAAAA (RR AA Fig. 7. Basic mutual authentication protocol. 3. transmits E W (g b mod p, C 1 ) to Alice. 4. Alice decrypts s message and obtains g b mod p and C 1. Alice computes K = g ab mod p and generates a nonce C 2 5. Alice transmits E K (C 1, C 2 ) to. 6. decrypts Alice s message and verifies that the first half of the message is C 1. computes E K (C 2 ) and transmits to Alice. 4.2 Security Properties of EKE The Bellovin-Merritt protocol provides the following security properties: Authentication of Alice: Only a user with knowledge of W could correctly decrypt s first message, obtain g b mod p, and compute K. authenticates Alice by checking that Alice encrypted his challenge C 1 using the correct key K. Authentication of : Similarly, only a valid could correctly compute K and E K (C 2 ). Security against Dictionary Attack: The only messages encrypted with W are g a mod p and g b mod p. In order for an adversary to check a possible password pwd, the adversary would need to decrypt both messages using key W = f(pwd ). After decrypting, however, the adversary cannot compute the key K due to the difficulty of the Diffie-Hellman problem, and hence has no way to determine if the possible password is correct. 4.3 Augmented Strong Password Protocols The EKE protocol prevents an adversary from impersonating Alice or without knowledge of W = f(pwd). The goal of augmented EKE is to ensure that a server does not need to store the client Alice s 7

pwd or W. That way, even if the server is compromised, an attacker cannot impersonate Alice. Instead, stores a prime p and 2 W mod p. The augmented strong password protocol is shown in Figure 8, and consists of the following steps: Alice Choose a, compute W and p from password Stores Alice, p, 2 W mod p 2 a mod p 2 b mod p, h(2 ab mod p, 2 bw mod p) Chooses b h (2 ab mod p, 2 bw mod p) Fig. 8. Augmented strong password protocol. 1. Alice generates a uniformly at random and transmits 2 a mod p to. 2. generates b uniformly at random, and transmits 2 b mod p and h((2 ab mod p) (2 bw mod p)), where h is a hash function. 3. Alice computes 2 ab mod p and h((2 ab mod p) (2 bw mod p)). If the hash value matches the value transmitted by, then Alice authenticates and transmits h ((2 ab mod p) (2 bw mod p)). Here h is a hash function that is different from h. 4.4 Security Properties of Augmented Strong Password Protocol The augmented strong password protocol provides the following security properties: Authentication of Alice: Alice must know the correct value of W to compute 2 bw mod p in the third message. Authentication of : must know 2 W mod p and b in order to compute 2 bw mod p. Security against Dictionary Attack: Whenever the key W appears in any message, the message is hashed. Hence an attacker cannot determine W without inverting the hash function. Security against Server Compromise: If an attacker compromises the server and obtains 2 W mod p, then the attacker must still solve an instance of the Discrete Logarithm Problem to find W, or mount a dictionary attack. 4.5 Secure Remote Password (SRP) Protocol SRP was proposed by Tom Wu in 1998, and is documented in RFC 2945. It appears in IETF protocols including Telnet (RFC 2944) and TLS (RFC 5054) authentication, and is implemented in OpenSSL. In SRP, stores g W mod p for some large prime p. SRP consists of the following steps: 1. Alice generates a random a, and then transmits her identity and g a mod p to. 2. generates b, a challenge C 1, and a 32-bit number u. transmits (g b + g W ) mod p, u, and C 1 to Alice. 3. computes K = (g a ) b (g W ) bu = g b(a+uw ) mod p. 4. Alice receives s message and extracts g b mod p by subtracting g W mod p from the first part of the message. Alice computes K = (g b ) a (g b ) uw = g b(a+uw ) mod p. Alice transmits E K (C 1 ) and C 2 to. 5. authenticates Alice based on her challenge and transmits E K (C 2 ) to Alice. 8

4.6 Security Properties of SRP SRP provides the following security properties: Authentication of Alice: Only a user with knowledge of W could compute (g b ) uw mod p (knowledge of g W mod p is not sufficient due to the difficulty of the Diffie-Hellman problem). Hence, only a valid Alice can compute the key K and respond to s challenge. Authentication of : The value of g W mod p must be known to compute (g W ) bu, and hence to compute the correct value of the key. Security against Dictionary Attack: In order to verify a guess of a password pwd, an attacker would have to solve an instance of the Diffie-Hellman problem to compute K, which is believed to be computationally difficult. Security against Server Compromise: If an attacker compromises the server and obtains g W mod p, then the attacker must still solve a Discrete Logarithm Problem to find W, or mount a dictionary attack. 5 Internet Protocol Security (IPsec) IPsec is a protocol suite designed to provide security properties, including confidentiality, integrity, and mutual authentication, to entities that communicate via the Internet Protocol (IP). IPsec can be used with IPv4 and IPv6, and is part of the IPv6 standard. IPsec is described by IETFs including RFC 5996 (Internet Key Exchange v2), RFC 4302 (Authenticated Header), and RFC 4303 (Encapsulating Security Payload). Under IPsec, Alice creates a cryptographically protected connection, called a Security Association (SA), to, and creates a corresponding SA to Alice. IPsec operates in two modes (Figure 9): Transport Mode Tunnel Mode IP header Rest of packet IP header Rest of packet IP header IPsec Rest of packet new IP header IPsec IP header Rest of packet Fig. 9. Transport and tunnel mode of IPsec. Transport mode: Transport mode adds IPsec information between the packet s IP header and the remainder of the packet. In transport mode, only the packet payload is encrypted and authenticated, while the IP header is unencrypted. Transport mode is used for IPsec over end-to-end connections. Tunnel mode: Tunnel mode adds a new IP header and IPsec information around the existing IP header. In tunnel mode, both the IP header and the packet payload are encrypted and authenticated. Tunnel mode establishes a private, secure communication link over an open, insecure channel such as the Internet, and is used to create virtual private networks. Tunnel mode is illustrated in Figure 10. In what follows, we first describe how IPsec creates a shared key between Alice and for the remainder of the session using the Internet Key Exchange (IKE) protocol. We then discuss how IPsec provides encryption and authentication to each packet. 5.1 Internet Key Exchange (IKE) The Internet Key Exchange consists of two phases. In Phase 1, mutual authentication and key establishment take place. In Phase 2, one or more SAs between Alice and are created. Phase 1 IKE has two modes of operation. Aggressive mode involves Alice and exchanging three messages, while main mode consists of three modes. The phase 1 protocol also changes based on whether Alice and use public key cryptography or a shared secret key to establish the connection. 9

Logical View A B Tunnel E F Physical View A B C D E F Flow: X Source: A Dest: F Data Source: B Dest: E Flow: X Source: A Dest: F Source: B Dest: E Flow: X Source: A Dest: F Flow: X Source: A Dest: F Data Data Data Encrypted Encrypted Fig. 10. Use of IPsec tunnel to create a virtual private connection. Nodes B and E act as proxies (tunnel endpoints) for nodes A and F. IKE using public signature keys: The IKE protocol when Alice and use digital signatures is described as follows (Figure 11). The protocol assumes that Alice and know each other s signature keys P K A and P K B, respectively. Alice Crypto Proposal Crypto Proposal Accepted g a mod p, R A Compute K = f(g ab mod p, R A, R B ) g b mod p, R B E K ( Alice, proof I am Alice, [certificate]) Compute K = f(g ab mod p, R A, R B ) E K (, proof I am, [certificate]) Fig. 11. IKE using public signature keys, main mode. 1. Alice sends a list of proposed cryptographic primitives, including primitives for encryption, hash, authentication, and Diffie-Hellman group. The Diffie-Hellman group consists of a prime p and a generator g. 2. replies to Alice with a message accepting the cryptographic primitives. 3. Alice generates a random number a and a nonce R A, and transmits g a mod p and R A to. 4. generates a random number b and a nonce R B, and transmits g b mod p and R B to Alice. 5. Alice and both compute K = f(g ab mod p, R A, R B ), where f is a publicly known function. 10

6. Alice encrypts her identity, a proof of her identity, and her certificate with the key K and transmits the ciphertext to. Alice computes the proof of identity by hashing her identity and the nonces, and then signing the hash with her private key. 7. decrypts the received message and authenticates Alice using the public key P K A. encrypts his identity, proof of identity, and certificate, and transmits the ciphertext to Alice. IKE using shared key: The IKE protocol when Alice and use a shared secret J in aggressive mode is described as follows (Figure 12). Alice Knows shared secret J Knows shared secret J CP, g a mod p, R A, Alice CPA, g b mod p, R B, proof I am, Proof I am Alice Fig. 12. IKE using shared secret keys, aggressive mode. 1. Alice sends a list of proposed cryptographic primitives, including primitives for encryption, hash, authentication, and Diffie-Hellman group. The Diffie-Hellman group consists of a prime p and a generator g. Alice also sends g a mod p, where a is a random number, a random nonce R A, and her identifier. 2. responds with a message accepting the cryptographic primitives. also sends g b mod p, where b is a random number, a random nonce R B, a proof of s identity, and s identifier. The proof of identity contains the same information as in the previous protocol, but is encrypted using the shared secret J. 3. Alice authenticates and transmits her proof of identity. 4. Alice and compute the shared key as K = f(j, g ab mod p, R A, R B ), where f is a publicly known function. 5.2 Communication Using IPsec After Alice and have agreed on a shared session key with the IKE protocol, they can use IPsec to provide encryption and message authentication. These cryptographic protections can be provided either through the Authentication Header (AH, described in IETF RFC 2402) or the Encapsulating Security Payload (ESP, described in IETF RFC 2406). AH provides only message authentication, while ESP provides both encryption and message authentication. We first describe the changes made to the IP headers by IPsec, followed by AH and ESP. IP headers in IPsec: The two widely-used versions of IP are IPv4 and IPv6. IPv4 (RFC 791) was introduced in 1981 and is used to route most Internet traffic. IPv6 (RFC 2460) was released in 1998 as a replacement for IPv4. The main difference between the protocols is that IPv4 uses 32-bit addresses, creating the possible problem of exhausting the space of possible addresses, while IPv6 uses 128-bit addresses. The IPv4 header is shown in Figure 13(a). To use IPsec with IPv4, the Protocol field is set to 50 (for ESP) or 51 (for AH). The IPv6 header is shown in Figure 13(b). To use IPsec with IPv6, the next header field is set to 50 (for ESP) or 51 (for AH). 11

Version (4 bits) Header Length (4 bits) 16-bit identifier Type of Service (8 bits) Flags (3 bits) Datagram Length (16 bits) Fragmentation Offset (13 bits) Version (4 bits) Type of Service (8 bits) Payload length (16 bits) Next Header (8 bits) Flow Label (20 bits) Hops Remaining (8 bits) Hops remaining (TTL) (8 bits) Upper Layer Protocol (8 bits) Header Checksum (16 bits) Source Address (128 bits) 32-bit Source IP Address 32-bit Destination IP Address Destination Address (128 bits) Options (a) (b) Fig. 13. (a) IPv4 header. (b) IPv6 header. Next Header (8 bits) Payload Length(8 bits) Unused (16 bits) Security Parameter Index (32 bits) Sequence Number (32 bits) Authentication Data (Variable) Fig. 14. The Authentication Header (AH). Authentication Header (AH): The AH is shown in Figure 14, and consists of the following fields: Next Header: The next protocol used in the packet (e.g., TCP or UDP). Payload Length: The size of the AH header, not including the first 8 octets. Security Parameter Index (SPI): A field that enables the destination to identify the security association and look up the associated cryptographic key. Sequence Number: A number that increases with each packet that is sent. Used to identify and discard packets that have been replayed. Authentication Data: Cryptographic integrity check on the data packet. Encapsulating Security Payload (ESP): The Encapsulating Security Payload (ESP) provides both encryption and message authentication. ESP is shown in Figure 15, and consists of the following fields: Security Parameter Index (SPI): Same as in the AH. Sequence Number: Same as in the AH. Initialization Vector: The IV required by cryptographic algorithms such as CBC mode encryption. Data: The encrypted data (packet contents). Padding: Optional, can be used to make the data a multiple of block size, or hide the length of the plaintext. Padding Length: Number of octets of padding. 12

Security Parameter Index (32 bits) Sequence Number (32 bits) IV (Initialization vector) (Variable) Data (Variable) Padding (Variable) Padding length (8 bits) Next header/protocol type (8 bits) Authentication Data (Variable) Fig. 15. The Encapsulating Security Payload (ESP). Next Header: Same as the AH. Authentication Data: Same as the AH. The Data, Padding, Padding Length, and Next Header fields are encrypted. 6 Secure Socket Layer (SSL) and Transport Layer Security (TLS) The Secure Socket Layer (SSL) and Transport Layer Security (TLS) are protocols for server authentication, session key establishment, and formation of a secure end-to-end connection between Alice and. They are implemented by web browsers including Internet Explorer, Firefox, Chrome, Safari, and Opera. SSL/TLS is described by RFC 5246. Both protocols begin with handshakes, which establish a session key and agree on cryptographic primitives to be used. The basic SSL/TLS handshake protocol has the following steps, which are illustrated in Figure 16: 1. Alice sends a connection request, a nonce R A, and a list of supported cryptographic primitives to. 2. chooses one of the supported primitives and transmits the chosen primitive, a random nonce R B, and his certificate to Alice. 3. Alice verifies the certificate and chooses a secret S and computes a key K = f(s, R A, R B ), where f is a publicly known function. Alice transmits E P KB (S) to, where P K B is s public key. Alice also transmits a keyed hash (using the key K) of the previous two messages. 4. decrypts E P KB (S) and computes K = f(s, R A, R B ). transmits a keyed hash of the first two messages and a known constant (the known constant is added to ensure that the keyed hashes sent by Alice and do not have the same value). The key generation function f may return two keys, K enc and K auth, that can be used for encryption and authentication, respectively. 6.1 Security Properties of SSL/TLS Handshake The SSL/TLS handshake provides the following security properties: 13

Alice Ciphers I support, R A Certificate, cipher I choose, R B Chooses secret S, Compute K = f(s, R A, R B ) EE PPKKBB (SS), h KK (mm 1, mm 2 h KK (mm 1, mm 2, cccccccccc) Compute K = f(s, R A, R B ) Fig. 16. The SSL/TLS protocol. Session Key Establishment: The key K that is generated by Alice is used as a session key. Since the secret S used to generate K is encrypted using s public key, a third party Eve cannot determine K. Authentication of the Server : The fourth message of the protocol authenticates, since only a user with s private key could obtain the key for the keyed hash. Authentication of Alice is not provided by the basic SSL/TLS protocol. One approach to authenticating Alice is for Alice to encrypt her login and password using the key K and transmit them to. Since a new session key is generated at each execution of SSL/TLS and the session key is unknown to the adversary, this approach enables to authenticate Alice while protecting the password from eavesdroppers. 6.2 The Record Protocol SSL/TLS performs encrypted and authenticated data transfer using the SSL Record Protocol. An SSL record is shown in Figure 17. sends data to Alice using the record protocol as follows: Data Data Fragment 1 MAC 1 Data Fragment 2 MAC 2 Record Header Record E K (Data Fragment 1, MAC 1) E K (Data Fragment 2, MAC 2) Header Fig. 17. The SSL record protocol. 1. breaks the data stream x to be transmitted into fragments x 1,..., x n. While SSL has a maximum fragment size, the actual fragment size can be determined by. 2. computes a MAC on each fragment. The MAC is computed using HMAC as: MAC i = HMAC(K auth, (seq type version length x i )), where K auth is a key for message authentication, seq is a sequence number, type is explained below, version is the version of SSL/TLS, and length is the length of the data fragment. 14

3. For each fragment, computes y i = E Kenc (x i MAC i ) using a block cipher such as AES, where K enc is the key used for encryption. 4. The transmitted record is given by (header y i ). The header contains the record type, SSL protocol version, and the length of the record. The possible record types are alert (used to alert the communicating party to closure of the connection or errors such as decryption failure and certificate expiration), handshake (for initiating a connection or resuming a paused connection), and change cipher spec (for changing which primitives are used for encryption or authentication). Sources for Today s Lecture: 1. Charlie Kaufman, Radia Perlman, and Mike Speciner Network Security: Private Communication in Public World, 2nd Edition. Prentice Hall, 2002, p. 291 301 and 423 438 and 441 476 and 477 501. 15