1. Mar 28, 2003Mårten Trolin1 This lecture Certificates and key management Non-interactive protocols –PGP SSL/TLS –Introduction –Phases –Commands

2. Mar 28, 2003Mårten Trolin2 Previous lecture New assignment Generating keys Distributing keys –Key splitting Master key and derived keys Key lengths –Symmetric keys –Asymmetric keys

3. Mar 28, 2003Mårten Trolin3 Key management – getting a certificate 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!

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

5. Mar 28, 2003Mårten Trolin5 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.

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

7. Mar 28, 2003Mårten Trolin7 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.

8. Mar 28, 2003Mårten Trolin8 Encrypting documents So far, we have mainly been discussing encryption in interactive protocols (e.g., TLS). In many cases, there is no interaction between the sender and the recipient –Email –Fax –Encrypted backups – in this case the sender and the receiver is the same. All these systems have in common that encryption and decryption take place at different times.

9. Mar 28, 2003Mårten Trolin9 Non-interactive protocols For interactive protocols, the symmetric key is decided in the handshake. For non-interactive protocols, this must be solved in another way. –The key cannot be negotiated. Different possibilities –Exchange a symmetric key. –Encrypt only using a public-key scheme. –Encrypt a session key using the recipients public key.

10. Mar 28, 2003Mårten Trolin10 Session key in non-interactive protocols For non-interactive protocols, the sender generates a session key. The session key is encrypted using the recipient’s public key. –Recipient’s public key must be known in advance. The message is encrypted with the (symmetric) session key. The encrypted message consists of the encrypted session key and the cipher text. The recipient decrypts the session key with his private key and decrypts the message.

11. Mar 28, 2003Mårten Trolin11 Key distribution The method is chosen in a way similar to interactive protocols –Symmetric key only when key exchange is possible, or when the person encrypting and decrypting is the same (e.g., for backups). –Asymmetric when no key exchange is possible. Public keys are preferably distributed in certificates. –Contains identifying information. –Either self-signed or signed by a CA.

12. Mar 28, 2003Mårten Trolin12 Encrypting and/or signing When encrypting documents, we can choose to –only encrypt. –encrypt and sign. –only sign. What we choose to do depends on the application. It is recommended to first sign and then encrypt.

13. Mar 28, 2003Mårten Trolin13 Signing before encrypting If both signing and encryption is used, it is recommended to sign first encrypt second. This way a third party can verify the signature without knowing the recipients key. –If the encrypted document is signed, the signature becomes specific to the recipient’s encrypted copy. The resulting message may or may not include the sender’s public key in a public key certificate.

14. Mar 28, 2003Mårten Trolin14 Signing and encrypting Document Signature Encrypted message Session key encrypted under Bob’s public key Session key encrypted under Clive’s public key Session key Message to be sent

15. Mar 28, 2003Mårten Trolin15 Pretty Good Privacy – PGP Pretty Good Privacy (PGP) is an email encryption and signing system. –First version in 1991. Uses public key certificates for key distribution and symmetric encryption with a session key. Available for almost any environment. –Commercial and non-commercial versions exist.

16. Mar 28, 2003Mårten Trolin16 PGP trust model Since PGP originally was targeted at individual users when no major CA’s were active, a distributed trust model was chosen. For Alice to verify Bob’s signature on a message, Alice must know Bob’s public key. Alice can choose to explicitly trust Bob’s key. –Useful if Alice herself can verify that the key belongs to Bob. –Unpractical for large communities.

17. Mar 28, 2003Mårten Trolin17 PGP trust model – introducers To solve the practical problem with key distribution, PGP uses introducers. Introducers sign other certificates. Anyone who trusts the introducer also trusts the certificate he has signed. –A certificate can have an unlimited number of signatures. A large number of signatures makes it more likely that the certificate will be trusted. –The system with introducers makes every user a CA. –Every user must decide which decide which introducers to trust.

18. Mar 28, 2003Mårten Trolin18 Extending the concept – meta-introducers Since the model with introducers is effectivaly one-layer, it is inefficient in many cases. –Example: A company with several departments employing PGP internally may want each department to sign the certificates of the employees. Meta-introducers exist for this purpose. Meta-introducers sign keys of other introducers, giving a three-layer model.

19. Mar 28, 2003Mårten Trolin19 Web of trust The CA model is hierarchical, whereas the PGP model is not. The PGP rather resembles a web. Which model to choose very much depends on the application. The CA model is better suited for well- structured organizations. The web model works better for informal communities.

20. Mar 28, 2003Mårten Trolin20 Partial trust A problem with the PGP model is that one user that goes bad destroys the whole system. –If a widely trusted user starts signing bogus certificates, all these bogus certificates will be as widely trusted A natural extension to the PGP model is to require not only one, but several signatures on a certificate for it to be valid. –Taken to another level – a user can assign to each introducer a certain number of trust points, and require have signatures for a certain sum of trust points to be trusted.

21. Mar 28, 2003Må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 28, 2003Mårten Trolin22 TLS IP TCP HTTPTLS IP TCP HTTP Not secureSecure

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

24. Mar 28, 2003Mårten Trolin24 TLS roles TLS defines two roles, the server and the client. The client always initiates the communication. –Example: Web browser The server stands ready to respond to a request from the server –Example: Web server

25. Mar 28, 2003Mårten Trolin25 TLS messages TLS defines several messages The messages are used in different stages –Handshake Key establishment Authentication Resuming a session –Sending data –Closing a transaction

26. Mar 28, 2003Mårten Trolin26 Initiating a transaction without authentication Client Server ClientHello ServerHello ServerKeyExchange ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ServerHelloDone