Topics: Digital Certificates (X.509, …), SSL/TLS (Secure Socket Layer / Transport Layer Security), HTTPS, Diffie-Hellman (DH), etc.

A. Man-in-the-Middle (MitM) Attacks against network communications

- Passive vs Active MitM attacks

Q: If Bob sends a request to Alice to get Alice’s public key, how would MitM attack work against this situation (i.e., public key sharing)?

· Attacks against public key sharing: the Man-in-the-Middle attack against public key sharing

How?

A scenario: A user A wants user B’s public key, so sends a request to B. B responds with his (B’s) public key.

Pre-requisites of MitM attack? The DNS services of the victims (in this scenario A and B) have been poisoned/altered by the hacker. That is, when A tries to find B’s IP address (using the DNS service), what’s returned is H’s IP address.

When B responds, the hacker do the same (as shown below):

Why (i.e., the impact)? Next time, when A needs B’s public key, it is H’s public key that will be returned to A.

- Case one - Confidentiality: When A use “B’s public key” to encrypt some data and then sends the ciphertext to B, the hacker H actually can decrypt the ciphertext. à a breach of confidentiality provided by public key encryption

Furthermore, once having decrypted the ciphertext, H can not only view it but also modify the data and then re-encrypts the modified data using B’s public key, and then sends the ciphertext to B.

- Case two – validating a digital signature: When A has received a document and signature from B (although in fact that message was sent by H, as shown below), A will retrieves “B’s public key” from the memory and use that key to validate the received document and signature. à The benefits that are supposedly provided by DS (that is, data integrity, signer origin integrity, and signer non-repudiability) are not provided in this case.

The lessons?

Do not share a public key by directly sending it over the network because it is subject to MitM attacks against public key sharing.

Instead, use a secure mechanism when sharing your public keys (like Digital Certificates).

B. X.509 digital certificates

- X.509 is the Public key Infrastructure (or PKI) certificate system

- Two primary reasons of using digital certificates:

o A certificate is a secure mechanism of sharing a public key.

o A certificate is often used to authenticate the owner/subject of that certificate.

For example, in HTTPS (HTTP over SSL), the e-commerce server has a server certificate, which is used by the customer’s browser to authenticate that server.

§ SSL/TLS (Secure Socket Layer/Transport Layer Security) is based on X.509 certificates.

The chain of dependency: HTTPS à SSL/TLS à X.509 certificates à Digital Signatures à hashing & public key crypto.

NOTE: a à b mean a ‘is dependent on’ b.

-

- There are two types of Certification Authorities (or CAs): Root CAs and Intermediate CAs.

o A root CA’s certificate is self-signed, meaning the CA certified itself.

o An intermediate CA’s certificate is signed/certified by another CA, which could be a root CA or an intermediate CA.

o A certificate chain is a chain of certificates showing the CA/subject relationships through the chain.

- A certificate created and used within an organization is not recognizable by the outside entities (for example, potential customers or business partners).

- To have a certificate that can be validated by any entities, we must purchase a certificate from a well-known CA.

- A common of X.509 certificates is that it is used in HTTP over SSL (or HTTPS) such that a potential customer can request the e-commerce company to send the company’s certificate and then use that company’s certificate to authenticate that company’s server.

A scenario: Suppose A’s certificate was issued by CA1, which is a root CA.

- The subject/owner/”issued-to” is A.

- CA1 is the CA/issuer/”issued-by”.

Q1: How is a certificate constructed?

A certificate contains two packets, the public key packet and the signature packet.

A’s certificate = A’s public key packet (subject=”A’s name”, subject’s public key=A’s public key, issuer= “CA1”, valid from t1 to t2, hashing algorithm= “SHA2”, signing algorithm=”RSA”, …)

+ A’s signature packet (= Encrypt hashing(A’s public key packet) using CA1’s private key)

+ CA1’s certificate

Q1A: How would another entity, say B, validate A’s certificate?

Ans: The validator must have CA1’s public key (in order to validate A’s signature packet.

Q1B: How would the validator obtain CA1’s public key?

Ans: Most (if not all) of the well-known CAs’ certificates are available in a networked computer; those certificates were installed in the compute during the system setup process.

Q2: How is a certificate validated?

Ans: The validator must have the CA’s public key, which could be retrieved from that CA’s certificate pre-installed in the validator’s computer.

Example: Suppose entity X has requested and received A’s certificate (from A). Show how would X authenticate A by validating A’s certificate.

- The validator: X

- The subject: A

- A’s CA: CA1

A’s certificate = A’s public key packet (subject=”A’s name”, subject’s public key=A’s public key, issuer= “CA1”, valid from t1 to t2, hashing algorithm= “SHA2”, signing algorithm=”RSA”, …)

+ A’s signature packet (= Encrypt hashing(A’s public key packet) using CA1’s private key)

+ CA1’s certificate

1. Has this certificate expired? If yes, abort; else, continue.

2. Who is the issuer of this certificate? CA1

3. Do I have this issuer’s certificate pre-installed in my certificate store? Yes (if the answer is NO, some extra processing is required)

4. Extract the issuer’s public key from its certificate. à CA1’s public key

5. Use CA1’s public key to validate A’s signature packet.

a. Decrypt A’s signature packet using CA1’s public key à hash1

b. Hashing(A’s public key packet) à hash2

c. Compare hash1 and hash2.

d. If not equal, abort;

Else,

(i) The source data is correct. That is, all information in A’s public key packet are correct.

(ii) The creator information is correct. That is, A’s signature packet was indeed signed by CA1 out of A’s public key packet.

(iii) Signer non-repudiability. CA1 cannot deny being the issuer of A’s certificate.

6. X then needs to compare the subject name inside the public key packet with what X already knows about the other end of the communication (as shown as the destination of message 3 below).

NOTE: A certificate is public. A hacker may obtain a copy of a certificate that belongs to another entity and then tries to impersonate that entity by sending that entity’s certificate to others (as shown in the above diagram).

In conclusion, if you receive a message from someone who claims to be A and that message is attached with a valid copy of A’s certificate, it is not sufficient to trust that the sender was really A.

C. HTTP over SSL/TLS (HTTPS)

Q: How are X.509 certificates used in HTTPS? For what?

HTTPS (HTTP over SSL/TLS) is the dominant web security protocol; it is used to secure HTTP traffic exchanged between an HTTP client (i.e., the web browser) and the HTTP server (i.e., the web server).

SSL/TLS are a suite of security protocols based on the X.509 Certificates protocol. X.509 is used for authentication in SSL/TLS.

The dependency relationship between these protocols? HTTPS à HTTP + SSL/TLS à X.509 à Digital Signatures à Public Key Crypto. + Hashing

In HTTPS, the server’s X.509 certificate is used by the browser to authenticate that server. (case A: B2C, Business-to-Customer, authentication)

Message 3 in the above diagram represents the HTTPS certificate request message.

Message 4 represents the response from the server in HTTPS.

E’s certificate = E’s public key packet (subject=”E”, issuer=”CA”, the subject’s public key = E’s public key, …)

+ A’s signature packet (= Encrypt hashing(E’s public key packet) using CA’s private key)

+ CA’s certificate

Q: How would the customer, C, authenticate the e-commerce server, E, using the received certificate in step 4?

Pre-requisites? C must have CA’s public key. (NOTE: CA’s certificate was pre-installed in E.)

1. C (in fact, C’s browser) will check whether the certificate has expired or not. If it is expired, abort (or generate a warning for the user to decide whether to proceed or not).

2. The browser will check the public key packet to find out who’s the issuer of this certificate. à “CA”

3. The browser then tries to find in its local certificate store that issuer’s certificate. à CA’s certificate

4. From the retrieved issuer’s certificate, the browser will extract the issuer’s public key. à CA’s public key

5. The browser then uses the issuer’s public key to validate the signature packet in E’s certificate. If not valid, abort. //Meaning that the certificate does not belong to E.

6. The browser compares the subject’s name (i.e., “E”) with the name of the receiver of message 3 (i.e., “E”) to ensure they match each other. If they do not match, abort. //Meaning that someone has stolen E’s certificate and tried to impersonate E (as in spam mails + rogue server attack).

NOTE 1: In B2C applications, the authentication based on X.509 is typically one-way authentication (that is, the business server is authenticated by the customer using the business server’s X.509 certificate).

NOTE 2: In B2B (Business-to-Business) applications, for example online automatic ordering by business A’s server placing the order on business B’s server, the authentication between the two servers are typically mutual. That is, A will ask B to present B’s certificate (in order for A to authenticate B), and B will do the same to authenticate A.

Q: How would a software vendor earn a potential customer’s trust such that the customer will be willing to install and try the software out?

Hint: The message mX in the diagram below needs to be revised such that ‘origin integrity’ is provided.

Your solution?

D. Diffie-Hellman (DH) key exchange and the 2-Phase “secure” network communications

Qa: What is the 2-phase network communications?

Phase one: Handshake

1.1: authentication using authentication methods (e.g., X.509, digital signatures, or MAC)

1.2: key exchange (to produce one or more session keys)

Phase two: secure sessions via session keys

Qb: How does the Diffie-Hellman algorithm work?

Qc: What is the role of key exchange in the 2-phase “secure” network communications?