1 / 26

Secure Information Flow for Reactive Programming Paradigm

Secure Information Flow for Reactive Programming Paradigm. Zhengqin Luo Zhengqin.luo@sophia.inria.fr. What is this talk about?. Secure information flow problem Programs can access confidential information Some of programs’ behaviors are publicly observation Reactive Programming Paradigm

arlo
Download Presentation

Secure Information Flow for Reactive Programming Paradigm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure Information Flow for Reactive Programming Paradigm Zhengqin Luo Zhengqin.luo@sophia.inria.fr SAFA workshop 2009

  2. What is this talk about? • Secure information flow problem • Programs can access confidential information • Some of programs’ behaviors are publicly observation • Reactive Programming Paradigm • Deterministic concurrency, cooperative scheduling • Synchronized threads, signals, suspensions, preemptions • Controlling information flow for reactive programs • How information can be deliberately leaked? • How to prevent insecure flows? • Dynamic and static enforcement SAFA workshop 2009

  3. Secure information flow problem • Programs interact with confidential information • Non-interference property • Inputs/outputs are classified by secret and public • Differs in secret inputs SHOULD NOT result in different public output • A simplified lattice model: L (public), H (secret) Credit card No., price Auction.com P Other cookies Steal-your-informaion.com Secret Secret P Public Public SAFA workshop 2009

  4. Typical insecure programs • High-order imperative ML notion • uL is public; vH is confidential • Direct flow uL:=!vH • Indirect flow If !vH then uL:=0 else uL:=1 • Indirect flow with thread creation If !vH then (thread (uL:=0)) else (thread (uL:=1)) • Caution! Carefully check your programs! SAFA workshop 2009

  5. Reactive Programming Paradigm - Informal • Based on high-order imperative ML • An reactive machine contains • Environment ξ : a set of emitted signals • Thread pool : <t1||…||ti||…||tn> • Reactive construct • (emit s) • (when s do N) - suspension • (watch s do N) - preemption • Cooperative scheduling (deterministic) • For example: a round-robin one • Computations are divided by instants SAFA workshop 2009

  6. Reactive Programming Paradigm - Informal < t1||t2||t3, Ø > Suspension: t1’ is waiting for some signal s, which is not in ξ1 , (when s do M) * < t1’||t2||t3, ξ1 > A cooperative round-robin scheduler Instant 1 < t1’||t2||t3, ξ1 > All threads are suspended * < t1’’||t2’||t3’, ξ2 > Instant transition: perform preemption t=(watch s do M) => t=() , if s is in ξ2 Reset signal environment < t1’’’||t2’’||t3’’, Ø > Instant 2 < T’, ξ’ > * < T’’, ξ’’> SAFA workshop 2009

  7. Insecure examples (1/2) – suspension • T1: If !h then (emit s) else (); when s do (l:=1) • T2: l:=2 ; emit s • h= true in the initial memory T1 || T2 , Ø → when s do (l:=1) || l:=2 ; emit s , {s} → when s do () || l:=2 ; emit s , {s} (l:=1) → () || l:=2 ; emit s , {s} → () || l:=2 ; emit s , {s} → () || emit s , {s} (l:=2) → () || (), {s} SAFA workshop 2009

  8. Insecure examples (1/2) – suspension • T1: If !h then (emit s) else (); when s do (l:=1) • T2: l:=2 ; emit s • h= false in the initial memory T1 || T2 , Ø → when s do (l:=1) || l:=2 ; emit s , Ø → when s do (l:=1) || l:=2 ; emit s , Ø → when s do (l:=1) || emit s ,Ø (l:=2) → when s do (l:=1) || () , {s} → when s do (l:=1) || () , {s} → when s do () || () , {s} (l:=1) → () || () , {s} SAFA workshop 2009

  9. Insecure examples (1/2) – suspension • T1: If !h then (emit s) else (); when s do (l:=1) • T2: l:=2 ; emit s • T1 || T2 is not secure by non-interference • Key observation • Signals carry information • Testing signals gets information • Suspension may change the order of observable actions SAFA workshop 2009

  10. Insecure programs (2/2) – preemption • T1: (watch s do (when t do (l:=1))) • T2: l:=2; if !h then (emit s) else (); pause; emit t • h=false in the initial memory T1 || T2 , Ø →T1 || T2 , Ø →T1 || if !h then (emit s) else (); pause; emit t , Ø (l:=2) → (watch s do (when t do (l:=1))) || pause; emit t, Ø → (watch s do (when t do (l:=1))) || () ; emit t , Ø → (watch s do (when t do (l:=1))) || () , {t} → (watch s do (when t do ())) || () , {t} (l:=1) → () || () , {t} SAFA workshop 2009

  11. Insecure programs (2/2) – preemption • T1: (watch s do (when t do (l:=1))) • T2: l:=2; if !h then (emit s) else (); pause; emit t • h=true in the initial memory T1 || T2 , Ø →T1 || T2 , Ø →T1 || if !h then (emit s) else (); pause; emit t , Ø (l:=2) → (watch s do (when t do (l:=1))) || pause; emit t, {s} → () || () ; emit t , Ø → () || () , {t} SAFA workshop 2009

  12. Insecure programs (2/2) – preemption • T1: (watch s do (when t do (l:=1))) • T2: l:=2; if !h then (emit s) else (); pause; emit • T1 || T2 is not secure by non-interference • Key observation • Preemption may change whether an observable actions is executed or not SAFA workshop 2009

  13. Our solution • Consider signal environment as part of the inputs/outputs (memory) • s= true <=> s is emitted • Classify signals with security level • sL, sH, tL, tH… • Then some of the programs should be rejected • if !xH then (emit sL) else (emit tL) • when sH do xL:=1; • watch sH do (…(xL:=1)...) • IS THAT ALL? SAFA workshop 2009

  14. Our solutions – more subtle case • Recall the insecure suspension example • T1: If !h then (emit s) else (); when s do (l:=1) • T2: l:=2 ; emit s • An slightly modified version • T1: If !h then (emit s) else (); when s do (); l:=1 • T2: l:=2 ; emit s • Observation: suspension construct will not only possible to reorder its body, but also all the computation afterward. • We should also reject • (when sH do …);…;xL:=1; SAFA workshop 2009

  15. Secure Information flow as a safety property • Non-interference, bisimulation • Comparing two execution of programs, a non-stand property • Intuitive notion of secure information flow • “one should not put in a public location a value elaborated using confidential information” ,[DD77] • A monitoring semantics • Keep track of the level of information gained along the computation • Run-time error: trying to assign to public location when the level recorded is more confidential • Secure information as a safety property [Bou08] • No such error occurs! SAFA workshop 2009

  16. A monitoring semantics • We extend the standard semantics with dynamic checks for insecure information flow • To keep track of information, each thread are extend by two variables (independent for each thread) t=(pc,cur,M) where • pc,cur ∈{L,H} • pc stands for the level of information that will affect the functional and imperative behavior of the thread • cur stands for the level of information that will affect the reactive behavior of the thread SAFA workshop 2009

  17. How pc is manipulated - example • The same as in [Bou08] • Example: • (L ,L , (if !xH then yH:= 1 else ()); zL:=1) • → (L ,L , (if !xH then yH:= 1 else ()); (zL:=1)L) • → (H,L , (if tt then yH:= 1 else ()); (zL:=1)L) • → (H,L , (yH:= 1); (zL:=1)L) • → (H,L , (); (zL:=1)L) • → (L,L , zL:=1) • Similar cases for other constructs pc is increased pc is transmitted Security check happens here, if it is (yL:=1), the check will fail pc is forgotten SAFA workshop 2009

  18. How cur is manipulated • Testing a signal by when (the case by watch is similar) • (pc,cur,whensl do N) →(pc,pc\/cur\/l, when <sl> do N) • Why pc is added to cur? • Examples: • (L, L, if !xHthen (when sL do N) else (when tL do N)) • →(H, L, if ttthen (when sL do N) else (when tL do N)) • →(H, L, (when sL do N) ) • →(H, H, (when <sL> do N) ) • But cur is never forgotten! • Compare (when s do N) and (when s do ());N • They have essentially the same effect to reorder instructions in case of suspension. SAFA workshop 2009

  19. Is the monitoring secure enough? • Consider this example: • If uH then when sH do () else (); !xL() || xL := λ_.(); emit sL • where xL = λ_.(yL:=1) , and yL:=0 initially • It is safe by the monitoring semantics • If uH then when sH do () else (); !xL() || xL := λ_.(); emit sL • Why is that? • Monitoring only learns information in one branch of conditional constructs. ① ② ⑤ ③ ④ ① ② ③ ④ ⑤ SAFA workshop 2009

  20. A type directed translation • An special programming construct (P M) for the target language • In the standard semantics • M->M’ => (P M) →(P M’) • (P V) → V • In the monitoring semantics • (pc,cur,(P V)) →(pc,pc\/cur, V) SAFA workshop 2009

  21. A type directed translation • How does the translation work? • Suppose we have (if !h then M else N) • and M will suspend while N will not • The translation is • (if !h then M else (P N)) • The subtle example again • Remember (pc,cur,(P V)) →(pc,pc\/cur, V) • If uH then when sH do () else (P ()); !xL() || xL := λ_.(); emit sL ① ② ⑤ ③ ④ ① ② ③ SAFA workshop 2009

  22. A particular reactive programming • High-order imperative language with reactive construct • An reactive machine is M=[μ,ξ,t,T] • μ is the store, ξ is the signal environment • t=(i,M) is the current running thread • T is the thread pool • M,N ::= V | (if M then N else N’) | (MN) | (M;N) |(ref M) | (!M) | (M:=N) | (thread M) | (sig) | (emit M) | | (when M do N) | (watch M do N) • V ::= λxM | sl| ul | tt | ff | () SAFA workshop 2009

  23. Security enforced by dynamic monitoring • Definition: Progress-insensitive security [SR09] • A symmetric relation R on reactive machines • M1=[μ1,ξ1,t1,T1] R M2=[μ2,ξ2,t2,T2] ， iff • 1) μ1=Lμ2,ξ1=Lξ2 • 2)if M1 → M’1 , either there exists M2 →* M’2 ,such that M’1 R M’2 • or for all M’2 =[μ’2,ξ’2,t’2,T’2] such that M2 →* M’2 , μ’2=Lμ’2,ξ’1=Lξ’2 • Definition: Safe programs • Does not run into security error in monitoring semantics • Our results (informal) • Theorem: For every programs M that its translation M’ is safe, then for every μ1=Lμ2,ξ1=Lξ2, we have [μ1,ξ1,(0,M’), Ø] R [μ2,ξ2, (0,M’), Ø] SAFA workshop 2009

  24. A type and effect system for safety • We also designed a type and effect system for a sound analysis of safety property • A fairly standard one extend the one for high-order language • Our results • Lemma: If a program is typable then its translation is safe • Lemma: The semantics of typable program is almost identical to its translation in the monitoring semantics • Theorem: Typable programs itself satisfy progress-insensitive security. SAFA workshop 2009

  25. Conclusion • Controlling information flow in reactive programs • Dynamically checking information – A monitoring semantics • Does not imply any security property • A simple type-directed translation • If translated program is safe, then it satisfy progress-insensitive security • A type safety result • Type-checked program => no need for monitoring SAFA workshop 2009

  26. Thank you! • Q & A SAFA workshop 2009

More Related