Expressive  Privacy  Control    with  Pseudonyms  

Seungyeop  Han,  Vincent  Liu,  Qifan  Pu,  Simon  Peter,    Thomas  Anderson,  Arvind  Krishnamurthy,  David  Wetherall  

University  of  Washington  

Internet  Tracking  is  Pervasive  

2  

Alice  

Bob  

Tracker  

User1:  UW,  CSE,  Route  to  [Alice’s  home]  User2:  SIGCOMM,  Hacking,  Depression  

Trackers  link  user  acTviTes  to  form  large  user  profiles  SIGCOMM  2013  

ImplicaTons  of  Tracking  for  Users  

•  Pros:    

 

3  

•  Cons:  

Lack  of  Privacy  

PersonalizaTon  

BeYer  Security  

Revenue  for  Service  

SIGCOMM  2013  

Threat  Model:  Trackers  Correlate  Unwanted  Traffic  

4  

Alice  

Bob  

Tracker  

User1:  UW,  CSE,  Route  to  [Alice’s  home]  User2:  SIGCOMM,  Hacking,  Depression  

SIGCOMM  2013  

Goal:  Give  Users  Control  over  How  They  are  Tracked  

5  

Alice  

Bob  

Tracker  

User1:  UW,  CSE    User2:  Route  to  [Alice’s  home]  User3:  SIGCOMM,  Hacking  User4:  Depression  

SIGCOMM  2013  

ImplicaTons  of  Giving  Users  Control  

•  Pros:    

 

6  

•  Cons:  

Lack  of  Privacy  

PersonalizaTon  

BeYer  Security  

Revenue  for  Service  

SIGCOMM  2013  

Current  Defenses  Provide    Insufficient  Control  

   Current  Defenses  – ApplicaTon  Layer:  Third-­‐party  cookie  blocking,  DoNotTrack  

– Network  Layer:  Tor,  Proxies  

   LimitaTons  – Coarse-­‐grained    – Not  cross-­‐layer  

7  SIGCOMM  2013  

Outline  

•  MoTvaTon  /  Background  •  Approach:  Cross-­‐Layer  Pseudonyms  •  System  Design  – ApplicaTon-­‐Layer  – Network-­‐Layer  

•  ImplementaTon  and  EvaluaTon  •  Conclusion    

8  SIGCOMM  2013  

Trackers  Link  User  Requests  

•  Important  idenTfiers  for  Web  tracking:  – ApplicaTon  info.  (cookie,  JS  localstorage,  Flash)  –  IP  Address    

9  

MulTple  requests  are  linkable  by  remote  trackers,  if  they  share  the  same  idenTfiers.  

Req.  1  (128.208.7.x),  header:  cookie(…)  

Req.  2  (128.208.7.x),  header:  cookie(…)  

User   Tracker  

SIGCOMM  2013  

Approach:  Pseudonym  AbstracTon  •  Pseudonym  =  A  set  of  all  idenTfying  features  that  persist  across  an  acTvity  

•  Allow  a  user  to  manage  a  large  number  of  unlinkable  pseudonyms  –  User  can  choose  which  ones  are  used  for  which  operaTons.  

 

10  

Pseudonym1  

IP1  

Cookie1  

Pseudonym2  

IP2  

Cookie2  

Alice   Tracker  Medical  informaTon  

LocaTon-­‐related  (Alice’s  home)  

SIGCOMM  2013  

How  We  Want  to  Use  Pseudonyms  

11  

ApplicaTon      

IP1  

Policy  Engine  

Alice  

     

OS  

IP  

Tracker  

Pseudonym1  

IP1  

Cookie1  

IP  IP   Pseudonym2  

IP2  

Cookie2  

DHCP   Routers  

SIGCOMM  2013  

2.  Network-­‐Layer  Design  

1.  Applica=on-­‐Layer  Design  

Medical  

LocaTon  

ApplicaTon-­‐Layer  Design  

•  ApplicaTon  needs  to  assign  different  pseudonyms  into  different  acTviTes.  – How  to  use  pseudonyms  depends  on  user  and  applicaTon.  

– APIs  are  provided  to  define  policies.    •  Policy  in  Web  browsing:  a  funcTon  of  the  request  informaTon  and  the  state  of  the  browser.  – Window  ID,  tab  ID,  request  ID,  URL,  whether  request  is  going  to  the  first-­‐party,  etc.  

12  SIGCOMM  2013  

Sample  Pseudonym  Policies  for  the  Web  

SIGCOMM  2013   13  

•  Default:  P1  =  P2  =  P3  •  Per-­‐Request:  P1  !=  P2  !=  P3  •  Per-­‐First  Party:  P1  =  P2  !=  P3  

ArTcle  on  PoliTcs  

facebook.com  

Likenews.com  

facebook.com  

P2  

P1  

P3  

Sample  Pseudonym  Policies  for  the  Web  

SIGCOMM  2013   14  

•  Default:  P1  =  P2  =  P3  •  Per-­‐Request:  P1  !=  P2  !=  P3  •  Per-­‐First  Party:  P1  =  P2  !=  P3  

ArTcle  on  PoliTcs  

facebook.com  

Likenews.com  

facebook.com  

P2  

P1  

P3  

Sample  Pseudonym  Policies  for  the  Web  

SIGCOMM  2013   15  

•  Default:  P1  =  P2  =  P3  •  Per-­‐Request:  P1  !=  P2  !=  P3  •  Per-­‐First  Party:  P1  =  P2  !=  P3  

Facebook  cannot  know    the  user’s  visit  to  news.com  

ArTcle  on  PoliTcs  

facebook.com  

Likenews.com  

facebook.com  

P2  

P1  

P3  

Pseudonyms  in  AcTon  

16  

ApplicaTon      

IP1  

Policy  Engine  

Alice  

     

OS  

IP  

Tracker  

Pseudonym1  

IP1  

Cookie1  

IP  IP   Pseudonym2  

IP2  

Cookie2  

DHCP   Routers  

SIGCOMM  2013  

2.  Network-­‐Layer  Design  

Network-­‐Layer  Design  ConsideraTon  

1.  Many  IP  addresses  for  an  end-­‐host  

2.  Proper  mixing  

3.  Efficient  rouTng  

4.  Easy  revocaTon  

5.  Support  for  small  networks    

17  SIGCOMM  2013  

Network-­‐Layer  Design  ConsideraTon  

1.  Many  IP  addresses  for  an  end-­‐host  

2.  Proper  mixing  

3.  Efficient  rouTng  

4.  Easy  revocaTon  

5.  Support  for  small  networks    

18  SIGCOMM  2013  

1)  IPv6  Allows  Many  IPs  per  Host    

IPv6  Address  

128bits  

19  

Small  networks  get  /64  address  space  (1.8e19)  

SIGCOMM  2013  

2,  3)  Symmetric  EncrypTon    for  Mixing  and  RouTng  

20  SIGCOMM  2013  

Network  Prefix  

To  route  the  packet    “within”  the  network  

To  route  the  packet    “to”  the  network  

Networks  can  use  this  part  as  they  want    

IPv6  Address  

128bits  

2,  3)  Symmetric  EncrypTon    for  Mixing  and  RouTng  

128bits  

Network  Prefix  

21  

Subnet   Host   Pseudonym  

Network  Prefix   Encrypted  ID    

Encrypt   Decrypt  Use  symmetric-­‐key  encryp=on  

•  End-­‐hosts  know  only  encrypted  IP  addresses  •  Router  uses  the  base  addresses  to  forward  packets  –  By  longest-­‐prefix  matching  with  subnet::host,  thus,  the  size  of  rou=ng  table  does  not  change.    

 

Base  

Encrypted  

SIGCOMM  2013  

RouTng  Example  

22  

Internet  

ISP  (  Prefix  ::  …  )  

Prefix   Encrypted  ID    

Sub::Host::Pseudo  

Sub::Host::Pseudo  

SIGCOMM  2013  

Outline  

•  MoTvaTon  /  Background  •  Approach:  Cross-­‐Layer  Pseudonyms  •  System  Design  – ApplicaTon-­‐Layer  – Network-­‐Layer  

•  ImplementaTon  and  EvaluaTon  •  Conclusion    

23  SIGCOMM  2013  

IPv6    Internet  

Prototype  ImplementaTon  

24  

Web  Browser      Policy  Engine  

Alice   Web  Server  

IP1        

OS  

IP  IP  IP  

IPv6  Tunnel  Broker  

Extension  

Gateway  /64  network  

IP  IP  IP  

SIGCOMM  2013  

function extreme_policy(request, browser){

return request.requestID;}

EvaluaTon  

•  Is  the  policy  framework  expressive  enough?  

•  How  many  pseudonyms  are  required?  

•  Do  policies  effecTvely  preserve  privacy?  

•  Are  that  many  pseudonyms  feasible?  

•  How  much  overhead  in  OS  and  router?  

SIGCOMM  2013   25  

Pseudonym  Policy  is  Expressive  

26  

Name   Descrip=on  Trivial     Every  request  uses  the  same  pseudonym  Extreme       Every  request  uses  different  pseudonym  Per  tab  [1]   Request  from  each  tab  uses  different  pseudonym  Per  1st-­‐party  [2]   Based  on  the  connected  page  (1st-­‐party)’s  domain  Time-­‐based  [3]   Change  pseudonym  every  10  minutes  

•  We  could  implement  all  the  protecTon  mechanisms  from  the  related  work  in  a  cross-­‐layer  manner.    

SIGCOMM  2013  

More  examples  in  the  paper:  Per  browsing  session,  3rd-­‐party  blocking  

[1]  CookiePie  Extension,  [2]  Milk,  Walls  et  al.  HotSec  2012,  [3]  Tor          

Privacy  PreservaTon  over  Policies  

27  SIGCOMM  2013  

1  

10  

100  

1000  

10000  

100000  

#  of  Pseud

onym

s  

10  bits  

Privacy  PreservaTon  over  Policies  

28  SIGCOMM  2013  

1  

10  

100  

1000  

10000  

1  

10  

100  

1000  

10000  

100000  

#  of  ac=vi=e

s  

#  of  Pseud

onym

s  

Conclusion  

•  Pseudonym  abstracTon:  user  control  over  unlinkable  idenTTes.    – Provided  new  network  addressing  and  rouTng  mechanisms  that  exploit  the  ample  IPv6  address  space.  

– Enabled  various  policies  with  expressive  policy  framework.  

– Prototyped  with  an  extension  for  web  browser  to  show  the  feasibility  

29  SIGCOMM  2013