Verified translation validation of static analyses Sandrine Blazy - PowerPoint PPT Presentation

Verified translation validation of static analyses Sandrine Blazy Univ. Rennes, CNRS IRISA, Inria joint work with Gilles Barthe, Vincent Laporte, David Pichardie and Alix Trieu IFIP WG 2.11 京都大学 2018 年 6 月 8 日 � 1

How to check security properties of implementations ? at program point XX: Verasco program.c No alarm ! 0 ≤ x ≤ 3 ∧ p ⟼ t[2*i+1] static analyzer … CompCert compiler program.asm security analysis Cryptographic constant-time property : • branching do not depend on secrets • memory accesses do not depend on secrets � 2

This talk at program point XX: Verasco program.c 0 ≤ x ≤ 3 ∧ p ⟼ t[2*i+1] static analyzer … CompCert lightweight proof e ff ort compiler 0 ≤ r 6 ≤ 3 ∧ r 1 ⟼ r 2 program.asm … General and lightweight methodology for carrying the results of a source analyzer down to lower-level representations � 3

This talk High-level abstract interpreter : Verasco program.c static • precise (e.g. precise points-to analysis) analyzer CompCert lightweight proof e ff ort compiler simple program.asm constant-time Low-level data-flow analysis : analysis • requires to manually rewrite programs • lack of precision • does not scale � 4

Alternative solution (work in progress) improved program.c program.c is constant-time Verasco static analyzer CompCert direct proof compiler and so is program.asm program.asm Brittle approach : it requires to • instrument all the semantics of CompCert • adapt and redo all the proofs • define new proof principles � 5

Background : the formally verified tools CompCert and Verasco � 6

CompCert methodology We program the compiler inside Coq. Language Definition compiler (S: program) := ... Compiler Semantics We state its correctness w.r.t. a formal specification of the language semantics. Soundness Proof Theorem compiler_is_correct : ∀ S C, compiler S = OK (C) � safe (S) � 
 Logical «C behaves like S». Framework (here Coq) We interactively and mechanically prove this theorem Proof. ...(* a few months later *) ... Qed. parser.ml compiler.ml pprinter.ml We extract an OCaml implementation of the compiler. Extraction compiler. � 7

Verification patterns (for each compilation pass) Verified transformation Verified translation validation transformation transformation validator Proved once for all One proof per program to compile = formally verified = not verified � 8

Verasco We program the static analyzer inside Coq. Language Definition analyzer (p: program) := ... Static Analyzer Compiler Semantics We state its correctness w.r.t. a formal specification of the language semantics. Soundness Proof Theorem analyzer_is_sound : ∀ P, analyzer P = Yes � 
 Logical safe(P). Framework (here Coq) We interactively and mechanically prove this theorem Proof. ... (* a few months later *) ... Qed. parser.ml pprinter.ml analyzer.ml We extract an OCaml implementation of the analyzer. Extraction analyzer. � 9

General architecture of Verasco CompCert C Clight C#minor ... CompCert compiler Alarms Abstract interpreter control flow Memory & value domain states Z → int numbers Nonrel → Rel Nonrel → Rel Convex Symbolic polyhedra equalities Integer congruences Integer & F .P . intervals

Verasco program.c static analyzer A lightweight methodology to correctly translate the CompCert lightweight proof 
 compiler results of static analysis e ff ort low-level program.asm annotations … � 11

Key ideas • Inlining enforceable properties • properties that can be enforced using runtime monitors 
 Inlining a monitor yields a defensive form (i.e. a program instrumented with runtime checks) 
 Enforcing a program to follow a property amounts to checking that it is safe. int *x; int *x; int t[3]; int t[3]; /* … */ z = x/y; assert { y != 0 }; /* … */ assert (x==t || x==t+1 || x==t+2); z = x/y; y = *x; y = *x; • Relative safety: P 1 is safe under the knowledge that P 2 is safe • An instance of relational verification � 12

Methodology Verasco p Verasco Def S p Φ Φ v : [l,h] i; ⇾ assert (l ≤ v && v ≤ h); i; safe S ( p ) safe S ( p Φ ) h · i CompCert CompCert h Φ i [ p ] h Φ i Def T [ p Φ ] safe T ([ p Φ ]) [ p ] safe T ([ p ]) Cosafe T [ p ] | = T h Φ i safe T ([ p ] h Φ i ) � 13

Use case: cryptographic constant-time � 14

Secure cryptography ? Lots of secure crypto algorithms were produced in the past decades: 
 AES, RSA, SHA1/2/3, ECDSA (used in Bitcoin). Attacks against these algorithms were also published: • Tromer, Osvik, Shamir, 2006: Attack against AES, recover the secret key from Linux's encrypted partitions in 65ms. • Yarom, Falkner, 2014: Attack against RSA in GnuPG 1.4.13. « On average, the attack is able to recover 96.7% of the bits of the secret key by observing a single signature or decryption round. » • Benger, van de Pol, Smart, Yarom, 2014: Attack on ECDSA using the secp256k1 curve « We demonstrate our analysis via experiments using the curve secp256k1 used in the Bitcoin protocol. In particular we show that with as little as 200 signatures we are able to achieve a reasonable level of success in recovering the secret key for a 256-bit curve. »

Timing attacks Secret data can have influence on running time of the program Attacker measures timing Attacker infers what is required to recover secret Examples Computes a b mod n, where b is a secret key in RSA 
 pseudo-code from Wikipedia if (secret) function modular_pow (base, exponent, modulus) foo(); if modulus = 1 then return 0 Assert :: (modulus - 1) * (modulus - 1) does not OVF base else result := 1 leaks how many bits bar(); base := base mod modulus of exponent are 1 while exponent > 0 if (exponent mod 2 == 1): result := (result * base) mod modulus exponent := exponent >> 1 base := (base * base) mod modulus return result

Use case: cryptographic constant-time Constant-time policy: the control flow and sequence of memory accesses of a program do not depend on some of its inputs (tagged as secret). Use of the points-to information from Verasco to keep track of security levels, and exploit this information in an information-flow type system • Leakage model: conditional branchings and memory accesses can leak information 
 Ex.: Leakage (< σ , if e then p1 else p2>) = σ (e) We were able to automatically prove that programs verify the constant-time policy. 
 Benchmarks: mainly PolarSSL and NaCl cryptographic libraries � 17

Conclusion Approach to formally verify translation of static analysis results in a formally verified compiler lightweight proof-e ff ort reduces security to safety improves a previous security analysis at pre-assembly level Improve Verasco to perform a very precise taint analysis • relies on a tainted semantics • encouraging results on a representative benchmark • main theorem: any safe program w.r.t. the tainted semantics is constant time (paper proof) � 18

Questions ? � 19

References • G. Barthe, S. Blazy, V. Laporte, D. Pichardie, A. Trieu. Verified translation validation of static analyses . Computer Security Foundations Symposium (CSF), 2017. • S. Blazy, V. Laporte, D. Pichardie. An abstract memory functor for verified C static analyzers . ICFP 2016. • J.H. Jourdan, V. Laporte, S. Blazy, X. Leroy, D. Pichardie. A formally-verified static analyzer . POPL 2015. • G. Barthe, G.Bertate, J.D.Campo, C.Luna, D. Pichardie. System-level non- interference for constant-time cryptography . Conference on Computer and Communications Security (CCS), 2014. . Schneider. Enforceable security policies . ACM Transactions on • F Information and System Security. 2000. . Piessens. Provably correct inline • M. Dam, B. Jacobs, A. Lundblad, F monitoring for multithreaded Java-like programs . Journal of Computer Security, 2010. � 20