Cryptographic Protocols

State of TLS: Present and Future

David Leonard | Liron Shimrony

December 15th, 2015

Introduction

• TLS 1.2 is not provably secure under the key-indistinguishability model. Using TLS-DHE, security of TLS can be proved

• TLS 1.3 draft-05 uses multiple keys during the handshake and thus it is possible to prove standard key indistinguishability

• OPTLS 1.3 adds support for 0-RTT, PSK and hopes to achieve elliptic curves implementations

TLS Protocol

• The TLS (Transport Layer Security) protocol, allows a client and a server to authenticate with each other

• The protocol consists of a handshake where the client proves that he who he claims to be and so is the server

• After handshake is complete, the parties can exchange messages securely

TLS < 1.3 Handshake Protocol

• Client and server exchange messages in TLS (<1.3)
   

• During the handshake process, 13 messages are exchanged and only one key is being generated

TLS Record Layer 

• It fragments and reassembles the data coming from the application into manageable blocks 
• It compresses the data and decompresses incoming data
• Applies a  MAC to the data and uses the MAC to verify incoming data
• It encrypts the hashed data and decrypts incoming data

Insecurities in the Handshake Protocol

• TLS Record layer exposes a method to check if a key is real or random

• Last message sent in the handshake is the finished message

  • Used to protect against Man in the Middle attacks

  • Is encrypted using keys generated by TLS Handshake

• Adversary can run a Test query using a challenge key

  • Adversary attempts to decrypt finished message using challenge key

  • Can now distinguish if the key was random or real

Solutions for proving security of TLS

• Consider a truncated version of the TLS Handshake

  • Don’t encrypt the finished messages

• Observe that the core protocol  using Ephemeral Diffie-Hellman captures the security properties of both the TLS Handshake and Record Layer

Motivations of TLS-DHE

• TLS-DHE provides perfect forward secrecy

  • As opposed to TLS-RSA

  • Attacker can use compromised key to decrypt previous session keys

• Google is switching over all their services to TLS-DHE

Building Blocks for the TLS-DHE Model

Decisional Diffie-Hellman Assumption

Digital Signature Schemes

Pseudo-Random Functions

Collision-Resistant Hashing

Stateful Length-Hiding Authenticated Encryption

PRF-ODH

Authenticated Key Exchange Protocols

Adversary A:

• Can perform adaptive corruptions

• Has full control over the network

  • Can drop, insert, re-order messages

• Has access to oracles representing parties in the protocol (server, client) and protocol instances

• Can perform Send, Reveal, Corrupt, Test queries

Security of Authenticated Key Exchange Protocols

The Protocol is insecure if A can perform either of the following:

• Causes an oracle (client or server) to accept maliciously

• Answers the test query successfully

Security of Authenticated Key Exchange Protocol with Truncated TLS

+

Authenticated and Confidential Channel Establishment

• Keys are generated in the pre-accept phase, mirrors Handshake Protocol in TLS

• Data is encrypted and transmitted in post-accept phase, mirrors Record Layer in TLS

Constructing an ACCE Protocol

The Protocol is insecure if A can perform either of the following:

• Causes an oracle to accept maliciously, known as an authentication-adversary

• Answers the encryption challenge successfully

TLS with Ephemeral Diffie-Hellman is a Secure ACCE Protocol

Need for PRF-ODH Assumption

A can perform a man in the middle attack to corrupt an oracle:

TLS 1.2 vs. TLS 1.3

• Using intermediate keys. provide confidentiality of handshake data such as the client certificate

• Signing the handshake transcript for authentication

• Encrypting the Finished message in the handshake and the application data with different keys

• Deprecating some cryptographic algorithms that were used in previous versions of TLS

• Using authenticated encryption with associated data (AEAD) schemes for symmetric encryption

• Less messages during handshake to reduce latency

TLS 1.3 Handshake Protocol

• Client and server exchange messages in TLS
   

• During the handshake process multiple keys are being generated

Adversary Model

• We consider probabilistic polynomial time adversary

• Listen to the network and can  intercept, inject and drop messages

• In order to keep track on the adversary success we add a LOST flag to our data and initialize it to false

• Adversary Interactions:

  • NewSession

  • Send

  • Reveal

  • Corrupt

  • Test

Match Security

​Match security ensures that the session identifiers (sid) effectively match to the partnered session:

• Sessions with the same session identifier for some stage:

  • Hold the same session key

  • Agree on that stage’s authentication level

  • Share the same contributive identifier at that stage

• Sessions are partnered with the intended participant

• Session identifiers are do not match at different stages

• At most two sessions have the same session identifier at any stage            

Multi-stage Security

• TLS 1.3 provides Perfect Forward Secrecy by default

• Keys are derived from HMS and Session_ID

Multi-Stage Security - Client Without a Parenter

Multi-Stage Security - Server Without a Partner

Multi-Stage Security - Server With a Partner

Multi-Stage Security - All Together

TLS 1.3 Advantages

• Soundness of Key Separation

• Key independence

• Encryption of Handshake Messages

• Session hash in key derivation

• Upstream hashing for signatures

OPTLS

Goals

• Created to replace many patches in the existing TLS protocol

• Serve as a basis to TLS 1.3

• Supports 0-RTT, 1-RTT

• Forward security

• Implement protocols using elliptic curves

Overview

• Basic of OPTLS server authentication

• Server posses signed certificate DH

•        is the server public key

• s is the server secret key

• Key derived from         and 

• Provides security even if one of the keys is exposed

• Outputs session key

Cached Keys and 0 - RTT

• Example of 0 - RTT - search engine (Google)

• First message exposed to replay attack

• Protected under 

Key Derivation

• Keys are derived from         and 

• Secure even if one key is exposed

Security Model

• Each party can initiate or respond to an instance of the protocol

• Parties maintain session state

• Protocol outputs a session key

• May be aborted without output.

Server Authentication

• Each server has public and secret key

• Clients can verify servers keys via trustful CA

• Public key: static DH 

• Secret key: DH exponent (s)

Adversary Model

• Probabilistic polynomial time

• Adversary A has full control over the network (MITM)

• Available queries:

  • StateReveal

  • Reveal

  • Corrupt

Basic Security

• Match security

• Two parties complete the protocol they output the same session key

• If session is not exposed, the adversary advantage to guess if b=b’ is ½+negl

• Perfect forward security

• Sessions are secured even if one of the ephemeral DH keys are exposed

HKDF Assumption

• HMAC Key Derivation Function (HKDF)

• Using two steps mechanism: extract and expand

• Extract: generate randomness from a secret input (not necessarily uniform) and outputs a uniformly random string

• Expand: uses the generated string together with a PRF to generate keying material

Gap-DDH Assumption

•  Given a cyclic group G of prime order p, the Computational Diffie-Hellman problem is:
  • Given (g,     ,     )  in G, computing         is intractable

• Group G is a GDH group if the DDH problem is solvable in polynomial time while the CDH problem is unsolvable in poly-time 

OPTLS Modes

• 1-RTT semi-static: The server has a semi-static       which can support application data in 0-RTT mode

• 1-RTT non-static: No static       and the ephemeral value        acts   as  

• PSK: Used with a pre-shared secret key

• PSK-DHE: Augments PSK with Diffie-Hellman key exchange to obtain perfect secrecy

Key Derivations

1-RTT Semi-Static Mode

Assuming that HKDF is secure and both the Gap-DDH and DDH problems are hard:

• Perfect forward secrecy with respect to the server secret and long-term signing key

• Resilient to disclosure of ephemeral exponents with respect to the server’s exponent y

Early Application Data in 1-RTT

Client can use a cached ssks to send data using eadk. eadk is proven secure via the One-pass security model:

• A can perform Reveal() and Test() queries with respect to eadk

• Matching conversations are based on (chello, ssks)

1-RTT Non-Static Mode

Assuming that HKDF is secure and the DDH problem are hard:

• Achieves perfect forward secrecy with respect to the server’s signing key

• Not resilient to disclosure of ephemeral exponents

PSK and PSK-DHE

By the TLS protocol, allows a client and server to use an established secret to start a new connection via pre-shared mode

• PSK achieves basic security if HKDF is secure

  • Does not achieve perfect forward secrecy

• PSK-DHE achieves perfect forward secrecy (server’s psk) as well as resilience to leaked ephemeral exponents (server’s y) if HKDF is secure and the DDH problem is hard

• Also holds for 0-RTT

Future Work

• Prove security of session resumption without restarting the entire handshake

• Security model of client-authentication

• Security proof of universally-composable security via the client’s a MAC value of client’s third message