Mar 4, 2003Mårten Trolin1 This lecture Diffie-Hellman key agreement Authentication Certificates Certificate Authorities

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

Mar 4, 2003Må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

Mar 4, 2003Må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

Mar 4, 2003Må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

Mar 4, 2003Må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

Mar 4, 2003Må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.

Mar 4, 2003Må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 ( –Online banking Each user needs a different shared secret for each server

Mar 4, 2003Må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

Mar 4, 2003Mårten Trolin10 Known public key – problems Complicated key distribution –Each user must know the key of the server it connects to

Mar 4, 2003Må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

Mar 4, 2003Må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

Mar 4, 2003Må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

Mar 4, 2003Må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.

Mar 4, 2003Må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.