A Universally Composable Framework for the Privacy of Email - - PowerPoint PPT Presentation

a universally composable framework for the privacy of
SMART_READER_LITE
LIVE PREVIEW

A Universally Composable Framework for the Privacy of Email - - PowerPoint PPT Presentation

A Universally Composable Framework for the Privacy of Email Ecosystems Pyrros Chaidos 1 , Olga Fourtounelli 1 , Aggelos Kiayas 2 , Thomas Zacharias 2 1 : National & Kapodistrian University of Athens 2 : University of Edinburgh This project


slide-1
SLIDE 1

A Universally Composable Framework for the Privacy of Email Ecosystems

Pyrros Chaidos 1, Olga Fourtounelli 1, Aggelos Kiayas 2, Thomas Zacharias 2

1: National & Kapodistrian University of Athens 2: University of Edinburgh

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 653497 (project PANORAMIX)

slide-2
SLIDE 2

It’s 2019 (almost)

Email Security 1-2-3

  • Secure storage (Serious Business)
  • Encrypt payload (Maybe?)
  • Protect metadata (Not really)

Photo Credit: Steve Jennings

slide-3
SLIDE 3

Emails & Security

  • Secure storage (Not this talk)
  • Encrypted payload (Not this talk)
  • Protected metadata (This talk)
  • To: / From: / Time / Size / Device used
  • Does it matter?
slide-4
SLIDE 4

Maybe it doesn’t

“one of the strongest predictors of whether or not you are going to be sensitive to surge - in

  • ther words, whether or not you are going to

kind of say, oh, 2.2, 2.3, I'll give it a 10 to 15 minutes to see if surge goes away - is how much battery you have left on your cell phone.”

  • Keith Chen, Former head of Research, Uber,

NPR interview (2016) “we absolutely don't use that to kind of like push you a higher surge price, but it's an interesting kind of psychological fact”

slide-5
SLIDE 5

Maybe it does

“We kill people based on metadata”

–Gen. Michael Hayden, former Director of NSA, CIA (2014)

slide-6
SLIDE 6

Global Passive Adversaries

  • Uber? CIA? Facebook? Metadata often becomes

valuable only after cross-validating with different targets/ sources → think big.

  • Applying this to metadata: GPA
  • Assume all links are tapped.
slide-7
SLIDE 7

Outline

  • 1. Develop UC framework to describe email privacy against strong

surveillance.

  • 2. Give variants for different levels of privacy/ practicality.
  • 3. Use framework to analyze different systems.
slide-8
SLIDE 8

Security from ! to " (aka the UC model)

  • UC security: Simulation vs Environment (")
  • Extremely easy to model GPA via Environment
  • Even stronger than classical GPA: " controls user behavior
  • We specify the interface and operation of the system via an ideal (but

potentially leaky) functionality

  • We then specify the exact security level via leakage functions
  • Security goal: given the leakage we can simulate the rest of "’s view
slide-9
SLIDE 9

Entities

  • Clients (i.e. end user computers/phones )
  • Assumed “thin”, i.e. not much more than E2E capabilities
  • Talk only to their Provider
  • Providers
  • Host inboxes & outboxes
  • Talk to Clients, Mix Nodes and potentially other SPs
  • Mix Nodes
  • Exchange messages
  • Talk to Providers only
  • Adversary

We assume communication is authenticated. For this talk, adversary ! is passive only

slide-10
SLIDE 10

Protocols & UC Security

  • Register: establish CL-SP relation
  • Send: push a message from client to SP outbox
  • Route: pass message from SP to SP via MXs
  • Receive: fetch message from inbox to client

In the UC setting, we describe an ideal functionality ℱ that describes how an email system “should” behave. Ideal functionality ℱ receives request “do X”, logs it, allows " to delay/reorder, performs request, calls leakage function.

slide-11
SLIDE 11

Real World Overview ! "

slide-12
SLIDE 12

Ideal World Overview ! " ℱ

$%&

slide-13
SLIDE 13

UC Security

  • Simulator can present a convincing view to the environment, with

very limited information (only what we specify via Leak).

slide-14
SLIDE 14

UC Security

  • Simulator can present a convincing view to the environment, with

very limited information (only what we specify via Leak).

slide-15
SLIDE 15

Defining Security via Leakage

  • Ideal functionality handles everything internally, but simulator needs

to simulate the real world.

  • Simulator knows the protocol
  • We give “hints” via leakage
  • Leakage function is called when:
  • Ideal function progresses (e.g pending message is delivered)
  • Time passes
  • Leakage function takes entire history as argument (in practice, last

few lines)

slide-16
SLIDE 16

Leakage Specifics

  • Unobserveability: reveal only Logged in / Logged out status of users

Leak%&'([event_ptr, 1] ≔ ActiveSet898&:_;:<[1]

  • Weak Anonymity: reveal # of outgoing and incoming msgs of users

=>?@A.CDED >FGH, 1 ≔ IJKGLM>N>GOPQR 1 , N>STUV>GOPQR 1 , W>K>LM>UN>GOPQR 1 , X>GKℎN>GOPQR 1 , at round end JKGLM>N>GOPQR 1 , N>STUV>GOPQR 1 , X>GKℎN>GOPQR 1 ,

  • therwise

i.e. sender is leaked immediately (so simulator can start faking the system), but receiver is leaked in batches

slide-17
SLIDE 17

Leakage Taxonomy

Unobservability Anonymity Weak Anonymity E2E Encryption

Sender Unlinkability Leaks Msg-Receiver Receiver Unlinkability Leaks Msg-Sender

slide-18
SLIDE 18

Leakage Taxonomy

Unobservability Leaks online/offline Anonymity Leaks Send/Receive Weak Anonymity Leaks Send/Receive # E2E Encryption Leaks Sender Unlinkability Receiver Unlinkability

slide-19
SLIDE 19
slide-20
SLIDE 20

System 1: Unobservability via Broadcast

  • Active users will either send one email or not.
  • The SP of an active user with an outgoing email will send the mail to

the recipient SP, and dummy mails to the other SPs.

  • The SP of an active user with no outgoing emails will send dummies

to all SPs. Simulation strategy: rely on encryption security and send dummies all the time. Only information needed is active status.

slide-21
SLIDE 21

System 2: Parallel Shuffle

  • MX nodes organized in strata
  • Each server re-encrypts messages, and evenly distributes them to the

next stratum.

  • Last stratum delivers back to SPs
slide-22
SLIDE 22
slide-23
SLIDE 23

System 2: Parallel Shuffle (take 2)

  • MX nodes organized in strata
  • Each server re-encrypts messages, and evenly distributes them to the

next stratum.

  • Last stratum delivers back to SPs
  • Simulation strategy: seems hard, we don’t know where messages

come from or go to. Fortunately, it doesn’t matter.

slide-24
SLIDE 24

Card Shuffling Internals

Lattice Shuffle (Håstad 2005) Shuffle !" cards using ! servers and multiple rounds. Rounds vary with desired closeness to uniform output

slide-25
SLIDE 25

Card Shuffling Internals

slide-26
SLIDE 26

Card Shuffling Internals

slide-27
SLIDE 27

System 2: Parallel shuffle

  • MX nodes organized in strata
  • Each server re-encrypts messages, and evenly distributes them to the

next stratum.

  • Last stratum delivers back to SPs
  • Simulation strategy: We don’t know where messages come from or go
  • to. But, because they end up shuffled, we can just use a random
  • rder for the final stratum and simulate from there.
slide-28
SLIDE 28

Recap

  • It’s (almost) 2019
  • Metadata is important
  • We present a UC framework to describe email privacy.
  • Our framework is flexible in terms of leakage (i.e security level)
  • We analyze two systems to demonstrate practicality.