This lecture

1
This lecture

• Certificates and key management
• Non-interactive protocols
• PGP
• SSL/TLS
• Introduction
• Phases
• Commands

2
Previous lecture

• New assignment
• Generating keys
• Distributing keys
• Key splitting
• Master key and derived keys
• Key lengths
• Symmetric keys
• Asymmetric keys

3
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
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
5
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
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
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
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
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
Session key in non-interactive protocols

• For non-interactive protocols, the sender
  generates a session key.
• The session key is encrypted using the
  recipients public key.
• Recipients 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
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
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
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 recipients
  encrypted copy.
• The resulting message may or may not include the
  senders public key in a public key certificate.

14
Signing and encrypting
Session key encrypted under Clives public key
Session key encrypted under Bobs public key
Document
Encrypted message
Session key
Signature
Message to be sent
15
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
PGP trust model

• Since PGP originally was targeted at individual
  users when no major CAs were active, a
  distributed trust model was chosen.
• For Alice to verify Bobs signature on a message,
  Alice must know Bobs public key.
• Alice can choose to explicitly trust Bobs key.
• Useful if Alice herself can verify that the key
  belongs to Bob.
• Unpractical for large communities.

17
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
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
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
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
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

24
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
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
Initiating a transaction without authentication
ClientHello
ServerHello
ServerKeyExchange
ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
Finished
ChangeCipherSpec
Finished
Server
Client