1 / 17

Tamper-Tolerant Software: Modeling and Implementation

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

gaetan
Download Presentation

Tamper-Tolerant Software: Modeling and Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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. Overview • Introduction • Background • Tamper-tolerant software • Implementation and experiments • Conclusion Fault tolerance and software protection

  4. 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. Overview • Introduction • Background • Tamper-tolerant software • Implementation and experiments • Conclusion • Fault tolerance and software protection

  6. 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. 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. Basic Tamper-Tolerance Scheme

  9. 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. 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. 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).

  12. Overview • Introduction • Background • Tamper-tolerant software • Implementation and experiments • Conclusion Tamper-tolerant software

  13. 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. Experimental Results IMR/RE (randomized execution) over 25% of SPEC benchmark code

  15. Experimental Results IMR/RE (randomized execution) over 100% of SPEC benchmark code

  16. Experimental Results Performance impact of rollback Simulated attacks with different probabilities of tampering

  17. 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

More Related