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
Top Related