Authenticated Encryption in TLS Same modelling Poor TLS track - PowerPoint PPT Presentation

Authenticated Encryption in TLS

Same modelling Poor TLS track record & verification approach - Many implementation flaws - Attacks on weak cryptography concrete security: each lossy step (MD5, SHA1, … ) documented by a game and a reduction (or an assumption) on paper - Attacks on weak constructions (MAC-Encode-then-Encrypt) Standardized complications - Attacks on compression - multiple algorithms and constructions - Persistent side channels (crypto agility) - Persistent truncation attacks - multiple keys - conditional security (crypto strength, compromise) - wire format, fragmentation, padding - stateful (stream encryption)

Handshake AppData Alert Plaintext Key 0 (1 sided) Key 1 Key 2 Key 3 Write channel Handshake AppData Alert Plaintext Key 1 Key 2 Key 3 Read channel

TLS 1.3 gets rid of weak AppData Handshake Alert … ct = 0x17 ct = 0x15 ct = 0x16 constructions, encrypts parts of the handshake, introduces plenty of auxiliary keys plaintext format parse 000 … plaintext ct ℓ + 1 decrypt 5 encrypt cipherlen App tag ciphertext TLS 1.0 ( ℓ + 1) Data

Handshake/Alert Application We model record-layer keys : fragments : d 0 , d 1 , d 2 security using a game at k 0 , k 1 , … Record Sequence of streams every level of the keyed by Handshake construction. Length-Hiding (padded) LHSE Multiplexed Streams We make code-based Stream Encryption with StAE security assumptions on sequence numbers the crypto primitives Generic (PRF, MAC) Generic AEAD AEAD construction We obtain security PRF MAC guarantees at the top- Verified Crypto level API for the TLS library Poly1305 GHASH ChaCha20 AES record layer

Symmetric Cryptography AES128 Chacha20 GHASH Poly1305 AES256 1-Time MAC Cipher IND-1CMA IND-PRF AEAD.Encoding AEAD AEAD.Invariant Stream Encryption Record Layer TLS record Protection protection

Client Server TLS record layer decrypt encrypt #1 #2

Client Server ideal encryption log #0 #1 decrypt encrypt table random #1 #2 lookup sampling

We program & verify AEAD for TLS 1.2 and TLS 1.3. We do not consider here classic, time-battered TLS modes such as AES_CBC (Mac-Encode-then-Encrypt)

One-time Pad for the MAC … IV || 0 IV || 1 IV || n … PRF PRF PRF AEAD Key … … lengths of Ciphertext plaintext and (tag) additional data … … T a Authentication key g

One-Time MACs (INT-CMA1) Ciphers (IND-PRF) For both GF128 or Poly1305, Assumed for AES and Chacha20 we get strong probabilistic security.

One-Time MACs (INT-CMA1) Ciphers (IND-PRF) Construction: Modelling: authenticated materials and their we use a variant with specialized oracles lengths are encoded as coefficients of a for each usage of the resulting blocks polynomial in a field (GF128 or 2^130 -5) as one-time MAC key materials - The MAC is the polynomial evaluated as one-time pad for encryption - at a random point, then masked. as one-time pad for decryption - We get strong probabilistic security.

many kinds of proofs not just code safety! functional correctness arithmetic correctness Given (low-level assembly) (field computations) a cipher, modelled as • a pseudo-random function AES128 Chacha20 GHASH Poly1305 AES256 abstraction a field for computing one-time MACs • & agility 1-Time MAC AES CBC injective message encodings Cipher • IND-1CMA security IND-PRF idealization We program and verify a generic AEAD.Encoding authenticated stream encryption injectivity AEAD with associated data . AEAD.Invariant loops & stateful invariants Stream We show (reasoning on ideal logs) Encryption safety LHAE • functional correctness TLS-specific mechanisms • TLS record fragmentation • security (reduction to PRF assumption) protection • content multiplexing • concrete security bounds for the • length-hiding, padding TLS API • 3 main record ciphersuites of TLS re-keying • TLS FFI 0-RTT, 0.5-RTT •

Probabilistic proof Theorem: the 3 main record ciphersuites for TLS Standard (on paper) in abstract 1.2 and 1.3 are secure, except with probabilities field + F* verification crypto assumption IND-1CMA IND-PRF AEAD.Encoding AEAD AEAD.Invariant Stream Encryption 𝑟 𝑓 is the number of encrypted records; 𝑟 𝑒 is the number of chosen-ciphertext decryptions; F* type-based verification on code 𝑟 𝑐 is the total number of blocks for the PRF formalizing game-based reduction

We verified concrete security GHASH AES128 Chacha20 Poly1305 AES256 on low-level, standard-compliant code 1-Time MAC (not just a crypto proof on paper) AES CBC Cipher IND-1CMA Interop as client and server • IND-PRF with 3 other implementations of TLS 1.2 and 1.3 AEAD.Encoding AEAD Reasonable performance. AEAD.Invariant • Stream Encryption LHAE TLS record protection TLS API TLS FFI

TLS 1.3 Handshake (Outline) TLS *** RSA SHA ECDH AES Crypto Algorithms

Client Server

Handshake syntax: parse/format Messages Extensions Negotiation Configuration Session Log Certificates flights digests Hash Signing Key Schedule keys State config shares machine & mode ODH HMAC PRF Record Layer Protection TLS API Network (TCP) Application (HTTPS etc)

Most of the RFC, most of the code. Correctness? Me Meta tapr progra ogramming mming in F* Performance? Inte termed mediate iate copie pies s cons nsider idered ed harmfu rmful. l. Security? Example: ClientH ientHello ello me messa sage ge Hands ndshake hake digest est Example: Hands ndshakeLog.r hakeLog.recv ecv comp mputed uted on th the fly

high-level parser high-level type high-level formatter val parseCH: type clientHello = val formatCH: bytes -> | ClientHello: clientHello -> option clientHello pv: protocolVersion -> bytes id: vlbytes1 0 32 -> inverse properties cs: seq ciphersuite {…} - > … val injCH: clientHello -> Lemma … erased specification low-level in-place low-level validator code extracted to C val validateCH: len: UInt32.t -> low-level serializer input: lbuffer len -> val serializeCH: Stack (option (erased clientHello * UInt32.t)) output: buffer -> (requires fun h0 -> live input) len: UInt32.t -> pv : … - > … -> (ensures fun h0 result h1 -> Heap (option UInt32.t) … h0 = h1 /\ match result with (ensures fun h0 result h1 -> | Some (ch, pos) -> modifies h0 output.[0..len-1] h1 /\ pos <= len /\ match result with format ch = buffer.read input h0 0..pos-1 | Some pos - > … //idem | None -> True)

pre-shared key Diffie-Hellman shared secret (𝒉 𝒚𝒛 ) early secret handshake secret master Export secret Integrity (QUIC) Encryption Export (QUIC) Handshake Integrity Encryption pre-shared keys Caption: for future sessions two kinds of key derivation steps Encryption Integrity key materials prior secret Extract Expand derived secret new secret

pre-shared key Diffie-Hellman shared secret (𝒉 𝒚𝒛 ) early secret handshake secret master Export secret Integrity (QUIC) Encryption Export (QUIC) Handshake Integrity Encryption pre-shared keys for future sessions Encryption Integrity Our (fresh) crypto model precisely reflects F* code modularity, involves a security definition for each color, supports agility and key compromise.

Everest: verified drop-in replacements for the HTTPS ecosystem complex, critical, verifiable • close collaboration: crypto, system, compilers, verification • new tools: F*, KreMLin, Vale • safety, functional correctness & crypto security • for standard-compliant system code Code, papers, details at https://project-everest.github.io https://github.com/project-everest https://mitls.org https://fstarlang.org