290 likes | 318 Views
Agile Management of Dynamic Collaboration. John Mitchell Patrick Lincoln Stanford University SRI International David Dill, Li Gong, Mary Baker Ajay Chander, Martin Gavrilov, Segio Marti Ninghui Li, Mark Mitchell, Harald Ruess.
E N D
Agile Management of Dynamic Collaboration John Mitchell Patrick Lincoln Stanford University SRI International David Dill, Li Gong, Mary Baker Ajay 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
Group Lookup Service Client lookup proxy service proxy Service 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 Problem: Standard Java-basedJini 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 Secure group communication Leave or recv • 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 loop receive? send
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) Compliance Checker Request Yes/No Advice Policies Credentials
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 relationships Eg: 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: angelos@dsl.cis.upenn.edu • SPKI (Simple Public Key Infrastructure) / SDSI (Simple Distributed Security Framework) • not really a “trust management system” • no clear definition of compliance checking • deployment status: cme@acm.org
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./as sdfgsdfg gfsdfg s gfdsdfg sdfg sdfgdsdfgf Asdfasdg./as sdfgsdfg gfsdfg 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 • Proxy intercepts request for page • Modify code before sending to browser Network Proxy 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
S discovery join query Class loader lookup proxy service proxy access Safe class library Instrument Jini Proxies Lookup Service L Client Service S 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