The Security Architecture of the M&M Mobile Agent Framework

1. The Security Architecture of the M&M Mobile Agent Framework P. Marques, N. Santos, L. Silva, J. SilvaCISUC, University of Coimbra, Portugalnsantos@dei.uc.pt 22 August 2001

2. Outlook • M&M Overview • Java and Mobile Agents security • M&M Security • Requirements • Challenges/Problems • Architecture 22 August 2001

3. M&M Overview • M&M Overview • Java and Mobile Agents security • M&M Security • Requirements • Challenges/Problems • Architecture • Conclusion 22 August 2001

4. M&M OverviewM&M Programming Model Middleware MobilityComponents Application B other app objects Application A other app objects HOST A HOST B 22 August 2001

5. M&M OverviewThe 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

6. Java and Mobile Agents security • M&M Overview • Java and Mobile Agents security • M&M Security • Requirements • Challenges/Problems • Architecture • Conclusion 22 August 2001

7. Java and Mobile Agents securityThe good • Dynamic class loading • Object serialization • Fine-grained security framework • Sandbox model • Many powerfull APIs • Simple to program 22 August 2001

8. Java and Mobile Agents securityThe 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

9. M&M Security • M&M Overview • Java and Mobile Agents security • M&M Security • Requirements • Challenges/Problems • Architecture • Conclusion 22 August 2001

10. M&M SecurityRequirements • General security models are hard to implement • How to protect agents from hosts? • Limited model: agent-accountable environments • Infrastructure owned by cooperating organizations • Contract: do not attack any agent executing on their hosts • Useful in the real world • This model assumes: • Hosts do not attack agents • Agents may mis-behave and attack hosts and other agents 22 August 2001

11. M&M SecurityRequirements • 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

12. M&M SecurityChallenges • 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

13. M&M SecurityChallenges • 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

14. M&M SecurityArchitecture 22 August 2001

15. M&M SecurityArchitecture • 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

16. M&M SecurityArchitecture • 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

17. Standard Java Classloading M&M agents ClassLoading M&M SecurityArchitecture 22 August 2001

18. M&M SecurityArchitecture • 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

19. M&M SecurityArchitecture • 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 • The agent calls the API directly. How to log them? • Changing the SecurityManager is not an option. 22 August 2001

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

21. Questions? 22 August 2001