A B Verschlsselung schtzt nur Inhalte, nicht die Metadaten! Wer - - PowerPoint PPT Presentation

a b
SMART_READER_LITE
LIVE PREVIEW

A B Verschlsselung schtzt nur Inhalte, nicht die Metadaten! Wer - - PowerPoint PPT Presentation

Anonymitt? nberwachbare Kommunikation! A B Verschlsselung schtzt nur Inhalte, nicht die Metadaten! Wer mit wem? Wann? Was? 1-hop proxy (VPN, SSH Tunnel etc) Alice1 Bob1 Y Alice2 Z Bob2 Relay


slide-1
SLIDE 1

Anonymität? Ünüberwachbare Kommunikation!

A B

slide-2
SLIDE 2

Verschlüsselung schützt nur Inhalte, nicht die Metadaten!

  • Wer mit wem?
  • Wann?
  • Was?
slide-3
SLIDE 3

1-hop proxy (VPN, SSH Tunnel etc)

Bob2 Bob1 Bob3 Alice2 Alice1 Alice3 Relay “Y” “ Z ” “X”

slide-4
SLIDE 4

Problem Vertrauenswürdigkeit und einfache Überwachbarkeit

Bob2 Bob1 Bob3 Alice2 Alice1 Alice3 Evil Relay?

Coerced Relay? Monitored Relay?

“Y” “ Z ” “X”

slide-5
SLIDE 5

Tor

slide-6
SLIDE 6

Tor

Bob Alice R1 R2 R3 R4 R5

slide-7
SLIDE 7

Tor

Bob Alice R1 R2 R3 R4 R5

slide-8
SLIDE 8

Tor

Bob Alice R1 R2 R3 R4 R5

slide-9
SLIDE 9

Tor

Bob Alice R1 R2 R3 R4 R5 Bob2

slide-10
SLIDE 10

Problem: (sufficiently) global passive adversaries

Bob Alice R1 R2 R3 R4 R5

slide-11
SLIDE 11
  • “Not secure against end-to-end attacks:

Tor does not claim to completely solve end-to-end timing or intersection attacks.“ (Tor Design Paper, 2004)

  • A global passive adversary is the most

commonly assumed threat when analyzing theoretical anonymity

  • designs. But like all practical low-

latency systems, Tor does not protect against such a strong adversary.“ (ebd.)

slide-12
SLIDE 12

“The results show that Tor faces even greater risks from traffic correlation than previous studies suggested. An adversary that provides no more bandwidth than some volunteers do today can deanonymize any given user within three months of regular Tor use with over 50% probability and within six months with over 80% probability.” (Users get routed: Traffic Correlation on Tor by Realistic Adversaries, 2013)

slide-13
SLIDE 13

Alternative: Broadcast-Architektur

Bob2 Bob1 Bob3 Alice2 Alice1 Alice3 E(Bob2, “Z”) E(Bob2, “Z”) E(Bob2, “Z”)

Beispiel Bitmessage

slide-14
SLIDE 14

Alternative: Mixnets

Bob Alice R1 R2 R3 (R4) (R5)

slide-15
SLIDE 15

Tor: Verbindungsaufbau

Bob Alice R1 R2 R3 (R4) (R5)

slide-16
SLIDE 16

Tor: Verbindungsaufbau

Bob Alice R1 R2 R3 (R4) (R5)

slide-17
SLIDE 17

Tor: Verbindungsaufbau

Bob Alice R1 R2 R3 (R4) (R5)

slide-18
SLIDE 18

Tor: Verbindungsaufbau

Bob Alice R1 R2 R3 (R4) (R5)

slide-19
SLIDE 19

Mixnets: nachrichtenbasiert statt paketbasiert !

Bob Alice R1 R2 R3 (R4) (R5)

slide-20
SLIDE 20

Bob Alice R1 R2 R3 (R4) (R5)

slide-21
SLIDE 21

Bob Alice R1 R2 R3 (R4) (R5)

slide-22
SLIDE 22

Bob Alice R1 R2 R3 (R4) (R5)

slide-23
SLIDE 23

Bob Alice R1 R2 R3 (R4) (R5)

slide-24
SLIDE 24

Bob Alice R1 R2 R3 (R4) (R5)

slide-25
SLIDE 25

Bob Alice R1 R2 R3 (R4) (R5)

slide-26
SLIDE 26

Bob Alice R1 R2 R3 (R4) (R5)

slide-27
SLIDE 27
slide-28
SLIDE 28

Mix-Strategien

  • Pool/Batching Mix

– sammle x Nachrichten (“threshold mix”) – warte x Minuten (“timed mix”)

(Mixmaster: timed + threshold: nur wenn x Nachrichten eingangen sind wird Queue nach Timeout geleert/versendet)

  • Stop & Go Mixes: Delay der einzelnen Hops

vom Nutzer vorgegeben

slide-29
SLIDE 29
  • 1

9 7 8 L i mi t a t i

  • n

s

  • f

E n d

  • t
  • E

n d E n c r y p t i

  • n

i n S e c u r e C

  • mp

u t e r N e t w

  • r

k s ( K a r g e r )

  • 1

9 8 1 U n t r a c e a b l e e l e c t r

  • n

i c ma i l , r e t u r n a d d r e s s e s a n d d i g i t a l p s e u d

  • n

y ms ( D a v i d C h a u m)

  • 1

9 8 5 N e t w

  • r

k s Wi t h

  • u

t U s e r O b s e r v a b i l i t y – D e s i g n O p t i

  • n

s ( P f i t z ma n n )

  • 1

9 9 1 I S D N

  • M

i x e s ( P f i t z ma n n )

  • [

1 9 9 5 “ I n i t i a l w

  • r

k

  • n

O n i

  • n

R

  • u

t i n g b e g i n s ” ]

  • 1

9 9 8 R e a l

  • T

i me M I X e s ( P f i t z ma n n ) h t t p : / / f r e e h a v e n . n e t / a n

  • n

b i b

slide-30
SLIDE 30
  • 1

9 9 2 a n

  • n

. p e n e t . f i ( T y p R e ma i l e r )

( 5 , N u t z e r , 8 N a c h r i c h t e n / T a g , ~ $ 1 / M

  • n

a t )

1

1 9 9 5 : C h u r c h

  • f

S c i e n t

  • l
  • g

y , L

  • s

A n g e l e s F B I F i n n l a n d → →

  • 1

9 9 2 C y p h e r p u n k s

  • R

e ma i l e r ( T y p 1 R e ma i l e r )

E i n f a c h e r R e ma i l e r , k e i n M i x i n g ( t i mi n g a n a l y s i s ) , k e i n P a d d i n g ( t r a f f i c → → a n a l y s i s )

  • 1

9 9 4 M i x ma s t e r ( T y p 2 )

  • 1

9 9 5 a n

  • n

y mi z e r , c 2 . n e t n y ms e r v e r

  • 2

2 M i x mi n i

  • n

( T y p 3 )

  • [

2 4 T

  • r

D e s i g n P a p e r ]

1

h t t p : / / f r e e h a v e n . n e t / a n

  • n

b i b / c a c h e / r e ma i l e r

  • h

i s t

  • r

y . h t ml

slide-31
SLIDE 31

Probleme Mixnets

  • Historisch:

– Keine Zustellungsgarantie – Lange Nachrichtenlaufzeiten (Tage!) – Komplizierte UIs, fehlende Integration – Spam-/Abuse-Problematik

  • Loopix Anonymity System (März 2017)

– Stop & Go – aktive Angriffe erkennen durch “loops” – “message latency in the order of seconds”

slide-32
SLIDE 32

Katzenpost

  • “echtes” Open Source Projekt

– Spezifikation auf Github – Implementierung in Go – [ Integration in K9 Mail ] – Finanzierung durch EU!

https://katzenpost.mixnetworks.org/