ProofCarrying Code Survivability Validation Framework

1
Proof-Carrying CodeSurvivability Validation
Framework

• Andrew W. Appel Princeton University
• July 2001

2
1. Security problems addressed

• Distributed authorization
• Public key distribution
• Certificate authorities
• Code signing
• Component-linking policies
• Access control
• Solution Proof-carrying authentication/authoriza
  tion

• Building systems with mix of trusted and
  untrusted components
• COTS
• Applets, servlets
• E-mail attachments
• Want rich, object-oriented APIs between
  components
• No virtual-memory context switch, please
• Solution Proof-carrying code

3
Protection problem
not trusted
System Resources
Access to system resources mediated by API
Application Program
API
Privilege Checking, Mediation, Capability
management
Must prevent capability-management from being
bypassed
4
Technology description Proof-carrying code
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
Policy
Policy
Safety Theorem
Safety Theorem
Safety Proof
Prover
-i( ?-i(... ?-r ( ...) ) )
OK
Checker
5
2. Assumptions

• A1 Hardware (instruction-set architecture)
  operates correctly
• No uncorrected bit-errors, no attacks by voltage
  variation,
• A2 Hosts access control policy is appropriate
• Written by host administrator
• Uses our policy language

6
3. Threats, Attacks, Vulnerabilities

• Design
• TAV-1.1 Exploitable inconsistency in policy
• TAV-1.2 Erroneous decision procedure for
  granting access
• Implementation
• TAV-2.1 Bug in implementation of protection
  mechanism
• TAV-2.2 Bug in implementation of decision
  procedure
• Operation
• TAV-3.1 Client code fetches/stores
  out-of-bounds address
• TAV-3.2 Client code jumps to out-of-bounds
  address
• TAV-3.3 Inconsistency in link-loading name
  resolution
• TAV-3.4 Client code doesnt execute whats
  checked
• TAV-3.5 Forging of certificates
• TAV-3.6 Attackers uses compromised keys

7
4. Survivability Security Goals

• AV Availability not addressed
• I Integrity
• Low-level addressed by Proof-carrying code
• High-level addressed by Proof-carrying
  authorization
• C Confidentiality
• Low-level addressed by Proof-carrying code
• High-level addressed by Proof-carrying
  authorization
• AU Authentication
• Addressed by proof-carrying authorization
• NR Nonrepudiation not addressed
• F Flexibility
• Flexible and expressive design of APIs and
  policies

8
5. Comparison with other systems
Operating system, virtual memory
System Resources
Virtual memory
Application Program
Privilege Checking, Mediation, Capability
management
API
9
Threat matrix

• Operating System with Virtual Memory

Design
Impl.
Operation
10
Java Virtual Machine
System Resources
Application Program
API
Privilege Checking, Mediation, Capability
management
Application Program
Run time
Link time
11
Threat matrix

• Java Virtual Machine

Design
Impl.
Operation
12
Code signing
I promise not to bypass APIs
System Resources
Application Program
API
Privilege Checking, Mediation, Capability
management
Signed, Microsoft
13
Threat matrix

• Code signing (ActiveX)

Design
Impl.
Operation
14
Our solution

• Proof-carrying code, proof-carrying authentication

Design
Impl.
Operation
15
6. Mechanisms

• M1 Prover constructs safety proof for
  untrusted application binary
• M2 Machine specification axiomatizes
  instruction-set architecture
• M3 Safety policy defines theorem to be
  proved
• M4 Proof checker determines whether proof
  matches theorem
• M5 Policy modeler validation technique for
  safety policies
• M6 Semantics of types used in constructing
  safety proofs
• M7 Digital signatures can be generated only by
  holder of private key
• M8 Expiration freshness dating certificates
  limits harm from key loss

16
Rationale

• Proof-carrying code, proof-carrying authentication

17
Trusted Computing Base
Foundational Proof-Carrying Code
18
8. Residual risks, limitations, caveats

• Might not scale to full-featured source languages
• Prover or checker might be too slow
• Compiler/prover technology might be too complex
  for development outside academia
• Covert channels
• Measurements of TCB dont include C compiler that
  compiles the checker

19
9. Costs

• Execution speed
• Interface-crossing performance excellent
• Intramodule execution very good
• Binary size
• Executable binaries larger (factor of two?)
• No cost to in-core footprint during execution
• Loading, linking time (proof check required)
• Software development
• Must use type-safe source language such as Java
• COTS software in Java OK
• COTS software in C, C not OK
• Technology development
• Competitive technologies (virtual memory, JVM, )
  established and well understood