MPRI 2-30: Automated Verification of Cryptographic Protocol - PowerPoint PPT Presentation

Source language: F# • F#, a dialect of ML: http://fsharp.org � “Combining the strong typing, scripting and � productivity of ML with the efficiency, stability, � libraries, cross-language working and tools of .NET.” • Very similar to OCaml, but with .NET libraries • Clean strongly-typed semantics – Modular programming based on strong interfaces – Algebraic data types with pattern matching � useful for symbolic cryptography, message formats

Core F# � (+ RCF constructs) • A ¡concurrent ¡ ¡ call-­‑by-­‑value ¡ lambda-­‑calculus ¡ • Fresh ¡(secret) ¡names ¡ • Channel-­‑based ¡ communica;on ¡ • Security ¡goals ¡as ¡ logical ¡assumes ¡ ¡ and ¡asserts ¡

An F# Library of Protocol Primitives We identify a set of platform libraries used in protocol code • Data: Data: string and byte array conversion functions • Net: Net: communication over TCP • Crypto: Crypto: cryptographic primitives • Principals: Principals: certificate and password store • Xml Xml: manipulating XML documents • Db: Db: managing private databases Each library is implemented as a wrapper ar Each library is implemented as a wrapper around the ound the corr corresponding .NET class esponding .NET class ( System.Net.Sockets.T System.Net.Sockets.TcpClient cpClient, .HMACSHA1 ) System.Security System.Security.Cryptography .Cryptography.HMACSHA1

Example: Authenticated RPC

Authenticated RPC Goals 1. A request s should be accepted by b only if it was a request sent by a 2. A response t should be accepted by a only if it was sent by b in response to s

Verification Techniques • Model Extraction – Translate F# code to ProVerif � Needs symbolic abstraction of libraries � ( tool: fs2pv) – Translate F# code to CryptoVerif � Needs probabilistic semantics of ML, � and computational abstraction of libraries � (tool: fs2cv) • Typechecking – Define secure type system for F# � Needs semantics, abstractions, � plus manual annotations, constraint solver � (tool: F7)

A Symbolic Model of the Library • An abstract model of Data and Crypto in F • Byte arrays represented as an algebraic datatype • Key generation as fresh name generation • Encryption and MAC as (private) constructors • Decryption as destructor

Other Symbolic Models of Crypto • Using seals [Morris’73] � or abstract types [Fournet’11] – each key contains a reference to a table that maps plaintexts to ciphertexts – encrypt adds plaintext to the table � and encrypts 0 instead – decrypt looks up the table; � if no value is found it still returns a value – under certain conditions the � encryption API is computationally sound

Other Symbolic Models of Crypto

Symbolic Verification Goal Given a protocol implementation P .ml .mli with public interface P Suppose we have symbolic models for our libraries LIBS=Data.ml, Crypto.ml, Net.ml, Principals.ml with public interfaces Data.mli, Crypto.mli, Net.mli, Principals.mli Our goal is that the program LIBS P .ml is robustly safe. That is, for all opponents O.ml that respect the public interfaces of LIBS and P .mli , LIBS P .ml O.ml is safe

Symbolic Verification � by Model Extraction

The Applied Pi Calculus [Abadi, Fournet] • A process calculus with an equational theory • Popular formalism for cryptographic protocols • Processes can be verified using ProVerif [Blanchet]

Extracting Applied Pi Models from F • We define a translation from F programs to applied pi calculus scripts – Follows Milner’s “Functions as processes” – Includes optimizations for eliminating irrelevant code • We prove that the translation is sound sound : � if the translation is robustly safe, so is the source.

Translating Authenticated RPC

Translating Crypto

Security Verification using ProVerif To use ProVerif for security verification: 1. Write symbolic models of libraries and their public interfaces Crypto.ml, Crypto.mli, Net.ml, Net.mli … 2. Annotate the program with security goals � P .ml 3. Define the public (attacker) F# interface � P-pub.mli 4. Translate all modules and their interfaces to applied pi � fs2pv Crypto.ml Crypto.mli … P .ml P-pub.mli > Script.pv 5. Run ProVerif on Script.pv. ProVerif may verify the script, or produce a counterexample, � or it may not terminate Security Theor Security Theorem em : � If the script Script.pv is verified by ProVerif then the program .ml is robustly safe. Crypto.ml Crypto.mli … P .ml P (by soundness of the translation and the correctness of ProVerif)

Symbolic Verification � by Typechecking

F7: Refinement Types for F# An enhanced type system that tracks logical invariants: • Refinement Types: x:ty x:ty { ϕ } – x:int { x > 0 } – pwd:string {Password(“Alice”,pwd)} • Dependent function types: x:ty x:ty -> -> ty ty’ – lookup: u:string {User(u)} -> p:string {Password(u,p)} – Pre-condition: User(u) , post-condition: Password(u,p) • Refinement subtyping: ty ty <: <: ty ty’ – x:ty { ϕ } <: ty • Typechecking guarantees (statically) that � no assert assert will fail at run-time – That is, each assert assert is entailed by its preceding assumes – It relies on an external SMT solver for logical proof obligations

Summary: Safety by Typing

Security Verification using F7 To use F7 for security verification: 1. Annotate libraries with security assumptions Crypto.ml7, Net.ml7, … 2. Annotate the program with security goals � P .ml7, P .ml 3. Define the public (attacker) F# interface � P-pub.mli 4. Verify that the program typechecks against � both the public interface and the program interface � Crypto.ml7, Net.ml7, … |- P .ml : P .ml7 <: P-pub.mli Security Theor Security Theorem em (by type safety): � If the libraries Lib.ml satisfy Crypto.ml7, Net.ml7, … � then the program Lib.ml P .ml is robustly safe.

Refinement Types for Crypto • Every MAC key has � a usage precondition • MACSays(k,b MACSays(k,b) � says that mackey k � may be used to MAC b • Each protocol defines � MACSays for its own � keys • Secret plaintexts may � not be encrypted with � compromised keys • Decryption does not � authenticate data

Verifying Authenticated RPC

Results

Protocol Implementations in F#

Verification with ProVerif

Verification with F7 • Other verifications not covered here: – Secure Multi-Party Sessions (2k lines, 2m) – TLS Transport Protocol (computational) (>5k lines, 13m)

Relevant Publications Verified Cryptographic Implementations for TLS,K. Bhargavan, C. • Fournet, R. Corin, and E. Zalinescu. ACM Transactions on Information and System Security, 15(1), 2012. (Also CCS 2008) Refinement Types for Secure Implementations, J. Bengtson, K. • Bhargavan, C. Fournet, A.D. Gordon, and S. Maffeis. ACM Transactions on Programming Languages and Systems, 33(2), 2011. Modular Verification of Security Protocol Code by Typing, K. • Bhargavan, C. Fournet, A.D. Gordon. ACM Symposium on Principles of Programming Languages, 445-456, 2010. Verified interoperable implementations of security protocols, K. • Bhargavan, C. Fournet, A.D. Gordon, and S. Tse. ACM Transactions on Programming Languages and Systems, 31(1):5, 2008. Verified implementations of the information card federated identity- • management protocol, K. Bhargavan, C. Fournet, A.D. Gordon, and N. Swamy. ACM Symposium on InformAtion, Computer and Communications Security, 123–135, 2008.

Summary • Protocol models often miss important security- critical details of implementations • Several ways to address this gap – Generate code from models (e.g. CV2ML) – Extract models from code (e.g. fs2pv) – Directly analyze protocol code (e.g. F7) • Our main focus will be on symbolic and computational verification by typechecking with F7

RCF: a concurrent λ -calculus with refinement types Slides adapted from A. D. Gordon’s see also the RCF tutorial

Tools, Reading • F# compiler: http://fsharp.org/ • F7 typechecker: http://research.microsoft.com/f7 Lecture notes on the course website: • RCF: a compact definition of the type system, plus exercises • Principles and Applications of Refinement Types , a tutorial on the RCF type system. • Cryptographic Verification by Typing for a Sample Protocol Implementation , a tutorial on F7 Research papers: http://research.microsoft.com/f7

A formal core for ML (outline) • A n assembly of standard parts, generalizing some ad hoc constructions in language-based security – FPC FPC (Plotkin 1985, Gunter 1992) – core of ML and Haskell – Concurrency in style of the pi-calculus pi-calculus (Milner, Parrow, Walker 1989) but for a lambda-calculus (like 80s languages PFL, Poly/ML, CML) – Symbolic crypto is derivable e.g. by coding up seals seals (Morris 1973, Sumii and Pierce 2002), not primitive as in the applied pi calculus – Security specs via assume/assert assume/assert (Floyd, Hoare, Dijkstra 1970s), generalizing eg correspondences (Woo and Lam 1992) – To check assertions statically, rely on dependent functions and pairs with subtyping (Cardelli 1988) and refinement types efinement types (Pfenning 1992, ...) aka pr predicate edicate subtyping subtyping (as in PVS, and more recently Russell) – Public/tainted kinds Public/tainted kinds to track data that may flow to or from the opponent, as in Cryptyc (Gordon, Jeffrey 2002) • For experiment, there is a downloadable implementation F7

RCF Part 1: SYNT SYNTAX AND SEMANTICS AX AND SEMANTICS

COMMUNICA COMMUNICATIONS & TIONS & CONCURRENCY CONCURRENCY

Communica;on ¡ ¡step ¡ Reduc;ons ¡step ¡are ¡ “up ¡to ¡structural ¡rearrangements” ¡

Reduc;ons ¡step ¡are ¡ “up ¡to ¡structural ¡rearrangements” ¡

FUNCTIONAL PROGRAMMING FUNCTIONAL PROGRAMMING � AND CONCURRENCY AND CONCURRENCY

LOGICAL SPECIFICA LOGICAL SPECIFICATIONS TIONS

Specifications: Assume Assume and Assert Assert • Suppose there is a global set of formulas, the log log • To evaluate assume assume C , add C to the log, and return (). • To evaluate assert assert C , return (). – If C logically follows from the logged formulas, we say the assertion succeeds succeeds; otherwise, we say the assertion fails fails. – The log is only for specification purposes; it does not affect execution • Our use of first-order logic predicates in C generalizes conventional assertions (like assert assert i>0 in eg JML, Spec#) – Such predicates usefully represent security-related concepts like roles, permissions, events, compromises

Semantics: expression safety • We ¡use ¡a ¡standard ¡small-­‑step ¡reduc;on ¡seman;cs; ¡ run;me ¡configura;ons ¡are ¡expressions ¡of ¡the ¡form ¡ ¡ ¡ ¡ ¡ ¡ ¡ ac;ve ¡ pending ¡ running ¡ assump;ons ¡ messages ¡ threads ¡ • An ¡expression ¡is ¡ safe ¡when, ¡ for ¡all ¡runs ¡of ¡A, ¡ all ¡asserIons ¡succeed ¡

Are these expressions safe?

PROGRAMMING EXAMPLE: PROGRAMMING EXAMPLE: ACCESS CONTROL IN ACCESS CONTROL IN � PAR ARTIALL TIALLY-TRUSTED CODE -TRUSTED CODE

Example: access control for files • Untrusted code may call a trusted library • Trusted code expresses security policy with assumes and asserts • Each policy violation causes an assertion failure • We statically statically prevent any assertion failures by typing

Logging dynamic events • Security ¡policies ¡ojen ¡ stated ¡in ¡terms ¡of ¡ dynamic ¡events ¡such ¡ as ¡role ¡ac;va;ons ¡or ¡ data ¡checks ¡ • We ¡mark ¡such ¡events ¡ by ¡adding ¡formulas ¡to ¡ the ¡log ¡with ¡ assume ¡

Access control with refinement types • Preconditions express access control requirements • Postconditions express results of validation • We typecheck partially trusted code to guarantee that � all preconditions (and hence all asserts) hold at runtime

F7 F7: refinement typechecking for F# F# AES.fs7 ¡ • We program in F# � RPC.fs7 ¡ Lib.fs7 ¡ • We specify in F7 � RPC.fs ¡ We typecheck programs � against interfaces Type ¡ Prove ¡ (F7) ¡ (Z3) ¡ • F7 does some type inference � Erase ¡ ¡ & calls Z3, an SMT solver, � types ¡ on each logical proof obligation RPC.fsi ¡ RPC.v ¡ • We thus develop � crypto libraries and � verify protocol implementations � Prove ¡ Compile ¡ (coq) ¡ (F#) ¡

Access control for files (demo)

RCF Part 2: TYPES FOR SAFETY TYPES FOR SAFETY

Three Steps Toward Safety by Typing 1. We include refinement types efinement types { x : T | C } � whose values are those of T that satisfy C 2. To exploit refinements, we add a judgment E |- C � meaning that C follows from the refinement types in E 3. To manage refinement formulas, we need (1) dependent versions of the function and pair types, and (2) subtyping

Assume and Assert

Type Judgements & Type safety

TYPE THEORIES BEHIND RCF TYPE THEORIES BEHIND RCF

Summary on RCF • RCF supports – functional programming a la ML – concurrency in the style of process calculus, and – refinement types allowing correctness properties to be stated in the style of dependent type theory. • Implementations & examples at http://research.microsoft.com/F7 � http://research.microsoft.com/Fstar • Related language design and implementation: � Aura, Fable, F7, F5, Fine, F*…

sample protocol AUTHENTICA AUTHENTICATED RPC TED RPC

Sample protocol: an authenticated RPC request ¡ HMAC(key,request) ¡ response ¡ HMAC(key,request,response) ¡ Client ¡ ¡ Service ¡

Informal description

Is this protocol secure?

Logical Specification

F# Implementation

Test Connecting to localhost:8080 Sending {BgAyICsgMj9mhJa7iDAcW3Rrk...} (28 bytes) Listening at ::1:8080 Received Request 2 + 2? Sending {AQA0NccjcuL/WOaYS0GGtOtPm...} (23 bytes) Received Response 4

Demo

SYMBOLIC VERIFICA SYMBOLIC VERIFICATION: TION: LOGICAL INVARIANTS � FOR CRYPTOGRAPHY

Invariants for Cryptographic Structures

Modelling Opponents as F# Programs

Symbolic Security Theorem

Symbolic proof (typechecking)

Security Proof: MACs