# Name-Based Security for Information-Centric Networking Architectures
## 5 Implementation and Evaluation
### Security Evaluation  
DID registry security is not in the scope of this work. A DID registry implementation should provide mechanisms that assure: (i) the uniqueness of DIDs, i.e., a user cannot register a DID (i.e., a name root) that has already been registered, (ii) DID document access control, i.e., only the owner of a DID document should be able to modify it, and (iii) user account management, i.e., DID owners should be able to recover/modify a lost/breached secret key (used for authenticating themselves to the DID registry).  
The scheme used in our paper is CCA-secure, and as proved in [16], it can be used for generating digital signatures using the algorithm presented in Section 4.1. The digital signatures generated by this algorithm have all the properties of traditional digital signatures, i.e., unforgeability (only the content owner can generate a valid signature for the associated name), non-re-usability (the signature that corresponds to a content name cannot be used with another name), and non-repudiation (a content owner cannot deny having generated a valid signature).  
As already discussed, a digital signature can only be generated by the content owner, and it cannot be generated even by authorized storage endpoints, i.e., network entities that know the secret key that corresponds to a content name. This has the advantage that users can make sure that they always receive authentic content, but on the other hand, it has the disadvantage that \(3^{rd}\) parties, including authorized storage points, cannot sign \"dynamic\" content (e.g., a live stream).  
Our access control solution is secure even in the presence of misbehaving storage endpoint. A storage endpoint cannot create a \(C_{user\_name}(key)\) for unauthorized users since it cannot create the re-encryption key required for this process. Moreover, storage endpoints learn no secret information. For a more thorough security analysis of this solution, interested readers are referred to [19].  
Key Revocation  
Our solutions rely on the following secret keys: (i) _master_ (i.e., the master secret key of a SKG), and (ii) the secret key associated with a content name. _master_ is the most important key: any entity that learns this key can re-generate all the keys that the SKG has extracted. _master_ keys must be securely stored by SKGs. In case a _master_ key is lost, the corresponding SKG should re-execute the Setup IBE  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Variable** & **Size (bits)** \\ \hline Public Parameters (\(PP\)) & 2048 \\ Master Secret Key (_master_) & 160 \\ Secret Key (SK) & 1024 \\ Ciphertext (C) & 2048 \\ Re-encryption key (RK) & 2048 \\ \hline \hline \end{tabular}
\end{table}
Table 4: Size of variables used by the IB-PRE algorithms.  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Algorithm** & **Time (ms)** \\ \hline Extract & 4.0 \\ Encrypt & 6.2 \\ RKGen & 9.8 \\ ReEncrypt & 1.0 \\ Decrypt & 5.3 \\ \hline \hline \end{tabular}
\end{table}
Table 3: IB-PRE algorithm computation times.  
algorithm and produce new \(PP\). Accordingly, the affected user(s) should update their DID documents and re-generate all secret and re-encryption keys. _master_ is the only key that can be used for extracting other keys. On the contrary, the secret keys that correspond to a name cannot be used for generating other secret keys, even for names that use the breached name as a prefix. For example, the key that corresponds to \"User A/Pictures\" cannot be used for extracting the key that corresponds to \"User A/Pictures/Holidays\", even if these keys share the same \(PP\). On the other hand, the loss of a secret key means that the corresponding name cannot be used as a public key. For this reason, every time a key is revoked, the version number of the corresponding name is increased, and a new secret key is generated.