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

 

Prevents:

  • Replay attacks

  • Dropping messages

  • Re-ordering of messages

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

 

A makes a client-oracle accept maliciously:

A makes a server-oracle accept maliciously:

A answers the Test query successfully:

+

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

Probability that an auth-adversary succeeds in making an oracle accept maliciously is:

Probability that an adversary succeeds in answering the encryption challenge correctly:

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

g^{xs}
gxsg^{xs}
g^{xs}
gxsg^{xs}
g^{xy}
gxyg^{xy}

Cached Keys and 0 - RTT

 

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

  • First message exposed to replay attack

  • Protected under 

g^{xs}
gxsg^{xs}

Key Derivation

 

  • Keys are derived from         and 

  • Secure even if one key is exposed

g^{xs}
gxsg^{xs}
g^{xy}
gxyg^{xy}

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)

g^s
gsg^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

 

 

 

g^{ab}
gabg^{ab}
  • Group G is a GDH group if the DDH problem is solvable in polynomial time while the CDH problem is unsolvable in poly-time 
g^a
gag^a
g^b
gbg^b

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

g^y
gyg^y
g^s
gsg^s
g^s
gsg^s
g^s
gsg^s

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)

 

 

If HKDF is secure and the Gap-DDH problem is hard, then this mode achieves One-pass security

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

Made with Slides.com