1 / 18

Self-Protecting Mobile Agents

Self-Protecting Mobile Agents. Funded by both ITS and Active Networks Programs NAI Labs, Network Associates, Inc. 17 July 2000. Lee Badger Brian Matt Steven Kiernan. Mobile Program. Mobile Program. Host. Host. Trusted Bases and Itinerant Programs.

suchin
Download Presentation

Self-Protecting Mobile Agents

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. Self-Protecting Mobile Agents Funded by both ITS and Active Networks Programs NAI Labs, Network Associates, Inc. 17 July 2000 Lee Badger Brian Matt Steven Kiernan

  2. Mobile Program Mobile Program Host Host Trusted Bases and Itinerant Programs • Protect the host: enforce least privilege • Type-safety, SFI, access control, Wrappers, IRM, PCC. • (BTW: policy definition is the hardest part) • Protect the mobile program

  3. Malicious Hosts Problem • Mobile agents will need to execute on unfriendly hosts, but a host may: • non-randomly modify an agent’s behavior • steal an agent’s secrets (if any) • deny execution • execute improperly • crash the agent • lie to an agent

  4. Technical Objectives • Protect software agents from tampering while allowing: • High mobility. • Detached operation. • Extended deployment periods. • Realistic infrastructure requirements.

  5. Existing Practice • Limit Mobility to Trusted Places • hardware peripherals, trusted hosts • Detect Malicious Execution After it Happens • state appraisal (Farmer), detection objects (Meadows), cryptographic traces (Vigna) , partial result authentication codes (Yee), fault-tolerance techniques (Schneider) • Prevent Malicious Execution • encrypted functions (Sander, Bazzi), code/data obfuscation (Collberg, Low, Hohl)

  6. Technical Approach (in a Nutshell) • Spread agents across multiple, unrelated hosts. • Force hosts to collude for their attacks to be effective.

  7. Applications of Obfuscation • “Security through obscurity.” NOT! • Long-lived resistance to analysis. NOT! • 1999 DVD copy protection break. • Protection of algorithms from theft. • DashO-Pro (www.preemptive.com) • Jcloak (www.force5.com) • Elixir (www.elixirtech.com) • RetroGuard (www.retrologic.com) • Temporary resistance to analysis. • E.g., IA experiment 9907 (dynamic IP numbers)

  8. Obfuscation (trivial to not-so-trivial) Kinds of Obfuscation Layout Obfuscation Preventive Obfuscation Data Obfuscation Control Obfuscation Language- Breaking Obfuscation

  9. Data Obfuscation variable splitting scalar/object conversion static data to procedure change variable lifetime add variable distance split/fold/merge arrays change encoding merge scalar variables Control Obfuscation break basic blocks inline methods outline statements unroll loops reorder statements reorder loops reducible to non-reducible flow graphs table interpretation Obfuscation

  10. Opaque Predicates • Opaque predicate: A fact about a program’s state known at obfuscation time that is hard to determine from the code. • Two basic manufacture techniques • Exploit difficulty in alias analysis. • E.g., embed graph operations • Exploit difficulty in concurrency. • E.g., embed threading

  11. Obfuscation “Strength” • Potency: Difficulty for a human to reverse engineer. !(software engineering practices) • Resilience: Difficulty of writing a tool to reverse the obfuscation. • Cost: Space/time costs. • Stealth: Ease of spotting obfuscation mechanisms. Ease of spying out the policy. From Douglas Low’s thesis.

  12. Source Code Obfuscation Transform Obfuscated Source code Run for n seconds Stop. Policy A Time-limited Black Box Hohl, Fritz, “An Approach to Solve the Problem of Malicious Hosts” • A host can deny execution, or lie, but it can’t disrupt the programs’ internal consistency for n seconds. • Can this temporary protection be leveraged into ongoing protection?

  13. Our Approach

  14. What “Policy” Means Here • Obfuscation potency, resilience, stealth, cost. • Self-monitoring granularity. • Replication level. • Non-collusion itinerary rules. • Obfuscation refresh rate. • Distribution of sensitive state. • Phone-home flee-home thresholds. • And More!

  15. Threats (Evaluation, too) • (Quickly) defeat obfuscation. • Track down sibling agents and implement coordinated attack. • Black-box testing revealing secrets. • Deny execution. • Inject bogus agents. • Analysis of long-lived agents. • Prohibitive cost.

  16. What We’ve Done So Far • Surveyed obfuscation tools. • Surveyed agent systems. • Choose a system (Kaariboga, ANTS) • Weak mobility • Java • Multi-hop • Open source • Created a build environment. • Formulated a technology transfer strategy.

  17. Task Schedule 01 02 03 Architecture Report Distributed Agents Prototype Obfuscation Agents Report Obfuscation Prototype Self-healing Agents Prototype Final Report

  18. Technology Transfer • Active Networks, systems such as ALP. • Open Source distribution. • Java. • Tool-based approach. • Start with Kaariboga, move to other systems. • Explore application to NAI products that employ agents.

More Related