Formal verification of low-level execution platforms Roberto - PowerPoint PPT Presentation

Roberto Guanciale Estonian Winter School Day 01 Formal verification of low-level execution platforms

Roberto Guanciale Assistant professor Computer Security Department of Theoretical Computer Science @KTH Research interest in Formal Verification Enthusiast software developer

Distributed Attacks B A

Distributed Attacks Software vulnerabilities Design flows ● Web parameter injection • Broken authentication •

Distributed Attacks Software vulnerabilities Password re-usage ● Poor Management Social engineering ● Misconfiguration ●

Distributed Attacks Software vulnerabilities Poor Management

OpenSSL 500 000 Lines of Code 1 Buffer Overflow Introduced 2012 Discovered 2014

Apps OS Hardware Host 1 Motivations

Apps OS Hardware Host 1 Motivations

Apps OS Hardware Host 1 Motivations

Apps OS Hardware Host 1 Motivations

Apps OS Hardware Host 1 Motivations

Apps Crypto Service OS Hypervisor Hardware Host 1 Motivations

∀ s. secure ( s ) Assumptions Models Verifjcation Formal Verification

CPU MEMORY Assumptions Models Verifjcation Formal Verification

OS Hypervisor CPU MEMORY Assumptions Models Verifjcation Formal Verification

OS Hypervisor CPU MEMORY Assumptions Models Verifjcation Formal Verification

Lecture plan 1) Formal verification 2) CPU models and proof strategy 3) Verification of memory virtualization 4) When the models are incorrect

Formal verification

Formal models states of the system ● Deterministic Finite Automata: integers • Stack, Heap, Current instruction: Java • … •

Formal models states of the system ● Deterministic Finite Automata: integers • Stack, Heap, Current instruction: Java • … • transition relation (behavior of the system) ● DFA: depends on the transition function • Java: depends on the program and the Java semantics •

Formal models states of the system ● Deterministic Finite Automata: integers • Stack, Heap, Current instruction: Java • … • transition relation (behavior of the system) ● DFA: depends on the transition function • Java: depends on the program and the Java semantics • labeled transition system ● • DFA: labels represent the accepted input characters • weak transition system (when some event is not important) •

Contract Verification  {P} C {Q} : when the precondition P is met, executing the program C establishes the postcondition Q. 

Contract Verification: Hoare logic  {P} C {Q} : when the precondition P is met, executing the program C establishes the postcondition Q.  

Contract verification: Hoare logic  {P} C {Q} : when the precondition P is met, executing the program C establishes the postcondition Q.    Java Modeling Language (JML)

Contract verification int SQRT(x) { int r = 0; while (r*r<=x) r++; return r; }

Hoare logic: weakest preconditon  Find the weakest precondition that guarantees that executing the program C establishes the postcondition Q.  Then prove P => WP

Hoare logic: weakest preconditon  Find the weakest precondition that guarantees that executing the program C establishes the postcondition Q  x:= exp {Q(x)}  WP = Q(exp)  Example  x:= 5 {Q(x) = x > y}  WP = Q(5) = 5 > y

Hoare logic: weakest preconditon  Find the weakest precondition that guarantees that executing the program C establishes the postcondition Q.  x:= exp {Q(x)}  WP = Q(exp)  Example  x:= y+1 {Q(x) = x > y}  WP = Q(y+1) = y+1 > y

Hoare logic: weakest preconditon  Find the weakest precondition that guarantees that executing the program C establishes the postcondition Q.  WP (C1; C2, Q) = WP(C1; WP(C2, Q))  Example x:=z+1 y:=x+y 1) WP(y:=x+y, y>5) = x+y > 5 Q = y > 5 2) WP(x:=z+1, x+y > 5) = z+1+y>5

Hoare logic: weakest preconditon  Find the weakest precondition that guarantees that executing the program C establishes the postcondition Q.  WP (IF C THEN C1 ELSE C2, Q) if (x>y) then z = x = else z=y  Example Q: z >= x /\ z >= y x>y => WP(z=x, z >= x /\ z >= y) eq x>y => x >= x /\ x >= y x<=y => WP(z=y, z >= x /\ z >= y) eq x<=y => y >= x /\ y >= y

Trace inclusion  Implementation model  Java Classes  DFA  Specification model  Interfaces  NFA

Trace inclusion  Implementation model  trace  traces  Specification model

Trace inclusion  Implementation model  trace  traces  Specification model

Trace inclusion  Implementation model  trace  traces  Specification model  Trace Inclusion

Formal verification: Trace inclusion

Formal verification: Trace inclusion

Formal verification: Trace inclusion

Formal verification: Trace inclusion  Implementation model  Specification model  Trace Inclusion  Contract verification  Then

Formal verification: Trace inclusion   Relation

Formal verification: Trace inclusion   Relation  Trace Inclusion  Contract verification  Property transfer

Formal verification: Trace inclusion   Relation  Trace Inclusion  Contract verification  Property transfer

Formal verification: simulation   Relation  Trace Inclusion 

Formal verification: express secrecy  K1 and K2 are secret variables (e.g. keys) int F (P1) { P2 := K1; }  P1 and P2 are public variables  The attacker can invoke the function F  F should not leak the value of Ks

Formal verification: express secrecy  K1 and K2 are secret variables (e.g. keys) int F (P1) { P2 := K1; }  P1 and P2 are public variables  The attacker can invoke the function F  F should not leak the value of Ks

Formal verification: express secrecy  K1 and K2 are secret variables (e.g. keys) int F (P1) { P2 := P1; }  P1 and P2 are public variables  The attacker can invoke the function F  F should not leak the value of Ks

Formal verification: express secrecy  K1 and K2 are secret variables (e.g. keys) int F (P1) { P2 := P1+K1; }  P1 and P2 are public variables  The attacker can invoke the function F  F should not leak the value of Ks

Formal verification: express secrecy  K1 and K2 are secret variables (e.g. keys) int F (P1) { if (K1 < 10) P2 := P1;  P1 and P2 are public variables }  The attacker can invoke the function F  F should not leak the value of Ks

Formal verification: express secrecy  K1 and K2 are secret variables (e.g. keys) int F (P1) { if (P1 < 10) P2 := P1;  P1 and P2 are public variables K2 := K1 + P1; }  The attacker can invoke the function F  F should not leak the value of Ks

Information flow security  K1 and K2 are secret variables (e.g. keys)  P1 and P2 are public variables

Information flow security: refinement

Information flow security: refinement 

Information flow security: refinement 

Information flow security: refinement 

Information flow security: refinement int S() { P := RND()*2; } P:2 P:1 P:4 K:0 P:0 P:2 P:1 P:4 K:1 P:0

Information flow security: refinement int I() { int S() { P := K*2; P := RND()*2; } } P:2 P:1 P:4 K:0 P:0 P:2 P:1 P:4 K:1 P:0

Information flow security: refinement int I() { int S() { P := K*2; P := RND()*2; } } P:2 P:2 P:1 P:1 P:4 K:0 P:0 P:4 K:0 P:0 P:2 P:1 P:4 K:1 P:0

Information flow security: refinement int I() { int S() { P := K*2; P := RND()*2; } } P:2 P:2 P:1 P:1 P:4 K:0 P:0 P:4 K:0 P:0 P:2 P:2 P:1 P:1 P:4 K:1 P:0 P:4 K:1 P:0

Information flow security: refinement 

Formal verification: bisimulation   Relation  Trace Inclusion 

Theorem prover Fully automated (propositional logic)  Automated, but not necessarily terminating (first order logic)  With automation, but mainly interactive (higher-order logic)  Isabelle  HOL4 

Isabelle/HOL4 A generic interactive proof assistant  Interactive:  more than just yes/no, you can interactively guide the system  Proof assistant:  helps to explore, find, and maintain proofs  Widely used systems, Active development, Reasonably easy to use  Internal Logic and object logic (HOL) 

Summary Motivations ● Refinements ● Information flow security ● Upcoming ● Formal models of CPUs • High level proof •

THANKS! Any questions? You can find me at robertog@kth.se http://prosper.sics.se/ References