1. Privacy in Content Oriented Networking: Threats and countermeasures Abdelberi Chaabane, Emiliano De Cristofaro, Mohamed Ali Kaafar, and Ersin Uzun

2. 1 3 Interconnecting information 2 Interconnecting hosts 1 Interconnecting wires TelephonyTCP/IP A brief History of networking

3. Change in Communication Paradigm Today Internet struggles – Scalability – Mobility – Security Move to Content-oriented Network – Traffic is already content-oriented CDN, overlays, P2P – Users/applications care “what to receive” They don’t care “from whom” Host based communication model is getting ‘’outdated’’ 2

4. Notable Content Oriented Networking Architectures 3 NetInf Network of Information DONA

5. Macro-building blocks Named Content – Objects are named to facilitate data dissemination and search Content Based Routing – Routing content rather than host Content Delivery – Using multipath routing and leveraging in network caching In Network caching – All components provide caching capability 4

6. CCN Operations 5

7. Contributions Systematic study of privacy challenges in CON – Exposing several worrisome issues – Proposing some countermeasures – Highlighting open problems Comparing CON to Today’s Internet (TI) from a privacy perspective 6

8. Outline 1.Privacy challenges in CON Cache privacy Content Privacy Name privacy Signature privacy 2.The potential of CON privacy Anonymity Censorship Resistance Untraceability Data authenticity and confidentiality 7

9. CON Privacy Cache Privacy -Data is cached in every hop -Infer who consumed what -Data is cached in every hop -Infer who consumed what Name Privacy -Names are related to the content - Infer what a user is consuming -Names are related to the content - Infer what a user is consuming Signature Privacy -Content is signed - Identify the communicating parties -Content is signed - Identify the communicating parties Content Privacy -Encryption is not mandatory -Publicly available content spied on / censored -Encryption is not mandatory -Publicly available content spied on / censored 8

10. Timing attack RTT S RTT C Fetch the targeted content RTT t 1.If |RTT t -RTT c | < ε: Content has been fetched by a neighboring consumer 2.If RTT t > RTT c and RTT t < RTT s : Content has been recently fetched from the source 3.Otherwise: The target content has not been consumed 9

11. Potential Solution Wait before reply – When a content m is fetched, the corresponding RTT m is stored – All subsequent requests to m are delayed with RTT m 1.Increased the delay 1. It provably achieves perfect privacy[1] 2.No assumption about content correlation/ Network topology 3.Reduced bandwidth 1: Acs, G., Conti, M., Gasti, P., Ghali, C., & Tsudik, G. Cache Privacy in Named-Data Networking. ICDCS’13. 10

12. Potential Solution Delay the first K – When a content m is fetched, the corresponding RTT m is stored and a random number K is chosen – K subsequent requests to m are delayed with RTT m 1.Assumption about content correlation 2.Increased delay for non popular content 1.Popular content is not delayed 2.Formal model to quantify the tradeoff privacy/latency [1] 3.Reduced bandwidth 11

13. Potential Solution Collaborative caching – Multiple caches collaborate to create a distributed cache 12

14. Potential Solution Collaborative caching – Multiple caches collaborate to create a distributed cache 1.Administrative collaboration 2.Potential Delay 1.Increases the anonymity set 2.Increases hit rate 13

15. Content Based Monitoring and Censorship CON routers – Long-term storage – Computationally powerful ‘Less’ powerful adversary is needed to perform censorship 14

16. Potential Solution Broadcast encryption – The producer send an encrypted message to a set of users N – Only users in N can decrypt the message 1.Producer generate/store N keys 2.Producer public key and cipher text are of size of O(√N) 1.Content is encrypted once 2.Caching is preserved 3.Fine grained user control (revocation) 15

17. Potential Solution Proxy re-encryption 16

18. Potential Solution Proxy re-encryption 1.Asymmetric encryption 1.Content is available for any user 2.Content is encrypted once 3.Caching is preserved 4.Fine grained user control (revocation) 17

19. Monitoring/Tracking Content name are semantically correlated with the content – E.g. /US/WebMD/AIDS/Symptoms/html Unlike HTTPS, content name is not encrypted as they are used for routing 18

20. Potential Solution Bloom Filter – Using Bloom filter to obfuscate the content name: A hierarchical Bloom filter for routing table A counting Bloom filter for each forwarding interface 1.Introduce false positives 2.BF require periodic resetting 1.Obfuscates content name 2.Small architectural changes 3.Reduce the size of routing/forwarding tables 19

21. Censorship/ Monitoring Signature is used to provide guarantee on provenance and integrity This signature can be used to censor/monitor the content. 20

22. Potential Solution Group Signature 21 Group Signature

23. Potential Solution Group Signature – Hide the signer in a set of potential signers (signer ambiguity) 22 Group Manager Pub Key Priv Key

24. Potential Solution Group Signature – Hide the signer in a set of potential signers (signer ambiguity) 1.Presence of a group manager 2.Censorship possible 1.Signature still verifiable 2.Efficient 23

25. Potential Solution Ring Signature – Hide the signer in a set of potential signers (signer ambiguity) – Signature is generated from the signer private key and a set of public key 24 Pub Key Priv Key

26. Potential Solution Ring Signature – Hide the signer in a set of potential signers (signer ambiguity) – Signature is generated from the signer private key and a set of public key 1.Communication overhead linear in the size of the ring 2.Censorship possible 1.Signer anonymity protected 2.Trustful content (as long as all signers are trustworthy) 3.No signers interaction / No group manager 25

27. Outline 1.Privacy challenges in CON 1.Cache privacy 2.Content Privacy 3.Name privacy 4.Signature privacy 2.The potential of CON privacy 1.Anonymity 2.Censorship Resistance 3.Untraceability 4.Data authenticity and confidentiality 26

28. Anonymity A Trusted Anonymzing proxyNatively provided by the architecture (no SRC/DST) - A single point of failure - A Local adversary could monitor all the traffic Mix Networks e.g. Tor 3 Hops to the source Low latency Mix Networks: ANDaNA[2] 2 Hops to the source Low latency Partially disable CON caching CCNx specific InternetCON 27 [2] ANDaNA: Anonymous named data networking application. DiBenedetto, S., Gasti, P., Tsudik, G., & Uzun, E. NDSS'12

29. Censorship DNS TemperingEffective in some CON Easier in CON: Name/Content are not encrypted No need for specialized hardware At a single router, censorship appears to be easier in CON InternetCON Host blacklisting Content (name) blacklisting DPI (Content blacklisting) Strong adversary specialized Hardware 28

30. Tracking Cookies No same origin policy Only dynamic content can be tracked Business model migration ? CON is more resilient to tracking but poses new challenges InternetCON -More difficult to carry (no addresses + caching) How to handle security incident ? Using IP and host fingerprinting 29 Stateless Tracking Widespread Efficient Tailored to the business model

31. Data authenticity and confidentiality One size fits all (SSL) Well studied Highly optimized End to End trust model Different consumer = different trust model Widely accepted (PKI) or new trust management model InternetCON 30

32. Take home messages Content Oriented Networking Privacy More resilient to tracking ‘’Weak’’ anonymity as native feature Possibly more vulnerable to censorship Some privacy challenges due to caches, naming, signatures 31

33. 32