Secure Information Flow for Reactive Programming Paradigm

1
Secure Information Flow for Reactive Programming
Paradigm

• Zhengqin Luo
• Zhengqin.luo_at_sophia.inria.fr

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

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
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!

5
Reactive Programming Paradigm - Informal

• Based on high-order imperative ML
• An reactive machine contains
• Environment ? a set of emitted signals
• Thread pool ltt1titngt
• 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

6
Reactive Programming Paradigm - Informal
lt t1t2t3, Ø gt
Suspension t1 is waiting for some signal s,
which is not in ?1 , (when s do M)

lt t1t2t3, ?1 gt
A cooperative round-robin scheduler
Instant 1
lt t1t2t3, ?1 gt
All threads are suspended

lt t1t2t3, ?2 gt
Instant transition perform preemption
t(watch s do M) gt t() , if s is in ?2
Reset signal environment
lt t1t2t3, Ø gt
lt T, ? gt

Instant 2
lt T, ?gt
7
Insecure examples (1/2) suspension

• T1 If !h then (emit s) else () when s
  do (l1)
• T2 l2 emit s
• h true in the initial memory
• T1 T2 , Ø
• ? when s do (l1) l2 emit s , s
• ? when s do () l2 emit s , s (l1)
• ? () l2 emit s , s
• ? () l2 emit s , s
• ? () emit s , s (l2)
• ? () (), s

8
Insecure examples (1/2) suspension

• T1 If !h then (emit s) else () when s
  do (l1)
• T2 l2 emit s
• h false in the initial memory
• T1 T2 , Ø
• ? when s do (l1) l2 emit s , Ø
• ? when s do (l1) l2 emit s , Ø
• ? when s do (l1) emit s , Ø (l2)
• ? when s do (l1) () , s
• ? when s do (l1) () , s
• ? when s do () () , s (l1)
• ? () () , s

9
Insecure examples (1/2) suspension

• T1 If !h then (emit s) else () when s
  do (l1)
• T2 l2 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

10
Insecure programs (2/2) preemption

• T1 (watch s do (when t do (l1)))
• T2 l2 if !h then (emit s) else () pause
  emit t
• hfalse in the initial memory
• T1 T2 , Ø
• ?T1 T2 , Ø
• ?T1 if !h then (emit s) else () pause emit
  t , Ø (l2)
• ? (watch s do (when t do (l1))) pause emit
  t, Ø
• ? (watch s do (when t do (l1))) () emit t
  , Ø
• ? (watch s do (when t do (l1))) () , t
• ? (watch s do (when t do ())) () , t
  (l1)
• ? () () , t

11
Insecure programs (2/2) preemption

• T1 (watch s do (when t do (l1)))
• T2 l2 if !h then (emit s) else () pause
  emit t
• htrue in the initial memory
• T1 T2 , Ø
• ?T1 T2 , Ø
• ?T1 if !h then (emit s) else () pause emit
  t , Ø (l2)
• ? (watch s do (when t do (l1))) pause emit
  t, s
• ? () () emit t , Ø
• ? () () , t

12
Insecure programs (2/2) preemption

• T1 (watch s do (when t do (l1)))
• T2 l2 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

13
Our solution

• Consider signal environment as part of the
  inputs/outputs (memory)
• s true ltgt 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 xL1
• watch sH do ((xL1)...)
• IS THAT ALL?

14
Our solutions more subtle case

• Recall the insecure suspension example
• T1 If !h then (emit s) else () when s
  do (l1)
• T2 l2 emit s
• An slightly modified version
• T1 If !h then (emit s) else () when s
  do () l1
• T2 l2 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 )xL1

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!

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

17
How pc is manipulated - example

• The same as in Bou08
• Example
• (L ,L , (if !xH then yH 1 else ()) zL1)
• ? (L ,L , (if !xH then yH 1 else ()) (zL1)L)
• ? (H,L , (if tt then yH 1 else ()) (zL1)L)
• ? (H,L , (yH 1) (zL1)L)
• ? (H,L , () (zL1)L)
• ? (L,L , zL1)
• Similar cases for other constructs

pc is increased
pc is transmitted
Security check happens here, if it is (yL1),
the check will fail
pc is forgotten
18
How cur is manipulated

• Testing a signal by when (the case by watch is
  similar)
• (pc,cur,when sl do N) ?(pc,pc\/cur\/l, when ltslgt
  do N)
• Why pc is added to cur?
• Examples
• (L, L, if !xH then (when sL do N) else (when
  tL do N))
• ?(H, L, if tt then (when sL do N) else (when tL
  do N))
• ?(H, L, (when sL do N) )
• ?(H, H, (when ltsLgt 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.

19
Is the monitoring secure enough?

• Consider this example
• If uH then when sH do () else () !xL() xL
  ?_.() emit sL
• where xL ?_.(yL1) , and yL0 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.

?
?
?
?
?
?
?
?
?
?
20
A type directed translation

• An special programming construct (P M) for the
  target language
• In the standard semantics
• M-gtM gt (P M) ?(P M)
• (P V) ? V
• In the monitoring semantics
• (pc,cur,(P V)) ?(pc,pc\/cur, V)

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

?
?
?
?
?
?
?
?
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) (MN)
  (ref M)
• (!M) (MN) (thread M)
  (sig) (emit M)
• (when M do N) (watch M do N)
• V ?xM sl ul tt ff ()

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) µ1Lµ2, ?1L?2
• 2) if M1 ? M1 , either there exists M2 ? M2
  ,such that M1 R M2
• or for all M2 µ2,?2,t2,T2 such that
  M2 ? M2 , µ2Lµ2, ?1L?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 µ1Lµ2,
  ?1L?2, we have µ1,?1,(0,M), Ø R µ2,?2,
  (0,M), Ø

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.

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 gt no need for monitoring

26

• Thank you!
• Q A