1. Security of Multithreaded Programs by Compilation Tamara Rezk INDES Project, INRIA Sophia Antipolis Mediterranee Joint work with Gilles Barthe, Alejandro Russo, Andrei Sabelfeld Torino, April 21 st Matyss COLOR Project

2. In this talk: Security of mobile code (proof carrying code) Verification of confidentiality in low level languages Connection between different type systems A modular approach to verification of multithreaded code and its connection to low level multithreaded code

3. In this talk: Security of mobile code (proof carrying code) Verification of confidentiality in low level languages Connection between different type systems A modular approach to verification of multithreaded code and its connection to low level multithreaded code

4. Proof Carrying Code scenarios PRODUCER SIDE CONSUMER SIDE

5. Mobile Code example: Java applets program PRODUCER SIDE CONSUMER SIDE

6. Mobile Code example: Java applets program PRODUCER SIDE CONSUMER SIDE NETWORK compiler security guarantees?

7. program PRODUCER SIDE CONSUMER SIDE NETWORK compiler iflow type inference difficult!

8. program PRODUCER SIDE CONSUMER SIDE NETWORK compiler iflow type inference difficult! accepted rejected iflow type checking easy

9. Proof Carrying Code program PRODUCER SIDE CONSUMER SIDE NETWORK compiler iflow type inference difficult! accepted rejected iflow type checking easy TCB

10. Motivation of this work Insecure flows in mobile code can be prevented by program analysis but Information flow for multithreaded low-level code has not been addressed so far

11. Contribution of this work We propose a framework to enforce security for multithreaded low-level programs and extends it for security-type preserving compilation

12. In this talk: Security of mobile code (proof carrying code) Verification of confidentiality in low level languages Connection between different type systems for iflow A modular approach to verification of multithreaded code and its connection to low level multithreaded code

13. Verification of iflow for low level code

14. High-level codeLow-level code

15. Verification of iflow for low level code High-level code Typing rules are syntax directed Low-level code Code is unstructured. Typing rules are not based on structure of the syntax

16. Verification of iflow for low level code High-level code Typing rules are syntax directed Memory model includes a store Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack

17. Verification of iflow for low level code High-level code Typing rules are syntax directed Memory model includes a store Typability: given by the typing rule of sequential composition Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack Typability : composition is given by the successor relation between program points

18. 18 Tracking information flow via control flow in high-level languages is syntax-directed: Control dependence regions are given by control structure if (y==0) then x :=3; else x:=1; Control dependence region includes program points x:=3; and x:=1 (dependent on expression y==0) Verification of iflow for low level code

19. |- If e then c else c: k e:k c:k1 c:k2 kk1 k k2 if (y==0) then x :=3; else x:=1;

20. |- If e then c else c: k e:k c:k1 c:k2 kk1 k k2 if (y==0) then x :=3; else x:=1; 1 load y 2 ifeq 6 3 push 3 4 store x 5 goto 8 6 push 1 7 store x 8…

21. |- If e then c else c: k e:k c:k1 c:k2 kk1 k k2 if (y==0) then x :=3; else x:=1; 1 load y 2 ifeq 6 3 push 3 4 store x 5 goto 8 6 push 1 7 store x 8… region(2)

22. 22 |- If e then c else c: k e:k c:k1 c:k2 kk1 k k2 if (y==0) then x :=3; else x:=1; 1 load y 2 ifeq 6 3 push 3 4 store x 5 goto 8 6 push 1 7 store x 8… region(2) se |- k :: st => st Instr[pc]=ifeq j i in region(pc) k se(i) k1 k k2 se

23. Observation: low level verification is more general…. High-level code Typing rules are syntax directed Memory model includes a store Typability of programs: given by the typing rule of sequential composition Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack Typability of programs: composition is given by the successor relation between program points

24. In this talk: Security of mobile code (proof carrying code) Verification of confidentiality in low level languages Connection between different type systems for iflow A modular approach to verification of multithreaded code and its connection to low level multithreaded code

25. How to connect two different type systems High-level code Typing rules are syntax directed Memory model includes a store Typability of programs: given by the typing rule of sequential composition Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack Typability of programs: composition is given by the successor relation between program points

26. How to connect two different type systems High-level code Typing rules are syntax directed Memory model includes a store Typability of programs: given by the typing rule of sequential composition Low-level code Code is unstructured. Typing rules are not based on structure of the syntax Memory model includes a store and an operand stack Typability of programs: composition is given by the successor relation between program points

27. How to connect two different type systems We annotate high level code with labels and keep these labels for compilation. The compiler generate low level control dependence regions for high-level control dependence regions We compile types of expressions in high level typing derivation trees into stack types Typability does not require further work.

28. In this talk: Security of mobile code (proof carrying code) Verification of confidentiality in low level languages Connection between different type systems for iflow A modular approach to verification of multithreaded code and its connection to low level multithreaded code

29. A modular approach: from sequential to multithreaded code verification… Barthe, Naumann, and Rezk (S&P 06) noticed that low-level type system generalized high- level type systems, and could be connected by specific compilers for information flow Russo and Sabelfeld (CSF 06) observed that verification of multithreaded code for a while language with a fork feature for thread creation could be done by a non-interference property not based on bisimulations

30. Feature of our framework Security guaranteed is not more restrictive than ones of sequential programs Example of an internal timing leak: if hi {sleep(100)}; lo:=1 || sleep(50); lo:=0

31. Approach of multithreaded verification Security guaranteed is not more restrictive than ones of sequential programs Example of an internal timing leak: if hi {sleep(100)}; lo:=1 || sleep(50); lo:=0 The scheduler treats the first thread as hidden from the second thread!!

32. Modularity is the consequence of the approach The framework modularly extends sequential semantics (language independence from the sequential part) Modular extension of sequential type systems Security type preserving compilation is also a modular extension of the sequential counterpart

33. A program consists of: A set of program points (including entry, exit) An instruction map from program points to Ins where Ins= SeqIns U {start pc}

34. Concurrent Semantics A state s consists of a mapping from threads to local states, plus a global state A configuration includes an execution history h

35. Hypothesis on the scheduler

36. Extended concurrent type system

38. In the paper: We prove soundness: by assuming soundness of the sequential type system We show how this result directly extends to type-preserving compilation schemes We instantiate the framework to a case study: the JAVA-like language to multithreaded JVM

39. Type-preserving compilation

42. Conclusion We have proposed a framework for controlling information flow in multithreaded code Thanks to modularity and language- independence, results for sequential languages can be reused.