Self-Protecting Mobile Agents Funded by both OASIS and Active Networks Programs NAI Labs 14 Feb. 2001 Lee Badger Brian Matt Larry Spector Doug Kilpatrick
Malicious Hosts Problem • Mobile agents will need to execute on unfriendly hosts, but a host may: • modify an agent’s behavior • steal an agent’s secrets (if any) • deny execution • execute improperly • crash the agent • lie to an agent
Technical Objectives • Protect software agents from tampering while allowing: • High mobility. • Detached operation. • Extended deployment periods. • Realistic infrastructure requirements.
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, Wang)
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?
Technical Approach (in a nutshell) agentlet 1 agentlet 2 agentlet 3 agentlet N agent ... Host Host Host Host Host Traditional Agent Self-Protecting Agent • Distribution: replicate agents across multiple, unrelated hosts. • Present a moving target • Monitoring/Recovery: regenerate corrupted “agentlets.” • Code/data Obfuscation: prevent host-based analysis • Refresh obfuscation before analysis can be completed
transform tool Strategy • New features and policy for existing agents. • No source code required. • Goal: no manual per-agent work required. Distribution Functions Monitor/Recovery Functions Obfuscating transform policy new binary agent (self-protecting) Original (binary) agent
a a a a b b b b S c c c c d d d d Bird’s Eye View time Protected period 1 Protected period 2 ... ... ... a a ... ... ... b b ... ... ... c c ... ... ... d d Agentlets Useful work Agentlets Migration dispatched re-obfuscate each other First Host Set Originator Host Second Host Set
Applications of Obfuscation • “Security through obscurity.” NOT! • Long-lived resistance to analysis. NOT! • But can increase cost of stealing. • DashO-Pro (www.preemptive.com) • Jcloak (www.force5.com) • Elixir (www.elixirtech.com) • RetroGuard (www.retrologic.com) • Temporary resistance to analysis.
Obfuscation (trivial to not-so-trivial) Kinds of Obfuscation Layout Obfuscation Preventive Obfuscation Data Obfuscation Control Obfuscation Language- Breaking Obfuscation
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 (proven NP-complete). • E.g., embed graph operations • Exploit difficulty in concurrency. • E.g., embed threading
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.
What We’ve Done So Far • Surveyed obfuscation tools. • Chose base technologies: Java, IBM Aglets, ANTLR. • Developed an initial toolkit/testbed. • Formulated a strategy to transfer technology. • Developed initial tools: • spi and spmod • First incremental step in agent transformation.
Aglets Runtime Layer Security Manager Cache Manager Persistence Manager Aglet Architecture Aglet System Architecture • Communications Layer • ATP, CORBA RMI etc.
Sandbox aglets to protect hosts. Server-server authentication. Signed aglets. Express agent preferences, to be honored by servers. Don’t run too long here. Restrict me (from calling specific methods, or accessing resources)! Aglet System Security Model
Aglet Life Cycle Secondary Store Server A Dispatch Dispose Create Aglet Aglet Retract Classes Server B Clone
Spmod tool Tool-based Approach • Transformation plugs into life-cycle events. • Therefore, transformation can be generic. • No source code required. • Often, no manual per-agent work required. “doner” functions, and variables (and maybe policy) spma commands (policy) new binary agent (self-protecting) Original (binary) agent
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...
2000 2001 2002 2003 March 14, 2000 Start Date March 15, 2003 End Date Administrative Info (Milestones) April 30, 2001 Prototype Distributed Agent Generation Tool Nov. 15, 2001 Obfuscation Techniques Evaluation Report Jan. 15, 2003 Final Report Feb. 28, 2001 Policy Specification and Architecture Report March 15, 2002 Obfuscated Agentlet Prototype Dec. 15, 2002 Distributed, Self-Healing Obfuscated Agentlet Prototype
Technology Transfer • DARPA programs: Active Networks, systems such as Ultra Log. • Open Source distribution. • Java. • Tool-based approach on binary files: no source needed! • Explore application to NAI products that employ agents.