Ghostor: Toward a Secure Data-Sharing System from Decentralized Trust

*Yuncong Hu, *Sam Kumar, and Raluca Ada Popa

University of California, Berkeley

*Co-primary authors

1

Motivating Example: Medical Record System

Alice

Oncologist

2

Storage Server

Threat Model

Alice

OncologistStorage Server

3

Existing Systems rely on Centralized Trust

Alice

Oncologist

Central Point of Trust!

Adversary can:• See files and who

accesses them• Serve old or

modified data

4

Storage Server

End-to-End Encryption [CFS, SiRiUS, Plutus, etc.]

Storage Server

File A:

File B:

ACL:

ACL:

Content:

Content:

Bob, Oncologist

Alice, Oncologist

Alice

Oncologist

5

Privacy Leakage in E2EE Data Sharing

Storage Server

File B:

ACL:

Content:

Alice, Oncologist

Alice

Oncologist

Alice has access to File BOncologist has access to File BAlice accesses File BOncologist accesses File B

6

Ghostor: Cryptographic Data-Sharing System

• Anonymity

• Verifiable Linearizability

7

Ghostor: Cryptographic Data-Sharing System

• Anonymity

• Verifiable Linearizability

8

Privacy Leakage in E2EE Data Sharing

Storage Server

File B:

ACL:

Content:

Alice, Oncologist

Alice

Oncologist

Alice has access to File BOncologist has access to File BAlice accesses File BOncologist accesses File B

9

E2EE Data Sharing vs. Ghostor’s Anonymity

Storage Server

Alice

Oncologist

Alice has access to File BOncologist has access to File BAlice accesses File BOncologist accesses File B

E2EE Data Sharing

10

E2EE Data Sharing vs. Ghostor’s Anonymity

Storage Server

Alice

Oncologist

Alice has access to File BOncologist has access to File BAlice accesses File BOncologist accesses File B

E2EE Data Sharing

Storage Server

Alice

Oncologist

UNKNOWN has access to File BUNKNOWN accesses File BUNKNOWN accesses File B

What files did Alice access?Is she part of the system?

Ghostor’s Anonymity

11

E2EE Data Sharing vs. Ghostor’s Anonymity

Storage Server

Alice

Oncologist

Alice has access to File BOncologist has access to File BAlice accesses File BOncologist accesses File B

E2EE Data Sharing

Storage Server

UNKNOWN has access to File BUNKNOWN accesses File BUNKNOWN accesses File B

What files did Alice access?Is she part of the system?

Ghostor’s Anonymity

12

E2EE Data Sharing vs. Ghostor’s Anonymity

Storage Server

Alice

Oncologist

Alice has access to File BOncologist has access to File BAlice accesses File BOncologist accesses File B

E2EE Data Sharing

Storage Server

UNKNOWN has access to File BUNKNOWN accesses File BUNKNOWN accesses File B

What files did Alice access?Is she part of the system?

Ghostor’s Anonymity

13

Ghostor-MH is a theoretical scheme that also hides

access patterns (see paper)

Ghostor: Cryptographic Data-Sharing System

• Anonymity

• Verifiable Linearizability

14

Verifiable Linearizability

Storage Server

File A:

File B:

ACL:

ACL:

Content:

Content:

Bob, Oncologist

Alice, Oncologist

No allergy

Alice

Oncologist

Allergic to X

15

Verifiable Linearizability

Storage Server

File A:

File B:

ACL:

ACL:

Content:

Content:

Bob, Oncologist

Alice, OncologistNo allergy

Alice

Oncologist Allergic to XUser can detect if he receives anything other than the latest write

16

Comparison to Existing Work

17

Rely on Central Trust• Split server into two

parts and assume one is honest, or

• Assume semi-honest adversary

Ghostor

Anonymity andVerifiable Linearizability

Verena [KFPC16]: Verifiable Linearizability

AnonymousCloud [KH12]: Anonymity

Based on Decentralized Trust• Avoids placing trust in a

few central machines

Bootstrapping Decentralized Trust

Storage System based on

Decentralized Trust

Blockchain

Transparency Logs Peer-to-Peer Bootstrap

18

Strawman: Use a Blockchain

User’s Machine

GhostorClient

Blockchain

read, write, create files

Expensive!

19

Ghostor’s System Architecture

GhostorStorage Server

User’s Machine

GhostorClient

Blockchain

checkpoint

checkpoint

20

One checkpoint for the entire system once per epoch

summary of operations

checkpoint

• History for each object is recorded as a hash chain of digests

• History is committed to blockchain at the end of each epoch

Server Storage

Blockchain

Alice’s Client Doctor’s Client

Chmod

Hash(Object)[first operation]

Signed by Alice

Signed by Server

Read

Hash(Object)Hash(Previous Digest)

Signed by Doctor

Signed by Server

Write

Hash(Object)Hash(Previous Digest)

Signed by Alice

Signed by Server

Read

Hash(Object)Hash(Previous Digest)

Signed by Doctor

Signed by Server

End of Epoch 1

Checkpoint: Epoch 1Hash(Latest Digest)

Chmod

Signed by Alice

Signed by Server

Write

Signed by Alice

Signed by Server

Read

Signed by Doctor

Signed by Server

Read

Signed by Doctor

Signed by Server

Verifiable History (Strawman)

21

How to make Verifiable History Anonymous?

• Signing keys are like capabilities

• Idea: have different users share capabilities for each object

22

Shared Capabilities

23

Header:

Content:

Object Data

PKAlice PKDoctor

WSK

Key-Private Encryption

WSK Padding

PSK

Stored by the object’s owner

RSK

RSK

RSK

Might reveal users’ public keys!

Permission Signing Key

Reader Signing Key

Writer Signing Key

Anonymously Distributed Shared Capabilities

• History for each object is recorded as a hash chain of digests

• History is committed to blockchain at the end of each epoch

Server Storage

Blockchain

Alice’s Client Doctor’s Client

Chmod

Hash(Object)[first operation]

Signed by Alice

Signed by Server

Read

Hash(Object)Hash(Previous Digest)

Signed by Doctor

Signed by Server

Write

Hash(Object)Hash(Previous Digest)

Signed by Alice

Signed by Server

Read

Hash(Object)Hash(Previous Digest)

Signed by Doctor

Signed by Server

End of Epoch 1

Checkpoint: Epoch 1Hash(Latest Digest)

Chmod

Signed by Alice

Signed by Server

Write

Signed by Alice

Signed by Server

Read

Signed by Doctor

Signed by Server

Read

Signed by Doctor

Signed by Server

Verifiable History (Strawman)

24

• History for each object is recorded as a hash chain of digests

• History is committed to blockchain at the end of each epoch

Server Storage

Blockchain

Alice’s Client Doctor’s Client

Chmod

Hash(Object)[first operation]

Signed byPSK

Signed by Server

Read

Hash(Object)Hash(Previous Digest)

Signed byRSK

Signed by Server

Write

Hash(Object)Hash(Previous Digest)

Signed byWSK

Signed by Server

Read

Hash(Object)Hash(Previous Digest)

Signed byRSK

Signed by Server

End of Epoch 1

Checkpoint: Epoch 1Hash(Latest Digest)

Chmod

Signed by PSK

Signed by Server

Write

Signed by WSK

Signed by Server

Read

Signed by RSK

Signed by Server

Read

Signed by RSK

Signed by Server

Verifiable Anonymous History

25

Additional Challenge: Concurrent Operations

26

Server Storage

Alice’s Client Doctor’s Client

Chmod

Hash(Object)[first operation]

Signed by PSK

Signed by Server

ReadHash(Previous)

Signed by RSK

ReadHash(Previous)

Signed by RSK

• Suppose Alice and Doctor read the object concurrently

• Both see the same latest digest

Additional Challenge: Concurrent Operations

27

Server Storage

Alice’s Client Doctor’s Client

Chmod

Hash(Object)[first operation]

Signed by PSK

Signed by Server

• Suppose Alice and Doctor read the object concurrently

• Both see the same latest digest

ReadHash(Previous)

Signed by RSK

ReadHash(Previous)

Signed by RSK

Additional Challenge: Concurrent Operations

28

Server Storage

Alice’s Client Doctor’s Client

Chmod

Hash(Object)[first operation]

Signed by PSK

Signed by Server

• Suppose Alice and Doctor read the object concurrently

• Both see the same latest digest

Read

Hash(Object)Hash(Previous Digest)

Signed by RSK

Signed by Server

ReadHash(Previous)

Signed by RSK

Wrong Hash(Previous)!

Insight: Client Signs over only Some Fields

29

Hash(Object)Hash(Previous)

Server

ReadNonce

RSK

Read

Hash(Object)Hash(Previous Digest)

Signed by RSK

Signed by Server

becomes

Concurrent Reads in Ghostor

30

Server Storage

Alice’s Client Doctor’s Client

Chmod

Hash(Object)[first operation]

Server

• Suppose Alice and Doctor read the object concurrently

• Both see the same latest digest

ReadNonce

RSK

ReadNonce

RSK

PSK

Concurrent Reads in Ghostor

31

Server Storage

Alice’s Client Doctor’s Client• Suppose Alice and Doctor read the object concurrently

• Both see the same latest digest

Hash(Object)Hash(Previous)

Server

Hash(Object)Hash(Previous)

Server

ReadNonce

RSK

ReadNonce

Read

RSKServer

Read

RSKServer

RSK

Chmod

Hash(Object)[first operation]

ServerPSK

This Technique Does Not Work for Writes

32

Server Storage

Alice’s Client Doctor’s Client• Suppose Alice writes the file

WriteNonceHash(Object) WSK

Chmod

Hash(Object)[first operation]

ServerPSK

This Technique Does Not Work for Writes

33

Server Storage

Alice’s Client Doctor’s Client• Suppose Alice writes the file

Hash(Previous)

Server

Hash(Previous)

Server

WriteNonceHash(Object) WSK

WriteNonceHash(Object)

Write

WSKServer

Hash(Previous)

Server

WriteNonceHash(Object) WSKWSK

WriteNonceHash(Object) WSK

Time-Stretch Attack

Chmod

Hash(Object)[first operation]

ServerPSK

Write

WSKServer

Concurrent Writes in Ghostor

34

Server Storage

Alice’s Client Doctor’s Client• Suppose Alice writes the file

Hash(Previous)

Server

Hash(Previous)

Server

PrepareHash(Object)

WSK

CommitHash(Object)Hash(Prepare)

Prepare

WSKServer

WSK

Commit

WSKServer

Hash(Object)Hash(Previous)

Server

ReadNonce

RSK

Read

RSKServer

Chmod

Hash(Object)[first operation]

ServerPSK

Ghostor Stack

Anonymously Distributed Shared Capabilities

Verifiable Anonymous History

Concurrent Operations

Preventing Resource Abuse

Hiding Network Information

Ghostor-MH

35

Ghostor Stack

Anonymously Distributed Shared Capabilities

Verifiable Anonymous History

Concurrent Operations

Preventing Resource Abuse

Hiding Network Information

Ghostor-MH

36

Described in our paper

Implementation

• Implemented Ghostor prototype in Go

• Built on top of Ceph RADOS• Linearizable, distributed, fault-tolerant object store

• Benchmarked on Amazon EC2 in multi-node, multi-SSD setup

37

Server-Side Latency to PUT a 1 MiB Object

0

10

20

30

40

50

Insecure End-to-EndEncryption

Anonymity ForkConsistency

VerifiableLinearizability

Ghostor

Late

ncy

(m

s)

38

Small Overhead

Small Overhead

Server-Side Latency to PUT a 1 MiB Object

0

10

20

30

40

50

Insecure End-to-EndEncryption

Anonymity ForkConsistency

VerifiableLinearizability

Ghostor

Late

ncy

(m

s)

39

25 ms

Total Latency

• To hide network information, Ghostor clients use the Tor anonymity network to contact the server

• With Tor, overall latency is several seconds

40

Conclusion

Ghostor is a cryptographic data sharing system based on decentralized trust

It achieves:

• Anonymity: server cannot tell which user makes an access

• Verifiable Linearizability: users detect if they don’t receive the latest data

Ghostor’s techniques could significantly boost the security guarantees of:

41Keybase

Conclusion

Ghostor is a cryptographic data sharing system based on decentralized trust.

It achieves:

• Anonymity: server cannot tell which user makes an access

• Verifiable Linearizability: users detect if they don’t receive the latest data

This material is based on work supported by the National Science Foundation Graduate Research Fellowship Program under Grant No. DGE-1752814. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.

Thank you!

42