Presentation is loading. Please wait.

Presentation is loading. Please wait.

Proving Computational Security of C Programs using VCC (and F7) FCC/ASA Harvard University - 28 th June 2012 F. Dupressoir (Open University & MSRC) C.

Similar presentations


Presentation on theme: "Proving Computational Security of C Programs using VCC (and F7) FCC/ASA Harvard University - 28 th June 2012 F. Dupressoir (Open University & MSRC) C."— Presentation transcript:

1 Proving Computational Security of C Programs using VCC (and F7) FCC/ASA Harvard University - 28 th June 2012 F. Dupressoir (Open University & MSRC) C. Fournet (MSRC) A. Gordon (MSRC & University of Edinburgh)

2 Cryptographic Code in C The security of much critical infrastructure depends in part on crypto code in C, yet vulnerabilities continue to be found. Designers starting to appreciate reference implementations – eg, TCG: “It has taken years to achieve good TPM interoperability”, need for “more precise language for describing TPM data structures and behaviors” – New TPM standard will come with a reference implementation in C

3 Prior Tools for Cryptographic Code ToolPaperLang.Symbolic/Computational CSurGoubault-Larrecq & Parennes, 2005CSymbolic FS2PV/CVBhargavan et al., 2005/2008F#Symbolic/Computational PistachioUdrea et al., 2006C - (compliance, unsound) F7Bhargavan et al., 2008F#Symbolic AspierChaki & Datta, 2009CSymbolic F7+CoSPBackes et al., 2010F#Computationally Sound CSec-ModexAizatulin et al., 2011CComputationally Sound (1-path) F7Fournet et al., 2011F#Computational VCCDupressoir et al., 2011CSymbolic (protocols) VCCPolikarpova & Moskal, 2012CSymbolic (stateful devices) Küsters et al., 2012Java-Computational Csec-ModexAizatulin et al., 2012 (draft)CComputational (1-path) Also, [O’Shea], [Pironti, Sisto et al.], [Backes, Hritcu et al.], [Jürjens et al.]…

4 THE DEVICE Create( ) = 0001 Create( ) = 0002 Export(02) = Export(01) = FE Create( ) = FF Encrypt(01 16 ) = 00 ( ) Unload(01) = 00 ( ) Clear(01) = 00 Create( ) = 0001 Decrypt(01 ( ) ) = FB Clear(03) = 00 Load( ( ) ) = 0003 Decrypt(03 ( ) ) = 00 16

5 The Device Buffer to write in parameters and read out results Create: template → handle – Uses a KDF Import: template * bytes → handle Export: handle → template * key Clear: handle → unit Unload: handle → bytes – Uses Encrypt-then-MAC Load: bytes → handle Encrypt/Decrypt: handle * bytes → bytes Internal State Slot 0 Template Key Slot N Template Key Primary SeedRoot Storage Key Slot i Template Key Input/Output Buffer …

6 Security

7 THE METHOD

8 Challenges Probabilistic C Programs – Tool usability, maintaining probabilistic features – Probabilistic VS under-specified behaviours Equivalence-Based Properties in C – F7: perfect secrecy approximated by parametricity – C: memory reused without being cleared Clear sets a bit to 0, but may not overwrite the slot Slots shared by sensitive and public objects with variable size – Fine-grained information-flow is hard for C Stack pointer may depend on secret Unspecified behaviours…

9 Total Functional Correctness and Specification Security VCC can prove functional correctness – Soundly deals with unspecified behaviours – Can prove termination F7 can prove computational security VCC and F7 have a coinciding core: – Pure inductive VCC specifications – First-order deterministic F7 expressions Probabilistic F7 modelled by derandomizing

10 The Method in a Picture Ideal F# Implementation Concrete F# Implementation Concrete C Implementation Ideal C Implementation F7 game-hopping VCC annotations Language Reference (Pure) System (Imperative) Cryptography ConcreteIdeal VCC annotations

11 Going Through the Steps Ideal F# Implementation Concrete F# Implementation F7 game-hopping

12 Going Through the Steps Concrete F# Implementation Concrete C Implementation VCC annotations

13 Going Through the Steps Ideal F# Implementation Ideal C Implementation VCC annotations Do the same on the other side Same contracts can be used: – VCC gives function-level abstraction – A single run of VCC proves both vertical sides of the square On observation functions – At adversary interface, capture everything the adversary can do – Internally, can be very vague: any unspecified behaviour causes verification failure at some level if it flows into the final output

14 Going Through the Steps Ideal F# Implementation Concrete F# Implementation Concrete C Implementation Ideal C Implementation F7 game-hopping VCC annotations

15 SIMULATION AS A CONTRACT Defining and Proving

16 Assumptions Assume existence of reference KDF void _(assume_correct) KDF(BYTE* t, UINT8 t_len, _(ghost \template tmpl) BYTE* s, UINT8 s_len, _(ghost \seed seed) BYTE* buf, UINT8* buf_len _(ghost out \key key)) _(decreases 0) // Termination _(maintains \thread_local_array(t, t_len)) // Memory Safety _(maintains \thread_local_array(s, s_len)) // Memory Safety _(ensures \mutable_array(buf, *buf_len)) // Memory Safety _(writes \array_range(buf,(size_t) keylength(tmpl)), buf_len) // Writes the buffer and the length // Simulation on inputs _(requires observeState(state) == refState) _(requires from_array(t,t_len) == tmpl && from_array(s, s_len) == seedRepr(seed)) // Simulation on outputs _(ensures observeState(state) == refState) _(ensures from_array(buf,*buf_len) == keyRepr(tmpl,key)) _(ensures \old(KDF_R(refState,tmpl,seed)) == (refState,key)); _(abstract (\kdfState*\key) KDF_R(\kdfState S, \bytes t, \seed s)) In practice, slightly more verbose and distant from F7 Assume the C implementation is equivalent (up to some observation)

17 Theorems Write reference implementation in VCC _(def (\state*\iobuffer) Create_R((\state*\iobuffer) in) { switch (unmarshal_Create_IN_R(snd(in))) { case None(): return (fst(in), cons(RC_UNMARSHAL, substring(snd(in),1,IOBLEN - 1)) }; case Some(tmpl): Return res = Create_cmd_R(fst(in),tmpl); switch (res) { case Error(rc): return (fst(in), cons(rc,substring(snd(in),1,IOBLEN - 1))); case Success(S,h): return (S, cons(RC_SUCCESS,cons(h,substring(snd(in),2,IOBLEN - 2))); } } }) Prove the C implementation is equivalent (up to adversary observations) void Create(void) _(decreases 0) // Termination _(writes \array_range(IOB,IOBLEN)) // Writes clause _(ensures \mutable_array(IOB,IOBLEN)) // Memory-safety _(maintains observe(store) == store.S) // State simulation invariant // Output simulation _(ensures \old(Create_R(store.S,from_array(IOB,IOBLEN))) == (store.S, from_array(IOB,IOBLEN)));

18 Theorems Translate reference implementation from F7 let Create_R (S: state * buf: iobuffer): state * iobuffer = match (unmarshal_Create_IN_R(buf)) | None() -> (S, cons RC_UNMARSHAL (substring buf 1 (IOBLEN - 1))) | Some(tmpl) -> match Create_cmd_R S tmpl with | Error(rc) -> (S, cons rc (substring buf 1 (IOBLEN - 1))) | Success(S,h) -> (S, cons RC_SUCCESS (cons h (substring buf 2 (IOBLEN - 2)))) Prove the C implementation is equivalent (up to adversary observation) void Create(void) _(decreases 0) // Termination _(writes \array_range(IOB,IOBLEN)) // Writes clause _(ensures \mutable_array(IOB,IOBLEN)) // Memory-safety _(maintains observe(store) == store.S) // State simulation invariant // Output simulation _(ensures \old(Create_R(store.S,from_array(IOB,IOBLEN))) == (store.S, from_array(IOB,IOBLEN)));

19 Conclusion You can prove computational security of C programs using existing tools – And a lot of work: specification needs to be more formal than just the C code Improve C verification tools? – Add probabilities and relational contracts Politely ask for formal specifications?

20 Preliminary Conclusions on the TPM Need automation (F7 to VCC, memory safety) – Very tedious work, concerning generated code – Why not generate it from a formal description on which security can be proved? First convince ourselves that the proof would work: several important bugs found and fixed – Agile object loading allowed modifying public part Adaptability of proof to other implementation choices is not obvious – Minor subsystems (slot/context allocation): easy – General (1.2 compatibility): major changes in formal spec


Download ppt "Proving Computational Security of C Programs using VCC (and F7) FCC/ASA Harvard University - 28 th June 2012 F. Dupressoir (Open University & MSRC) C."

Similar presentations


Ads by Google