Mar 12, 2002 Mårten Trolin 1

This lecture

• Diffie-Hellman key agreement

• Authentication

• Certificates

• Certificate Authorities

• SSL/TLS

Mar 12, 2002 Mårten Trolin 2

Previous lecture

• General differences between asymmetric and symmetric cryptography

• General design of interactive protocols

• Key exchange

• Man-in-the-middle

Mar 12, 2002 Mårten Trolin 3

Diffie-Hellman

• The first public key type result to be published!

• Performs agreement on a common key without a need for the parties to have public and private keys

Mar 12, 2002 Mårten Trolin 4

Diffie-Hellman key agreement

TCP/IP

User Web server

Sends x ( = ga mod p)

Communication encrypted under k = gab mod p

Generates a number 0 < a < p and computes x = ga mod p

Decides on a prime p and a number g < p

Generates a number 0 < b < p and computes y = gb mod p

Sends y ( = gb mod p)

Computes k = xb mod p

Computes k = ya mod p

Mar 12, 2002 Mårten Trolin 5

Diffie-Hellman key agreement

• The user computes xb = (ga)b mod p

• The server computes ya = (gb)a mod p

• Since (ga)b = gab = gba = (gb)a mod p both parties will use the same key!

• Vulnerable to a man-in-the-middle attack– The man-in-the-middle negotiates one key with the user and one

key with the server

Mar 12, 2002 Mårten Trolin 6

Authentication

• Authentication is the process where the parties convince each other of their identity– Your passpart authenticates you to the border guard

– Producing your signature on a credit card slip authenticates you to the sales-person

• Shared secret (password)

• Known public key

• Public key certificate

Mar 12, 2002 Mårten Trolin 7

Shared secret

• The server has given the user a password on a secure channel (registered mail, in person etc.)

• After negotiating a common symmetric key, the user sends his password to the server.

• The server verifies the password against the password stored in the database

• If the contents match, the user is accepted.

Mar 12, 2002 Mårten Trolin 8

Shared secret – problems

• Vulnerable to the man-in-the-middle attack if server not authenticated– Secure in combinations with other methods

• Suitable only for situations where there are a limited number of users– Webmail services (www.hotmail.com, www.mail.ru,

www.one.lv)

– Online banking

• Each user needs a different shared secret for each server

Mar 12, 2002 Mårten Trolin 9

Known public key

• If the user knows the server’s public key in advance, he can verify its correctness during key agreement

• Protects against man-in-the-middle, since the user would detect that the public key has been replaced

• Protects against fake servers, since the fake server does not know the original server’s private key

Mar 12, 2002 Mårten Trolin 10

Known public key – problems

• Complicated key distribution– Each user must know the key of the server it connects to

Mar 12, 2002 Mårten Trolin 11

Public key certificates

• Known public keys eliminates the man-in-the-middle attack, but leaves the key management complicated

• Public key certificates address this problem

• Public key certificates lets a trusted third party (Certificate Authority, CA) use a digital signature to certify that a public key belongs to a certain entity (person or organization)– Compare with passports

Mar 12, 2002 Mårten Trolin 12

Public key certificates

• A public key certificate consists of– A public key

– Information on the owner

• Name, address, photograph, finger-print, credit card number, etc.

– A signature on the above data by a trusted party

• Trusted party could be the government, a bank, etc.

User’s public key

Identification data

Digital signature by CA

User’s Private key

Public information

Private information

Mar 12, 2002 Mårten Trolin 13

Certificate authorities (CAs)

• Trusted parties that sign certificates

• Trusted because they are known to sign only true information

• Their public keys are widely spread– If a user knows a CA’s public key, he can verify every certificate

that CA has signed

Mar 12, 2002 Mårten Trolin 14

Example of use of certificates

TCP/IPUser(pu, su)

Web server(ps, ss)User’s public key pu

k1 encrypted under pu. Public key certificate containing ps.

Communication encryptedunder k = k1 k2

Decrypts k1 using su. Generates k2

Generates k1

k2 encrypted under ps.Decrypts k2 using ss.

Mar 12, 2002 Mårten Trolin 15

Certificates and man in the middle

• If the user knows the CA public key in advance, he can verify the certificate.

• We are now safe from the man-in-middle• A man-in-the-middle has to replace the original public

key with his own.– The signature in the certificate is no longer valid since the public

key changed!

• The user expects a certificate with certain identifying information. The man-in-the-middle does not possess such a certificate.– User will terminate the transaction.

Mar 12, 2002 Mårten Trolin 16

Key management

• The applicant generates a key pair (public key and private key).

• The public key is sent to the Certificate Authority (CA) together with identifying data.

• The CA verifies the data and signs it with its private key (creating a certificate).

• The signed certificate is sent back to the issuer.

• Note: No secret information is ever transmitted!

Mar 12, 2002 Mårten Trolin 17

Key managent – getting a certificate

Server Certificate Authority

Private key

Public key

Public key and request information

CertificateVerifies that the

information in the request is correct

Generates key pair

Mar 12, 2002 Mårten Trolin 18

Verifying a certificate

• The user needs to know the public key of the CA– Web browser come with certain CA public keys installed.

• To verify the validity of a certificate, the user must– verify the digital signature in the certificate with the CA public

key

– verify that the identifying information is what it should be.

Mar 12, 2002 Mårten Trolin 19

Certificate chains

• Certificates can be chained– Each certificate in the chain is

signed with the private key of the certificate above.

• If the user knows the root certificate, he can verify that each step is valid.

• Using chains, the CA can outsource signing to other organizations it trusts without giving away its private key.

E n d ce rtif ica te

In te rm e d ia te ce rt if ica te

R o o t ce rtf ica te

Mar 12, 2002 Mårten Trolin 20

Certificate chains

E n d u se r 1 E n d u se r 2

S u b ord ina te C A 1

E n d u se r 3 E n d u se r 4

S u b ord ina te C A 2

E n d u se r 5

S u b ord ina te C A 3

R o o t C A

The end user certificates are verified by following the chain up to the root certificate authority (CA)– If every step in the chain is valid, the end user certificate is

considered valid.

Mar 12, 2002 Mårten Trolin 21

SSL/TLS

• SSL (Secure Socket Layer) and TLS (Transport Layer Security) are standards for how to secure TCP/IP communications– As of the latest revision, TLS is the official name for what used

to be called SSL. However, SSL is still the word most frequently used.

• TLS is a layer on top of the TCP layer

Mar 12, 2002 Mårten Trolin 22

TLS

IP

TCP

HTTP TLS

IP

TCP

HTTP

Not secure Secure

Mar 12, 2002 Mårten Trolin 23

TLS

• Uses public keys and certificates for key negotiation– Certificates in X.509 format

• Symmetric cryptography for actual communication– Exact cipher used decided during hand-shake.

• TLS standard defines certain commands that can be used in communication