This lecture

1
This lecture

• Diffie-Hellman key agreement
• Authentication
• Certificates
• Certificate Authorities
• SSL/TLS

2
Previous lecture

• General differences between asymmetric and
  symmetric cryptography
• General design of interactive protocols
• Key exchange
• Man-in-the-middle

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

4
Diffie-Hellman key agreement
TCP/IP
User
Web server
Decides on a prime p and a number g lt p
Generates a number 0 lt a lt p and computes x ga
mod p
Sends x ( ga mod p)
Generates a number 0 lt b lt p and computes y gb
mod p
Sends y ( gb mod p)
Communication encrypted under k gab mod p
Computes k ya mod p
Computes k xb mod p
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

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

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.

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

9
Known public key

• If the user knows the servers 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 servers
  private key

10
Known public key problems

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

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

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.

Users public key
Identification data
Digital signature by CA
Public information
Users Private key
Private information
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 CAs public key, he can verify
  every certificate that CA has signed

14
Example of use of certificates
TCP/IP
User(pu, su)
Web server(ps, ss)
Users public key pu
k1 encrypted under pu. Public key certificate
containing ps.
Generates k1
Decrypts k1 using su. Generates k2
k2 encrypted under ps.
Decrypts k2 using ss.
Communication encryptedunder k k1 ? k2
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.

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!

17
Key managent getting a certificate
Generates key pair
Public key and request information
Certificate Authority
Server
Private key
Public key
Verifies that the information in the request is
correct
Certificate
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.

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.

20
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
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
TLS
Not secure
Secure
HTTP
HTTP
TLS
TCP
TCP
IP
IP
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