Private Information Retrieval over ICN Christian Tschudin - - PowerPoint PPT Presentation

Private Information Retrieval


• ver ICN

/edu/ucla/cs/nom16/PIRoverICN/ndx

sha256 MPHF PIR

Christian Tschudin
 University of Basel, Switzerland and Symphony.com, Palo Alto, USA

Overview


How to lookup secrets over public NDN?

• Named Data Networking

• from packets to data structures
• Security and Privacy


… in many forms

• Private Information Retrieval over ICN

• a practical protocol
• Outlook: going SSL-less

• the challenge to secure data structures

/edu/ucla/cs/nom16/PIRoverICN/ndx

sha256 MPHF PIR

From Packets to Services

• NDN: usually introduced as Interest/Data packet exchange
• Here is another viewpoint:

• Interest pkt = DB query

• Data pkt = DB reply —> lookup(name)

• DNS as a first NDN incarnation
• Agenda becomes: “The network is the database”

What “things” does such a network store, if not packets?

From Packets to Data Structures

• Van’s name hierarchy


envisaged “collections”

• Recent, more explicit forms:


manifests and catalogs


• no “discovery”/selectors

• can combine elements from different namespace sub-trees

• FLIC (File-Like ICN Collection) another example à la UNIX index node
• Essential operation on such collections:

• lookup by (entry) name —> how can this be made “private”?

Privacy in NDN

Signed content envisaged from the beginning, but not enough:
 Privacy must be supported, enabled, even enforced …

• Privacy has many forms:

• content privacy (confidentiality as in classical encryption)

• intent privacy (encrypted names such that only locator is in the clear)

• lookup privacy (topic of this talk)

• transport privacy (MIX nets, TOR)

• execution privacy (host does not learn anything about algo and result)

Private Index Lookup


(and how to retro-fit in into NDN)

Inside-out sequence of presentation:

• use “private information retrieval”

• needs a position index
• use Minimal Perfect Hash Functions

• maps 256 bits to position 0..N-1
• use SHA256 to normalize names

• for classic NDN names

• but also “self-certifying names” (e.g.


content- or representation-access)

/edu/ucla/cs/nom16/PIRoICN/ndx sha256 MPHF PIR {nameless} The_Content

Private Information Retrieval (PIR)

• PIR proposed in 1998

• by Chor, Goldreich, Kushilevitz and Sudan

• trivial solution (undesired): download full table

• non-trivial solutions exist!
• Practical PIR:

• information theoretic PIR

• relies on two or more


non-colluding servers


• cloaked queries

• servers do a GS(2) matrix mult

• client can undo cloaking

k servers 1 q k client a 1 a k n b ... a L l 1 a L k q

Minimal Perfect Hash Fcts (MPHF)

• Looping over a DB’s entries does not scale (to billions, pragmatically)
• Replace “forall i in DB { if (i.key==key) return i; }”


with “return DB[key2pos(key)]”

• Minimal perfect hash functions:

• no collisions

• no holes (map N keys to 0…N-1)
• How to find a MPHF?

• several probabilistic algorithms available (since 1993)

• MPHF size “a few bits per entry”

• as key we will use the SHA256 of a NDN name … see again the workflow

A Named-Data Protocol for PIR

• Publisher has DB L

• computes mphf

• sends it with L to two


non-colluding servers


• Client

• downloads mphf

• cloaks the query

• requests PIR lookup twice

• combines results

L and mphf PIR_lookup1(pos) PIR_lookup2(pos) publisher done get(mphf) mphf pos=mphf(h) lookup(h) d1 d2 init(loc1,loc2) d=combine(d1,d2) d PIR2 PIR1 app client lib

OK? No: the two queries (and replies) must be encrypted!

Private Index Lookup (PIL)

PIL a useful primitive in NDN

• Private walking of the hierarchical namespace


dir1 = private_lookup(“/edu/ucla/cs“ + hash(“.”)); // locator
 dir2 = private_lookup(“/edu/ucla/cs“ + hash(dir1 + "nom16"));
 dir3 = private_lookup(“/edu/ucla/cs“ + hash(dir2 + "venue"));

• FLIC traversing
• Other data structures:


linked lists, (data structure) trees, …

Going SSL-less

• Static names still in use today:

• store data (incl keys) in encrypted form


and run trusted operations in edge devices

• This is what NDNfit does (private fitness data),


what Symphony does in the cloud (private messaging)

• Long run: untrusted net (as a DB, transport endpoint, computing)


SSL means you trust that endpoint - can we avoid this?
 —> from passive storage to PIR servers, and other forms of
 name rewriting (never request the same hash value twice)

waiting for homomorphic encryption…

Conclusions

• Search privacy: “how to lookup secrets over public NDN”
• We demonstrate PIR over ICN: specially crafted NDN names
• PIR is realistic for NDN (and small tables) today,

• more involved for large data structures (files, trees,


linked lists, graphs), potentially we loose some privacy

• Beyond SSL: secure the data structures, not single pkt flows

• need to exploit research results in “structured encryption”