EE 418 Network Security and Cryptography Lecture #18 Outline

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 Bob rely on symmetric-key cryptography, they have to share the same secret encryption- decryption key. How to they established that shared secret key over an insecure communication channel? 2. On the other hand, if Alice and Bob 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 ﬁrst problem, related to symmetric-key cryptography, and we showed that there are two possible approaches that Alice and Bob can take: (a) Alice and Bob can use public key cryptography to establish a shared secret key that they can then use to communicate securely using symmetric-key cryptography. (Diﬃe-Hellman protocol) (b) Alice and Bob 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 Bob 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 KA. Similarly, Bob is assumed to share a key KB with the KDC. Alice and Bob both have unique identiﬁers IDA and IDB that are known to each other and the KDC. 2. Alice contacts the KDC and requests a shared key to communicate with Bob by generating a random nonce rA and sending a message IDA||IDB||rA.

3. The KDC generates a shared key KAB and a ticket tB = EKB (KAB||IDB). The KDC sends EKA (rA||IDB||KAB||tB) to Alice. 4. Alice decrypts the message sent by the KDC and extracts tB and KAB. Alice checks to make sure that the decrypted rA sent by the KDC matches the rA sent by Alice. Alice then transmits IDA||tB to Bob. 5. Bob decrypts tB using KB and extracts KAB. Bob generates a random number rB and transmits

EKAB (rB) to Alice.

6. Alice decrypts Bob’s transmitted message using KAB. Alice computes EKAB (rB − 1) and transmits this message to Bob. By decrypting the message using KAB, Bob veriﬁes that Alice knows the key KAB.

1 KDC Alice Bob

|| || Chooses rA Generates 𝐼𝐼𝐷𝐷𝐴𝐴 𝐼𝐼𝐷𝐷𝐵𝐵 𝑟𝑟𝐴𝐴 Computes 𝐾𝐾𝐴𝐴𝐴𝐴 = ( || ( || 𝐵𝐵 𝑡𝑡𝐵𝐵𝑜𝑜𝑜𝑜 𝑒𝑒𝐾𝐾 𝐾𝐾𝐴𝐴𝐴𝐴 𝐼𝐼𝐷𝐷𝐴𝐴� Extracts KAB , 𝐾𝐾𝐴𝐴 𝐴𝐴 𝐵𝐵 𝐾𝐾𝐴𝐴𝐴𝐴 𝐵𝐵𝐵𝐵𝐵𝐵 𝑒𝑒 𝑟𝑟 𝐼𝐼𝐷𝐷 𝑡𝑡 � tBob using KA Extracts K using K 𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵 AB A ( Chooses rB

𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 𝑟𝑟𝐵𝐵� ( 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, Bob, and the KDC, including the ticket tB. 2. The attacker obtains a key KAB generated during a previous execution of the N-S protocol. 3. The attacker contacts Bob, pretending to be Alice, and transmits IDA||tB to Bob. 4. Bob decrypts tB using KB and extracts the key KAB, which is known to the adversary. Bob generates

a random number rB and transmits EKAB (rB) to Alice. 5. Since the attacker knows KAB, (s)he decrypts Bob’s transmitted message using KAB. The attacker

transmits EKAB (rB − 1) to Bob.

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 rA and sends IDA||IDB||rA to the KDC.

2. The KDC computes tB = EKB (KAB||IDA||L), where L is the lifetime of the secret key KAB. The KDC

transmits y1 = EKA (rA||IDB||KAB||L) and tB to Alice.

3. Alice decrypts y1 and obtains KAB. Alice computes y2 = EKAB (IDA||time), where time is Alice’s current system time. Alice transmits y2||tB to Bob. 4. Bob decrypts tB and obtains KAB. If time > L, then the key has expired and Bob discards the key. Bob

replies to Alice with EKAB (time + 1).

2 Eve records

Eve Bob Obtains old key K AB recorded

( 𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵

𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 𝑟𝑟𝐵𝐵′� ( 1 ′ 𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 𝑟𝑟𝐵𝐵 − �

Fig. 2. The replay attack on Needham-Schroeder.

KDC Alice Bob || || Chooses r Generates , A 𝐴𝐴 𝐵𝐵 𝐴𝐴 chooses lifetime L 𝐼𝐼𝐷𝐷 𝐼𝐼𝐷𝐷 𝑟𝑟 𝐴𝐴𝐴𝐴 Computes 𝐾𝐾 = ( || || = ( || || || 𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵 𝑒𝑒𝐾𝐾𝐵𝐵 𝐾𝐾𝐴𝐴𝐴𝐴 𝐼𝐼𝐷𝐷𝐴𝐴 𝐿𝐿� 𝑦𝑦1 𝑒𝑒𝐾𝐾𝐴𝐴 𝑟𝑟𝐴𝐴 𝐼𝐼𝐷𝐷𝐵𝐵 𝐾𝐾𝐴𝐴𝐴𝐴 𝐿𝐿� || Computes 𝐵𝐵𝐵𝐵𝐵𝐵 1 𝑡𝑡 𝑦𝑦 = ( || ) || 𝑦𝑦2 𝐾𝐾𝐴𝐴𝐴𝐴 𝐼𝐼𝐷𝐷𝐴𝐴 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵 𝑦𝑦2 Extracts time ( + 1

𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 �

Fig. 3. The Kerberos protocol.

3 Review: Public Key Infrastructure

On Thursday, we started from an observation that, when Alice and Bob communicate using public key cryptography, both users’ public keys should be managed to ensure that Alice has Bob’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 Bob 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 Certiﬁcate Authorities (CAs), which are trusted third-parties used to verify public keys. Alice can verify Bob’s public key with the help of a CA through the following procedure, depicted in Figure 4:

1. Alice sends a request to Bob for Bob’s public key. 2. Bob sends a certiﬁcate C, which contains Bob’s public key PKB, Bob’s identity, and possibly other information including the expiration time of the key (see Section 3.1). Attached to C is a signature

σ = SigPKCA (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 PKB as Bob’s public key.

Certificate Alice Bob Authority

Bob, PKBob Verifies PKBob belong to Bob Stores SigCA(PKBob)

Alice SigCA(PKBob) Bob

PK , Sig (PK ) Verifies Bob CA Bob

PKBob (

𝐸𝐸𝑃𝑃𝐾𝐾𝐵𝐵𝐵𝐵𝐵𝐵 𝑚𝑚�

Fig. 4. Verifying Bob’s public key using a certiﬁcate authority (CA).

Thus, we can think of PKI as a secure system that generates, manages, and updates certiﬁcates 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 certiﬁcates for purpose of access control and preser- vation of anonymity. For example, when one has access to a service if it belongs ot a group, but the unique member is not identiﬁed.

3.1 X.509 Certiﬁcates

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 Certiﬁcate Authorities

There are many CAs operating in different countries and under different ownership. Examples include Syman- tec and GoDaddy, along with smaller CAs run by enterprises and individuals. The PKI must have a mech- anism 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 Bob try to verify each other’s identities. Typically, Alice authenticates herself to Bob by proving that she has knowledge of a shared secret, such as a cryptographic key KAB. One method for Alice and Bob 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 Bob. Bob responds by sending a random nonce (a random number that is only used once), denoted RB, to Alice.

2. Alice responds to Bob’s challenge with EKAB (RB). Alice then transmits a nonce RA.

3. Bob veriﬁes that the received message Y = EKAB (RB). If it does, then Bob responds to Alice’s challenge

with EKAB (RA).

4. If the value of EKAB (RA) is correct, Alice authenticates Bob.

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/[email protected]

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/[email protected]

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 certiﬁcate.

A more diﬃcult scenario arises when Alice and Bob do not share a cryptographic key K, but instead share a password pwd. This occurs when Alice is a client (user) and Bob is a server. In this case, if Alice and Bob 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 Bob’s challenge RB and Alice’s response EK (RB). 2. Eve takes a list of possible passwords pwd1, . . . , pwdn. For each password, Eve computes Ki = f(pwdi)

and EKi (RB). If EKi (RB) = EK (RB), then Eve has found the correct password. The dictionary attack is eﬀective because users typically choose passwords that are much easier to guess than cryptographic keys. If Alice and Bob 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 Bob share a password pwd and can compute W = f(pwd), where f is a publicly known function. Bellovin-Merritt also assumes that Alice and Bob have knowledge of a prime p and generator g, as in the Diﬃe-Hellman key exchange. The protocol achieves mutual authentication of Alice and Bob, and enables Alice and Bob to generate a stronger key K for further communication. The protocol consists of the following steps:

a 1. Alice generates a random a. Alice transmits her identity to Bob, along with EW (g mod p). a 2. Bob decrypts Alice’s message and obtains g mod p. Bob generates a random number b and a nonce C1, and computes K = gab mod p.

6 RA 2 is approved. Its public key is Root 47383AE349… Root’s signature

CA 4 is approved. RA 1 RA 2 Its public key is 542EA34149… RA 2’s signature

CA 1 CA 2 CA 3 CA 4

Fig. 6. A hierarchial PKI.

Alice Bob

Knows K Knows KAB AB I am Alice

I am Bob, RB

(

𝐸𝐸𝐾𝐾𝐴𝐴𝐴𝐴 𝑅𝑅𝐵𝐵�

(

𝐸𝐸𝐾𝐾𝐴𝐴𝐴𝐴 𝑅𝑅𝐴𝐴�

Fig. 7. Basic mutual authentication protocol.

b 3. Bob transmits EW (g mod p, C1) to Alice. b ab 4. Alice decrypts Bob’s message and obtains g mod p and C1. Alice computes K = g mod p and generates a nonce C2 5. Alice transmits EK (C1,C2) to Bob. 6. Bob decrypts Alice’s message and veriﬁes that the ﬁrst half of the message is C1. Bob computes EK (C2) 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 Bob’s first message, obtain gb mod p, and compute K. Bob authenticates Alice by checking that Alice encrypted his challenge C1 using the correct key K. – Authentication of Bob: Similarly, only a valid Bob could correctly compute K and EK (C2). – Security against Dictionary Attack: The only messages encrypted with W are ga mod p and gb mod p. In order for an adversary to check a possible password pwd0, the adversary would need to decrypt both messages using key W 0 = f(pwd0). 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 Bob without knowledge of W = f(pwd). The goal of augmented EKE is to ensure that a server Bob 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, Bob stores a prime p and 2W mod p. The augmented strong password protocol is shown in Figure 8, and consists of the following steps:

Alice Bob Choose a, compute W and Stores “Alice”, p, 2W mod p p from password

2a mod p

Chooses b 2b mod p, h(2ab mod p, 2bW mod p)

h’(2ab mod p, 2bW mod p)

Fig. 8. Augmented strong password protocol.

1. Alice generates a uniformly at random and transmits 2a mod p to Bob. 2. Bob generates b uniformly at random, and transmits 2b mod p and h((2ab mod p)||(2bW mod p)), where h is a hash function. 3. Alice computes 2ab mod p and h((2ab mod p)||(2bW mod p)). If the hash value matches the value transmitted by Bob, then Alice authenticates Bob and transmits h0((2ab mod p)||(2bW mod p)). Here h0 is a hash function that is diﬀerent 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 2bW mod p in the third message. – Authentication of Bob: Bob must know 2W mod p and b in order to compute 2bW 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 2W mod p, then the attacker must still solve an instance of the Discrete Logarithm Problem to ﬁnd 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, Bob stores gW 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 ga mod p to Bob. b W 2. Bob generates b, a challenge C1, and a 32-bit number u. Bob transmits (g + g ) mod p, u, and C1 to Alice. 3. Bob computes K = (ga)b(gW )bu = gb(a+uW ) mod p. 4. Alice receives Bob’s message and extracts gb mod p by subtracting gW mod p from the ﬁrst part of the b a b uW b(a+uW ) message. Alice computes K = (g ) (g ) = g mod p. Alice transmits EK (C1) and C2 to Bob. 5. Bob authenticates Alice based on her challenge and transmits EK (C2) 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 (gb)uW mod p (knowledge of gW 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 Bob’s challenge. – Authentication of Bob: The value of gW mod p must be known to compute (gW )bu, and hence to compute the correct value of the key. – Security against Dictionary Attack: In order to verify a guess of a password pwd0, 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 gW 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 conﬁdentiality, 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 Bob, and Bob 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 ﬁrst describe how IPsec creates a shared key between Alice and Bob 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 Bob are created. Phase 1 IKE has two modes of operation. Aggressive mode involves Alice and Bob exchanging three messages, while main mode consists of three modes. The phase 1 protocol also changes based on whether Alice and Bob 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: B Source: B Flow: X Source: A Dest: E Dest: E Source: A Dest: F Flow: X Flow: X Dest: F Data Source: A Source: A Dest: F 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 Bob use digital signatures is described as follows (Figure 11). The protocol assumes that Alice and Bob know each other’s signature keys PKA and PKB, respectively.

Alice Bob Crypto Proposal

Crypto Proposal Accepted

a g mod p, RA

b g mod p, RB Compute Compute ab ab K = f(g mod p, RA, RB) K = f(g mod p, RA, RB)

EK(“Alice”, proof I am Alice, [certificate])

EK(“Bob”, proof I am Bob, [certificate])

Fig. 11. IKE using public signature keys, main mode.

1. Alice sends Bob a list of proposed cryptographic primitives, including primitives for encryption, hash, authentication, and Diﬃe-Hellman group. The Diﬃe-Hellman group consists of a prime p and a generator g. 2. Bob replies to Alice with a message accepting the cryptographic primitives. a 3. Alice generates a random number a and a nonce RA, and transmits g mod p and RA to Bob. b 4. Bob generates a random number b and a nonce RB, and transmits g mod p and RB to Alice. ab 5. Alice and Bob both compute K = f(g mod p, RA,RB), where f is a publicly known function.

10 6. Alice encrypts her identity, a proof of her identity, and her certiﬁcate with the key K and transmits the ciphertext to Bob. Alice computes the proof of identity by hashing her identity and the nonces, and then signing the hash with her private key. 7. Bob decrypts the received message and authenticates Alice using the public key PKA. Bob encrypts his identity, proof of identity, and certiﬁcate, and transmits the ciphertext to Alice.

IKE using shared key: The IKE protocol when Alice and Bob use a shared secret J in aggressive mode is described as follows (Figure 12).

Alice Bob

Knows shared secret J Knows shared secret J

a C P, g mod p, RA, “Alice”

b CPA, g mod p, RB, proof I am Bob, “Bob”

Proof I am Alice

Fig. 12. IKE using shared secret keys, aggressive mode.

1. Alice sends Bob 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 a g. Alice also sends g mod p, where a is a random number, a random nonce RA, and her identifier. 2. Bob responds with a message accepting the cryptographic primitives. Bob also sends gb mod p, where b is a random number, a random nonce RB, a proof of Bob’s identity, and Bob’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 Bob and transmits her proof of identity. ab 4. Alice and Bob compute the shared key as K = f(J, g mod p, RA,RB), where f is a publicly known function.

5.2 Communication Using IPsec

After Alice and Bob 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 ﬁrst 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 Type of Service Flow Label Version Header Type of (4 bits) (8 bits) (20 bits) Length Service Datagram Length (16 bits) Next Header Hops Remaining (4 bits) (4 bits) (8 bits) Payload length (16 bits) (8 bits) (8 bits) Flags 16-bit identifier Fragmentation Offset (13 bits) (3 bits)

Hops remaining Upper Layer Source Address (128 bits) Header Checksum (16 bits) (TTL) (8 bits) Protocol (8 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 ﬁelds:

– 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 ﬁrst 8 octets. – Security Parameter Index (SPI): A ﬁeld 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 ﬁelds:

– 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 ﬁelds 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 Bob. 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 RA, and a list of supported cryptographic primitives to Bob. 2. Bob chooses one of the supported primitives and transmits the chosen primitive, a random nonce RB, and his certificate to Alice. 3. Alice verifies the certificate and chooses a secret S and computes a key K = f(S, RA,RB), where f is a

publicly known function. Alice transmits EPKB (S) to Bob, where PKB is Bob’s public key. Alice also transmits a keyed hash (using the key K) of the previous two messages.

4. Bob decrypts EPKB (S) and computes K = f(S, RA,RB). Bob transmits a keyed hash of the ﬁrst two messages and a known constant (the known constant is added to ensure that the keyed hashes sent by Alice and Bob do not have the same value).

The key generation function f may return two keys, Kenc and Kauth, 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 Bob

Ciphers I support, RA

Certificate, cipher I choose, RB

Chooses secret S, Compute

K = f(S, RA, RB) ( ), ( ,

𝐵𝐵 𝐸𝐸𝑃𝑃𝐾𝐾 𝑆𝑆 ℎ𝐾𝐾 𝑚𝑚1 𝑚𝑚2� Compute

K = f(S, RA, RB) ( , , )

ℎ𝐾𝐾 𝑚𝑚1 𝑚𝑚2 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐

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 Bob’s public key, a third party Eve cannot determine K. – Authentication of the Server Bob: The fourth message of the protocol authenticates Bob, since only a user with Bob’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 Bob. 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 Bob 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. Bob sends data to Alice using the record protocol as follows:

Data

Data Fragment 1 MAC 1 Data Fragment 2 MAC 2

Record Record E (Data Fragment 1, MAC 1) E (Data Fragment 2, MAC 2) Header K Header K

Fig. 17. The SSL record protocol.

1. Bob breaks the data stream x to be transmitted into fragments x1, . . . , xn. While SSL has a maximum fragment size, the actual fragment size can be determined by Bob. 2. Bob computes a MAC on each fragment. The MAC is computed using HMAC as:

MACi = HMAC(Kauth, (seq||type||version||length||xi)),

where Kauth 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, Bob computes yi = EKenc (xi||MACi) using a block cipher such as AES, where Kenc is the key used for encryption. 4. The transmitted record is given by (header||yi). 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 certiﬁcate 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.