- freely available
Future Internet 2017, 9(3), 27; doi:10.3390/fi9030027
2. Survey of the Evolution of IoT Architectures
3. General Security Analysis of IoT Systems
- Authentication and physical threats: highly distributed deployments of a large number of IoT devices, such as RFID tags and wireless sensors, will generally be deployed in public areas without any protection, which makes the devices difficult to manage and vulnerable to physical attacks. For example, an illegitimate sensor may register itself claiming that it is at one location while it is actually at a different location. Or a sensor installed in a room monitoring the room temperature is moved to another room by a malicious person. This introduces the challenge of authenticating IoT devices, which involves recognizing the device and verifying its association with a correct topological address.
- Integrity: the unattended environment for IoT devices also makes data integrity a concern. Once deployed, most of these devices will operate in a self-supported manner. As with very limited maintenance or even no maintenance, tampering data is a much easier task than in a supervised wired network. Further, as a result of a natural loss of calibration or a deliberate perturbation of the measurement environment by an attacker, the data collected by IoT devices is quite likely to have low quality and might be corrupted at the environmental level. In short, IoT data may be noisy and easy to spoof and forge.
- Confidentiality: the communication method between devices and the gateway is primarily wireless, which results in confidentiality risks. For example, eavesdropping is a major concern in wireless networks. Unfortunately, unlike many other wireless environments, such as cellular and Wi-Fi networks, it is difficult for IoT networks to provide confidentiality for data transmission due to the resource-constrained nature of low-end devices, which are a large fraction of IoT devices . Different from typical devices in traditional wired and wireless networks, such as smartphones, tablets, PCs and routers, most of the devices in future IoT networks are active sensors or passive RFID tags, which have very limited resources and capabilities. Constraints on power, computational capability, storage and other aspects of an IoT device introduce a high barrier for it to perform the necessary operations to achieve data confidentiality, such as through encryption and key management.
- Privacy: as an existing public concern for monitoring and interacting with the real world, the consequence of information leakage in local IoT networks becomes exacerbated when integrated into the global Internet. By connecting real world objects and information through the Internet, data may become accessible to various organizations and domains across the Internet, instead of only being revealed to a small group, which makes it more likely to be exposed to sophisticated malicious parties and therefore increases the probability of being exploited and attacked.
4. MobilityFirst-Based IoT Architecture
4.1. Overview of the MobilityFirst Infrastructure
4.2. MobilityFirst-Based IoT Architecture Design
- Devices: a wide variety of devices, e.g., sensors, actuators and tags, that use embedded techniques to sense, communicate and/or interact with the external environments.
- MobilityFirst network: MobilityFirst provides connectivity for different distributed IoT devices and applications. Due to the seamless mobility support of MobilityFirst, besides well-established IoT system, more dynamic IoT applications/systems can be developed on top of it.
- IoT middleware: MobilityFirst-based IoT middleware integrates three functional layers— Aggregator, Local Service Gateway (LSG), and the IoT server. The aggregator supports sensor abstraction to hide the hardware specifics for sensors and presents a single interface to query and subscribe to the sensor data. LSG connects the local IoT system to the global Internet and provides necessary management, including naming resolution, key management and context processing services. The IoT server is a logically centralized server in the control plane that manages subscription memberships as well as provides a lookup service so that subscribers may query for the IoT data/services.
- Applications: end users who consume the IoT data and may feed back to the external environment through actuators.
4.3. Protect IoT through Existing MobilityFirst Network Services
5. IoT Middleware Security
5.1. Overview of the Name Resolution Framework in MobilityFirst-Based IoT
5.2. Major Functionalities of IoT Name Resolution Service
- GUID Assignment: IoT-NRS serves as a surrogate and works together with the NCRS to assign GUIDs to network objects, such as IoT data, certain devices or a group of IoT devices, to assist advanced network services in the global Internet. The relation between the GUID and the device/data might be one-to-one, one-to-many and many-to-one. From the application point of view, generally the data is of interest and one piece of data has one GUID, which is associated with a list of attributes describing the data object. With respect to devices, it is more often than not that a group of devices map to a single GUID. As an example, it is reasonable to assign one GUID to all of the temperature sensors in a particular room. However, sometimes one device may obtain a GUID if necessary. For example, if the device is the only device in its category or it is important for the application. Also, sometimes one sensor may associate with two or more GUIDs. For example, a multi-function sensor attached to Tom’s mug may have with attributes of location information and associated with the mug’s temperature.
- Membership Credential Establishment: IoT-NRS at the LSG may act as a group authority to establish membership credentials associated with the IoT device in the scope of the local IoT system. This long-term membership credential identifies the device in the local group. A proper symmetric cryptographic algorithm is chosen to generate such a credential (i.e., a symmetric key) so that low-end devices can afford to perform security operations. After establishing the membership credential, short-term keys (for example, session keys) and functional keys (for example, attestation key) may be derived from the membership key.
- Name Translation between GUID and Membership Key: Two directional name mapping between the GUID and the membership key connects the local IoT system to the global network so that IoT-related operations can be performed seamlessly.
- Membership Management: IoT-NRS should also provide membership management, where the membership is represented by the GUID and/or the membership key. Such management includes renewal and revocation operations. Both the GUID and the membership key have expiration times to guarantee key freshness and security strength. Therefore, renewing in a timely and efficient fashion is essential to keep the device/data “alive" in the system. On the other hand, revocation is needed to remove compromised/dysfunctional devices so that potential security/privacy threats can be reduced.
6. Delegation-Based Key Provisioning Protocol
6.2. System Model
6.3. Security Requirements
- Scalability: As many IoT systems are large scale deployments, it would be extremely difficult to establish a secure credential for each device if human intervention is required. To enhance usability and chance of practical deployment, it is important and necessary to remove manual operations by the user on an out-of-band (OOB) channel, such as secure pairing. Instead, a trusted third party is introduced to facilitate automatic trust establishment as well as reduce human error.
- Consistency: All the three protocol participants should have a consistent view of the protocol session. Namely, the three participants involved know who the peers are with respect to the specific session.
- Dynamic mutual trust and delegation: With the success of the protocol, each pair of the involved participants can reach a mutual trust at the end of the procedure. Further, the Guardian establishes the mutual trust dynamically with the Parent and obtains delegation before executing the privilege with respect to the Child.
- Secrecy and forward secrecy: The principle of least privilege should be followed, implying that any resultant secret key should only be shared between the involved two parties. No third party should be able to distinguish the resultant key from a random key. Also, the forward secrecy should be conserved so that the compromise of a long-term secret key will not affect the confidentiality of past communication sessions .
- Lightweight: As we focus on those resource limited devices, efficiency is a priority. When designing the protocol, the Child, which is typically, though not necessarily, a resource-constrained device, should be protected by shifting work load to the Guardian and the Parent as much as possible.
- Average administration requirements: The protocol should require as little professional knowledge as possible. The configurations are automatic and user-friendly so that people do not need to be IT experts to operate the protocol.
6.4. Adversarial Model
6.5. Protocol Design Choices and Considerations
6.5.1. Investigation of Three Party Key Exchange Protocols
6.5.2. SIGMA Protocol
6.6. Protocol Specifications
- G→C :G sends Message 1 to C to initiate a protocol session. The goal is to establish a trust relationship and a corresponding symmetric key to represent such trust. To construct Message 1, G generates a random nonce and sends it together with its identifier to C in plaintext.
- C→G :Currently, C has no knowledge regrading G, but sends back Message 2 to direct G to P for further authentication and delegation. Message 2 contains identity information for all three parties, and initial random nonces from C and G for a protocol session.
- G→P :Upon receiving Message 2 from C, G first verifies and are from Message 1 as well as no duplicate identifiers, i.e., and and . If all the verifications succeed, G then forwards Message 2 as Message 3 to C’s parent party P;
- P→G :Upon receiving Message 3 from G, P should validate the following:
Then P generates its own nonce , the Diffie-Hellman private exponent x and public value to construct Message 4, which corresponds to the first message of SIGMA protocol. Message 4 includes all three nonces so as to enhance the three-party context. This works as a challenge to G to reduce the chance of a denial of service (DoS) attack on P.
- All the identity information are correct.
- G can be authenticated.
- C is indeed its child entity.
- Requested privilege on C can be authorized to G.
- Authorization decision could be based on G’s identity and an additional data structure for the authorization. In different embodiments, various information may be included in the authorization data structure. Such data structure may be sent and verified by P and G in protocol exchange with Messages 4–6.
- G→P :Now G and P engage in a mutual authentication from Message 4 to Message 6. G first verifies that , , , and are from Message 3 as well as is an element of the Diffie-Hellman group. Then G sends Message 5, which corresponds to the second message of the SIGMA protocol, with the enhanced protocol context (e.g., matching identifiers and all three nonces) and its own Diffie-Hellman public value . G signs Diffie-Hellman public values with its public key certificate , and then computes a Message Authentication Code (MAC) on G’s own identity, further bound with C’s identity using the derived key from both parties Diffie-Hellman values. Note that the key used to compute the MAC is derived by Equations (1) and (2).
- P→G :P parses and validates the following in Message 5:
Then P sends back Message 6, which corresponds to the third message of the SIGMA protocol, with matching protocol context, signing Diffie-Hellman public values in reverse order (to protect against reflection attacks) with its own public key certificate , and computes the MAC on P’s own identity, using the same derived key . Note that Message 6 introduces additional data structures as part of the 3PKD protocol, namely two key provisioning tokens, upon making delegation decision to G:
- Verify , , , and () are from Message 4.
- Verify and G is authorized to receive a key for C.
- User the public key contained in to verify the signature .
- Verify is an element of the Diffie-Hellman group.
- P as the key provisioning server, generates a random key material k, which will be used later by G and C to compute shared secret key , to be delivered to both G and C.
- P generates an associated token for C using Equation (5), which includes the same authenticated data for this protocol instance (all identifiers and nonces) and encrypts the key k using , which is the existing parent key that P has established with C, prior to this protocol execution.
- As the key material k is securely encapsulated into and , P sends both tokens to G in Message 6, in addition to SIGMA authentication data structures.
- G→C :Upon receiving Message 6, G first validates as the following:
If all the validations succeed, at this point, G and P have completed mutual authentication and established a fresh secret symmetric key derived from the Diffie-Hellman handshake and the current session information as in Equation (3). Then G uses to decrypt token and extract the secret k, which implies G receives an authorization from P. Then G directly extracts from Message 6, and forwards it to C as Message 7 to further confirm with C whether they can reach the agreement that P has granted authorization to this delegation bounding to the same session.
- Verify , , , , and are from Message 5.
- Parse as and .
- User to verify .
- Verify .
- Verify signature .
- C→G :C validates the token with matching session information (namely, , , , and are from Message 2), then recovers the same key material k with . To construct Message 8, C computes session ID as in Equation (6) and uses key derived by Equation (7) to authenticate the message. As an option, G and C could further engage in an additional exchange locally to establish a pair secret ( could be ). This pair secret may be used as a contribution to the session information and further derivation, so that P has no knowledge of the established key between G and C;
- G→C :G parses Message 8 as , and MAC . G first verifies is from Message 2 and then verifies derived by Equation (6). G computes with Equation (7) and uses it to verify the . At last, G constructs Message 9 and sends it to C as an acknowledgement. Locally, G computes key with Equation (8) as the final outcome of the protocol.
- C: validate Message 9 and computeC parses Message 9 as , and MAC . C verifies is from Message 1, validates and then use to verify . C also computes the shared secret key with Equation (8).Message 8 and Message 9 are created by C and G, respectively and validated by G and C, respectively, to complete the 3PKD protocol to confirm the matching session information, and consistency in the provided key material from P. Therefore, all three parties reach an agreement that the delegation has been properly granted and confirmed by C, P and G, and derive as the final outcome of the protocol.
- C agrees: P and G are corresponding parties in the delegation as P and G; and P and G know that C agrees;
- P agrees: G can be authorized to receive the delegation on C; and both C and G know that P agrees;
- G agrees: P has successfully authorized the delegation to C, and C is indeed P’s child; C and P know that G agrees.
6.7. Discussions and Security Analysis
6.7.1. Protocol Security Analysis
6.7.2. Lightweight Approach
6.8. Proof of Concept
6.8.1. Modularized Prototype Framework
6.8.2. Implementation Choices and Considerations
6.8.3. Demo of the Prototype
- Step 1: G initiates the protocol and sends the first message < Guardian Request > to C.
- Step 2: C replies to G with < Child Response > indicating the identity of P.
- Step 3: G sends < Delegation Request > to P.
- Step 4: P performs SIGMA protocol and sends < Authentication Challenge > to G.
- Step 5: G replies P’s challenge with < Authentication Challenge Response >.
- Step 6: P grants two tokens to G in < Contract (TK1, TK2) >. P close the socket.
- Step 7: G forwards < Contract (TK2) > to C.
- Step 8: C starts the final handshake to confirm the key agreement in < Signed Contract > with G.
- Step 9: G finishes the handshake with < Contract Review > to confirm the key agreement with C.
- Step 10: C confirms the success of the handshake and key agreement.
6.9. Use Cases
Conflicts of Interest
- Ashton, K. That ‘Internet of Things’ Thing. RFID J. 2009, 22, 97–114. [Google Scholar]
- Atzori, L.; Iera, A.; Morabito, G. The Internet of Things: A Survey. Comput. Netw. 2010, 54, 2787–2805. [Google Scholar] [CrossRef]
- Giusto, D.; Lera, A.; Morabito, G.; Atzori, L. The Internet of Things; Springer: New York City, NY, USA, 2010. [Google Scholar]
- Strategic Business Insights (Firm). Six Technologies with Potential Impacts on US Interests out to 2025; Technical Report; The National Intelligence Council: Washington, DC, USA, 2008. [Google Scholar]
- Federal Trade Commission. Internet of Things—Privacy and Security in a Connected World; FTC: Seattle, WA, USA, 2013. [Google Scholar]
- Gartner Says the Internet of Things Installed Base Will Grow to 26 Billion Units By 2020; Gartner Inc.: Stamford, CT, USA, 2013.
- MobilityFirst Future Internet Architecture. Available online: http://mobilityfirst.winlab.rutgers.edu/ (accessed on 19 June 2017).
- eXpressive Internet Architecture. Available online: https://www.cs.cmu.edu/~xia/ (accessed on 19 June 2017).
- Named Data Networking. Available online: http://named-data.net/ (accessed on 19 June 2017).
- Nebula Future Internet Architecture Project. Available online: http://nebula-fia.org (accessed on 19 June 2017).
- CoRE Working Group DF-1 Protocol and Command Set Reference Manual; IETF Standards; Fremont, CA, USA, 1996.
- MelsecNet. Available online: https://eu3a.mitsubishielectric.com/fa/en/ (accessed on 19 June 2017).
- Distributed System (SDS). Available online: http://holjeron.com/products/sds-products/ (accessed on 19 June 2017).
- Newman, M. BACnet: the Global Standard for Building Automation and Control Networks; Momentum Press: New York City, NY, USA, 2013. [Google Scholar]
- European Telecommunications Standards Institute (ETSI). Low Throughput Networks (LTN): Functional Architecture; European Telecommunications Standards Institute (ETSI): Valbonne, France, 2014; ETSI GS LTN 002 v1.1.1. [Google Scholar]
- Global Sensor Networks. Available online: https://github.com/LSIR/gsn/wiki (accessed on 19 June 2017).
- Aberer, K.; Hauswirth, M.; Salehi, A. Infrastructure for Data Processing in Large-scale Interconnected Sensor Networks. In Proceedings of the IEEE International Conference on Mobile Data Management, Mannheim, Germany, 7–11 May 2007; pp. 198–205. [Google Scholar]
- Shelby, Z. RFC6690: Constrained RESTful Environments (CoRE) Link Format; IETF Standards; CoRE Working Group: Fremont, CA, USA, 2012. [Google Scholar]
- Shelby, Z.; Hartke, K.; Bormann, C.; Frank, B. RFC7252: The Constrained Application Protocol (CoAP); IETF Standards; CoRE Working Group: Fremont, CA, USA, 2014. [Google Scholar]
- Lee, C.T.; Yang, C.H.; Chang, C.M.; Kao, C.Y.; Tseng, H.M.; Hsu, H.; Chou, P.H. A Smart Energy System with Distributed Access Control. In Proceedings of the IEEE International Conference on Internet of Things, Cambridge, MA, USA, 6–8 October 2014. [Google Scholar]
- Cirani, S.; Picone, M.; Gonizzi, P.; Veltri, L.; Ferrari, G. IoT-OAS: An OAuth-Based Authorization Service Architecture for Secure Services in IoT Scenarios. IEEE Sens. J. 2015, 15, 1224–1234. [Google Scholar] [CrossRef]
- Blazquez, A.; Tsiatsis, V.; Vandikas, K. Performance Evaluation of OpenID Connect for an IoT Information Marketplace. In Proceedings of the 81st IEEE Vehicular Technology Conference (VTC Spring), Glasgow, UK, 11–14 May 2015; pp. 1–6. [Google Scholar]
- Seitz, L.; Selander, G.; Gehrmann, C. Authorization Framework for the Internet-of-Things. In Proceedings of the 14th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), Madrid, Spain, 4–7 June 2013; pp. 1–6. [Google Scholar]
- Fotiou, N.; Kotsonis, T.; Marias, G.F.; Polyzos, G.C. Access Control for the Internet of Things. In Proceedings of the International Workshop on Secure Internet of Things (SIoT 2016), Crete, Greece, 27 September 2016; pp. 29–38. [Google Scholar]
- Gerdes, S.; Bergmann, O.; Bormann, C. Delegated CoAP Authentication and Authorization Framework (DCAF); IETF Internet Draft: Fremont, CA, USA, 2015. [Google Scholar]
- Nitti, M.; Pilloni, V.; Colistra, G.; Atzori, L. The Virtual Object as a Major Element of the Internet of Things: A Survey. IEEE Commun. Surv. Tutor. 2016, 18, 1228–1240. [Google Scholar] [CrossRef]
- oneM2M. Available online: https://www.onem2m.org/ (accessed on 20 June 2017).
- Li, J.; Zhang, Y.; Nagaraja, K.; Raychaudhuri, D. Supporting Efficient Machine-to-machine Communications in the Future Mobile Internet. In Proceedings of the IEEE Wireless Communications and Networking Conference Workshops (WCNCW), Paris, France, 1–4 April 2012; pp. 181–185. [Google Scholar]
- Li, S.; Zhang, Y.; Raychaudhuri, D.; Ravindran, R. A Comparative Study of MobilityFirst and NDN based ICN-IoT Architectures. In Proceedings of the 10th IEEE International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness (QShine), Rhodes Island, Greece, 18–19 August 2014; pp. 158–163. [Google Scholar]
- Trappe, W.; Howard, R.; Moore, R.S. Low-Energy Security: Limits and Opportunities in the Internet of Things. IEEE Secur. Priv. 2015, 13, 14–21. [Google Scholar] [CrossRef]
- Zhang, F.; Nagaraja, K.; Zhang, Y.; Raychaudhuri, D. Content Delivery in the MobilityFirst future Internet Architecture. In Proceedings of the 35th IEEE Sarnoff Symposium (SARNOFF), Newark, NJ, USA, 21–22 May 2012; pp. 1–5. [Google Scholar]
- Su, K.; Bronzino, F.; Ramakrishnan, K.; Raychaudhuri, D. MFTP: A Clean-Slate Transport Protocol for the Information Centric MobilityFirst Network. In Proceedings of the 2nd ACM International Conference on Information-Centric Networking, San Francisco, CA, USA, 30 September–2 October 2015; pp. 127–136. [Google Scholar]
- Li, S.; Zhang, Y.; Raychaudhuri, D.; Ravindran, R.; Zheng, Q.; Dong, L.; Wang, G. IoT Middleware Architecture over Information-Centric Network. In Proceedings of the 2015 IEEE Globecom Workshops, San Diego, CA, USA, 6–10 December 2015; pp. 1–7. [Google Scholar]
- Moskowitz, R.; Nikander, P. Host Identity Protocol (HIP) Architecture; IETF Internet Standard, RFC 4423; The Internet Society: Fremont, CA, USA, 2006. [Google Scholar]
- Andersen, D.G.; Balakrishnan, H.; Feamster, N.; Koponen, T.; Moon, D.; Shenker, S. Accountable Internet Protocol (AIP). In Proceedings of the ACM SIGCOMM Conference on Data Communication, Seattle, WA, USA, 17–22 August 2008. [Google Scholar]
- Pan, J.; Jain, R.; Paul, S.; So-In, C. MILSA: A New Evolutionary Architecture for Scalability, Mobility, and Multihoming in the Future Internet. IEEE J. Sel. Areas Commun. 2010, 28, 1344–1362. [Google Scholar] [CrossRef]
- Liu, X.; Trappe, W.; Zhang, Y. Secure Name Resolution for Identifier-to-Locator Mappings in the Global Internet. In Proceedings of the 22nd IEEE International Conference on Computer Communications and Networks (ICCCN), Nassau, Bahamas, 30 July–2 August 2013; pp. 1–7. [Google Scholar]
- Liu, X.; Trappe, W.; Lindqvist, J. A Policy-driven Approach to Access Control in Future Internet Name Resolution Services. In Proceedings of the 9th ACM workshop on Mobility in the Evolving Internet Architecture, Maui, HI, USA, 7–11 September 2014; pp. 7–12. [Google Scholar]
- GlobalPlatform. The Trusted Execution Environment: Delivering Enhanced Security at a Lower Cost to the Mobile Market; GlobalPlatform Inc.: Redwood City, CA, USA, 2011. [Google Scholar]
- GlobalPlatform. TEE Systems Architecture v1.0; GlobalPlatform Inc.: Redwood City, CA, USA, 2011. [Google Scholar]
- Steiner, J.G.; Neuman, B.C.; Schiller, J.I. Kerberos: An Authentication Service for Open Network Systems. In Proceedings of the USENIX Winter, Dallas, TX, USA, 12 February 1988; pp. 191–202. [Google Scholar]
- Kaliski, B.; Arnold, T.S.; Schlafly, R.; Markowitz, M.; Yin, Y.L.; Arazi, B.; Blake, I.; Chen, L.; Finkelstein, L.; Fumy, W.; et al. IEEE Standard Specifications for Public-Key Cryptography; IEEE Computer Society: Los Alamitos, CA, USA, 2000. [Google Scholar]
- Canetti, R.; Krawczyk, H. Security Analysis of IKE’s Signature-based Key-Exchange Protocol. In Advances in Cryptology—CRYPTO 2002; Springer: New York City, NY, USA, 2002; pp. 143–161. [Google Scholar]
- Krawczyk, H. SIGMA: The ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols. In Advances in Cryptology-CRYPTO 2003; Springer: New York City, NY, USA, 2003; pp. 400–425. [Google Scholar]
- Choo, K.K.R.; Boyd, C.; Hitchcock, Y.; Maitland, G. On Session Identifiers in Provably Secure Protocols. In Security in Communication Networks; Springer: New York City, NY, USA, 2004; pp. 351–366. [Google Scholar]
- Needham, R.M.; Schroeder, M.D. Using encryption for authentication in large networks of computers. ACM Commun. 1978, 21, 993–999. [Google Scholar] [CrossRef]
- Denning, D.E.; Sacco, G.M. Timestamps in Key Distribution Protocols. ACM Commun. 1981, 24, 533–536. [Google Scholar] [CrossRef]
- Merkle, R.C. Secure Communications over Insecure Channels. ACM Commun. 1978, 21, 294–299. [Google Scholar] [CrossRef]
- Diffie, W.; Hellman, M.E. New directions in cryptography. IEEE Trans. Inf. Theory 1976, 22, 644–654. [Google Scholar] [CrossRef]
- Adrian, D.; Bhargavan, K.; Durumeric, Z.; Gaudry, P.; Green, M.; Halderman, J.A.; Heninger, N.; Springall, D.; Thomé, E.; Valenta, L.; et al. Imperfect forward secrecy: How Diffie-Hellman fails in practice. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, Denver, CO, USA, 12–16 October 2015; pp. 5–17. [Google Scholar]
- Diffie, W.; Van Oorschot, P.C.; Wiener, M.J. Authentication and Authenticated Key Exchanges. Des. Codes Cryptogr. 1992, 2, 107–125. [Google Scholar] [CrossRef]
- Karn, P.; Simpson, W. Photuris: Session-Key Management Protocol; IETF Network Working Group: Fremont, CA, USA, 1999. [Google Scholar]
- Harkins, D.; Carrel, D. The Internet Key Exchange (IKE); Technical Report, RFC 2409; IETF Network Working Group: Fremont, CA, USA, 1998. [Google Scholar]
- Kaufman, C. Internet Key Exchange (IKEv2) Protocol; IETF Network Working Group: Fremont, CA, USA, 2005. [Google Scholar]
- wolfSSL. Available online: https://www.wolfssl.com/wolfSSL/Home.html (accessed on 19 June 2017).
- ARM. mbedTLS. Available online: https://tls.mbed.org/ (accessed on 19 June 2017).
- Dworkin, M. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. In NIST Special Publication 800-38D; National Institute of Standards and Technology: Gaithersburg, MD, USA, 2007. [Google Scholar]
- Kivinen, T. More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE); RFC3526; IETF Network Working Group: Fremont, CA, USA, 2003. [Google Scholar]
- Rescorla, E.; Modadugu, N. Datagram Transport Layer Security Version 1.2; RFC6347; IETF Network Working Group: Fremont, CA, USA, 2012. [Google Scholar]
|Random Number Generator|
|nonce generated in the protocol session|
|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|
|Pseudo random function with k as the key and s as the seed|
|One way hash function on material M|
|Signature on material M using the private key of X|
|Message Authentication Code of M using key k|
|Authenticated encryption: B is encrypted and is authenticated using key k|
|Certificate of the protocol participant X|
|Token generated by Parent and granted to Guardian|
|Token generated by Parent and granted to Child|
|Parent key shared between Parent and Child|
|k||Random key generated by Parent for Guardian and Child|
|Intermediate component derived from Diffie-Hellman|
|Symmetric key derived from and used for computing message authentication code|
|Symmetric key derived from and used for protecting token|
|Symmetric key derived from and k and shared between Guardian and Child|
|Membership key shared between Guardian and Child|
|Local secret shared only between Guardian and Child (could be )|
|Cryptography Operation||Algorithm Choice|
|pseudo random function (prf)||HMAC-SHA256|
|Diffie-Hellman Groups||2048-bit MODP Group |
|asymmetric crypto||2048 bits RSA|
|Message Authentication Code (MAC)||HMAC-SHA256|
|symmetric key size||32 bytes|
|key identifier size||32 bytes|
|identifier size||32 bytes|
|MAC tag size||32 bytes|
|AES-GCM tag size||16 bytes|
|SHA-256 digest size||32 bytes|
|RSA key size||2048 bits|
|Diffie-Hellman key size||2048 bits|
© 2017 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).