330 likes | 464 Views
Privacy in Content Oriented Networking: Threats and countermeasures . Abdelberi Chaabane, Emiliano De Cristofaro , Mohamed Ali Kaafar , and Ersin Uzun. A brief History of networking. 3 Interconnecting information. Telephony. TCP/IP. 2 Interconnecting hosts.
E N D
Privacy in Content Oriented Networking: Threats and countermeasures Abdelberi Chaabane, Emiliano De Cristofaro, Mohamed Ali Kaafar, and ErsinUzun
A brief History of networking 3 Interconnecting information Telephony TCP/IP 2 Interconnecting hosts 1 Interconnecting wires
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’’
Notable Content Oriented Networking Architectures DONA NetInf Network of Information
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
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
Outline • Privacy challenges in CON Cache privacy Content Privacy Name privacy Signature privacy • The potential of CON privacy Anonymity Censorship Resistance Untraceability Data authenticity and confidentiality
CON Privacy Name Privacy Cache Privacy • Names are related to the content • Infer what a user is consuming • Data is cached in every hop • Infer who consumed what Signature Privacy Content Privacy • Content is signed • Identify the communicating parties • Encryption is not mandatory • Publicly available content spied on / censored
Timing attack RTTS RTTC Fetch the targeted contentRTTt • If |RTTt -RTTc| < ε: Content has been fetched by a neighboring consumer • If RTTt > RTTc and RTTt < RTTs: Content has been recently fetched from the source • Otherwise: The target content has not been consumed
Potential Solution • Wait before reply • When a content m is fetched, the corresponding RTTm is stored • All subsequent requests to m are delayed with RTTm Increased the delay It provably achieves perfect privacy[1] No assumption about content correlation/ Network topology Reduced bandwidth 1: Acs, G., Conti, M., Gasti, P., Ghali, C., & Tsudik, G. Cache Privacy in Named-Data Networking. ICDCS’13.
Potential Solution • Delay the first K • When a content m is fetched, the corresponding RTTm is stored and a random number K is chosen • K subsequent requests to m are delayed with RTTm Assumption about content correlation Increased delay for non popular content Popular content is not delayed Formal model to quantify the tradeoff privacy/latency [1] Reduced bandwidth
Potential Solution • Collaborative caching • Multiple caches collaborate to create a distributed cache
Potential Solution • Collaborative caching • Multiple caches collaborate to create a distributed cache Administrative collaboration Potential Delay Increases the anonymity set Increases hit rate
Content Based Monitoring and Censorship • CON routers • Long-term storage • Computationally powerful • ‘Less’ powerful adversary is needed to perform censorship
Potential Solution • Broadcast encryption • The producer send an encrypted message to a set of users N • Only users in N can decrypt the message Producer generate/store N keys Producer public key and cipher text are of size of O(√N) Content is encrypted once Caching is preserved Fine grained user control (revocation)
Potential Solution • Proxy re-encryption
Potential Solution • Proxy re-encryption Asymmetric encryption Content is available for any user Content is encrypted once Caching is preserved Fine grained user control (revocation)
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
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 Introduce false positives BF require periodic resetting Obfuscates content name Small architectural changes Reduce the size of routing/forwarding tables
Censorship/ Monitoring • Signature is used to provide guarantee on provenance and integrity • This signature can be used to censor/monitor the content.
Potential Solution • Group Signature • Group Signature
Potential Solution • Group Signature • Hide the signer in a set of potential signers (signer ambiguity) Pub Key Priv Key Group Manager
Potential Solution • Group Signature • Hide the signer in a set of potential signers (signer ambiguity) Presence of a group manager Censorship possible Signature still verifiable Efficient
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 Pub Key Priv Key
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 Communication overhead linear in the size of the ring Censorship possible Signer anonymity protected Trustful content (as long as all signers are trustworthy) No signers interaction / No group manager
Outline • Privacy challenges in CON • Cache privacy • Content Privacy • Name privacy • Signature privacy • The potential of CON privacy • Anonymity • Censorship Resistance • Untraceability • Data authenticity and confidentiality
Anonymity Internet CON A Trusted Anonymzing proxy Natively provided by the architecture (no SRC/DST) - A single point of failure - A Local adversary could monitor all the traffic Mix Networks: ANDaNA[2] • 2 Hops to the source • Low latency • Partially disable CON caching • CCNx specific Mix Networks e.g. Tor • 3 Hops to the source • Low latency [2] ANDaNA: Anonymousnamed data networking application.DiBenedetto, S., Gasti, P., Tsudik, G., & Uzun, E. NDSS'12
Censorship Internet CON DNS Tempering Effective in some CON Content (name) blacklisting Host blacklisting Easier in CON: • Name/Content are not encrypted • No need for specialized hardware DPI (Content blacklisting) • Strong adversary • specialized Hardware At a single router, censorship appears to be easier in CON
Tracking Internet CON Cookies • Widespread • Efficient • Tailored to the business model • No same origin policy • Only dynamic content can be tracked • Business model migration ? Stateless Tracking -More difficult to carry (no addresses + caching) • How to handle security incident ? • Using IP and host fingerprinting CON is more resilient to tracking but poses new challenges
Data authenticity and confidentiality Internet CON 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
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