PACE: An Architectural Style for Decentralized Trust Management - PowerPoint PPT Presentation

PACE: An Architectural Style for Decentralized Trust Management Girish Suryanrayana, Justin R. Erenkrantz , Scott Hendrickson, Richard N. Taylor Institute for Software Research Donald Bren School of Information and Computer Sciences University of California, Irvine http://www.isr.uci.edu/

Introduction State-of-the-practice: distributed systems Client asks server for correct answer May have many clients, servers, peers Relies upon system-wide consensus Unrealistic for certain problem domains PACE: style designed for these domains 2

Definition of Consensus Simultaneous agreement by involved parties Currently rely upon controlling authorities What if we don’t have these authorities? Can we come to a consensus? (Perhaps.) Little experience with consensus-free systems Properly term these ‘decentralized’ 3

Causes of Decentralization Introduced by [Khare & Taylor, ICSE ‘04] Latency: bandwidth, propagation delay, etc. Physical constraint: out-of-date answers Agency: independent controlling authorities Social constraint: multiple right answers Together, impossible to know right now 4

Impossibility of Consensus Multiple correct answers simultaneously What is the exchange rate for the yen? Depends upon the bank you ask Satisficing and rational man: Herb Simon Best choice based on what we know May not be optimal, but good enough 5

An Analogy: Stock Markets Centralized: NYSE One broker per stock Distributed: Nasdaq Computerized trading Decentralized: Over-The-Counter Direct transactions 6

Trust Relationships Can be critical to facilitating interactions Goal is to provide knowledge to users How much does Alice trust Bob? Then, how much should I trust Bob? Place a value on this trust relationship Rely upon that to make uncertain decisions 7

Threats of Decentralization Lack of authority raises security issues Malicious peers may launch attacks Can not prevent their entrance! How do we identify who is good? (What is good? What is evil?) Identify threats; deploy countermeasures 8

(Some) Threats of Decentralization Impersonation: Mallory says she is Bob to Alice Fraudulent Actions: Mallory doesn’t complete transactions Misrepresenting Trust: Mallory tells everyone Bob is evil Collusion: Mallory and Eve tell everyone Bob is evil Denial of Service: Mallory tries to bring Alice down Addition of Unknowns: Alice has never met Bob Deciding Whom to Trust: What makes Bob good? Out-of-band Knowledge: Alice and Bob are old friends 9

Two Architectural Abstractions External: Know what others are doing Protocols: dialect of communication REST: architecture behind HTTP/1.1 Internal: How we compose ourselves Program: what we are doing C2: Event-based architecture 10

Need for an Architectural Style Previous work by others into trust models Abdul-Raman, Blaze, Marsh, Aberer, etc. No integration path provided May desire specific communication strategy Participate in an external network PACE provides one such integration path 11

PACE Architectural Style PACE is an internal architectural style Extends the C2 architectural style Specific functionality layers Allows isolation of a ‘service’ to one layer Constraints on components and connectors Relatively high-level constraints 12

PACE Guiding Principles Digital Identities - Forms relationships Separation of External and Internal Data Explicit Trust - Allows exchange of trust Comparable Trust - Defines range Dependency of Layers - Specific ordering Implicit Trust - Depends upon location 13

PACE Architecture Layers Communication Network Information Communication Communication Information Information Trust Communication Trust Trust Application Information Application Carol Trust Alice Application Application Bob 14

PACE Framework Multicast Handler C2-style diagram HTTP Sender Custom Protocols Multicast Manager Communication Layer Communication Manager Swappable components Signature Manager Multiple networks Information Layer Internal External Information Information Internal distinction Layer Trust Key Credential Trust Manager Manager Manager Isolates domain specifics Application Application Trust Policy Layer A P P L I C A T I O N 15

PACE Countermeasures Impersonation: Adopt digital signatures Fraudulent Actions: Advertise ‘frauds’ as a deterrent Misrepresenting Trust: Consider using transitivity Collusion: Non-forgable signatures (Byzantine Generals) Denial of Service: Communication choke-point; firewalls Addition of Unknowns: Still allow unknowns to be visible Deciding Whom to Trust: Domain-specific trust model Out-of-band Knowledge: Manual overrides of trust 16

Evaluation: Auction Advertise (10 units) Carol Bob l eBay without eBay Bid ($20/unit) Sell Advertise (10 units) Auctions without Bid ($25/unit) Bob trusts Alice = t ba(Bids) = 0.4 controlling authority Bob trusts Carol = tbc(Bids) = 0.8 Alice trusts Bob = tab(Sell) = 0.8 Carol trusts Bob = tcb (Sell) = 0.8 Force consideration of Ordering of Events: Alice 1. Bob advertises to Alice and Carol trust when making 2. Alice and Carol respond with bids 3. Bob trusts Carol more than Alice decisions! 4. Bob decides to sell to Carol even though Alice offers a higher bid. 17

Evaluation: COP Common Operational Picture French display French display Real-time view of situations “Allies” communicate U.S. display 18

Future of PACE Act as internal architecture with ARRESTED Set of decentralized REST extensions Integration of more trust models What trust model trade-offs desirable? Identifying more threats of decentralization What architectural trade-offs necessary? 19

Conclusions Decentralization requires dealing with trust Compensating for lack of authority Modular trust and communication layers PACE induces trust-centric properties Follow architectural style, known behavior Demonstrated by two sample applications 20

Thanks!

Future: APEP A power generator in every home National Fuel Cell Research Center Electricity travels at speed of light Real-time monitoring impossible Larger question is how to manage? Competing interests and governments 22

Future: Crisis Management Low-probability, high-consequence events Focused on response to events Many governmental organizations involved How to resolve conflicts? Authority: who is in command? Informational: evolving situations 23

Latency Primarily a physical concern “Lag between sending and receiving” Data out-of-date before received Answer may change in time to transmit Answer changes when not connected Impossible to know right now 24

Agency Primarily an organizational construct Multiple correct answers are valid Independent social boundaries May not perceive identically Need to reconcile agency conflicts Create illusion of consensus! 25

Architectural Styles Can Help Set of constraints upon software system Indicate how to build software Gain properties by adhering to a style Understood benefits Reuse style frameworks Use ADLs to describe architectures 26

Properties of a Style General agreement on terminology Not aligned on precise meaning Components loci of computation Connectors loci of communication 27

BASE Constraints Not always possible to B est-effort communicate with others Incomplete or incorrect data A pproximate must always be assumed Can only implicitly trust yourself; S elf-centered must develop relationships Agencies may come and go; E vent-driven ad hoc nature; loose coupling 28

ARRESTED Extensions to REST for decentralization External properties: A: Asynchronous, R: Routable Internal properties: E: Estimated, D: Decision-making 29

REST & C2 Architectural Styles External: REST and ARRESTED [Khare, 04] Explicit resource and representation Principal style behind HTTP/1.1 Internal: C2 Explicit components and connectors Event-driven architecture 30