1 / 10

Tamper Resistant Software: An Implementation

Tamper Resistant Software: An Implementation. By David Aucsmith, IAL. In Information Hiding Workshop, RJ Anderson (ed), LNCS, 1174, pp. 317-333, 1996.

leroy
Download Presentation

Tamper Resistant Software: An 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 Resistant Software: An Implementation By David Aucsmith, IAL In Information Hiding Workshop, RJ Anderson (ed), LNCS, 1174, pp. 317-333, 1996. “Integrity Verification Kernels (IVKs) … can be inserted into software to verify the integrity of critical operations. [They] cannot be observed or modified.” Presented by Andrew Paxie14 September 2000

  2. The focus of mypresentation Overview of Paper • Introduction • Threat Model • Principles and Architecture • Integrity Verification Kernels • Interlocking Trust • Integrity Verification Protocol • Technology Extensions • Conclusion

  3. Defend against these threats Threat Model (I) Outsider trying to get in. (II) Malicious code running on system. (III) Complete control over system. (a) No special tools. (b) Specialized software analysis tools. (c) Specialized hardware analysis tools. “Threat follows value.”

  4. IVK Principles • “Software [must] contain a secret … [as this] forms the basis for the trust that the application has not been tampered with.” • Hide the secret and make its recovery difficult: • Disperse it in time and space (cf. Shannon). • Obfuscate and interleave operations. • Make code installation unique (cf. Cohen). • Provide an interlocking trust mechanism.

  5. Interlocking Trust • “…the failure or by-pass of any one IVK will be detected by another.” • The idea comes from authentication protocol design. • This is a challenge-response protocol. • Defend against man-in-the-middle. • Defend against message replay.

  6. Integrity Verification Protocol (1) Definitions: App = an application • Contains an IVK which participates in the IV protocol. eIVK = entry IVK. • Has a well known address, AE System Integrity Program • Contains eIVK and (an)other IVK(s) • Is available to all programs. App IVK System Integrity Program 1a 1c eIVK IVK 1b

  7. Integrity Verification Protocol (2) • Notation: • For a module, X, X = A, E, S: • KX is a key for X, K1X is public, K-1X is private. • HX is a hash function computed on X. • RX is a random value X creates. • AX is the address of module X. • F is a flag storing test results as each protocol step runs. • Assume that: • H is well known to all IVKs. • A contains location and size info.

  8. Key to protocol steps: Challenge. Integrity check. Response. Response check. Protocol points: Verify yourself and others before proceeding. Use random numbers to defend against replay 1 App IVK (A) 2 13 4 12 8 9 eIVK (E) SIP IVK (S) 11 7 10 5 3 6 Integrity Verification Protocol (3)

  9. (1) A verifies selfF0 := (HA = K1A[K-1A[HA]]) 1 (2) A challenges EA->E: K1E[K1E[HA] | F | AA | RA] (3) E verifies selfF1 := (HE = K-1E[K1E[HE]]) 2 13 (4) E verifies AF2 := (HA = K-1E[K1E[HA]]) 4 12 (12) E responds to AE->A: K-1E[F | RA] (13) A checks responseF8 := (RA = K1E[RA]) 3 Integrity Verification Protocol (4) F = 0? App IVK (A) eIVK (E) SIP IVK (S)

  10. Conclusion Aucsmith combines a variety of techniques to ‘armour’ an IVK against observation and modification. The integrity verification protocol is integral to the mechanism. Q: Does the technique outlined defend against the threat categories proposed?

More Related