---

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

Questions

• How should we encrypt payloads? Can all payloads be encrypted? What
  are the implications of payload encryption for other NDN goals (e.g.,
  efficient caching)?
• 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?

Confidentiality Requirements

Building Management

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)

Models

• 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

OpenMHealth

• are the requirements any different with respect to name confidentiality?
• encrypting name is perhaps more important
• change the names for different consumers?