[Nfd-dev] Close NFD backdoor

[Yingdi Yu]

Hi all,

Beichuan and I had a discussion about a backdoor of nfd which allows apps to dump unsolicited data packets into content store of local nfd and how to close the backdoor. Here is a summary of the discussion, we would like to hear your comments. If people agree with it, we will start the implementation soon.

================
1. NFD backdoor
Current NFD implementation allows local applications to dump unsolicited data packets into content store. This backdoor enables malware to cache poison local content store. To close the backdoor, nfd should 1) reject unsolicited data packets and 2) authenticate prefix registration on local nfd.

2. In-app storage
Some existing applications (such as ChronoChat) are using the backdoor to abuse local content store as an in-memory storage of data packets, because current library does not provide in-app storage. The differences between content store and in-app storage include: 
a) content store is a cache, it is not guaranteed that a data packet will always be there. In contrast, the existence of a data packet in an in-app storage is completely under the app's control.
b) content store is aware of FreshnessPeriod of data packets, but an in-app storage should not. 

The working flow of in-app storage is: an app creates its own in-app storage. If the app generates some unsolicited data packets and insert them in the in-app storage. When receiving an interest, the app will first try to see if there is a matched data packet in the in-app storage and then process the interest if there is no matched data. With the in-app storage, apps do not need to abuse content store, and we can eliminate the source of unsolicited data in the localhost environment.

For now, we need to provide two types of in-app storage:
a) explicit-controlled storage: data packets need to be explicitly deleted; when storage is full, all data insertions must fail until app explicitly increases the capacity of the storage.
b) FIFO: capacity is fixed, the first inserted data will be automatically deleted when the storage is full.
The implementation of the in-app storage could be more flexible to support other strategies, but the two above seems to be sufficient for now.

3. Authentication of prefix registration on local nfd
Currently all apps are using the system-default key to sign prefix registration command. There are several drawbacks of this mechanism:
a) every app get the access to the system-default private key.
b) the system-default key is trusted to register any prefix.

A better model should be: users should have per-prefix registration keys (the privilege of the key is expressed in the key name), and authorize applications to get the access of key for particular prefixes. This resembles the network control model of current os, e.g., when a user starts a new app which will listen to some ports, the os will ask user to give the permission to the app.

More specifically, when an app wants to register a prefix "/a/b", it will first look for a key "/localhost/prefix-register-key/a/b/[keyId]" in the user's keystore. If there is no such key, the app will create one and ask for user's permission. User authorizes that by signing the prefix-register-key using user's own key (whose privilege is pre-configured at nfd side). After that the app will use key "/localhost/prefix-register-key/a/b/[keyId]" to sign request for prefix "/a/b". At the nfd side, nfd will check:
a) whether the requested prefix matches the signing key name.
b) whether the key "/localhost/prefix-register-key/a/b/[keyId]" is signed by a trusted user.
c) whether the user is allowed to register the prefix.
The request will be accepted only if all the three conditions are satisfied. 

If an app finds that the prefix-register-key it needs has already existed in the user's keystore (e.g., created by some other apps), it will ask the user for the access to the existing key. This access control feature is already supported by the osx-keychain based keystore.

================


Yingdi




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140907/a74acf48/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140907/a74acf48/attachment.bin>