Agile Management of Dynamic Collaboration John Mitchell Stanford

Agile Management of Dynamic Collaboration John Mitchell Stanford University Patrick Lincoln 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 u. Coalitions via peer-to-peer service concept • Sites may offer services • Clients may broadcast service requests • Service established by installation of mobile code u. Secure adaptive wireless networking protocols • Key management and message delivery for secure unicast, multicast, and point-to-point communication u. 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 Client lookup proxy service proxy Group Lookup Service Mobile code u 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-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 u. Client may need to trust service • Client requests wireless broadcast service • Does not want to send documents to enemy u. Service may restrict access • Database service may reveal sensitive information • Only give information to authorized clients

Peer Model of Authorization u. 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 (3 rd party) – maintains credentials – provides credentials when requested

Dynamic groups Join or send Secure group communication Leave or recv u Key Management • Cryptography provides secure communication • Update keys securely as group changes u 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 u. Routing in dynamic changing wireless networks u. Problem: in certain circumstances a ‘route’ can be assembled with an infinite loop send receive?

Example: AODV wireless routing u. Murphi state exploration reveals potential for loop formation (Dill, also see Gunter) u. An example of the scalability of symbolic analysis tools to relevant protocols u. We are assembling tools and methodology to analyze ad-hoc networking protocols and architectures, building on CAPSL work (Millen)

Trust Management u Problem: Authentication and trust • Service may not be what client wanted • Client may not be authorized for service u 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) Request Policies Credentials Compliance Checker Yes/No Advice

Trust Management u. Basic query • Is this request, supported by these credentials, in compliance with this installations policy? u 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 u. Policy. Maker • [BFL, Oakland’ 96] • [BFS, Financial Crypto ‘ 98] u. Key. Note • [BFIK, RFC submission’ 99] • deployment status: angelos@dsl. cis. upenn. edu u. 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? u. 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 sdfgdsdfgf u 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 loadtime code modification to insert checks and controls

Mobile code risks u. Invasion of privacy u. Denial of service u. Corruption of computing environment u. Need to enforce security and resource constraints • File access, screen resources, etc

Security for mobile code u. Examine code before executing u. Monitor execution and trap risky operations u. Customization • Insert run-time tests according to user policy

Prior work: modify code in proxy Browser Proxy Network UI u. Proxy intercepts request for page u. Modify code before sending to browser

Bytecode Modification u. 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 u. Method-level replacement • Change function calls to new function • Generally, check or modify arguments and call original function

Jini Security Goals u. Provide secure infrastructure • Dynamic group configuration • Provision and access to services u. Combine three methods • Secure communication protocols • Mobile code security • Trust management

Securing Jini with Code Filtering u. The Situation • Service Code transferred from lookup service to client, over RMI interfaces u. The Problem • Secure client from unknown / largely untrusted service code u. A Solution • Instrument Class. Loader to replace possibly harmful bytecode with safe version

Instrument Jini Proxies Lookup Service discovery L S join Class loader Client lookup proxy service proxy query S Service access Safe class library 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 u. Unauthorized File Access (Printer Service) • Read Access to privileged files • Write Access to Local folders / Partitions • Denial of file system resources (Disk flooding) u. Denial of screen resources (e-Vending machine) • Screen flooding

Controlled / Filtered Behavior u. File Access (Printer Service) • Read Access to specified privileged files denied • Write Access to specified folders denied • File Write-to size limited u. Screen resources (e-Vending machine) • Multiple windows restricted

Possible Extensions u. Tunable resource Monitor • file, network, screen, threads, audio, other resources… • OS independent u. 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: u. A malahini project (newstart June/July 00) u. Two whole-project meetings u. Three organizational meetings u. Teams within project formed, collaborating u. Coordination with other DC performers u. Examples, demonstrations, papers in preparation http: //crypto. stanford. edu/dyn-coalitions/

Forming Project Coalitions u. Working together with group inference project (Millen & Denker) u. Working with other DC performers and commercial researchers (Boneh, Dean) u. Identified related DAML work on semantics, core theory of security policies Your Picture Here

Risks u. 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 u. Surfing accidents • Risk mitigation strategy: Practice

Helemai kahui a hele aku END (of the beginning) The group that comes and goes