Tamper-Tolerant Software:
Modeling and Implementation
Mariusz H. Jakubowski
Chit Wei (Nick) Saw
Ramarathnam Venkatesan
Microsoft Research
Redmond, WA (USA)
International Workshop on Security (IWSEC 2009)
October 28-30, 2009 – Toyama, Japan
Introduction
• Software integrity
– Enforcing “correct” program execution
– Copy protection, licensing, DRM, anti-malware, OS
security, …
• Fault tolerance
– Enhancing system robustness
– Redundancy, rollback, failover, …
• Goals of our work:
– Adapt fault tolerance to the malicious-attacker
scenario.
– Study real-life security of tamper-tolerant software.
IWSEC 2009
Toyama, Japan
October 28-30, 2009
2
Overview
Fault tolerance and software protection
•
•
•
•
•
Introduction
Background
Tamper-tolerant software
Implementation and experiments
Conclusion
IWSEC 2009
Toyama, Japan
October 28-30, 2009
3
Fault Tolerance
• Methods to enhance system robustness:
– Redundancy (duplicated components)
– Voting (majority-logic error correction)
– Rollback (redoing operations upon failure)
– Failover (switching to fresh component)
–…
• Designed to handle “random” faults
• Not intended against intelligent attackers
IWSEC 2009
Toyama, Japan
October 28-30, 2009
4
Overview
Fault tolerance and software protection
•
•
•
•
•
Introduction
Background
Tamper-tolerant software
Implementation and experiments
Conclusion
IWSEC 2009
Toyama, Japan
October 28-30, 2009
5
Tamper-Tolerant Software
• Main idea: Detect and correct tampering
at runtime.
• Distinct from traditional anti-tamper
responses:
– Error messages
– Crashes
– Graceful degradation
– Other forms of obfuscated failure
IWSEC 2009
Toyama, Japan
October 28-30, 2009
6
Building Blocks
• Techniques adapted from fault tolerance
– Code redundancy: Multiple copies to prevent single
points of attack.
– Code individualization: Diversified copies to force
extra analysis.
– State checkpointing: Rollback of execution to undo
tampering.
• Additional techniques from software protection
– Integrity checks: Detect tampering (e.g., oblivious
hashing or integrity-checking expressions).
– Delayed responses: Prevent easy discovery of
integrity checks.
– Error correction: Fix tampering (e.g., by voting).
IWSEC 2009
Toyama, Japan
October 28-30, 2009
7
Basic Tamper-Tolerance Scheme
IWSEC 2009
Toyama, Japan
October 28-30, 2009
8
Tamper-Tolerance Techniques
• Individualized modular redundancy (IMR)
– Multiple redundant, individualized code blocks
– “Secure” version of standard TMR/V (triple modular
redundancy with voting) and related schemes
• Schemes using IMR:
– Voting (IMR/V): Execute multiple blocks and output
most common (or corrected) result.
– Detection and correction (IMR/DC): Roll back and
execute a redundant block upon tamper detection.
– Randomized execution (IMR/RE): Choose different
individualized blocks for execution.
IWSEC 2009
Toyama, Japan
October 28-30, 2009
9
Tamper-Tolerance Modeling
• Graph-based tamper-resistance model [Dedić et al.
’07]
–
–
–
–
Program: Graph (e.g., control-flow graph)
Execution: “Semi-random” walk on the graph
Integrity checks: Verification of correct execution
Tamper responses: Delayed crashes or failures
• Attack model: “Graph game” involving tampering of
nodes and observation of effects.
• Main result: Attacker must take a “long” time to find all
checks.
• For tamper-tolerance: Replace delayed crashes with
delayed fixes.
IWSEC 2009
Toyama, Japan
October 28-30, 2009
10
Tamper-Tolerance Modeling
• Simplified model:
– n: number of integrity checks in program
– p: probability of executing a check per program run
– d: effort required to attack each check per run
• Analysis
– 1/p runs to trigger and analyze one check
– n/p runs to analyze n independent checks
– dn/p effort to analyze n checks
• Set p = 1/n. Then attacker’s work factor is dn2
(quadratic in number of checks).
IWSEC 2009
Toyama, Japan
October 28-30, 2009
11
Overview
Tamper-tolerant software
•
•
•
•
•
Introduction
Background
Tamper-tolerant software
Implementation and experiments
Conclusion
IWSEC 2009
Toyama, Japan
October 28-30, 2009
12
Implementation
• Compiler plug-in (C++)
– Based on Phoenix compiler infrastructure
– Transforms high-level intermediate
representation (close to source code)
• Experiments on SPEC benchmarks
– Redundant blocks with randomized execution
(IMR/RE)
– Stack-frame rollback
IWSEC 2009
Toyama, Japan
October 28-30, 2009
13
Experimental Results
IMR/RE (randomized execution) over 25% of SPEC benchmark code
IWSEC 2009
Toyama, Japan
October 28-30, 2009
14
Experimental Results
IMR/RE (randomized execution) over 100% of SPEC benchmark code
IWSEC 2009
Toyama, Japan
October 28-30, 2009
15
Experimental Results
Performance impact of rollback
Simulated attacks with different probabilities of tampering
IWSEC 2009
Toyama, Japan
October 28-30, 2009
16
Conclusion
• Tamper-tolerant software
– Fixing tampering instead of crashing
– Adaptation of fault tolerance to software
protection
• Future work
– Methods to diversify and hide tamper
correction
– Metrics for security evaluation
IWSEC 2009
Toyama, Japan
October 28-30, 2009
17