Side-Channel Attack on Encrypted Traffic Network packets’ sizes and directions between user and a popular search engine By acting as a normal user and eavesdropping traffic with sniffer pro 4.7.5. Collected in May 2012 Internet Client Encrypted Traffic Server Fixed pattern: identified input string User Input Observed Directional Packet Sizes a: 801→, ←54, ←509, 60→ 00: 812→, ←505, 60→, 813→, ←507, b-byte s-byte There are researches on how to locate the web applications, which is not our focus in our work. The data are collected from popular search engine (Google). NB. These data were collected 2 years ago, currently, Google may already fix it. However, there may exist in other applications. Our goal is not to list the current existing side-channels, but to show the importance of such attacks. The key is that, usually, user found the side-channels and then company fixed it. Our solution may assist the designer and programmer of an application in pre-considering such side-channels and solve it in the designing process. The data were collected in one type of setting (browsers, platforms and where to collect (the victim machine, or LAN, or WLAN…)), however, it is general enough to show the problem. Indicator of the input itself

Longer Inputs, More Unique the Patterns S value for each character entered as: Second keystroke: First Keystroke Second Keystroke a b c d 509 487 493 501 497 504 516 488 482 481 502 473 477 543 478 499 Left table: for the first keystroke Right table: second column: a-d as the first keystroke, 3-6 columns: a-d as second keystroke following a-d, correspondingly. For right table: If the adversary only observe the traffic for second keystroke, s/he can distinguish 12 out of 16. For example, when s=493, the adversary knows it is : (a)b By combining two observations (traffic for both first and second keystrokes), s/he can completely distinguish all the possiblilities. Of course, in reality, it may take more than two keystrokes to uniquely identify an input string. 16 out of 16 12 out of 16 The unique patterns leak out users’ private information: the input string

Re-Identification Attack In publishing sensitive data, deleting explicit identifiers is not sufficient Due to re-identification (or linking) attack Using quasi-identifiers, in this Case DOB, Zip code, and Gender Medical data Voter list Name DOB Zip code Gender Bob 73-2-10 22031 M Alice 73-2-13 Eve 73-2-15 Malice 73-2-28 ... SSN DOB Zip code Gender Disease deleted 73-2-10 22031 M AIDS 73-2-26 Hypertension 68-1-1 Toothache 68-1-30 F Headache ...

Apply the Idea to PPTP Ceiling padding: pad every packet to the maximum size in the group PPTP: Padding group PPTP goals: Privacy Cost S Value Padding (Prefix) char Option 1 Option 2 473 477 478 (c) c (c) d 499 (d) b 516 (d) d 501 (a) c (b) a PPDP: Anonymized group PPDP goals: Privacy Data utility Ceiling padding Quasi-ID Function 1 Function 2 Sensitive Attribute Generalization So we can borrow the concept from PPDP and apply to PPTP: k-indistinguishability (k is an integer) is satisfied if the size of every padding group is no less than k However, there are a few difference, and hence challenges...