# A Security Framework for the Internet of Things in the Future Internet Architecture
## 6 Delegation-Based Key Provisioning Protocol
### Discussions and Security Analysis  
The delegation-based key provisioning protocol specified in Section 6.6 involves three parties and contains nine messages. However, in the context of the MobilityFirst-based IoT architecture, there is another round of message exchange before the execution of this key provisioning protocol. When grouping a set of IoT devices to form an IoT network or when a device is joining an existing IoT network, the IoT-NRS initiates the device discovery process by sending out registration beacons periodically. An IoT device responds to the beacon with its intention to join the network. After the beacon and the response message exchange, to register the new device and establish a long-term membership credential, the IoT-NRS initiates a new session of our key provisioning protocol by sending Message 1 of the protocol with its identifier and a fresh nonce. We do not explicitly include the first round of message exchange into the key provisioning protocol specification because: (1) the beacon and the response message exchange is sent over an open channel and is irrelevant to the security operations; and (2) the context of MobilityFirst IoT architecture does not limit the applicability of our key provisioning protocol. This protocol is general and can be applied to other scenarios, which will be discussed in Section 6.9.  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Symbol** & **Notation** \\ \hline \(rng\) & Random Number Generator \\ \(||\) & Concatenation \\ \(N_{i}\) & \(i^{th}\) nonce generated in the protocol session \\ \(ID_{X}\) & Identifier of the protocol participant \(X\) \\ \(g\) & Generator of Diffie-Hellman group \\ \(x\) & Parent’s Diffie-Hellman private component \\ \(y\) & Guardian’s Diffie-Hellman private component \\ \(prf(k,s)\) & Pseudo random function with \(k\) as the key and \(s\) as the seed \\ \(hash(M)\) & One way hash function on material \(M\) \\ \(sig_{X}(M)\) & Signature on material \(M\) using the private key of \(X\) \\ \([M]_{k}\) & Message Authentication Code of \(M\) using key \(k\) \\ \([A||B]_{k}\) & Authenticated encryption: \(B\) is encrypted and \(A||B\) is authenticated using key \(k\) \\ \(cer^{\prime}X\) & Certificate of the protocol participant \(X\) \\ \(\alpha\) & Token generated by Parent and granted to Guardian \\ \(\beta\) & Token generated by Parent and granted to Child \\ \(kek\) & Parent key shared between Parent and Child \\ \(k\) & Random key generated by Parent for Guardian and Child \\ \(dk\) & Intermediate component derived from Diffie-Hellman \\ \(ak\) & Symmetric key derived from \(dk\) and used for computing message authentication code \\ \(ek\) & Symmetric key derived from \(dk\) and used for protecting token \(\alpha\) \\ \(sid\) & Session identifier \\ \(ck\) & Symmetric key derived from \(sid\) and \(k\) and shared between Guardian and Child \\ \(sk\) & Membership key shared between Guardian and Child \\ \(ps\) & Local secret shared only between Guardian and Child (could be _null_) \\ \hline \hline \end{tabular}
\end{table}
Table 1: Protocol Notations.  
Both Choo's 3 PKD protocol and SIGMA protocol are proven to be secure _individually_. However, combining them together and customizing them to be applicable for resource-limited devices does not necessarily imply the result is _secure_. One of our major contributions includes providing security guarantees for overlaying Choo's 3 PKD protocol and SIGMA protocol as well as adopting lightweight measures to reduce overhead. Below, we will discuss our contributions to the key provisioning protocol in detail and show that all the security requirements listed in Section 6.3 are achieved.