1. Tamper-Tolerant Software: Modeling and Implementation International Workshop on Security (IWSEC 2009) October 28-30, 2009 – Toyama, Japan Mariusz H. Jakubowski Chit Wei (Nick) Saw Ramarathnam Venkatesan Microsoft Research Redmond, WA (USA)

2. IWSEC 2009 Toyama, Japan October 28-30, 20092 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.

3. IWSEC 2009 Toyama, Japan October 28-30, 20093 Overview Introduction Background Tamper-tolerant software Implementation and experiments Conclusion Fault tolerance and software protection

4. IWSEC 2009 Toyama, Japan October 28-30, 20094 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

5. IWSEC 2009 Toyama, Japan October 28-30, 20095 Overview Introduction Background Tamper-tolerant software Implementation and experiments Conclusion Fault tolerance and software protection

6. IWSEC 2009 Toyama, Japan October 28-30, 20096 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

7. IWSEC 2009 Toyama, Japan October 28-30, 20097 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).

8. IWSEC 2009 Toyama, Japan October 28-30, 20098 Basic Tamper-Tolerance Scheme

9. IWSEC 2009 Toyama, Japan October 28-30, 20099 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.

10. IWSEC 2009 Toyama, Japan October 28-30, 200910 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.

11. IWSEC 2009 Toyama, Japan October 28-30, 200911 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 dn 2 (quadratic in number of checks).

12. IWSEC 2009 Toyama, Japan October 28-30, 200912 Overview Introduction Background Tamper-tolerant software Implementation and experiments Conclusion Tamper-tolerant software

13. IWSEC 2009 Toyama, Japan October 28-30, 200913 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

14. IWSEC 2009 Toyama, Japan October 28-30, 200914 Experimental Results IMR/RE (randomized execution) over 25% of SPEC benchmark code

15. IWSEC 2009 Toyama, Japan October 28-30, 200915 Experimental Results IMR/RE (randomized execution) over 100% of SPEC benchmark code

16. IWSEC 2009 Toyama, Japan October 28-30, 200916 Experimental Results Performance impact of rollback Simulated attacks with different probabilities of tampering

17. IWSEC 2009 Toyama, Japan October 28-30, 200917 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