EE 418 Network Security and Cryptography Lecture #18 Outline
Total Page:16
File Type:pdf, Size:1020Kb
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 first 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. (Diffie-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 identifiers 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 IDAjjIDBjjrA. 3. The KDC generates a shared key KAB and a ticket tB = EKB (KABjjIDB). The KDC sends EKA (rAjjIDBjjKABjjtB) 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 IDAjjtB 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 verifies 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 IDAjjtB 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 IDAjjIDBjjrA to the KDC. 2. The KDC computes tB = EKB (KABjjIDAjjL), where L is the lifetime of the secret key KAB. The KDC transmits y1 = EKA (rAjjIDBjjKABjjL) and tB to Alice. 3. Alice decrypts y1 and obtains KAB. Alice computes y2 = EKAB (IDAjjtime), where time is Alice's current system time. Alice transmits y2jjtB 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 Certificate 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 certificate 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 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 in- formation, printing, etc. { Privacy: Issuance of anonymous or pseudonymous certificates 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 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.