Atom Horizontally Scaling Strong Anonymity Albert Kwon - - PowerPoint PPT Presentation

atom
SMART_READER_LITE
LIVE PREVIEW

Atom Horizontally Scaling Strong Anonymity Albert Kwon - - PowerPoint PPT Presentation

Atom Horizontally Scaling Strong Anonymity Albert Kwon Henry Corrigan-Gibbs MIT Stanford Srinivas Devadas Bryan Ford MIT EPFL 10/30/17,


slide-1
SLIDE 1

Atom

Horizontally Scaling Strong Anonymity

Albert Kwon Henry Corrigan-Gibbs MIT Stanford Srinivas Devadas Bryan Ford MIT EPFL 10/30/17, SOSP’17

slide-2
SLIDE 2

Motivation

2

Anonymous bulletin board (broadcast) in the face of global adversary

Protest at 4 p.m.!

slide-3
SLIDE 3

Anonymous communication networks

3

Anonymity provider (set of servers)

slide-4
SLIDE 4

Existing systems vs. Atom

4

Properties Tor [USENIX Sec’04] Atom Riposte [Oakland’15] Scaling Anonymity against global adversaries Latency (1 million users) Horizontal Vulnerable Vertical Horizontal Secure Secure < 10s 11 hrs 28min

slide-5
SLIDE 5
  • A large number of users

are malicious

Deployment and threat model

  • Constant fraction of the

servers are malicious

○ 20%

5

  • Global network adversary
slide-6
SLIDE 6

Atom overview

6

slide-7
SLIDE 7

...

4 1 3 2

Atom overview

7

1 2 3 4 4 1 3 2 Unknown random permutation

  • f all inputs

2 1 4 3

Layer 1 Layer 2 Layer L

slide-8
SLIDE 8

Horizontally scalability

8

... ... ... ...

Width Depth

More servers => Larger width Fixed (Independent of the width)

slide-9
SLIDE 9

Challenges

9

  • 1. Guaranteeing anytrust property

slide-10
SLIDE 10

Challenges

10

  • 1. Guaranteeing anytrust property
  • 2. Group mixing and routing protocol

2 1 1 2 1 2 1 2 1 2

slide-11
SLIDE 11

Challenges

11

  • 1. Guaranteeing anytrust property
  • 2. Group mixing and routing protocol
  • 3. Active adversaries

1 2

slide-12
SLIDE 12

...

Active attacks

12

1 2 3 4

1

1 1

slide-13
SLIDE 13

Challenges

13

  • 1. Guaranteeing anytrust property
  • 2. Group mixing and routing protocol
  • 3. Active adversaries
  • 4. Tolerating server churn

1

slide-14
SLIDE 14

Challenges

14

  • 1. Guaranteeing anytrust property
  • 2. Group mixing and routing protocol
  • 3. Active adversaries
  • 4. Tolerating server churn

1

slide-15
SLIDE 15

Generating anytrust groups

15

Randomly select k servers

Pr[group is fully malicious] = 0.2k Pr[any group is fully malicious] < (# of groups) · 0.2k < 2-64

k = 32 20% malicious

Public randomness

slide-16
SLIDE 16

Handling actively malicious servers

16

Trusted third party

$ & @ # Trap messages (nonces)

...

$ & @ # Idea: use verifiable trap messages

slide-17
SLIDE 17

$ & @ # 1 4 3 2

Send trap and real messages in a random order

17

...

: encrypted for TTP

$ & @ #

Trusted third party

slide-18
SLIDE 18

TTP checks for the traps

18

...

: encrypted for TTP

$ & @ #

Trusted third party

3 2 4 & $ 1 @ #

slide-19
SLIDE 19

What happens when a trap message is dropped?

19

...

: encrypted for TTP

$ & @ #

Trusted third party

3 2 4 & $ 1 @ #

slide-20
SLIDE 20

What happens when a real message is dropped?

20

...

: encrypted for TTP

$ & @ #

Trusted third party

3 2 4 & $ 1 @ #

slide-21
SLIDE 21

Improving the trap messages

21

  • Distributing the trust in the third party
  • Distributing the trap verification and decryption
slide-22
SLIDE 22

Properties of trap-based defense

22

  • If the adversary tampers with any trap, then no plaintext

revealed

  • Can remove 1 message with probability ½

○ Remove t messages with probability 2-t ○ Realistically remove < ~64 msgs

  • Reactive
slide-23
SLIDE 23

Two modes of operation

23

Trap messages Zero-knowledge Proof Idea Verify untamperable traps Verify protocol with ZKP Anonymity set size N - t N Defense type Reactive Proactive Latency 1x 4x

slide-24
SLIDE 24

Implementation

  • ~4000 lines of Go
  • Both trap and ZKP based defenses
  • Code available at github.com/kwonalbert/atom

24

slide-25
SLIDE 25

Evaluation setup

  • Heterogenous set of 1024 EC2 servers

○ 80% of the servers were 4-core machines

  • 20% malicious servers
  • Trap messages
  • 160-byte msgs

25

Depth = 10

32 server group

… … … …

slide-26
SLIDE 26

Latency is inversely proportional to the number of servers

26

Better

23x

slide-27
SLIDE 27

Latency scales linearly with the number of users

27

Better

slide-28
SLIDE 28

Limitations

  • Medium to high latency

28

  • Denial-of-service

Depth = 10

32 server group

slide-29
SLIDE 29

Related work

  • Strong anonymity but veritically scaling

○ Dissent[OSDI’12], Riffle [PETS’16], Riposte [Oakland’15], ...

  • Horizontally scaling systems but weaker anonymity

○ Crowds [ACM’99], Mixminion [Oakland’03], Tor [USENIX Sec’04], Aqua [SIGCOMM’13], Loopix [USENIX Sec’17], …

  • Distributed mixing

○ Parallel mix-net [CCS’04], matrix shuffling [Håstad’06], random switching networks [SODA’99, CRYPTO’15], ...

  • Private point-to-point messaging

○ Vuvuzela [SOSP’15], Pung [OSDI’16], Stadium [SOSP’17]

29

slide-30
SLIDE 30

Conclusion

  • Atom provides horizontally-scaling strong anonymity

○ Global anonymity set ○ Latency is inversely proportional to the number of servers

  • Supports 1 million users with 160 byte msgs in 28min

github.com/kwonalbert/atom

30

slide-31
SLIDE 31

31

These icons were acquired from thenounprojcet.com, and are under CC BY 3.0 US Created by Anil Created by H Alberto Gongora Created by H Alberto Gongora Created by Andre Luiz Gollo Created by Creative Stall