Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
The Security Architecture of the M&M Mobile Agent Framework P. Marques, N. Santos, L. Silva, J. Silva CISUC, University of Coimbra, Portugal [email protected] 22 August 2001 1 Outlook M&M Overview Java and Mobile Agents security M&M Security Requirements Challenges/Problems Architecture 22 August 2001 2 M&M Overview M&M Overview Java and Mobile Agents security M&M Security Requirements Challenges/Problems Architecture Conclusion 22 August 2001 3 M&M Overview M&M Programming Model Application B other app objects Application A other app objects HOST A HOST B Middleware Mobility Components 22 August 2001 4 M&M Overview The component approach Component approach: mobile agent support built as a set of components Applications become agent-enabled by using binary software components (JavaBeans and ActiveX) Easy to program (Visual Builder Tools) Security is integrated into the application security framework Agents can be application specific Only the required components are included in each application 22 August 2001 5 Java and Mobile Agents security M&M Overview Java and Mobile Agents security M&M Security Requirements Challenges/Problems Architecture Conclusion 22 August 2001 6 Java and Mobile Agents security The good Dynamic class loading Object serialization Fine-grained security framework Sandbox model Many powerfull APIs Simple to program 22 August 2001 7 Java and Mobile Agents security The bad Notion of thread but no notion of process All classes are loaded to the same JVM A mis-behaving agent may deadlock the JVM No standard and correct way of killing a thread. No resource control mechanism The standard security model has no notion of user Authentication and authorization based on who signed the code and where it came from Java was designed for single-user environments. No operating-system like features! 22 August 2001 8 M&M Security M&M Overview Java and Mobile Agents security M&M Security Requirements Challenges/Problems Architecture Conclusion 22 August 2001 9 M&M Security Requirements General security models are hard to implement How to protect agents from hosts? Limited model: agentattacks accountable environments Infrastructure owned by cooperating organizations Contract: do not attack any agent executing on their hosts Useful in the real world attacks attacks attacks Host This model assumes: Hosts do not attack agents Agents may mis-behave and attack hosts and other agents 22 August 2001 10 M&M Security Requirements Protect the agent runtime from agents Unauthorized access or operation Excessive resource consumption Overflow by agents Protect agents from agents Tampering or eavesdropping Killing Limited protection of agents from hosts Cryptography to hide secrets from hosts 22 August 2001 11 M&M Security Challenges How to establish the notion of user Agent permissions should be granted based on its owner. The same agent code may be used by several different entities But, in the standard Java model: Each class can only have one ProtectionDomain The policy files do not support the notion of user. How to have different ProtectionDomains for the same agent code? 22 August 2001 12 M&M Security Challenges Integration with applications M&M components should integrate seamlessly with existing applications If the application has already instantiated a SecurityManager the M&M must work with it. But, before JDK 1.2 Security policy coded in the SecurityManager Each application had a specific SecurityManager. After JDK 1.2 Security policy in external files The SecurityManager need not be changed 22 August 2001 13 M&M Security Architecture 22 August 2001 14 M&M Security Architecture Works with Java 2 security model. Only requires that a standard SecurityManager be instantiated. Uses standard Java 2 policy files. Principals: agent owner, agent programmer and hosts Each principal has a pair of private/public keys Strong isolation between agents and system resources Proxies avoid direct communications between agents and other mobility components. The Java 2 AccessController protects accesses to the Java API 22 August 2001 15 M&M Security Architecture Authentication Each agent is given an AgentIdentity at creation: agent name, owners, hash of the code, creation and expiration dates. Signed by the agent owners’ private keys. Hosts use the agent owners’ public keys to validate migrations Virtual signers: the authenticated owners of the agent. Authorization For each agent a new ClassLoader is created: AgentClassLoader ProtectionDomain defined with the virtual signers In the policy files the virtual signers are specified in the “signedBy” field. 22 August 2001 16 M&M Security Architecture Standard Java Classloading AgentIdentityA Class ClassLoader InstanceA ProtectionDomain 22 August 2001 M&M agents ClassLoading InstanceB Agent Class AgentIdentityB AgentClassLoaderA AgentClassLoaderB Agent Instance A Agent Instance B ProtectionDomainA ProtectionDomainB 17 M&M Security Architecture Remote Management Interfaces (via RMI) Authentication of the client Server code runs with the permissions of the client Remote Instalable services Run with the permissions of the principal who installed it. More features: Extensive logging facilities Cryptographic primitives for agents: confidentiality and integrity Migrations protected by SSL sockets 22 August 2001 18 M&M Security Architecture Limitations Resource control. Some solutions modified JVM JVM Profiling Interfaces Integration with existing applications If the SecurityManager is modified it may not work. In practise: most modified SecurityManagers still work with the Mobility components. Logging of API calls 22 August 2001 The agent calls the API directly. How to log them? Changing the SecurityManager is not an option. 19 Conclusions Right now it is not possible to define a perfect security model for mobile agents. Most applications can deal with the risk of the current models: Accept the risk, if cost is reasonable Use external security mechanisms The Java language is good for programming mobile agents, but has some limitations: lack of processes, lack of resource control mechanisms, lack of multi-user support 22 August 2001 20 Questions? 22 August 2001 21