Download
agile management of dynamic collaboration n.
Skip this Video
Loading SlideShow in 5 Seconds..
Agile Management of Dynamic Collaboration PowerPoint Presentation
Download Presentation
Agile Management of Dynamic Collaboration

Agile Management of Dynamic Collaboration

3 Vues Download Presentation
Télécharger la présentation

Agile Management of Dynamic Collaboration

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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)

  9. 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

  10. 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)

  11. 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

  12. 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

  13. 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

  14. 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

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

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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. Overall Project Goal and Approach A service-oriented DC infrastructure based on • Secure communication protocols • Decentralized trust management • Secure mobile code

  26. 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/

  27. 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

  28. 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

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