6.7.1. Protocol Security Analysis
The key provisioning protocol provides strong security on provisioned keys by leveraging two different protocols, namely a three-party key distribution protocol (3PKD) and a two-party SIGMA protocol, for parent-guardian authentication. These two protocols are overlaid with enhanced protocol session context (all identifiers and nonces) so that all protocol participants have consistent and a correct view of the protocol session. Upon the successful completion of the key provisioning protocol, each party needs to confirm its commitment to the fact that they agree on, and contribute (e.g., contribute a nonce) to the shared secret(e.g., a shared key or a seed used to generate a shared key).
Introducing enhanced protocol session context into the protocol design excludes the possibility of an identity misbinding attack, where an attacker successfully convinces the peers that the key exchange succeeded, yet the key agreement is bound by each of the participants to a wrong “peer” [44
]. One of the measures adopted in the key provisioning protocol to prevent identity-related attacks, e.g., a misbinding attack, is adding identifiers in the corresponding messages when necessary. We assume the identifiers of Child C
, Guardian G
and Parent P
respectively. In the context of the MobilityFirst-IoT, there are two types of identifiers : the globally-used GUID and the locally-used membership credential. Thus,
should be the GUIDs of G
respectively. However, as C
is typically a low-end IoT edge device, it does not necessarily have a GUID. Further, before the completion of the key provisioning protocol, as C
has not successfully finished the device registration yet, C
does not hold a local membership credential of G
’s network. In fact,
should be a “local” identifier recognizable by P
and used to facilitate the establishment of a long-term membership key shared with G
. To summarize,
is neither a GUID nor a local membership key. Instead,
is only a local identifier that uniquely identifies C
. For example, assuming P
is a device manufacturer and C
is a product device from P
could be the model and serial number that is stored in P
’s database. In other application scenarios of the key provisioning protocol,
are not necessarily GUIDs, which is specific to the design of the MobilityFirst network. Alternatively,
could be any other forms of identifier that allow G
to identify and further authenticate each other.
The first stage of our protocol contains the first three messages and corresponds to the first stage of Choo’s 3PKD protocol, in which each of the two peer parties contributes a nonce to the new protocol session. Also, as the “server” P is unknown to G at this point, C explicitly specifies its Parent P by providing . This design provides flexibility, which many other existing server-based key distribution protocols, such as Kerberos, lack. In Message 2, the identity of the Parent is specified by the Child, and hence the Guardian knows who to contact for delegation from the Child. In practice, as a Child may have several pre-existing trust relationships that can be leveraged, the Child has the freedom to direct the Guardian to any of the Parents sharing an established trust. In case one Parent is unreachable by the Guardian or the mutual trust establishment between the Guardian and the Parent fails, the Guardian may inform the Child of the delegation failure. Then the Child can in turn provide another Parent as the new referee.
In the second stage (Message 4–6), which corresponds to the SIGMA protocol, a Parent-Guardian authentication is completed using the Diffie-Hellman exchange. This authentication process, facilitated by a PKI, is essential to exclude the possible collusion of the Child and the Parent. As this authentication request is initiated by G in Message 3, P sends its Diffie-Hellman value, which can be pre-generated, as a challenge to G to reduce the chance of a denial of service (DoS) attack on P as the Diffie-Hellman algorithm requires a lot of computing resource and G has to pay the price first.
The last stage of our protocol (Message 7–9) corresponds to the second stage of the 3PKD protocol. In this stage, the key material k provided by P is delivered to C, and then G and C reach a key agreement based upon k. The protocol is concluded by a handshake between G and C so that both of them confirm that the other party has computed the correct shared secret with respect to the correct protocol session. In our embodiment, we introduced the session context in terms of session identifier , which is derived from the complete session information (all identifiers, nonces and optional local secret between G and C), and use it as a glue to combine SIGMA protocol between the first stage and the second stage of 3PKD protocol. With the approach of repeating the session information through the protocol, each of the parties has a fresh and consistent view of the current protocol session, which significantly increases the difficulty of launching attacks targeting the context of a protocol instance, such as replay attacks and misbinding attacks. At the end of the third stage, dynamic mutual trust between the Child and the Guardian and the Parent-to-Guardian delegation are achieved. Secrecy and forward secrecy are also satisfied through handling key materials properly.
The key provisioning protocol may further realize stronger security on provisioned keys as compared with existing pairing protocols. In contrast to pairing protocols that do not have a security proof (which causes them to be troublesome due to possible man-in-the-middle attacks and frequent human errors in any manual operations), the protocol as described may be performed with no manual intervention from the user for key provisioning. Compared with traditional key provisioning protocols that do not rely on a server or key infrastructure, such as secure pairing, there is no manual operation by a user on an out-of-band (OOB) channel. Instead, the device Parent party is leveraged as the trusted third party to facilitate trust establishment. Such design reduces human error, hence satisfying average administration requirements and increasing usability. Further, it removes the requirement of close proximity for key provisioning, as required by most OOB channels involving manual operations by human, and hence increases the chance of practical deployment and satisfies the scalability requirement.
6.7.2. Lightweight Approach
This key provisioning protocol is carefully designed for IoT networks as a light key solution. As one of the most important features, the protocol design favours the resource-limited Child device C in all possible means. The strategy is to minimize the number of messages C needs to process and shift the work load to those more capable devices, namely G and P, as much as possible. Consequently, the key provisioning complexity is transferred to the edge device’s Parent party and the Guardian device, making it possible for minimally complex IoT edge devices to operate with secure interactions.
Compared with public key certificates, our protocol implements only lightweight symmetric key operations and secure storage for at least a single symmetric key and protected key operations with the stored key. Specifically, all of the security operations on the Child are symmetric cryptographic computations, which makes the protocol feasible for low-end IoT edge devices.
Timestamps and nonces are two typical security measures to guarantee the freshness of a protocol instance and to prevent replay attacks. Timestamps require strict time synchronization, and consequently increases the hardware cost as an oscillator with high accuracy is not necessarily cheap. On the other hand, nonces require a (pseudo) random generator and some form of database to retrieve if a nonce appeared before. As a comparison, nonces are relatively cheaper, and hence we chose to use nonces to protect against replay attack. Unlike a Kerberos system, the Child device is not required to have secure clock synchronization.
Furthermore, the protocol can be implemented with a minimal number of protocol messages handled by the child device. The protocol can thus minimize the computation and power costs to a Child device, such that lightweight devices like sensors, actuators, and microcontroller units (MCUs) can be provisioned with secret keys securely. In addition, the first four messages are sent as plaintext in open channels to reduce overhead. Modifying and/or replaying the messages in the first stage will result in protocol abortion later as each piece of session information will be verified in the following stage.