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/

2

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

3

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’

4

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

5

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

6

An Analogy: Stock Markets

Centralized: NYSE One broker per stock Distributed: Nasdaq Computerized trading Decentralized: Over-The-Counter Direct transactions

7

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

8

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

9

(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

10

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

11

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

12

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

13

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

14

PACE Architecture Layers

Communication Information Trust Application

Bob

Communication Information Trust Application

Network

Carol

Communication Information Trust Application

Alice

Communication Information Trust Application

15

PACE Framework

Communication Layer Information Layer Trust Layer Application Layer Communication Manager External Information Internal Information Key Manager Signature Manager Trust Manager Application Trust Policy HTTP Sender Custom Protocols Multicast Manager Multicast Handler Credential Manager

A P P L I C A T I O N

C2-style diagram Swappable components Multiple networks Internal distinction Isolates domain specifics

16

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

17

Evaluation: Auction

eBay without eBay Auctions without controlling authority Force consideration of trust when making decisions!

Alice Bob Carol l

Bid ($20/unit) Sell Advertise (10 units) Advertise (10 units) Bid ($25/unit) Bob trusts Alice = t ba(Bids) = 0.4 Bob trusts Carol = tbc(Bids) = 0.8 Alice trusts Bob = tab(Sell) = 0.8 Carol trusts Bob = tcb (Sell) = 0.8 Ordering of Events:

• 1. Bob advertises to Alice and Carol
• 2. Alice and Carol respond with bids
• 3. Bob trusts Carol more than Alice
• 4. Bob decides to sell to Carol even

though Alice offers a higher bid.

18

Evaluation: COP

Common Operational Picture Real-time view of situations “Allies” communicate

U.S. display

French display French display

19

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?

20

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

Thanks!

22

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

23

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

24

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

25

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!

26

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

27

Properties of a Style

General agreement on terminology Not aligned on precise meaning Components loci of computation Connectors loci of communication

28

BASE Constraints

Best-effort

Not always possible to communicate with others

Approximate

Incomplete or incorrect data must always be assumed

Self-centered

Can only implicitly trust yourself; must develop relationships

Event-driven

Agencies may come and go; ad hoc nature; loose coupling

29

ARRESTED

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

30

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