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

pace an architectural style for decentralized trust
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

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/

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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’

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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

slide-6
SLIDE 6

6

An Analogy: Stock Markets

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

slide-7
SLIDE 7

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

slide-8
SLIDE 8

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

slide-9
SLIDE 9

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

slide-10
SLIDE 10

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

slide-11
SLIDE 11

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

slide-12
SLIDE 12

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

slide-13
SLIDE 13

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

slide-14
SLIDE 14

14

PACE Architecture Layers

Communication Information Trust Application

Bob

Communication Information Trust Application

Network

Carol

Communication Information Trust Application

Alice

Communication Information Trust Application

slide-15
SLIDE 15

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

slide-16
SLIDE 16

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

slide-17
SLIDE 17

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.

slide-18
SLIDE 18

18

Evaluation: COP

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

U.S. display

French display French display

slide-19
SLIDE 19

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?

slide-20
SLIDE 20

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

slide-21
SLIDE 21

Thanks!

slide-22
SLIDE 22

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

slide-23
SLIDE 23

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

slide-24
SLIDE 24

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

slide-25
SLIDE 25

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!

slide-26
SLIDE 26

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

slide-27
SLIDE 27

27

Properties of a Style

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

slide-28
SLIDE 28

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

slide-29
SLIDE 29

29

ARRESTED

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

slide-30
SLIDE 30

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