# Name-Based Security for Information-Centric Networking Architectures
## 4 Name-Based Security Solutions
### Outsourcing Content Storage and Content Provenance Verification  
Trust delegation is a typical application of IBE [16]. In the context of ICN, trust delegation is of significant importance, since a piece of content may be hosted by multiple entities. The solution presented here provides a secure way for a content owner to authorize an entity to host (i.e., store and provide on demand) part of the namespace she owns (hence, the content items associated with it). This is achieved as follows: firstly, the content owner uses her SKG and generates the secret keys that correspond to the content names (or the portion of the namespace) the authorized entity will store, then, the content owner distributes these keys to that entity. Back to our file sharing example: Suppose that \"User A\" wants to authorize \"CDN-A\" to store all family photos; he generates \(SK_{UserA/Pictures/Family}\) and securely distributes it to \"CDN-A\". This key is then used for proving content provenance (see next). It should be noted that the rightful owner of these keys is the content owner and that the authorized entity simply acts on the owner's behalf, therefore, the fact that the content owner knows these keys is not considered key escrow. Moreover, key distribution should be secured (however, key distribution is out of the scope of this paper). Content provenance verification is usually referred to as the \"verification of the identity of the transmitting entity.\" However, in ICN, users should not care who sends a content item, as long as the content authenticity can be verified. In this work, we refer to content provenance verification as the process of verifying that _a transmitting entity is authorized by the content owner to host and share the requested item_. Therefore, we are not concerned with WHO the transmitting entity is. Content provenance verification, in this context, is useful in cases where a user wants to receive an item only from endpoints trusted by the content owner, for example, for accounting reasons, spam prevention, phishing protection, and so on. Provenance verification can be achieved using a simple challenge-response protocol and the secret key generated by the content owner. In the following, we give an example of a challenge-response routine that can be incorporated into a key agreement protocol (in our description we consider the TLS-like protocol presented in [18]). After all messages have been exchanged, a user is able to verify that she will receive the desired item from an authorized endpoint:  
* The user sends to the network a _Hello_ message indicating the portion of the namespace in which he is interested in (for example, in our file sharing example this could be \"User A/Pictures/Family\"). This message is forwarded using standard ICN mechanisms. * A network endpoint, authorized to host (part of) this namespace, responds with a _Hello response_. If the endpoint is authorized for a less fine-grained portion of the namespace (for example, \"User A/Pictures\"), it indicates that in its response. Similarly, if the endpoint is authorized for a limited time, or it is authorized for a specific version of the namespace, it includes in its response the authorization expiration time (in the form of a timestamp) and/or the version number. Multiple endpoints may reply to a Hello message. * The user selects a random number \(r\), encrypts it using the IBE _Encrypt_ algorithm, the content owner's \(PP\), and an appropriate key (e.g., in our previous example, if an endpoint is authorized for a limited time, the encryption key would be \"User A/Pictures/Family:timestamp\"), includes this ciphertext to the next message of the key agreement protocol, and sends it to the network. * An appropriate endpoint decrypts the ciphertext and sends the decrypted plaintext back to the user as part of the key agreement protocol. If the number that the endpoint sends in the last message is equal to the number the user generated, then the endpoint is considered authorized.