1. Apr 2, 2002Mårten Trolin1 Previous lecture On the assignment Certificates and key management –Obtaining a certificate –Verifying a certificate –Certificate chains SSL/TLS –Layer between TCP and application protocol –Phases –Messages

2. Apr 2, 2002Mårten Trolin2 This lecture TLS details –Phases Handshake Securing messages –What the messages contain –Authentication The second assignment

3. Apr 2, 2002Mårten Trolin3 TLS phases Handshake –Establish connection –Agree on encryption algorithm –Exchange key –Authentication Server only or both client and server Authentication with certificates Securing messages –Sending the actual messages –Integrity checks with MACs

4. Apr 2, 2002Mårten Trolin4 TLS Handshake Client Server ClientHello ServerHello ServerKeyExchange ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ServerHelloDone ClientHello Certificate

5. Apr 2, 2002Mårten Trolin5 ClientHello The client initiates the communication by sending the ClientHello message. The message contains –version number –optional session ID used to resume a previous session –list of cipher suites supported The cipher suite includes key exchange algorithm, symmetric algorithm (including chaining mode) and MAC algorithm.

6. Apr 2, 2002Mårten Trolin6 Certificate TLS Handshake Client Server ClientHello ServerHello ServerKeyExchange ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ServerHelloDone ServerHello ServerKeyExchange ServerHelloDone Certificate

7. Apr 2, 2002Mårten Trolin7 ServerHello In response to the ClientHello message, the server sends a ServerHello message. In this message, the server finally decides which cipher suite to use. The ServerHello message contains –version number –optional session ID included if the server allows the client to resume a previous session –the cipher suite to be used, picked from the list of proposals given by the client

8. Apr 2, 2002Mårten Trolin8 Certificate The Certificate message contains the server certificate, including the chain leading up to the CA root certificate. –Optional according to the TLS specifications, but most (all?) implementations require a server certificate. –If no certificate is sent, the ServerKeyExchange is required.

9. Apr 2, 2002Mårten Trolin9 ServerKeyExchange The ServerKeyExchange message is used for the key exchange. –Includes the server part of the key exchange. –Exact meaning depends on the cipher suite chosen. For RSA, the server’s public key is sent. For Diffie-Hellman, the modulus p, the generator g and x = g a is sent. –Necessary if no public key is sent in the certificate. If the information in the certificate can be used for signing, the key information is signed.

10. Apr 2, 2002Mårten Trolin10 ServerHelloDone The ServerHelloDone marks the end of the server’s part in the handshake. It does not contain any other information.

11. Apr 2, 2002Mårten Trolin11 TLS Handshake Client Server ClientHello ServerHello ServerKeyExchange ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ServerHelloDone ClientKeyExchange Finished ChangeCipherSpec Certificate

12. Apr 2, 2002Mårten Trolin12 ClientKeyExchange The ClientKeyExchange message contains the client part in the key agreement. The exact format depends on the exchange algorithm agreed on previously –For RSA, the client generates random numbers from which the symmetric key is derived. –For Diffie-Hellman, the message contains y = g b, the client’s part in the agreement. From this the symmetric key is extracted.

13. Apr 2, 2002Mårten Trolin13 ChangeCipherSpec and Finished Formally a protocol of its own, the ChangeCipherSpec message indicates that from this point, communication is encrypted. The Finished message, itself encrypted, marks the end of the handshake. It consists of a hash of the handshake encrypted with the agreed cipher suite.

14. Apr 2, 2002Mårten Trolin14 TLS Handshake Client Server ClientHello ServerHello ServerKeyExchange ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ServerHelloDone ChangeCipherSpec Finished Certificate

15. Apr 2, 2002Mårten Trolin15 ChangeCipherSpec and Finished The server’s ChangeCipherSpec and Finished messages play the same role as the client’s message.

16. Apr 2, 2002Mårten Trolin16 Introducing client authentication The TLS specifications allows for client authentication. The client authenticates himself with a certificate, just as the server. Whether or not client authentication should be used (and what to if it is unsuccessful) is determined by the server.

17. Apr 2, 2002Mårten Trolin17 TLS Handshake with client authentication ClientServer ClientHello ServerHello ServerKeyExchange ClientKeyExchange ChangeCipherSpec Finished ServerHelloDone Certificate CertificateRequest CertificateVerify Certificate Finished

18. Apr 2, 2002Mårten Trolin18 CertificateRequest If the server wants the client to provide a certificate, the server sends a CertificateRequest message in the handshake. The CertificateRequest contains information on which certificates the server accepts. –Types of certificates. –CA certificates known to the server. –Using this information, an interactive program can show a list of accepted certificates for the user to choose from.

19. Apr 2, 2002Mårten Trolin19 Certificate In response, the client sends his certificate to the server. This message has the same format as the corresponding message from the server. –The client certificate, and all certificates in the chain leading up to the root certificate.

20. Apr 2, 2002Mårten Trolin20 CertificateVerify Unless the client can prove that he knows the private key, the certificate is useless. The CertificateVerify message gives this proof. CertificateVerify contains a signature with the client private key on the complete handshake. –The server can verify this signature with the public key in the certificate. –If this verification is successful, the server knows that the client knows the private key.

21. Apr 2, 2002Mårten Trolin21 Verifying the certificate All certificates in TLS are in the X.509 format. To verify that a certificate is valid, the verifier must –Check that the CA signature is valid. –Check that the owner of the certificate knows the private key. –Check that the identifying information is what it should be. The protocol specifies how to perform the first two parts, but the last part is up to the implementation.

22. Apr 2, 2002Mårten Trolin22 Verifying the certificate The certificates used in TLS, X.509 certificates, define certain fields. –Algorithm identifier –Issuer –Period of validity –Subject –Subject’s public key –Extensions –Signature by issuer’s private key The field named Subject contains information about the owner.

23. Apr 2, 2002Mårten Trolin23 Verifying the certificate – the subject field The subject field takes the form of a distinguished name and consists of several elements. –Country –Province –Organization –Common Name –etc. For server certificates, the Common Name field contains the host name of the server, e.g., www.verisign.com.

24. Apr 2, 2002Mårten Trolin24 Certificate contents This picture shows how Internet Explorer shows the contents of a certificate. Note that the CN field contains the host name of the server.

25. Apr 2, 2002Mårten Trolin25 The subject field, cont. The Common Name usually identifies the owner. For server certificates for web servers, the web browser checks that the host name the user sees in the address/location field matches the Common Name. For client certificates, each implementation must decide a scheme for how to use the identifying information. –Personal number –User name –Real name (risk for collisions)

26. Apr 2, 2002Mårten Trolin26 X.509 certificates, cont. Version 3 of X.509 certificates introduces certificate extensions. Extensions can be used for several purposes, among others to restrict the use of the certificate –Only as server certificate. –Only as client certificate. –To sign other certificates (i.e., as a CA certificate). When a certificate is verified, it should be verified that it is used for its intended purpose. When you create certificates, make sure to indicate the intended use!

27. Apr 2, 2002Mårten Trolin27 Next phase, secure messaging After the handshake is complete, the client and the server start exchanging encrypted messages. Each message is appended with a MAC before it is encrypted The key for encryption, the key for the MAC and the Initialization Vector (if used) is extracted from the key exchange messages.

28. Apr 2, 2002Mårten Trolin28 The assignment The task is to create a Certificate Authority –Create a CA certificate and private key –Create a certificate request A private and a public key, with request information –Sign the certificate request with the server private key Use command line openssl for the task. Documentation is available from http://www.openssl.org/docs/apps/openssl.html.

29. Apr 2, 2002Mårten Trolin29 The assignment Hand in the solution no later than April 16. For delays, one point per day is deducted from the result. Maximum score is four points. Hand in the certificates created, and the commands you used to create them, with a short description of each command. It is up to you to decide what kind of certificates to create.