# Name-Based Security for Information-Centric Networking Architectures
## 4 Name-Based Security Solutions  
### Content Integrity Protection and Content Authentication  
The integrity of a content item is protected by a digital signature generated by the content owner. Providing that the underlay IBE scheme is chosen-ciphertext attack (CCA) secure, a digital signature is generated as follows [16] (Figure 3a):1. The content owner selects a secure hash function and calculates the item's hash \(h\).
2. She creates \(SK_{content\_name/h}\) by invoking the _Extract_ algorithm of the SKG, i.e., she creates the secret key that corresponds to the content name appended with \(h\).  
The latter secret key is the (public) digital signature of the item identified by \(content\_name\). A digital signature can be trivially verified by anybody using the following steps (Figure 3b):  
1. Calculate the hash \(h\) of the item covered by the signature.
2. Select a random number \(r\).
3. Use the IBE _Encrypt_ algorithm to encrypt \(r\) using as a key \"\(content\_name/h\)\" and as \(PP\) the content owner's \(PP\).
4. Verify that the ciphertext produced in the previous step can be decrypted using the IBE _Decrypt_ algorithm and the signature as a key.  
It can be observed that \(SK_{content\_name/h}\) is treated as a public information, and this solution does not require any secret key associated with the content. Hence, keeping track of the current version of the content name is not required by this solution.  
An interesting property of this solution is that it can be used to verify content authenticity. With this solution, signatures can only be generated by the content owners, since the signature generation relies on the _Extract_ IBE algorithm that can be executed only by the SKG. Therefore, a signature provides an unforgeable means of linking content items to their owners. As a result, a user can be sure that the content item she received is indeed what she asked for.  
In order to show the significance of this property, we present an authentication attack applicable to the NDN architecture. Suppose, a user requests the item \"User A/Pictures/Picture1\" (where \"User A\" is a name root owned by the content owner). The header of the corresponding data packet in the NDN architecture contains (among others) the following fields: the content name, a digital signature over the packet data and the content name, and a pointer to the public key of \"User A\". An attacker can modify the packet data, compute a new signature using his key, and replace the information in the header with the new signature and a pointer to the attacker's public key. The integrity of the new packet is still preserved, but this is not what the user really asked for. The reason why this attack is possible is because there is no binding between the public key of \"User A\" and the content name; in other words, a user by receiving only a public key (and not for example a digital certificate) cannot verify that this key indeed belongs to \"User A\". In our solution, this binding exists since the word  
Figure 3: Digital signature: (**a**) creation; (**b**) verification.  
\"User A\" is both the root of the content item name _and_ the public key of \"User A\". This attack is not specific to ICN: Recently researchers used a similar attack (and other techniques) to break Apple's iMessage messaging system [17].