1. 1 The Problem o Fluid software cannot be trusted to behave as advertised unknown origin (must be assumed to be malicious) known origin (can be erroneous or even malicious) o We must worry about extrinsic code properties (non-semantic properties) –e.g., author, time of creation, 3rd party-endorsements,... semantic code properties (behavioral properties) –e.g., memory safety, lack of information flow, etc. o To handle untrusted fluid software we need: safety enforcement technologies, and design and development methodologies

2. 2 The State of the Art o Cryptographic techniques require external trust relationships good for non-semantic properties o Security monitors monitor the execution and halt if a fault is detected impose data representation constraints run-time checking alone is limited –hard to detect certain faults –halting the execution not always acceptable o Static checking reduced run-time cost quickly becomes undecidable for optimized code JVM: type safety for unoptimized intermediate code

3. 3 Simple And Powerful Static Checking o The code is accompanied by a detailed proof Proof-Carrying Code (PCC) Proof Code Proof Checker Yes/No o The proof “explains the code” to the static checker o No more proving, just proof checking o The “hard work” is delegated to the code source where it should be o The proof certifies that the “hard work” was done properly

4. 4 Features of PCC o Safety without sacrificing performance works for low-level languages (even machine code) works for optimized code o The trusted code base is small checking is easier than proving no need to use (and trust) a compiler o Flexible and general (in principle) need a specification that captures the property of interest and a proof of that property for the untrusted code “if you can prove it, PCC can check it!” install one checker for a multitude of policies o But what about generating the proofs?

5. 5 Certifying Compilation o We typically expect our tools to establish certain basic properties e.g., type safety for a compiler for a type-safe language e.g., lack of race conditions for an Esterel compiler o We must either run the tool ourselves (we better trust it) trust the user to run it (hard to enforce) o Alternatively, use tools that certify their output delegate but do not trust effective way to debug the tools themselves ! Proof Code Proof Checker Yes/No Certifying Code Generator

6. 6 Current Status o Proof-carrying code Intel x86 and DEC Alpha implementations (~ 50Kb code) Proofs are 10%-75% the size of the code (for type safety) Fast proof checking (~ 100Kb/s) parameterized by the specification of the safety policy o Certifying compiler for a subset of C –combines performance (on par with GCC -O4) –with type safety for full Java (under development) o Near future: certification back-end for GCJ (GNU Compiler for Java) gain leverage from using off-the-shelf untrusted compilers

7. 7 What next? o Even in C we try to write type safe programs o Is it possible to discover why a C program is safe? “ratify” a broad set of safe programming practices there will be failures –hopefully they point to programming errors –or else, the tool suggests convenient stylistic adjustments –or else, the tool inserts run-time checks this could be compiler independent Proof Code Proof Checker Yes/No Untrusted code Heuristic-based certifier

8. 8 Criteria for Success o 1 year A toolkit for producing provably-safe native methods with off-the-shelf Java compilers o 3 years A toolkit for certifying type safety of C programs o Common thinking in … years Type and memory faults are as common as uncaught memory parity errors If an application crashes, replace the motherboard