Agile Management of Dynamic Collaboration
John Mitchell Patrick LincolnStanford University SRI International
David Dill, Li Gong, Mary BakerAjay Chander, Martin Gavrilov, Segio Marti
Ninghui Li, Mark Mitchell, Harald Ruess
Goal: Trust and security for dynamic coalitions
Coalitions via peer-to-peer service concept• Sites may offer services• Clients may broadcast service requests• Service established by installation of mobile code
Secure adaptive wireless networking protocols• Key management and message delivery for secure
unicast, multicast, and point-to-point communication
Decentralized authentication and trust decisions• Policy language and compliance checker
Service-oriented infrastructure based on secure communication protocols, decentralized trust
management, and secure mobile code
Jini-Based Service Architecture
Three phases for dynamic service installation• Request lookup server; receive lookup proxy code• Specify service via lookup proxy; receive service proxy
code• Access service via downloaded service proxy
Service
LookupService
Group
Client serviceproxy
lookupproxy
Mobile code
Problem: Standard Java-based Jini has no security guarantees
Solution: Develop protocols, trust mechanism, mobile code security
Solutions useful for Jini and for other dynamic coalition platforms
Mutual suspicion
Client may need to trust service• Client requests wireless broadcast service• Does not want to send documents to enemy
Service may restrict access • Database service may reveal sensitive
information• Only give information to authorized clients
Peer Model of Authorization
Every entity can potentially be: • a requester
– maintains credentials– submits credentials with its requests
• an authorizer– maintains polices– is the ultimate authority for its own authorization
decisions– may delegate to other entities
• a credential provider (3rd party)– maintains credentials– provides credentials when requested
Dynamic groups
Join or send
Leave or recv
Secure group communication
Key Management• Cryptography provides secure communication• Update keys securely as group changes
Message delivery• E.g., dynamic routes must be loop-free
Problem: Protocol design is difficult and error prone Solution: Protocol analysis by proven formal methods
Example: AODV wireless routing
Routing in dynamic changing wireless networks
Problem: in certain circumstances a ‘route’ can be assembled with an infinite loopsend receive?
Example: AODV wireless routing
Murphi state exploration reveals potential for loop formation (Dill, also see Gunter)
An example of the scalability of symbolic analysis tools to relevant protocols
We are assembling tools and methodology to analyze ad-hoc networking protocols and architectures, building on CAPSL work (Millen)
Trust Management
Problem: Authentication and trust• Service may not be what client wanted• Client may not be authorized for service
Solution: Trust management• Decentralized security management based on
authorities granted to a cryptographic key• Distributed policy determined by service policies and delegation (ability to transfer authority)
ComplianceChecker
Request
Policies
Credentials
Yes/No
Advice
Trust Management
Basic query• Is this request, supported by these credentials, in
compliance with this installations policy?
Three components• Security policies
Eg: Strategic information is available to commanders and immediate subordinates named by them (delegation once)
• Security credentials Eg: Authority A certifies that Kc is the key of a commander
• Trust relationshipsEg: This installation trusts authority A and principals certified by
authority A (transitivity)
Background on Trust Management
PolicyMaker• [BFL, Oakland’96] • [BFS, Financial Crypto ‘98]
KeyNote• [BFIK, RFC submission’99]• deployment status: [email protected]
SPKI (Simple Public Key Infrastructure) / SDSI (Simple Distributed Security Framework)
• not really a “trust management system”– no clear definition of compliance checking
• deployment status: [email protected]
What is a Delegation Relationship?
Example relationships from other systems• Entrusting (Logic for Auth and Access Control)
– Alice allows Bob to act on Alice’s behalf– Implication: a request from Bob should be viewed
as if it came from Alice
• Granting (SPKI)– Alice grants certain rights to Bob– Implication: if Alice has a certain right, then Bob
should also have it
• Trusting (PGP, PEM)– Alice trusts Bob about something– Implication: if Bob says something, then Alice
agrees
Mobile Code Security
Asdfasdg./assdfgsdfggfsdfg s
gfdsdfg sdfg sdfgdsdfgf
Asdfasdg./assdfgsdfggfsdfg s
gfdsdfg sdfg sdfgdsdfgf
Code transmitted and executed• E.g., transparent dynamic installation of user
interface, communication protocol, device driver, Jini service proxy
Problem: Untrusted code executed inside mission-
critical system Solution: Dynamic code analysis, code monitoring, and
load-time code modification to insert checks and controls
Mobile code risks
Invasion of privacy Denial of service Corruption of computing environment
Need to enforce security and resource constraints• File access, screen resources, etc
Security for mobile code
Examine code before executing Monitor execution and trap risky
operations Customization
• Insert run-time tests according to user policy
Prior work: modify code in proxy
BrowserProxy
Network
Proxy intercepts request for page Modify code before sending to browser
UI
Bytecode Modification
Class-level replacement• Define subclass of library (or other) class• Replace references to class with subclass (const
pool)• Works because of subtyping• Not possible if class is final
Method-level replacement• Change function calls to new function• Generally, check or modify arguments and call
original function
Jini Security Goals
Provide secure infrastructure • Dynamic group configuration• Provision and access to services
Combine three methods• Secure communication protocols• Mobile code security• Trust management
Securing Jini with Code Filtering
The Situation• Service Code transferred from lookup
service to client, over RMI interfaces
The Problem• Secure client from unknown / largely
untrusted service code
A Solution• Instrument ClassLoader to replace possibly
harmful bytecode with safe version
Client
Instrument Jini Proxies
LookupService
Service
Safe class library
Class loader
L
S
serviceproxy
lookupproxy
discovery S
join
query
access
Safe means client resource-controlled
The Approach
Infrastructure pieces• RMI compliant Lookup Service (includes an
HTTP server)• Service proxy class (pre-compiled,
registered with LS on local file system)• Client desires certain services
– Mockup Printer Service– GUI enabled e-Vending Machine
Examples of Malicious Behavior
Unauthorized File Access (Printer Service)• Read Access to privileged files• Write Access to Local folders / Partitions• Denial of file system resources (Disk flooding)
Denial of screen resources (e-Vending machine)• Screen flooding
Controlled / Filtered Behavior
File Access (Printer Service)• Read Access to specified privileged files denied• Write Access to specified folders denied• File Write-to size limited
Screen resources (e-Vending machine)• Multiple windows restricted
Possible Extensions
Tunable resource Monitor• file, network, screen, threads, audio, other
resources…• OS independent
General framework for rewriting of Java libraries• patches!• Efficient implementation of Java APIs
Overall Project Goal and Approach
A service-oriented DC infrastructure based on • Secure communication protocols• Decentralized trust management• Secure mobile code
Progress:
A malahini project (newstart June/July 00) Two whole-project meetings Three organizational meetings Teams within project formed, collaborating Coordination with other DC performers Examples, demonstrations, papers in
preparation http://crypto.stanford.edu/dyn-coalitions/
Forming Project Coalitions
Working together with group inference project (Millen & Denker)
Working with other DC performers and commercial researchers (Boneh, Dean)
Identified related DAML work on semantics, core theory of security policies
Your Picture Here
Risks
Technology platforms we study die out• Momentum behind commercial efforts like
Jini is highly volatile and hard to predict• Risk mitigated by focusing on general-
purpose approaches, developing broadly applicable scientific understanding
Surfing accidents• Risk mitigation strategy:
Practice
END(of the beginning)
Helemai kahui a hele aku
The group that comes and goes