Download Welcome! [documents.epfl.ch]

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
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