View
21
Download
0
Category
Tags:
Preview:
DESCRIPTION
Information Flow Static Analysis. Foundational Checker. Evidence. SMT Solver. SMT result checker. A Certificate Infrastructure for Machine-Checked Proofs of Conditional Information Flow. Torben Amtoft K , Josiah Dodds P , Zhi Zhang K , Andrew Appel P , - PowerPoint PPT Presentation
Citation preview
A Certificate Infrastructure for Machine-Checked Proofs of Conditional Information Flow
Torben AmtoftK, Josiah DoddsP, Zhi ZhangK, Andrew AppelP,Lennart BeringerP, John HatcliffK, Xinming OuK, Andrew CousinoK
K = Kansas State University P = Princeton University
Information Flow Static Analysis
SMT Solver
Foundational Checker
SMT result checker
Evidence
2
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X[3]:=Y{}
Advanced rules for agreement
logic
{}X:=Y{}
Formally Verified agreement logic
analysis
3
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X[3]:=Y{}
Advanced rules for agreement
logic
{}X:=Y{}
Formally Verified agreement logic
analysis
\{π β \}X :=Y \{ π β \}Agreement Logic
Amtoft, T., Banerjee, A.: Information flow analysis in logical form. In Giacobazzi, R., ed.:SAS 2004. Volume 3148 of LNCS., Springer (2004) 100β115
4
Agreement Logic
means x has the same value when evaluated in and
ProgramProgram{xβ}{y \} βπ§1 π§ 2π¦ 1π¦ 2
π₯1 π₯2
π¦ 1
π₯2
Proof!
5
#derives x from y
6
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X[3]:=Y{}
Advanced rules for agreement
logic
{}X:=Y{}
Formally Verified agreement logic
analysis
SPARK annotations
#derives x from y
Chapman, R., Hilton, A.: Enforcing security and safety models with an information flowanalysis tool. ACM SIGAda Ada Letters XXIV (2004) 39β46
7
SPARK annotations
The SPARK programming language has annotations for information flow
The annotation #derives x from y means that only information from y might flow into x
SPARK has a static analysis to check this type of contract
These annotations are not always as expressive as programmers want
8
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X[3]:=Y{}
Advanced rules for agreement
logic
{}X:=Y{}
Formally Verified agreement logic
analysis
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
{}X[3]:=Y{}
Advanced rules for agreement
logic
Amtoft, T., Hatcliff, J., Rodriguez, E.: Precise and automated contract-based reasoning forverification and certification of information flow properties of programs with arrays. InGordon, A.D., ed.: ESOPβ10. Volume 6012 of LNCS. (2010) 43β63
9
Hoare-Style rules for agreement logic
inspired by SPARK annotations
verifies #derives x from y on the program
10
Advanced rules for conditional information flow
More expressive rules
Rules for reasoning about specific array locations, rather than entire arrays at once
11
Without conditional rules
More expressive rules
Rules for reasoning about specific array locations, rather than entire arrays at once
12
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X[3]:=Y{}
Advanced rules for agreement
logic
{}X:=Y{}
Formally Verified agreement logic
analysis
Formally verified static
analysis
Leroy, X. 2003. Java bytecode verification: Algorithms and formalizations. Journal of Automated Reasoning 30, 235β269.
A.W. Appel. VeriSmall: Verified Smallfoot shape analysis. CPP 2011: First International Conference on Certified Programs and Proofs, (2011).
Leroy, X.: Formal certification of a compiler back-end or: programming a compiler with aproof assistant. POPLβ06. (2006) 42β54
Y. Bertot. A Coq formalization of a type checker for object initialization in theJava virtual machine. CAV'01.
D. Aspinall, L. Beringer, M. Hofmann, H.-W. Loidl, and A. Momigliano. A programlogic for resource verification. TPHOLs 2004, volume 3223 ofLNCS, pages 34β49. Springer, 2004.
13
ProofProof
Formally verified static analysisMany single-execution analyses
Formalizing the verifications require formalizing type-systems, operational semantics, and source languages
Soundness relates analyzer to operational semantics
Static Analysis Static AnalysisorWitness
Verified Results
Verified Results
14
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X[3]:=Y{}
Advanced rules for agreement
logic
{}X:=Y{}
Formally Verified agreement logic
analysis
Static analysis for conditional
information flow
15
πβAgreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X:=Y{}
Hoare-Style rules for
agreement logic
{}X:=Y{}
Formally Verified agreement logic
analysis
16
Contributions
Implemented a static analysis with advanced rules for conditional information flow
Analysis generates witnesses to be formally verified in Coq
If the witness verifies, the result of the analysis is correct with respect to the operational semantics
17
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X[3]:=Y{}
Advanced rules for agreement
logic
{}X:=Y{}
Formally Verified agreement logic
analysis
18
\{π β \}X :=Y \{ π β \}Agreement Logic
SPARK annotations
#derives x from y
Formally verified static
analysis{}X[3]:=Y{}
Advanced rules for agreement
logic
{}X:=Y{}
Formally Verified agreement logic
analysis
19
Information Flow Static Analysis
SMT Solver
Foundational Checker
SMT result checker
Evidence
Michael Armand, Germain Faure, Benjamin Gregoire, Chantal Keller, Laurent ThΓery & Benjamin Werner (2011): Verifying SAT and SMT in Coq for a fully automated decision procedure. In: PSATTT β11
20
Example Application Program
21
Mailbox Example
if IN_1_RDY and not OUT_0_RDY then
DATA_1 := IN_1 DAT;
IN_1_RDY := false;
OUT_0_DAT := DATA_1;
OUT_0_RDY := true;
end if;
22
Mailbox Example{IN_1_RDY OUT_0_RDY IN_1_DAT β IN_1_RDY OUT_0_RDY OUT_0_DAT β IN_1_RDY OUT_0_RDY }β βif IN_1_RDY and not OUT_0_RDY then
{IN_1_DAT }βDATA_1 := IN_1 DAT;{DATA_1 }βIN_1_RDY := false;{DATA_1 }βOUT_0_DAT := DATA_1;{OUT_0_DAT }βOUT_0_RDY := true;{OUT_0_DAT }β
end if;{OUT_0_DAT }β
23
2-Assertions
β¦πΈ β§π1=β¦πΈ β§S2π1 ,π2β¨Eβ
24
2-Assertions
β¦πΈ β§π1=β¦πΈ β§S2π1 ,π2β¨Eβ
25
2-Assertions
β¦πΈ β§π1=β¦πΈ β§S2π1 ,π2β¨Eβ
26
2-Assertions
Β¬( β¦πΈ β§ΒΏΒΏπ1β¨ β¦πΈ β§S2)β¨ β¦πΈ β§π1= β¦πΈ β§S 2π1 ,π2β¨ΟβEβ ΒΏ
27
2-Assertions
(Β¬ β¦π β§ΒΏΒΏπ1β¨Β¬ β¦π β§S 2)β¨ β¦πΈ β§π1= β¦πΈ β§S 2
π1 ,π2β¨ΟβEβ ΒΏ
28
Triples
Holds when
29
Hoare TripleFixpoint validHoareTriple (X: list SkalVar) C (asns: assns):= match asns with | Assns => (forall, lookupsComplete X -> (twoAssnsInterpretation ) -> Opsem C -> Opsem C -> (twoAssnsInterpretation )) | β¦
30
(twoAssnsInterpretation ) ->Opsem C -> Opsem C ->(twoAssnsInterpretation ))
31
Evidence
Evidence takes the form
If is well typed and the evidence statements are sound wrt. the operational semantics of our language we have a valid triple. Each form of evidence corresponds directly to a coq constructor.
32
Rulesβ
β’ AssignE (Ξ , π₯ , π΄ ):{Ξ [ π΄π₯ ]}π₯βπ΄ {Ξ }
ββ’ AssertE (π΅ ) : {π΅βΞ }Assert (π΅) {Ξ }
ββ’Skip E (Ξ ) : {Ξ }Skip {Ξ }
33
Conditional ruleβ’π1 : {Ξ1 }πΆ1 {π β²βπΈβ }β’π2: {Ξ2 }πΆ2 {π β²βπΈ β }β’π :ππΆ
β
πββ²
β’CondE (π1 ,π2 ,π ,π΅ ) : {π΅βΞ1β§ (Β¬π΅βΞ2 )β§ (πβ π΅ β ) }πΆ {π β²βπΈ β }
Evidence exists for the triple if
Evidence exists for both branches of We have Necessary Precondition (NPC) evidence for and across
34
Coq Evidence Type
Evidence is an inductive proposition:
Inductive TEvid (X: list SkalVar) : Command -> assns -> Prop :=| TSkipE ...| TAAssignE ...| TCondE ......
35
Coq Evidence Type
| TAAssignE : forall Theta x A, TEvid X (Assign x (AExp A)) (Assns(TwoAssnsSubstA Theta x A) Theta)
β
β’ AssignE (Ξ , π₯ , π΄ ):{Ξ [ π΄π₯ ]}π₯βπ΄ {Ξ }
36
Evidence Soundness
(
)
37
Soundness StatementTheorem soundness : forall X {C asns}, TEvid X C asns -> (validHoareTriple X C asns)
Paper proof is done. Coq proof is complete for all but the loop rules WhileE and ForPolyE
38
Precondition Generator in Coq
Evidence is large
Move from generating a witness to implementing algorithm
ProofProof
38
Static Analysis Static AnalysisorWitness
Verified Results
Verified Results
39
Future Work
Complete Coq proofs
Verify SMT results
Finish Coq precondition generator
Hook up to a certified compiler for an end-to-end system
Evaluate the tool on more real-world examples
40
Questions
Assignment Rule
Example
{y#}x:=y{x#}
β
β’ AssignE (π ,π₯ , π΄) :{π [ π΄π₯ ]}π₯βπ΄ {π }
Post-condition form
The post-condition of some rules takes the form
Post-conditions of this form specify the information-flow properties we are interested in
Post-condition form
Our algorithm generates triples of the form
The values of might flow into variable when the respective hold
We do this for each modified in C
Conditional
Conditional Example{secure#, secure => low#, !secure => hi#}if secure then {low} hi := lowelse {hi#} low := hifi{low#}
Checking the Evidence
We said earlier that is a proof that we have generated a valid triple if is typed correctly and if our evidence is proven sound.
To actually verify this we define evidence as a coq type and prove it sound with respect to the defined operational semantics
Coq Evidence
We use a deep embedding of the logic and programming language
The operational semantics of our core language are defined in coq
Two assertions ()
Inductive twoSatisfies(s1 s2:State): TwoAssn -> Prop :=|TwoSatisfies: forall B E, BEval B s1 = Some true ->BEval B s2 = Some true -> (Eval E s1 = Eval E s2) -> twoSatisfies s1 s2 (B, E).
Precondition Generator in CoqFixpoint generatePrecondition
(c:Command) (post:TwoAssns) (X: list SkalVar): (TwoAssns * list SkalVar) := ...
Theorem generatePreconditionEvidence: forall C Y X Z post pre, (pre, X)=generatePrecondition C post Z ->
allVarsIn X Y = true-> TEvid Y C (Assns pre post).
Conclusions
Fully automated and formally verified information flow contract checker
Piece of an eventual end-to-end system
β¦
End
Semanticsπβ¨π΅β β¦ π΅ β§π=π‘ππ’π
π1 ,π2β¨Β¬π1β¨π1 ,π2 ,β¨π 2
π1 ,π2β¨π 1βπ2
π1β¨π΅π2β¨π΅π1 ,π2β¨π΅
β¦π΅ β§π1= β¦π΅ β§S2
π1 ,π2β¨π΅β
Previous work
SIFL precondition algorithm to check conditional information flow policies
Algorithm uses an agreement logic with hoare-style rules
Allows for precise treatment of arrays and for loops
Recommended