
721a888122a4f591df1f105157e1ad44.ppt
- Количество слайдов: 33
Agile Management of Dynamic Collaboration John Mitchell Stanford University Patrick Lincoln SRI International David Dill, Li Gong, Mary Baker Ninghui Li Dynamic Coalitions PI Meeting January 12, 2001
Project Organization u Contract u Personnel • Start date: 5/4/2000 • Duration: 48 months • Stanford (12 mo optn) – – John Mitchell (PI) Mary Baker, David Dill (Faculty) Ninghui Li (Researcher) Graduate Students • SRI u Agent POC Steve Spendlove SPAWAR – Patrick Lincoln (co-PI) – Research scientists • Consultant – Li Gong (Sun/Java. Soft) January 12, 2001 2
January 12, 2001 3 Goal u. Trust and security for dynamic coalitions • Coalitions via peer-to-peer service concept – Sites may offer to provide services – Clients search for services – Service may be established using mobile code • Secure adaptive (wireless) networking – Key management, discovery, search and delivery for secure peer-to-peer 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
January 12, 2001 4 Background u Jini • Dynamic service search and configuration • Based on Java, RMI • Limited Java security u Peer-to-peer • Napster: centralized • Gnutella, Freenet: decentralized • Inefficient n 2 coalition update • No security u Trust management • Emerging approach for distributed infrastructure • Based on keys, policies, inference engine • No off-the-shelf implementation u Protocols • Secure multicast, P 2 P: rests on key management • Decentralized routing flawed (e. g. , AODV, BGP) • Security, reliability require careful design and analysis
January 12, 2001 5 Progress Summary u Jini architecture • Code filter • Architecture design • Implementation of some parts in progress u Peer-to-peer • Evaluate current systems – coalition discovery and search problems – network simulation New Personnel: Ninghui Li, Trust Management Mary Baker, Wireless Networking u Trust management • Comparison with other access control mechanisms • Identify role-based TM • Implementing inference engine Collaboration: Drew Dean, Xerox u Protocols (ad hoc wireless routing) • Improve DSR reliability – watchdog, pathrater • Discover looping in AODV – model checking, abstraction Collaboration: Jon Millen, SRI
Jini-Based Service Architecture Client lookup proxy service proxy Lookup Service January 12, 2001 6 Group 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 limited security guarantees Approach: Develop protocols, trust mechanism, mobile code security Solutions useful for Jini and for other dynamic coalition platforms
January 12, 2001 7 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 Approach: Dynamic code analysis, code monitoring, and loadtime code modification to insert checks and controls
January 12, 2001 8 Dynamic peer-service goals u. Manage client risks • Authenticate or establish trust in service (solution: TM) • Contain mobile code risks (solution: code filter) u. Manage service risks • Authenticate or establish trust in client u. Dynamic trust (solution: TM) (solution: Trust Management) • Service has no prior knowledge of client • Client has no prior knowledge of service • Establish trust through signed statements by transitively known principals
Illustrative scenarios January 12, 2001 9 u Disneyland • Wireless device for – Electronic cash – Data communication – Attraction UI • Functions – Store, communicate secure data – Find trusted friends and family – Control local devices u Mobile reconnaissance team • Ad hoc wireless networking • Secure group communication • Client obtains real-time data and control features from service
January 12, 2001 10 Jini Architecture • Lookup server stores credentials • Client, server consult TM • Client runs bytecode filter • Trust management is a service Client trusts service Lookup Service Client Trust Mgmt Client filters mobile code Service trusts client Lookup Service Filter Client Service Client Trust Mgmt
More details Client authentication of service (1) discovery Lookup Service (1) discovery (2) query(attr[]) service. Item Sp ID# attr[] (3) service. Item[] (2) Service. Regis Extract key/auth info from attr[] (w/ ID) (3) register(Sp, ID, attr[]) ID# Client January 12, 2001 11 Service credentials Sp attr[] (5) Trust proof or yes/no (4) query(key, trust credentials) TM Engine Database and cache; Fetches credentials Constructs auth proof PKI / Trust CA (not a peer)
Peer-to-peer systems January 12, 2001 12 u. Several recent systems in use • Napster, Gnutella, Freenet, Casino 2000, … • Move toward decentralized peer-to-peer services u. Basic functions • Maintain decentralized network of active peers • Search active peers for document, other resource u. Problems • • Gnutella uses DFS, Freenet uses BFS, both wasteful How to maintain network of active peers efficiently How to query active peers and forward responses How to evaluate, analyze, simulate system
January 12, 2001 13 Peer-to-peer effort u. Study existing systems • Install, test, analyze Gnutella, Freenet, … • Build ns (network sim) test environment (in progress) u. Design improved protocols (in progress) • Efficient discovery and query • Consider applications – Public key infrastructure – Nameserver for Baker’s Mobile. People architecture • Close analogy to ad hoc wireless routing
January 12, 2001 14 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 partial authority) Request Policies Credentials Compliance Checker Yes/No Proof
Trust management progress January 12, 2001 15 u. Study revocation • Feigenbaum and Li u. Comparison with other mechanisms • Chander, Dean, Mitchell u. Begin development of Role-based trust mgmt • Increase expressiveness, appropriate for trust based on role of individual in organization u. Begin study of distributed implementation • Current experimental implementations require centralized deduction (Prolog theorem prover)
Role-Based Trust Management January 12, 2001 16 u. Background • Traditional role-based access control lacks – distributed roles, distributed credentials, role-delegation • Existing trust management lacks: – explicit support for roles, the ability to use partial rights u. Approach • Principals named by Entities and Roles – e. g. , company. A’s employee • Permissions: assigned to roles by distributed policy • Role-delegation • Request with a role
Work in progress on RBTM u. Identify concepts for dynamic coalitions • role-delegation • role-formula u. Develop logic-based language for concepts u. Implement a RBTM engine that • manages roles and credentials for entities • does distributed certificate discovery u. Integrate RBTM engine into Jini framework January 12, 2001 17
January 12, 2001 18 Why isn’t SPKI/SDSI the answer? u. Problems with delegation and names • Delegation from SPKI, local names from SDSI • Need better integration to be useful u. SPKI/SDSI lacks some desirable features • intersections of names • parameterized names K_hospital's physician(alice) u. Some issues not addressed by SPKI/SDSI • Distributed certificate discovery – find a certificate chain in a set of credentials • Privacy issues, deliver minimal certificates, etc. Need better implementation of superset of subset of SPKI/SDSI
Protocols January 12, 2001 19 u. Reliability • Routing protocols assume nodes follow protocol • Investigate problems caused by misbehavior • One solution: improve throughput by monitoring u. Correctness • Model checking – Exhaustively check all states of a system – Works only for finite-state model • Predicate abstraction – Use automatic theorem proving for arbitrary size system – Reduce unbounded system to finite-state approximation
January 12, 2001 20 Background: Ad hoc routing u. Mobile wireless network • composed of limited range wireless devices • no dedicated routers u. Several routing protocols proposed • Dynamic Source Routing (DSR) – On-demand source routing, maintains route cache • Ad hoc, On-demand, Distance Vector routing (AODV) – Not source routing; node only knows what’s next S D
Node Misbehavior January 12, 2001 21 u. Node agrees to forward other nodes’ packets but instead drops the packets u. Reasons for node misbehavior: • • Malicious nodes mounting denial of service attacks Selfish nodes conserving resources Overloaded nodes Broken software
Solutions January 12, 2001 22 u. Watchdog and Path Rater mitigate the effects of node misbehavior u. Assumptions • Bi-directional links • Promiscuous mode u. Philosophy: avoid adding more complexity to the routing protocol
January 12, 2001 23 Watchdog u. Forwarding node verifies next node passes on packet u. Watchdog notifies source of possible node misbehavior S A B A listens to B forwarding to C C D
January 12, 2001 24 Path Rater u. Rate nodes based on reliability (as reported by watchdog) • Node rating initially neutral • Misbehaving node gets strongly negative rating u. Increment rates of nodes on active paths • Decrement rating of nodes on paths if link-break occur u. Pick path with highest average rating u. Fallback: route discovery • If all known paths contain misbehaving nodes, run Path Rater Route Request (PRRR) S A B C D
Throughput n n January 12, 2001 25 17% improvement at 40% misbehaving (low mobility) 27% improvement at 40% misbehaving (high mobility)
Overhead Results January 12, 2001 26
Protocol correctness January 12, 2001 27 u. Protocols are notoriously difficult to design u. Goal: make formal verification techniques applicable to important network protocols u. Approach: • Model checking systematically generate states of a system for fixed numbers of nodes – Mature; works only for finite-state models. • Predicate abstraction uses automatic theorem proving to verify for any number of nodes. – New: works for descriptions with unbounded states.
Predicate abstraction January 12, 2001 28 Protocol description Properties to check Predicate abstractor Abstract FSM checker Simple Predicates (e. g. x > 0) Reduce verification of large or infinite-state systems to standard finite-state model checking
Predicate Abstraction Details January 12, 2001 29 u. Prototype checker exists • Combines several different libraries • SVC: “Stanford Validity Checker” (automatic theorem prover) • BDD-based model checking – uses Boolean functions to represent FSMs and their states u. Performance increased 10 -fold in last 2 months • Successive approximation based on counterexamples. u. Used on AODV and cryptographic protocols
January 12, 2001 30 AODV u“Ad hoc, On-demand, Distance Vector routing” • Automatically assemble networks of mobile nodes u. Routes are required to be loop-free • Routes may fail if loops exist u. Route loops found using Mur model checker • During timeout of routes – previously discovered by Broch and Maltz of CMU • During processing of RERR messages – previously unknown; newly introduced in AODV version 4 AODV is broken. Can we fix it?
AODV Modification January 12, 2001 31 u. Changed protocol to eliminate (? ) loops • Mur verification with 4 nodes found no problems u. Found bugs in “fixed” protocol • Use predicate abstraction to study larger networks • Problem results from arbitrary message delays • Example requires 5 nodes (too big for Mur !) u. Goal • Complete repair of AODV protocol • Verify version 5 of AODV using predicate abstraction
January 12, 2001 32 Progress Summary u Jini architecture • Code filter • Architecture design • Implementation of some parts in progress u Trust management • Comparison with other access control mechanisms • Identify role-based TM • Implementing inference engine u Peer-to-peer • Evaluate current systems – coalition discovery and search problems – network simulation u Protocols (ad hoc wireless routing) • Improve DSR reliability – watchdog, pathrater • Discover looping in AODV – Formal tools find new bugs
Deliverables January 12, 2001 33 u. Upcoming Year 1 report deliverables • Trust-management approach to policy analysis and negotiation for dynamic coalitions, • A Jini-based system for dynamic discovery, query, and selection of services and community members • Architecture for trust management used negotiations for dynamic coalitions, • Mobile-code security mechanisms in Jini environment
721a888122a4f591df1f105157e1ad44.ppt