1. Mar 12, 2002Mårten Trolin1 This lecture Diffie-Hellman key agreement Authentication Certificates Certificate Authorities SSL/TLS

2. Mar 12, 2002Mårten Trolin2 Previous lecture General differences between asymmetric and symmetric cryptography General design of interactive protocols Key exchange Man-in-the-middle

3. Mar 12, 2002Mårten Trolin3 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

4. Mar 12, 2002Mårten Trolin4 Diffie-Hellman key agreement TCP/IP User Web server Sends x ( = g a mod p) Communication encrypted under k = g ab mod p Generates a number 0 < a < p and computes x = g a mod p Decides on a prime p and a number g < p Generates a number 0 < b < p and computes y = g b mod p Sends y ( = g b mod p) Computes k = x b mod p Computes k = y a mod p

5. Mar 12, 2002Mårten Trolin5 Diffie-Hellman key agreement The user computes x b = (g a ) b mod p The server computes y a = (g b ) a mod p Since (g a ) b = g ab = g ba = (g b ) 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

6. Mar 12, 2002Mårten Trolin6 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

7. Mar 12, 2002Mårten Trolin7 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.

8. Mar 12, 2002Mårten Trolin8 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

9. Mar 12, 2002Mårten Trolin9 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

10. Mar 12, 2002Mårten Trolin10 Known public key – problems Complicated key distribution –Each user must know the key of the server it connects to

11. Mar 12, 2002Mårten Trolin11 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

12. Mar 12, 2002Mårten Trolin12 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

13. Mar 12, 2002Mårten Trolin13 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

14. Mar 12, 2002Mårten Trolin14 Example of use of certificates TCP/IP User (p u, s u ) Web server (p s, s s ) User’s public key p u k 1 encrypted under p u. Public key certificate containing p s. Communication encrypted under k = k 1  k 2 Decrypts k 1 using s u. Generates k 2 Generates k 1 k 2 encrypted under p s. Decrypts k 2 using s s.

15. Mar 12, 2002Mårten Trolin15 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.

16. Mar 12, 2002Mårten Trolin16 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!

17. Mar 12, 2002Mårten Trolin17 Key managent – getting a certificate Server Certificate Authority Private key Public key Public key and request information Certificate Verifies that the information in the request is correct Generates key pair

18. Mar 12, 2002Mårten Trolin18 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.

19. Mar 12, 2002Mårten Trolin19 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.

20. Mar 12, 2002Mårten Trolin20 Certificate chains 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.

21. Mar 12, 2002Mårten Trolin21 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

22. Mar 12, 2002Mårten Trolin22 TLS IP TCP HTTPTLS IP TCP HTTP Not secureSecure

23. Mar 12, 2002Mårten Trolin23 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