Transcript Welcome! [documents.epfl.ch]

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