WAVE: A Decentralized Authorization Framework with Transitive - - PowerPoint PPT Presentation

▶
wave a decentralized authorization framework with
SMART_READER_LITE
LIVE PREVIEW

WAVE: A Decentralized Authorization Framework with Transitive - - PowerPoint PPT Presentation

Jun 22, 2023 353 likes •1.09k views

WAVE: A Decentralized Authorization Framework with Transitive Delegation [Andersen et al., USENIX Security 2019] Slides credit Michael Andersen Representative authorization example BLDG2/Floor3/HVAC BLDG2/Floor3 BLDG2/Floor3/LIGHT

slide-1
SLIDE 1

WAVE: A Decentralized Authorization Framework with Transitive Delegation

[Andersen et al., USENIX Security 2019] Slides credit Michael Andersen

slide-2
SLIDE 2

Representative authorization example

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

slide-3
SLIDE 3

Traditional approach

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS E.g. OAuth, LDAP

slide-4
SLIDE 4

Traditional approach

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Problems: Central point of attack

slide-5
SLIDE 5

Traditional approach

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Problems: Central point of attack Can’t even trust operator

slide-6
SLIDE 6

Traditional approach

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Problems: Central point of attack Can’t even trust operator

slide-7
SLIDE 7

Traditional approach

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Problems: Central point of attack Can’t even trust operator

slide-8
SLIDE 8

Traditional approach

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Problems: Central point of attack Can’t even trust operator

slide-9
SLIDE 9

Traditional approach

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Problems: Central point of attack Can’t even trust operator

slide-10
SLIDE 10

Traditional approach

Building Owner Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Problems: Central point of attack Can’t even trust operator Sometimes delegation unsupported

Tenant Company CEO

slide-11
SLIDE 11

Traditional approach

Building Owner Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Problems: Central point of attack Can’t even trust operator Sometimes delegation unsupported When supported, not transitive

Tenant Company CEO

slide-12
SLIDE 12

Lack of transitive delegation

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

slide-13
SLIDE 13

Lack of transitive delegation

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

slide-14
SLIDE 14

Lack of transitive delegation

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

slide-15
SLIDE 15

What we want:

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

slide-16
SLIDE 16

Existing work lacks some important features

System / Work Avoid central authority Transitive Delegation Permission Discovery No ordering constraints Offline participants Protected permissions LDAP, AD OAuth2 Macaroons SDSI/SPKI

slide-17
SLIDE 17

What is WAVE

WAVE is a cryptographically enforced decentralized authorization system

System / Work No central authority Transitive Delegation Permission Discovery No ordering constraints Offline participants Protected permissions

WAVE

  • It can be used in place of most mainstream authorization systems
  • Anyone can delegate permissions or revoke permissions they have delegated
  • Anyone can discover their permissions and form a proof of authorization
  • Anyone (even devices) can verify proofs of authorization
slide-18
SLIDE 18

WAVE achieves this with three techniques:

slide-19
SLIDE 19

Graph Based Authorization

  • Popularized by SDSI/SPKI [Rivest, Lampson, 1996]
  • Represents permissions as a graph, rather than an ACL table
  • Naturally represents transitive delegation

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

slide-20
SLIDE 20

Graph Based Authorization

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

slide-21
SLIDE 21

Graph Based Authorization

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Participants: Entities Collections of cryptographic keys: identifier is PK

slide-22
SLIDE 22

Graph Based Authorization

Building Owner Tenant Company CEO Employees BLDG2/Floor3 BLDG2/Floor3/HVAC BLDG2/Floor3/LIGHT BLDG2/Floor3/DOORS

Grants of permissions: Attestations Signed certificates created by Entities

slide-23
SLIDE 23

Graph Based Authorization

Building Owner Tenant Company CEO

Attestations grant permissions on a resource Permission: Read, Write Resource: BldgOwner/BLDG2 Expires: 2019/04/05

slide-24
SLIDE 24

Graph Based Authorization

Tenant Company CEO

Attestations grant permissions on a resource Resources are in a namespace which identifies the authority entity Permission: Read, Write Resource: BldgOwner/BLDG2 Expires: 2019/04/05 Namespace Authority

slide-25
SLIDE 25

NS/BLDG2/Floor3/DOORS NS/BLDG2/Floor3

Graph Based Authorization

Building Owner Tenant Company CEO Employee

Proof of permissions: A path through the graph from Namespace Authority to the prover

* In WAVE, not SDSI/SPKI

Proof grants the intersection of the permissions of each attestation Verifiable by anyone*, attached to messages

Proof

slide-26
SLIDE 26

This forms a single global graph

slide-27
SLIDE 27

This forms a single global graph

  • Multiple namespace authorities in the

graph

slide-28
SLIDE 28

This forms a single global graph

  • Multiple namespace authorities in the

graph

  • Different entities will only see portions
  • f the graph
slide-29
SLIDE 29

This forms a single global graph

  • Multiple namespace authorities in the

graph

  • Different entities will only see portions
  • f the graph
slide-30
SLIDE 30

We need to hide portions of the graph

slide-31
SLIDE 31

Reverse Discoverable Encryption

Building Owner Tenant Company CEO Employees

slide-32
SLIDE 32

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager

slide-33
SLIDE 33

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager Janitorial Services NS/Floor3

slide-34
SLIDE 34

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

slide-35
SLIDE 35

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

Discovering permissions

slide-36
SLIDE 36

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

Three kinds of attestations:

  • On path, intersecting
slide-37
SLIDE 37

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

Three kinds of attestations

  • On path, intersecting
  • On path, not intersecting
slide-38
SLIDE 38

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

Three kinds of attestations

  • On path, intersecting
  • On path, not intersecting
  • Not on a path
slide-39
SLIDE 39

Technique in a nutshell

Encrypt attestations In each attestation, include a secret that allows you to decrypt upstream attestations that have intersecting permissions (on path, intersecting)

slide-40
SLIDE 40

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

slide-41
SLIDE 41

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

slide-42
SLIDE 42

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

slide-43
SLIDE 43

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

slide-44
SLIDE 44

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

slide-45
SLIDE 45

Attempt 1: public-key encryption

Building Owner Tenant Company CEO EncPK(NS/Floor3) EncPK(NS/Floor3) EncPK(NS/Floor4) F3 Manager HVAC Controller EncPK(NS/Floor3) Janitorial Services EncPK(NS/Floor3) SK, PK SK, PK SK, PK SK, PK SK, PK Consider that all the encrypted attestations are in a public ledger, so HVAC can see them all What is the problem with this approach? HVAC needs to decrypt the entire path to create a proof of authorization, but it cannot

slide-46
SLIDE 46

Attempt 2: public-key encryption

Building Owner Tenant Company CEO EncPK(NS/Floor3) EncPK(NS/Floor3, SK) EncPK(NS/Floor4) F3 Manager HVAC Controller EncPK(NS/Floor3, SK) Janitorial Services EncPK(NS/Floor3) SK, PK SK, PK SK, PK SK, PK SK, PK Now HVAC controller can decrypt the whole path What is the problem with this approach? It can decrypt too much. Basically, all the attestations F3 manager and Tenant CEO ever received, even if not intersecting!

slide-47
SLIDE 47

Insights

  • The encryption & secret must capture the permissions
  • It will not be tight, but the idea is to reduce the visibility of

any entity only to permissions that are potentially relevant

  • It is an example of encrypting on a public ledger while still

allowing relevant entities to decrypt

  • We use Identity Based Encryption (IBE) and Wildcard

Identity Based Encryption (WIBE) [Abdalla, 2006]

slide-48
SLIDE 48

IBE

IBE = identity based encryption

  • Encrypt with someone’s identity instead of PK
  • Setup() -> msk, mpk by a trusted key generator
  • Enc(mpk, ID; m) -> c, where ID is a string, the identity
  • KeyGen(msk, ID) -> skID
  • Dec(c, skID)->m

Security: semantic security for message m, but ID revealed

slide-49
SLIDE 49

WIBE

  • Setup() -> msk, mpk by a trusted key generator
  • Enc(mpk, ID; m) -> c, where ID = (ID1, …, IDn)
  • KeyGen(msk, ID*) -> skID*, where ID* is a vector of strings with some

wildcards

  • Dec(skID*, c) -> m, if ID* matches ID

Security: semantic security for message m, but all IDs revealed

slide-50
SLIDE 50

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3 How can we apply WIBE here? Who is the private key generator? Each user has its own WIBE system. How do we generate secret keys?

slide-51
SLIDE 51

The encryption & secret must capture the permissions

  • Every entity has a WIBE master key

○ No PKG, every entity has their own system

  • When you create an attestation from A to B with permissions

○ Form WIBE ID = P(permissions) ○ KeyGen(msk, ID) -> sk ○ Include sk in attestation ○ Encrypt attestation using WIBE params for recipient using same ID This is simplified, please see paper for more details

slide-52
SLIDE 52

RDE = Nesting IBE and WIBE

Highly technical. You don’t need to understand details, just get a sense.

IBE.Enc(IBE.mpksubject, NS; [read; NS, floor3, *, *; 2019, Jan, *, *]=P, WIBE.Enc(WIBE.mpksubject,P; WIBE.KeyGen(WIBE.mskissuer, ID*i) for IDi* that could decrypt current attestation, Attestation A, IBE.KeyGen(IBE.mskissuer; NS) ) ) issuer subject Attestation A (read, NS/floor3/*, 2019/Jan/*) IBE protects URLs WIBE protects keys preissuer

slide-53
SLIDE 53

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

Encrypted using: ID: F(NS/Floor3) Params: Controller Contains secret key: ID: F(NS/Floor3) MSK: F3 Manager

slide-54
SLIDE 54

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

Encrypted using: ID: F(NS/Floor3) Params: F3 Manager Contains secret key: ID: F(NS/Floor3) MSK: CEO

slide-55
SLIDE 55

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

Encrypted using: ID: F(NS/Floor3) Params: CEO Contains secret key: Not necessary

slide-56
SLIDE 56

Encrypted using: ID: F(NS/Floor4) Params: CEO Cannot be decrypted: wrong resource

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

slide-57
SLIDE 57

Encrypted using: ID: F(NS/Floor3) Params: Janitorial Services Cannot be decrypted: No key from Janitorial Services

Reverse Discoverable Encryption

Building Owner Tenant Company CEO NS/Floor3 NS/Floor3 NS/Floor4 F3 Manager HVAC Controller NS/Floor3 Janitorial Services NS/Floor3

slide-58
SLIDE 58

Reverse Discoverable Encryption Summary

  • Allows entities to decrypt attestations that they can use in a proof
  • Does not require out of band communication
  • Works when attestations are granted in any order

Full version (in paper) supports expiry of attestations

slide-59
SLIDE 59

We need a place to store the encrypted attestations

slide-60
SLIDE 60

A “classical” blockchain (e.g. Ethereum) nearly works

  • Our earlier work used a blockchain

○ Cryptographically proven integrity ○ No central authorities

  • Unfortunately it didn’t scale well

○ Blockchains don’t really go past a few tens of transactions per second ○ Especially if transactions are large (attestation objects)

slide-61
SLIDE 61

Unequivocable Log Derived Map (ULDM)

Horizontally scalable public ledger with cryptographic integrity proofs Similar to Certificate Transparency or Key Transparency, except: 1) Over CT, it supports efficient proof of non-existence, which allows revocation 2) Over KT, no need for monitoring by clients in every epoch ULDM aims to provide similar guarantees to a blockchain, when only storing

  • bjects
slide-62
SLIDE 62

High Level Overview

Clients Storage servers

slide-63
SLIDE 63

High Level Overview

Clients Auditors Storage servers

slide-64
SLIDE 64

Constructed using three Merkle trees

0: Attestation

Merkle Tree Log Can prove:

  • Append-only
  • Value exists in log

Merkle Tree Map Can prove:

  • Value does not exist
  • Value exists

Merkle Tree Log Can prove:

  • Append-only
  • Value exists in log

Operation Log

1: Attestation 2: Entity 3: Revocation

...

Object Map

Hash -> Attestation Hash -> Attestation Hash -> Entity Hash -> Revocation

...

Map Root Log

0: H(Map0) 1: H(Map1) 2: H(Map2) 3: H(Map3)

...

Root Root Root

slide-65
SLIDE 65

Operation Log ~ Certificate Transparency

Storage server stores Merkle tree, which acts like append-only log Server publishes signed MH Root on every epoch to auditors Auditors check that current tree is an extension of the previous tree against the two Merkle roots. How?

grows only this way

slide-66
SLIDE 66

Constructed using three Merkle trees

0: Attestation

Merkle Tree Log Can prove:

  • Append-only
  • Value exists in log

Merkle Tree Map Can prove:

  • Value does not exist
  • Value exists

(Lookup is by hash of value) Merkle Tree Log Can prove:

  • Append-only
  • Value exists in log

Operation Log

1: Attestation 2: Entity 3: Revocation

...

Object Map

Hash -> Attestation Hash -> Attestation Hash -> Entity Hash -> Revocation

...

Map Root Log

0: H(Map0) 1: H(Map1) 2: H(Map2) 3: H(Map3)

...

Root Root Root HOW?

slide-67
SLIDE 67

Auditor replays operation log to construct replica

0: Attestation

Operation Log

1: Attestation 2: Entity 3: Revocation

...

Object Map

Hash -> Attestation Hash -> Attestation Hash -> Entity Hash -> Revocation

...

Map Root Log

0: H(Map0) 1: H(Map1) 2: H(Map2) 3: H(Map3)

...

Ensures Object Map is properly derived from operation log Clients send Root Hash of Map Root Log to auditors periodically (daily)

  • Ensures every client is seeing the same data structure

Root Root Root

slide-68
SLIDE 68

Revocation = the ability to revoke an attestation

Ideas? We can place the revoked attestation on the ledger with the message ``revoked’’ The ledger supports proofs of non-inclusion which helps Issues with this?

  • Need to protect the attestation still, so some sort of RDE?
  • Need to make sure that only permitted entity revokes it.

Another idea is for the issuer of the attestation to include a nonce in the attestation, and sign that nonce with the revocation message and put in the ledger Issues with this?

  • The authorization verifier needs to lookup the signature in the ledger, but

does not know what it is

slide-69
SLIDE 69

Revocation in WAVE

Each attestation contains h(s) for s a random seed When revoking, place s in storage indexed by h(s) Anyone wishing to check that the attestation was not revoked will query by h(s) and check that s is the hash preimage

slide-70
SLIDE 70

Unequivocable Log Derived Map Summary

  • Stores encrypted attestations, public entity
  • bjects, revocations
  • Uses cryptographic proofs of integrity
  • Forces operators to be honest, or be

detected as dishonest

  • Auditing requires infrequent communication

between clients and auditors

slide-71
SLIDE 71

WAVE is implemented

We’ve used various versions of WAVE over the course of three years: >200 devices, 20 buildings, multiple namespaces and organizations It’s written in Go, with some crypto in C++ github.com/immesys/wave

slide-72
SLIDE 72

It’s pretty fast

  • Graph-changing operations - very fast by UI standards:

○ Creating an entity takes 9ms ○ Creating an attestation takes 43 ms ○ Decrypting an attestation takes 6ms

  • Proof building / verification:
slide-73
SLIDE 73

Conclusion

WAVE is a decentralized authorization system that

  • ffers transitive delegation by using graph based authorization
  • Stores the graph in global storage with cryptographically enforced integrity
  • Encrypts attestations, hiding the graph
  • It can be used in place of most traditional authorization systems