Scaling Proof-Carrying Code to Production Compilers and Security Policies

1
Scaling Proof-Carrying Code to Production
Compilers and Security Policies

• Edward W. Felten Princeton University
• Andrew W. Appel Princeton University
• Zhong Shao Yale University
• February 2000

2
The problem Mobile Code Security
Code Producer
Code Consumer
Code
Source Program
Compiler
Execute
load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store
r1, 4(r7) add r7,0,r3 add r7,8,r7 beq r3, .-20
3
Existing Practice Trust or Enforcement
Enforcement
Trust

• Technical mechanisms prevent misbehavior.
• Run untrusted, safe code.
• Technology
• proof-carrying code
• High assurance
• Works for only some security properties.

• Social mechanisms prevent misbehavior.
• Run only trusted code.
• Technology
• public-key infrastructure
• code signing
• Subject to corruption
• Works for any security property

4
Technical Objectives

• Secure integration of components can be achieved
  through trust or protection. Our objectives
• Protection mechanisms for secure integration of
  untrusted components.
• Our approach typed intermediate languages,
  certifying compilers, proof-carrying code.
• Authentication mechanisms for flexible
  integration of trust and protection.
• Our approach proof-carrying authentication.

5
Expected major achievements
Felten, Appel Princeton U. Distributed Authentica
tion Frameworks Proof-Carrying Authentication
Appel, Felten Princeton U. Mobile
Code Security Proof-Carrying Code
Shao Yale U. Certifying Compilers FLINT/ML FLIN
T/Java
Language- machine- independent mobile
code safe lang. interop.
Secure Key Distribution File servers
Secure Linking
PCC systems for ML, Java
6
Part I Proof-Carrying Code
Distributed Authentication Frameworks Proof-Ca
rrying Authentication
Appel, Felten Princeton U. Mobile
Code Security Proof-Carrying Code
Certifying Compilers FLINT/ML FLINT/Java
Secure Linking
PCC systems for ML, Java
7
Existing Practice Hardware VM protection
Code Producer
Code Consumer
Machine Code
Machine Code
Source Program
Execute
Compiler
load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store
r1, 4(r7) add r7,0,r3 add r7,8,r7 beq r3, .-20
Operating System virtual memory
Protected resources
Disadvantages Large trusted code base of
O.S. Clumsy, slow interfaces between trusted
untrusted code
8
Existing Practice Software Fault Isolation
Code Producer
Code Consumer
Machine Code
Machine Code
Source Program
SFI Insert extra instructions before load,
store, jump instructions
Compiler
load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store
r1, 4(r7) add r7,0,r3 add r7,8,r7 beq r3, .-20
Safe Machine Code
Disadvantages Slowdown of untrusted code Clumsy,
slow interfaces between trusted untrusted
code Complex TCB
Execute
9
Existing Practice Bytecode Verification
Code Producer
Code Consumer
ByteCode
Java Program
Bytecode Verifier
Compiler
load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store
r1, 4(r7) add r7,0,r3 add r7,8,r7 beq r3, .-20
OK
Just-in-time Compiler
Native code
Execute
10
Proof-Carrying Code
(Necula Lee 1997)
Code Producer
Code Consumer
Native Code
Source Program
Compiler
Execute
load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store
r1, 4(r7) add r7,0,r3 add r7,8,r7 beq r3, .-20
Safety Proof
-i( ?-i(... ?-r ( ...) ) )
OK
Checker
11
Advantages of Proof-carrying code

• Trusted Computing Base is quite small
• Safety policy
• Proof checker
• No need to trust compiler
• (or prover!)
• Verification conditions can be general, flexible,
  expressive
• Can use types, dataflow, induction, any other
  provable property
• Automated theorem-proving is mature enough for
  application

• In contrast, optimizing JITs are quite large
• JIT is in TCB
• Bug in JIT is security hole
• Bytecodes too close to source
• too easy to reverse-engineer
• too hard to optimize at site of origin
• Many compiler optimizations dont fit in bytecode
  type system.
• Bytecodes are ad-hoc,
• ill-specified

12
Shrinking the TCB - make the prover work harder
13
Safety policy (trusted computing base)
Logical connectives (and,or,?)
Machine Semantics
Typing rules
Read/write policies
14
How to shrink the safety policy
Machine Semantics
Logic and, or, ? ...
Read/write policies
Typing rules
15
Part II Proof-Carrying Authentication
Felten, Appel Princeton U. Distributed Authentica
tion Frameworks Proof-Carrying Authentication
Mobile Code Security Proof-Carrying Code
Certifying Compilers FLINT/ML FLINT/Java
Secure Key Distribution File servers
Secure Linking
16
Authentication Existing Practice
Alice
Bob
decision procedure
Charlie
17
Authentication Our Approach CCS99
Alice
Bob
proof verifier
Charlie
18
Encoding Authentication in Logic
?x. (KC signed x) ? (Charlie says x)
KC signed (?x. (KA signed x) ? (Alice says x))
?K. ?P. ?x. (KC signed ?y.(K signed y) ? (P
says y)) ? (K signed x) ? (P says x)
19
Other Abstractions

• groups
• local name spaces
• roles
• delegation
• time, expiration, and revocation

done with definitions and lemmas no additions to
the logic
20
Encoding Other Frameworks

• can encode other frameworks
• paper sketches how to encode SPKI
• how to do it
• make a definition for each SPKI primitive
• prove each SPKI processing rule as a lemma
• can help other frameworks interoperate
• can serve as machine code for frameworks

21
Implementation

• implemented in Twelf, which is based on the
  Edinburgh Logical Framework
• definitions, lemmas, and proofs are all Twelf
  code
• size of proof (for the example)
• main proof is 123 tokens
• proofs of lemmas are 108 tokens total
• further reductions possible active research area

22
Goal Integrating Trust and Protection

• PCC offers higher assurance than trust does.
• But PCC doesnt work for all properties.
• This program will not display misleading dialog
  boxes.
• This control software wont let the vehicle tip
  over.
• Integration allows mixed use of trust and
  protection for different properties within the
  same program.

Verify when we can trust when we must.
23
Part III Certifying compilers
Distributed Authentication Frameworks Proof-Ca
rrying Authentication
Mobile Code Security Proof-Carrying Code
Shao Yale U. Certifying Compilers FLINT/ML FLIN
T/Java
Language- machine- independent mobile
code safe lang. interop.
Secure Linking
PCC systems for ML, Java
24
The FLINT certifying compiler
ML
Java
Add new front-ends to build new certifying
compilers !
Safe C
Parse semantic
Parse semantic
Parse semantic
Key use typed intermediate languages! Motto
If Joe Hacker can understand it, we will type it.
High-level FLINT
Analysis Optimization
Medium-level FLINT
Code Gen.
Low-level FLINT
Hints
Safety Theorem
Theorem Prover
Program for execution
25
Why typed IL ?

• Safe and secure low-level mobile code
• (Why? applets, JINI, active network,
  extensible systems)
• Java VM language is too complex and high-level
• PCC and TAL are good but how to generate them?
• Types for stating and verifying invariants
• IDL for common component libraries
• Safe and principled language interoperation
• Help optimizations and compiler debugging

26
What makes a good typed IL ?

• As low-level as possible (close to real
  machine)
• makes TCB smaller helps generate PCC and TAL
• Machine-independent (still an IL)
• Simple
• types used in the IDL will be read by programmers
• Expressive
• need to prove not just simple type safety
• Efficient

27
Recent progress in FLINT

• New results
• Extending FLINT to support Java
• Typechecking runtime type dispatches
• Examples GC, reflection, type dynamic, pickling
• Typechecking link-time cross-module optimizations
• Express inlining as staged compuation
• Current implementation
• Can handle Standard ML and MiniJava
• Types are now propagated through all optimization
  phases
• Currently working on typed closure conversion

28
Metrics to measure success (smaller is better)

• Size of trusted computing base
• Number complexity of rules in safety policy
• Size of proof checker
• Size of other runtime-system components
• Time, space needed for creating proofs
• Time, space needed for checking proofs
• Time, space to execute untrusted code
  (relative to previous practice such as JITs)

29
Task Schedule
Proof-Carrying Authentication
Proof-Carrying Code
FLINT/ML FLINT/Java
PCC Logic Sample safety policy Prototype prover
?-release certifying ML compiler, subset Java
Security Logic
Distributed Authentication Software
?-release certifying ML compiler
ML PCC prototype
?-release certifying subset Java compiler
Secure Linking
Java PCC prototype
30
Technology Transfer

• Key components are open-source, widely used in
  academia
• Standard ML of New Jersey (FLINT) compiler
• LF (Twelf) proof checker
• These components have been used in commercial
  applications
• SML/NJ maintenance of telephone switch software
  (Lucent)
• LF Cedilla systems secure Java JIT compiler
• ML, Java software built with our system will be
  compatible with existing ML, Java software and
  software-development processes

31
Scaling Proof-Carrying Code to Production
Compilers and Security Policies

• Edward W. Felten Princeton University
• Andrew W. Appel Princeton University
• Zhong Shao Yale University
• February 2000

32
Language-independent safety policy
Machine Semantics
Logic and, or, ? ...
Read/write policies
(programming-language specific) (compiler
specific) Typing rules Without types in safety
policy, code consumer does not impose choice of
language compiler on code producer
33
Challenges from Java

• OO primitives are too high level
• method invocation field selection checkcast
• Access control
• objects of twin type can access private fields
• Name-based subtyping hierarchy
• Reflection (class Class), linking loading
• Concurrency
• On-the-fly code optimizations