NDN Retreat February 2015: Breakout Notes, Group 2
At the NDN Retreat, four breakout sessions happened to discusses issues with NDN development. Notes from the breakout are made available below in raw, unedited form.
Group 2: Data confidentiality/encryption based access control approach
What are the confidentiality needs of the netenvs?
Confidentiality of content vs confidentiality of the user
- How should we encrypt payloads? Can all payloads be encrypted? What
are the implications of payload encryption for other NDN goals (e.g.,
- How can we encrypt portions of the namespace to prevent the names
themselves from leaking information?
- What are the tradeoffs of confidentiality protection in terms of
complexity, performance, etc.? How can we best support advanced forms
of crypto (e.g., ABE) for applications that benefit from them?
Data might contain sensitive information (whose ID entered a building, are there people in a particular space)
Can’t necessarily assume that the network is physically protected from eavesdropping
Names might contain sensitive information (e.g., that there’s a motion detector in a particular room)
- tension between data in names for routing, caching, and querying vs confidentiality of name
User access to names may be sensitive (e.g. police investigating)
- Caching gives up forward secrecy
- Can encrypt parts of names (an opaque blob), but it is stable for the lifetime of the key
- interest names need a transparent portion and an opaque portion
- the opaque (encrypted) portion provides confidentiality of the name
- may change frequently to avoid disclosure (no stable mapping), using a nonce or timestamp
- the opaque portion is not used for routing or caching
- onions to provide additional (hierarchical) confidentiality within names?
- e.g. /ucla/[e1] -> /ucla/building[e2] -> /ucla/building/room1/[e3]
There is an ACL per building and/or per room (authorized user list)
- each device encrypts data with symmetric key, administrator grants access to data by publishing the symmetric key encrypted with user key
- key can be leaked
- any old data is available to someone with the key (but they already had the data and could have stored or shared it)
- easy to implement
- per device or per room or per building access control
- change key when user access is revoked
- change key periodically
- not as expressive as ABE, but a lot simpler
- are the requirements any different with respect to name confidentiality?
- encrypting name is perhaps more important
- change the names for different consumers?