6.824 2001 Lecture 15: Cryptographic protocols

Big picture
  Crypto often not needed on a single system
  Communication over untrusted networks requires crypto
    Bad guys might read, modify, delete, forge messages
  What tools are useful in this situation?

- Cryptographic protocol: a protocol designed to achieve a security
  objective. One assumes that one of the parties in the protocol can
  be malicious.

- Building blocks:
  - Abstractions:
    Confidentiality -- eavesdropper can't understand messages.
    Authentication -- who am I talking to? Did they really say that?
  - Primitives
    Symmetric-key systems (encrypt, decrypt, MACs)
    Public-key systems (encrypt, decrypt, signatures)
    Cryptographic hashes
    Pseudo-random generators

What turns out to be hard?
  Cryptographic primitives rarely turn out to have serious flaws.
    So leave them to the experts.
  Crypto protocols *almost always* turn out to have serious flaws.
    So leave them to the experts?
    But worth understanding, often reflect system-level misunderstandings.
  Even w/o flaws, crypto and crypto protocols rarely the weakest link.
    That is, attackers rarely bother to target crypto.
    Much easier to find buffer overrun bugs in printer daemon.    

- An example of a cryptographic protocol: SSL 3.0
  - Communication privacy over the Internet (mostly with Web servers)
    Claimed features:
    - provides confidentiality of communication in the face of active
      and passive attackers:
      1. confidentiality
      2. authenticity
      3. replay protection
    - provides user authentication
    - provides server authentication

- Structure of SSL
  - 2 layers that run over a reliable transport:
    1. Bottom layer: record layer
    2. Top layer: handshake protocol and application data

  - Usage:
    1. CLient opens an TCP connection
    2. Key exchange protocol over unauthenticated, unencrypted record
       layer (which uses TCP to communicate with server)
    3. The hand handshake protocols sets encryption and authentication
       keys
    4. Application data is sent over encrypted and authenticated
       record layer

  - Many options

- State for record layer and handshake protocol:
  1. Session ID --- nonce chosen by a server
  2. A peer certificate --- used for authentication
  3. A cipher spec --- which ciphers to use
  4. A client and server random number
  5. A master secret ---- shared secret between client and server
     client value, client random number, and server random number
  6. Keys derived from master secret:
     1. server write MAC key
     2. client write MAC key
     3. server write encryption key
     4. client write encryption key
  7. send sequence number   --- for replay attacks
  8. receive sequence number  --- for replay attacks
     (record layer fragments messages into fixed-size message)

- Message formats

  Applications hands record layer:
    struct {
       int type;
       int version;
       int length;
       uchar fragment[length];
    } SSLPlaintext;

  Record layer transforms these records into:
  
    struct {
       int type;
       int version;
       int length;
       select (CipherSpec.cipher_type) {
         case stream: GenericStreamCipher;
         case block: GenericBlockCipher;
       } fragment;
     } SSLCiphertext;

    struct {
       uchar content[SSLPlaintext.length];
       uchar MAC[CipherSpec.hash_size;
    } GenericStreamCipher;
  
  - The MAC is computed before encrypting.
  - The MAC is dependent on write MAC key, seq_num, type, length,
    fragment

- Handshake protocol
  - Purpose: authenticate server, client, and generate the 4 keys
  1. ClientHello (client_version, random, session_id, cipher_suites) ->
  2. <- ServerHello (server_version, random, session_id, cipher_suites)
  3. <- ServerCertificate (certificate_list)
  4. <- ServerHelloDone
  5. ClientKeyExchange( E(pre_master_secret)ServerPubKey ) ->
  6. ChangeCipherSpec (cipher_suite) ->
  7. [Finished(MAC(master_secret, all handshake message)] ->
  8. <- ChangeCipherSpec, cipher_suite
  9. <- [Finished, MAC(master_secret, all handshake message)]
  10. <-> [Data(plaintext)]

  Notes: 
  - Messages between [] are encrypted and authenticated
  - Some of the message above are optional
  - Ad 1: many ciphers
  - Ad 2: many ciphers 
  - Ad 3: list of certificates signed by certificate authorities
    Clients verifies one with the public key of the authority
  - Ad 5: typically uses RSA
  - Ad 6: announce with cipher client uses in the next messages
    Generate keys
  - Ad 7: verifier of the protocol. server recomputes over the
    messages it has received and checks
  - etc.

  Cost:
    - two expensive public-key operations  (checking server signature
    and encrypting pre_master_secret). Limits servers to 10-15
    transaction per second.
    - to avoid expense: session IDs.