Noise Explorer Fully automated modeling, analysis and verification - PowerPoint PPT Presentation

Noise Explorer Fully automated modeling, analysis and verification for arbitrary Noise protocols IACR Real World Crypto Nadim Kobeissi Symposium 2019 Karthikeyan Bhargavan San Jose, California

Noise Protocol Framework: What is it? A Framework for Secure Channel Example Noise Handshake Pattern Protocols NK: • Based on Diffie-Hellman key <- s agreement. ... • Simple language for describing -> e, es messages. <- e, ee • From message description, complex state transformations are derived. • Author: Trevor Perrin. 2

Trevor Perrin’s Talk at RWC2018 https://youtu.be/3gipxdJ22iM 3

Understanding the Notation Handshake Pattern Notation Example Noise Handshake Pattern • s, e : local static and ephemeral key IK: pairs. Automatically generated when <- s they appear in a message. ... • ss, se, es, ee : Diffie-Hellman operations. Automatically mixed into -> e, es, s, ss state. <- e, ee, se • Once we have shared secret agreement, encryption on certain payload elements kicks in automatically. 4

Handshake State Machine State Transformation Functions Example Noise Handshake Pattern • Defined cryptographic operations: XX: EncryptAndHash, HKDF , etc. -> e • Defined local state objects: <- e, ee, s, es CipherState, SymmetricState, HandshakeState . -> s, se • Defined state transformations when processing tokens in messages: MixHash, MixKey , etc. 5

Popular Adaptations of Noise WhatsApp WireGuard XX: IKpsk2: -> e <- s <- e, ee, s, es ... -> s, se -> e, es, s, ss IK: <- e, ee, se, psk <- s ... -> e, es, s, ss <- e, ee, se 6

Security Goals in the Noise Specification Grade Based System Example Noise Handshake Pattern • Authentication: three grades: KN: • 0, 1, 2 -> s • Confidentiality: six grades: ... • 0, 1, 2, 3, 4, 5 -> e 0 0 • Identity hiding: <- e, ee, se 0 3 • Not currently evaluated by Noise Explorer. -> 2 1 <- 0 5 7

Security Goals in the Noise Specification Authentication Grades Example Noise Handshake Pattern • Authentication 0 : No authentication. KN: • “This payload may have been sent by any -> s party, including an active attacker.” • Authentication 1 : Sender ... authentication vulnerable to KCI. -> e 0 0 • “If the recipient's long -term private key has been compromised, this authentication can be <- e, ee, se 0 3 forged.” -> 2 1 • Authentication 2 : Sender authentication resistant to KCI. <- 0 5 • “Assuming the corresponding private keys are secure, this authentication cannot be forged.” 8

Security Goals in the Noise Specification Confidentiality Grades Example Noise Handshake Pattern • Confidentiality 0 : No confidentiality. KN: “This payload is sent in cleartext.” • -> s • Confidentiality 1 : Encryption to ephemeral recipient. ... “This payload has forward secrecy, since encryption • involves an ephemeral-ephemeral DH ("ee"). However, -> e 0 0 the sender has not authenticated the recipient, so this payload might be sent to any party, including an active <- e, ee, se 0 3 attacker.” • Confidentiality 2 : Forward secrecy for sender -> 2 1 compromise only, vulnerable to replay. “If the recipient's static private key is compromised, <- 0 5 • even at a later date, this payload can be decrypted. This message can also be replayed, since there's no ephemeral contribution from the recipient.” 9

Security Goals in the Noise Specification Confidentiality Grades Example Noise Handshake Pattern • Confidentiality 3 : Weak forward secrecy. KN: “The recipient's alleged ephemeral public key may have • been forged by an active attacker. In this case, the attacker could later compromise the recipient's static -> s private key to decrypt the payload.” • Confidentiality 4 : Weak forward secrecy if ... sender’s private key was compromised. -> e 0 0 “If the sender's static private key was previously • compromised, the recipient's alleged ephemeral public key may have been forged by an active attacker. In this <- e, ee, se 0 3 case, the attacker could later compromise the intended recipient's static private key to decrypt the payload.” -> 2 1 • Confidentiality 5 : Strong forward secrecy. “Assuming the ephemeral private keys are secure, and • <- 0 5 the recipient is not being actively impersonated by an attacker that has stolen its static private key, this payload cannot be decrypted.” 10

So Many Security Goals! 50+ Handshake Patterns in the Noise Allows for Use-Case Specific Spec Alone Protocols • How do we verify all of these protocols • TLS isn’t (and shouldn’t be) the answer against (50+ · 10) = 500+ security to everything. queries? • How can we ascertain which security promises any Noise Handshake Pattern can give? 11

12

Noise Explorer: Design and Formally Verify Noise Handshake Pattern any • Desig ign n Nois ise Protoc ocol ols: Immediate to- • Nois ise Explorer Compendium dium: Formal spec validity checks, helpful verification results for 50+ Noise visualizations. Handshake Patterns. • Gen ener erat ate e Model els for Forma mal • NEW: Gen ener erat ate e Imp mplem emen entations tations: Verif ific icatio ion: Symbolic models for Generates full implementations of your ProVerif. Noise Handshake Pattern in JS and Go. • Top-level processes. • Sophisticated queries for all security goals. • Compromised principal (Charlie). 13

What is Formal Verification with ProVerif? Automated formal verification… …with ProVerif. • Beating the “code first, specify later” (if • Developed at INRIA Paris by Bruno ever) methodology. Blanchet and team. • Two main in models: Symbolic model • Check it out: and computational model. http://prosecco.gforge.inria.fr/personal /bblanche/proverif/ • We use the symbolic model, where we can model protocol flows and try to • I defended my Ph.D. thesis last month, find contradictions to security queries. which has many, many, many uses of ProVerif: https://hal.inria.fr/tel- 01950884 14

Generating Applied Pi Models for ProVerif Components to Model Diffie-Hellman in ProVerif • In ProVerif, all cryptographic primitives fun dhexp(key, key):key. are perfect symbolic black-boxes with equation forall a:key, b:key; no algebraic properties. dhexp(b, dhexp(a, g)) = dhexp(a, dhexp(b, g)). 15

Generating Applied Pi Models for ProVerif Components to Model AEAD in ProVerif • In ProVerif, all cryptographic primitives fun encrypt(key, nonce, bitstring, are perfect symbolic black-boxes with bitstring):bitstring. no algebraic properties. • Encryption is a PRP, hashing is a PRF, fun decrypt(key, nonce, bitstring, etc. bitstring):aead reduc forall k:key, n:nonce, ad:bitstring, plaintext:bitstring; decrypt(k, n, ad, encrypt(k, n, ad, plaintext)) = aeadpack(true, ad, plaintext). 16

Generating Applied Pi Models for ProVerif State Management in ProVerif Components to Model letfun mixKeyAndHash(ss:symmetricstate, • In ProVerif, all cryptographic primitives input_key_material:key) = are perfect symbolic black-boxes with let (cs:cipherstate, ck:key, no algebraic properties. h:bitstring) = symmetricstateunpack(ss) in • Encryption is a PRP, hashing is a PRF, let (ck:key, temp_h:key, etc. temp_k:key) = hkdf(ck, input_key_material) in • Common state management library for let (cs:cipherstate, temp_ck:key, all generated models. h:bitstring) = symmetricstateunpack(mixHash(symmetricstat epack(cs, ck, h), key2bit(temp_h))) in symmetricstatepack(initializeKey(t emp_k), ck, h). 17

Our Findings • Analysis of 50+ Noise Handshake Patterns. • We contribute a formally verified set of groundings for all security goals. • We show that if pattern validity rules are not followed, subtle attacks can be found. 18

Contributions to Noise Specification Improvements to Revision 34: • More well-defined pattern validity rules and security grades. • Higher assurance for fundamental pattern security grades. • New security grades for all 23 deferred patterns. 19

Noise Versus TLS: Lines of Code Lines of Code 300000 250000 200000 150000 100000 50000 0 BORINGSSL BEARSSL NOISEEXP: IK 20

Time for a Demonstration! Aspects that will be demonstrated: 1. Pattern designer and validator: https://noiseexplorer.com/ 2. Automatically generated formal verification results: https://noiseexplorer.com/patterns/IK/ (as an example) 3. Detailed analysis results: https://noiseexplorer.com/patterns/IK/A.html (as an example) 21

The Future of Noise Small, Use-Case Specific Protocols Upcoming Work in Noise • Entire library is ~1,000 LoC, specific • Signatures. Handshake Patterns can be smaller. • Stateful hashing and symmetric (Great post by David Wong: crypto overhaul. https://cryptologie.net/article/446/qui • NoiseSocket, NLS. c-crypto-and-simple-state-machines/) • Implementations that generate • Much smaller and more use-case implementations? specific state machine than TLS or similar. 22