language-based security proof-carrying code
DESCRIPTION
Language-Based Security Proof-Carrying Code. Greg Morrisett Cornell University Thanks to G.Necula & P.Lee. Papers for this Lecture. G. Necula, “Proof-Carrying Code”. PoPL'97. G.Necula and P.Lee. “Safe Kernel Extensions Without Run-Time Checking”. OSDI'96. - PowerPoint PPT PresentationTRANSCRIPT
Language-Based SecurityProof-Carrying Code
Greg MorrisettCornell University
Thanks to G.Necula & P.Lee
June 2001 Lang. Based Security 2
Papers for this LectureG. Necula, “Proof-Carrying Code”. PoPL'97.
G.Necula and P.Lee. “Safe Kernel Extensions Without
Run-Time Checking”. OSDI'96.
G.Necula and P.Lee. “The Design and Implementation of a Certifying Compiler.” PLDI’98, June 1998. [pldi98.ps]
I also highly recommend Necula’s PhD thesis (CMU).
June 2001 Lang. Based Security 3
Ideally:
Your favoritelanguage
Low-Level IL
optimizer
machine code
verifier SecurityPolicy
SystemBinary
trusted computing base
June 2001 Lang. Based Security 4
Idea #1: Theorem Prover!
Your favoritelanguage
Low-Level IL
optimizer
machine code
NuPRL SecurityPolicy
SystemBinary
trusted computing base
June 2001 Lang. Based Security 5
Unfortunately...
NuPRL
trusted computing base
June 2001 Lang. Based Security 6
Observation
Finding a proof is hard, but verifying a proof is easy.
June 2001 Lang. Based Security 7
PCC:
optimizer
machine code
verifier SecurityPolicy
SystemBinary
prover
code proof
could be you
trusted computing base
“certified binary”
in-variants
June 2001 Lang. Based Security 8
Making “Proof” Rigorous:Specify machine-code semantics and security
policy using axiomatic semantics. {Pre} ld r2,r1(i) {Post}
Given:– security policy (i.e., axiomatic semantics and
associated logic for assertions)– untrusted code – annotated with invariant assertions
it’s possible to calculate a verification condition:– an assertion A such that– if A is true then the code respects the policy.
June 2001 Lang. Based Security 9
The ClientThe client takes its code & the policy:
– constructs some loop invariants.– constructs the verification condition A from
the code, policy, and loop invariants.– constructs a proof that A is true.
code proof
“certified binary”
in-variants
June 2001 Lang. Based Security 10
VerificationThe Verifier (~ 4-6 pages of C code):
– takes code, loop invariants, and policy– calculates the verification condition A.– checks that the proof is a valid proof of A:
• fails if some step doesn’t follow from an axiom or inference rule
• fails if the proof is valid, but not a proof of A
code proof
“certified binary”
in-variants
June 2001 Lang. Based Security 11
Advantages of PCCIn Principle: Simple, small, and fast TCB. No external authentication or cryptography. No additional run-time checks. “Tamper-proof”. Precise and expressive specification of code
safety policies.
code proofin-
variants
June 2001 Lang. Based Security 12
An Experiment: Packet Filters• Safety Policy:
– given a packet, returns yes/no– packet is read-only, small scratchpad– no loops
• Compare:– Berkeley Packet Filter Interpreter– Modula-3 (but turn off type-checking)– Software Fault Isolation (sandboxing)– PCC (hand-optimized, proved)
June 2001 Lang. Based Security 13
Results:PCC wins:
03
69
1215
0 10 20 30 40 50
Thousands of packets
ms
PCCSFIM3BPF
June 2001 Lang. Based Security 14
Is PCC the answer?
PCC seems to offer everything we need:– small, simple trusted computing base– optimize all you want, any language, any
security policy, etc.
But how do we make it scale to real programs?
June 2001 Lang. Based Security 15
Scaling Problem #1:How to generate proofs?• Manual construction is too painful for real
programs.• Interactive theorem provers are really only
feasible for a relatively small fraction of the code.
• We need something that’s fully automatic most of the time.
June 2001 Lang. Based Security 16
One ApproachRestrict the safety policy to type safety.• Necessary for most policies anyway:
– cannot execute code or access data for which you do not have a capability.
– type systems are a meta-policy that allow programmers to define fine-grained notions of “capability” and “access”.
• abstract types, interfaces, static scope, etc.
• Start with a well-typed, high-level program– you have a proof for the high-level code– preserve the proof as you compile
June 2001 Lang. Based Security 17
Type-Preserving Compilation
Source code
Type-checker
Proof oftype-safety
OptimizerCode-
generator
binary
Proof oftype-safety
June 2001 Lang. Based Security 18
Touchstone [Necula]• Compiles type-safe subset of C to
certified binaries for the DEC Alpha.• Security policy is type-safety:
– parameters of the right type to functions– values of the right type in arrays, structs– array indices in bounds
• Highly-optimizing– competitive with GCC, DEC cc– eliminates array bound checks when
possible
June 2001 Lang. Based Security 19
Touchstone Performance
0x
2x
4x
6x
8x
10x
12x
Spe
edup
vs.
"G
NU
gcc
-O0"
GNU gcc -O4 2.33 3.82 3.51 2.97 2.44 2.62 5.50 2.92 3.17
DEC cc -O4 2.92 3.68 3.52 2.79 2.44 2.76 6.88 11.52 3.92
Touchstone 2.64 3.89 3.52 3.86 1.93 2.20 4.00 9.16 3.48
blur sharpen qsort simplex kmp unpack bcopy edge GMEAN
In spite of the fact that C compilers do not insert array bound checks, Touchstone iscompetitive.
June 2001 Lang. Based Security 20
Touchstone Compilation Time
• Geometric means:– compilation 75%– VC generation 2%
– proving 21%– proof checking 2%
0.0
1000.0
2000.0
3000.0
4000.0
5000.0
6000.0T
ime
(m
s)
Proof Checking (ms) 5.9 21.0 16.1 108.7 9.6 50.0 1.9 9.3
Proving (ms) 81.0 257.0 127.0 1272.0 108.0 1912.0 25.0 143.0
VC Generation (ms) 6.9 22.3 12.0 73.9 8.4 55.9 3.3 9.7
Code Generation (ms) 271.0 818.0 560.0 4340.0 348.0 1885.0 136.0 697.0
blur sharpen qsort simplex kmp unpack bcopy edge
June 2001 Lang. Based Security 21
JVM vs. TouchstoneJVM:
– portable– $$$
Touchstone:– extremely good performance– extremely small TCB– fast verification
June 2001 Lang. Based Security 22
However...• Touchstone’s type system suits only one
very simple language:– no abstract data types, objects, etc.– no threads
• Proof size was an issue:– proofs were 1-3x the size of the code, just for
a really simple notion of type-safety.– but recent work by Necula shows that this can
be compressed down to tiny overhead (e.g., 10%)
June 2001 Lang. Based Security 23
Touchstone proof size
0
5000
10000
15000P
CC
bin
ary
size
(by
tes)
Proof 718 2774 1778 11810 1246 5636 250 1122
Invar 162 342 272 825 132 804 36 102
Code 320 1248 560 3584 624 2496 64 640
blur sharpen qsort simplex kmp unpack bcopy edge
Touchstone’s proof size relative to code andinvariant annotations.
June 2001 Lang. Based Security 24
Summary thus far...• Proof-carrying code is great in principle.
– It’s the right general framework.– For special-purpose applications, can’t be
beat.
• But for general-purpose extensions:– Need some way to get the proof
automatically (limit policy to type-safety).– Engineering proof size is an issue.– Compiling high-level languages is an issue.
June 2001 Lang. Based Security 25
Design Details
Safety policyCertifyingCompiler
Theorem Prover
VCGenerator
Proof Checker
ClientServer
UntrustedComplexSlow
TrustedSimpleFast
Proof
Invar
Code
VC
Source
Logic
Code
June 2001 Lang. Based Security 26
Proof RepresentationUse a variant of LF to represent assertions and
proofs.– write down assertion language– write down inference rules for the logic– proof-checking becomes LF type-checking– decouples the logic and assertion language from
the verifier.– of course, you still have to establish the
soundness and consistency of the logic that you encode within LF. And this is very hard for realistic settings.
June 2001 Lang. Based Security 27
Representing LF ProofsIn practice LF proof objects are HUGE.Recent work on proof oracles compresses this
down to nothing [PoPL’2001?]– assume you can match the goal against the
conclusions of the proof rules (e.g., 1st-order unification.) If you can’t match with this, then force the representation to contain more information
– only some (small) subset of the rules will apply (say k of them.)
– so you only need to spit out lg(k) bits to indicate which rule is actually used in the proof.
– the matching lets you then establish sub-goals that need to be proven.
June 2001 Lang. Based Security 28
Where PCC stands• Cedilla has built a certifying compiler for Java.
– generates optimized x86 code– but you can write your own code too!– uses a Nelson-Oppen-style prover
• The proof checker is actually machine independent– map object code up to a machine-independent IL (Secure
Assembly Language)– proofs are with respect to that the SAL code– retargeting the prover to another machine just involves
writing a (correct) mapping from the machine code to SAL.
June 2001 Lang. Based Security 29
Foundational PCC [Appel, Felty]Eliminate more trust from PCC:
– logic encoded into LF– implicit machine semantics
Rather, encode things from the machine semantics up.– you prove w.r.t. the semantics that {Pre}C{Post} is
valid.
Interesting observation:– to do any reasonable proof, you start introducing
“types” or invariants that look suspiciously like TAL– except that you have a semantic encoding as to
what the TAL types mean w.r.t. the machine.