LC-DEX: Lightweight and Efficient Compressed Authentication Based Elliptic Curve Cryptography in Multi-Hop 6LoWPAN Wireless Sensor Networks in HIP-Based Internet of Things †
Abstract
:1. Introduction
- An optimization of our previous proposed compression of HIP DEX protocol header [9] over an adaptable 6LoWPAN compression header;
- A minimization of the optional signaling packets (NOTIFY and CLOSE_ACK) and a proposition of a replacement technique in a novel distribution model;
- An efficient minimization in the overall E2E transmission delays of the HIP DEX handshake;
- An important reduction on the computational and communication energy costs of the handshake;
- Alleviation of HIP peers from the scalar multiplication of the key generation by the integration of a trust third party;
- Proposition of a new lightweight security association establishment scheme for LC-DEX;
- Proposition of a HIP DEX opportunistic mode during handshake packets’ exchange with the introduction of a Domain Name System service;
- Studies of the security threats and requirements of the proposed solution.
2. Problem Exposure and Motivations
- The separation of the identity and the physical location of the communicating peers is the strength of the HIP-based solution that facilitates end-users mobility and ensures a good level of location privacy. HIP separates the end-point identifier and locator roles of IP addresses. These qualities are highly recommended in many IoT deployments, as in health care and military applications;
- The number of exchanged messages to establish a key agreement mechanism is only four messages, which is not the case for the other security protocols;
- The use of HIP as a Keying material and IPsec for the tunneling for securing the communication between the two parts. This guarantees the security of communication in the network layer (coupling IPsec with HIP) and, as a consequence, securing all types of transport traffic layer (UDP or TCP);
- The protocol is designed to be resistant to Denial of Service (DoS) and man-in-the-middle attacks [5].
3. Background and Related Works
3.1. Authentication Goals in IoT
- Devices with low memory and computational capabilities;
- New applications and services are provided between users and devices in IoT;
- Solid nodes and secure communication for users;
- IoT devices can be integrated into all aspects of existing domains;
- Security of communications between nodes in WSN is critical because it is difficult or even impossible for human intervention after the deployment of sensors;
- Devices are battery-powered in general, and embedded applications must have low computational costs to save energy;
- Real-time applications in IoT require a high level of security with lightness in execution;
- IoT domains become very wide and distance between the sensor node and/or servers must not have a consequence on the communication overhead.
3.1.1. HIP-Based Solutions
3.1.2. Existing M2M-IoT Mutual Authentication Solutions
3.2. Authentication with HIP DEX Protocol
3.3. Overview of 6LoWPAN Compression Solutions
- Minimal communication cost: reduced length of compressed packets has as consequence a lower amount of formation will be communicated;
- Lower energy consumption for the communication phase;
- Minimal packet fragmentation rates: the reduced sizes of the exchanged packets help to reduce the fragmentation frequency;
- Gain in storage space;
- Optimization of the used throughput: the removal of unnecessary bytes of information from a packet’s header, data throughput will be eventually improved because significant bytes in the message will be free to contain the application data.
- For communications over a local link, the IPv6 header can be reduced to 2 bytes (1-byte Dispatch and 1-byte LOWPAN_IPHC);
- For communications requiring multiple IP hops, the header can be compressed to 7 bytes (1-byte Dispatch, 1-byte LOWPAN_IPHC, 1-byte Hop Limit, 2-bytes Source Address, and 2-bytes Destination Address).
3.4. HIP DEX Packet’s Format Analysis and Proposed Compression
3.4.1. HIP Header Fix Parameters Compressibility
3.4.2. HIP DEX-6LoWPAN Header’s Compressibility
4. The Proposed Optimization in HIP DEX Communication Energy Consumption
- : The MSL time required to the last packet sent by the sender’s HIP to attend the receiver’s HIP successfully;
- : The time spent by the CLOSE packet sent by the initiator to attend the CTTP. We consider that it is the same interval time spent by the CTTP to send the CLOSE packet to the responder;
- : The UAL waiting time of the responder for the reception of a message, such that . If , the responder may tear down the HIP association;
- : The time interval that the CTTP does not exceed to send repeated CLOSE messages to the responder.
4.1. HIP DEX Distribution Scheme
- Constrained nodes can achieve symmetric encryption;
- CTTP can perform asymmetric encryption because it is the most energy-consuming operation in the HIP DEX process;
- Each node must have a direct connection to the selected CTTP nodes during the initialization phase;
4.1.1. Initialization Phase
- Manual method: This solution requires a distribution of the public key to the end devices by uploading it to their memory manually. So, there are no messages exchange to distribute the key. The pair-keys must be changed periodically and charged again to all end devices to resist key recovery. The manual distribution key is beneficial from a security point of view because attackers can not divine the public key. However, it is not practical for IoT networks qualified by their wide geographical areas;
- Automated method: Despite the energy efficiency of the manual key distribution method (omitting the key transmission), it is not practical for many IoT applications where the administrator must charge the key in devices memories at least once a month.
4.1.2. New HIP DEX Secure Lightweight Association Establishment Phase
- The process starts with sending a trigger packet, I1, by the initiator to the responder;
- After receiving I1 and a successful mutual authentication with the CTTP, the responder sends the R1 packet containing the puzzle and (y,P) parameters to the CTTP;
- The CTTP performs the scalar multiplication operation = × where the resulting is the responder’s public key (HI). Then, the CTTP forwards R1 packet to the responder;
- The initiator sends the puzzle solution, the random value x, and MAC in the I2 packet to the CTTP;
- The CTTP computes = × that represents the initiator’s public key (HI) such that the CTTP stores the generator point P received in step 2. The CTTP, also, computes the secret’s initiator as S = × . Then, CTTP forwards the received I2 packet, including the computed S, to the responder;
- On receiving I2, the responder checks the puzzle solution and does not need to calculate the secret key because it has already been obtained from the CTTP. In HIP DEX the secret key calculated by the initiator and the responder are the same;
- The fourth message R2, also, has the MAC value, the key wrap parameters F(S,y) and it finalizes the handshake.
Mutual Authentication Responder/CTTP
- The adopted communication mechanism is the Direct Sensor Access (DSA) between the CTTP and the HIP-peer (Responder);
- The first step is about the reception of the hashed password, that will be used as an ID by all the sensor devices in the HIP IoT domain. Indeed, the base station is responsible for the generation of the OTP IDs that are updated after a certain period and calculated by a dedicated algorithm. These OTP IDs are stored in a local database in the target base station;
- The second step is about the verification if it is the first time to communicate with the CTTP. If it is the case, the mutual authentication using the OTP ID received, previously, from the base station is used to identify each other. Otherwise, there is no need to perform mutual authentication, and R1 is sent to the CTTP.
5. Introduction of a Domain Name System in a HIP DEX Opportunistic Mode
- After computing the , the responder’s HI (HI_R): the public key (see Figure 7, Section 4.1.2), the CTTP computes the HIT_R from HI_R using FOLD function to get the 96 bits-compressed format of HI_R and then stores a binding of HI_R and HIT_R corresponding to the responder in its local memory;
- The CTTP sends the calculated HIT_R to the initiator;
- After computing the as the initiator’s HI (HI_I) using FOLD function to get the 96 bits-compressed format of HI_I and then stores a binding of HI_I and HIT_I corresponding to the initiator in its local memory;
- The CTTP sends the calculated HIT_I to the responder.
6. Evaluation and Experimental Results
6.1. Network Model
6.2. Minimization of HIP DEX Handshake Packets’ Sizes
6.3. End-to-End Transmission Delay Reduction
6.3.1. End-to-End Transmission Delay
- is the transmission delay in seconds;
- L is packet length in bits;
- R is the transmission rate in bits/s. In our experiment, we implement a Constant Bit Rate (CBR) model equal to 250 kb/s.
6.3.2. Propagation Delay
- is the propagation delay in m/s;
- D is the distance between the Initiator and the Responder. In the experiment, we chose nodes with 1 meter of distance;
- is the propagation speed, which is calculated as speed of . The speed of light is 2.998 × m/s and the velocity factor = 1 because the propagation medium is the air.
6.3.3. Processing Overhead
6.3.4. Queuing Delay
- is in seconds;
- PN is a number of packets to process;
- L is the packet length;
- R is the transmission rate in b/s. As indicated in Section 6.3.1, R = 250 kb/s.
6.3.5. Overall E2E IoT Handshake Time Reduction
- is the transmission delay;
- Pr is the propagation delay;
- is the queuing delay;
- is the processing delay.
6.4. Energy Model
- Time is the execution time (ms) for individual cryptographic operation (time elapsed in CPU operations);
- Current is obtained based on experimental results;
- Voltage is the nominal voltage = 4.8 V.
6.4.1. Evaluation of the Multi-Hop Energy Communication Cost of the Proposed HIP DEX Compression Model
6.4.2. Efficient Reduction on the Energy Communication Costs in Comparison of Our Previous Work
6.4.3. Evaluation of the Computational Cost of the Proposed HIP DEX Compression Model
6.4.4. Overall Energy Consumption Results Compared with HIP-Based Solutions in IoT
6.5. Optimization in the Energy Consumption during the Life Cycle of the HIP-Sensor Peers
- The delegation of the most heavy cryptographic operation of HIP DEX to the CTTP, has a direct impact in minimizing the computational energy cost of the sensor during the active state and more precisely during the generation data mode;
- The exchanged parameters during the transmission of the R1 packet by the responder and during the transmission of the I2 packet by the responder are minimized in the proposed SLA model (see Section 4.1.2, Figure 7). Hence, we contribute to minimizing the energy consumption during the transmission mode for both the initiator and the responder in the active state.
7. Memory Requirements
8. Security Considerations
9. Results and Discussion
10. Conclusions and Future Works
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Acknowledgments
Conflicts of Interest
References
- Garcia-Morchon, O.; Keoh, S.; Kumar, S.; Hummen, R.; Struik, R. Security Considerations in the IP-Based Internet of Things. Draft-Garcia-Core-Security-04. 11 September 2013. Available online: https://datatracker.ietf.org/doc/html/draft-garcia-core-security-06 (accessed on 3 August 2021).
- Gubbi, J.; Buyya, R.; Marusica, S.; Palaniswami, M. Internet of Things (IoT): A vision, architectural elements, and future directions. Future Gener. Comput. Syst. 2013, 29, 1645–1660. [Google Scholar] [CrossRef] [Green Version]
- Dulman, S.; Havinga, P.; Chatterjea, S. Introduction to Wireless Sensor Networks. In Networked Embedded Systems, 1st ed.; CRC Press: Boca Raton, FL, USA, 2009; pp. 1–31. [Google Scholar]
- Rescorla, E.; Modadugu, N. Datagram Transport Layer Security Version 1.2. RFC 6347, (Proposed Standard), January 2012. Updated by RFC 7507. Available online: https://datatracker.ietf.org/doc/html/rfc6347 (accessed on 1 September 2021).
- Moskowitz, R.; Hummen, R.; Komu, M. HIP Diet EXchange (DEX) Draft-Ietf-HIP-DEX-24, Internet Draft (Work in Progress). 19 January 2021. Available online: https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex (accessed on 10 August 2021).
- Kaufman, C.; Hoffman, P.; Nir, Y.; Eronen, P.; Kivinen, T. Internet Key Exchange Protocol Version 2(IKEv2). RFC 7296 (Internet Standard), October 2014. Available online: https://www.rfc-editor.org/rfc/rfc7296.html (accessed on 20 October 2021).
- Blunk, L.; Vollbrecht, J.; Aboba, B.; Carlson, J.; Levkowetz, H. Extensible Authentication Protocol (EAP). June 2004 (Last Update 5 October 2017). Available online: https://datatracker.ietf.org/doc/rfc3748/ (accessed on 5 July 2021).
- Bettoumi, B.; Bouallegue, R. Evaluation of Authentication Based Elliptic Curve Cryptography in Wireless Sensor Networks in IoT Context. In Proceedings of the 26th International Conference on Software, Telecommunications and Computer Networks (SoftCOM), Split, Croatia, 13–15 September 2018; pp. 1–5. [Google Scholar]
- Bettoumi, B.; Bouallegue, R. Efficient Reduction of the Transmission Delay of the Authentication Based Elliptic Curve Cryptography in 6LoWPAN Wireless Sensor Networks in the Internet of Things. In Proceedings of the 2021 International Wireless Communications and Mobile Computing (IWCMC), Harbin, China, 28 June–2 July 2021; pp. 1471–1476. [Google Scholar]
- Adjih, C.; Baccelli, E.; Fleury, E.; Harter, G.; Mitton, N.; Noel, T.; Pissar, R. FIT IoT-LAB: A large scale open experimental IoT testbed. In Proceedings of the IEEE 2nd World Forum on Internet of Things (WF-IoT), Milan, Italy, 14–16 December 2015. [Google Scholar]
- Khurri, A.; Kuptsov, D.; Gurtov, A. On Application of Host Identity Protocol in Wireless Sensor Networks. In Proceedings of the 7th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (IEEE MASS), San Francisco, CA, USA, 8–12 November 2010; pp. 345–358. [Google Scholar]
- Ponomarev, O.; Khurri, A.; Gurtov, A. Elliptic Curve Cryptography (ECC) for Host Identity Protocol (HIP). In Proceedings of the 9th International Conference on Networks, Menuires, France, 11–16 April 2010; pp. 215–219. [Google Scholar]
- Chen, Q.-B.; Hu, H.-J.; Zhao, Y.-L.; Chai, R. HIP-based network mobility management for WSN. In Proceedings of the IEEE Youth Conference on Information, Computing and Telecommunications, Beijing, China, 28–30 November 2010. [Google Scholar]
- Moskowitz, R. Host Identity Protocol Architecture, Draft-ietf-hip-rfc4423-bis-20, Internet Draft 14 February 2019. Available online: https://datatracker.ietf.org/doc/html/draft-ietf-hip-rfc4423-bis (accessed on 22 April 2021).
- Jokela, P.; Moskowitz, R.; Melen, J. Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP), RFC 7402 April 2015. Available online: https://www.tech-invite.com/y70/tinv-ietf-rfc-7402.html (accessed on 28 April 2021).
- Heer, T. LHIP lightweight Authentication Extension for HIP, Draft-heer-hip-lhip-00, Internet Draft. February 2007. Available online: https://datatracker.ietf.org/doc/html/draft-heer-hip-lhip-00 (accessed on 12 May 2021).
- Hummen, R.; Hiller, J.; Henze, M.; Wehrle, K. Slimfit—A HIP DEX compression layer for the IP-based internet of things. In Proceedings of the IEEE 9th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), Workshop IoT, Lyon, France, 7–9 October 2013; pp. 259–266. [Google Scholar]
- Sahraoui, S.; Bilami, A. Compressed and distributed host identity protocol for end-to-end security in the IoT. In Proceedings of the International Conference on Next Generation Networks and Services (NGNS), Casablanca, Morocco, 28–30 May 2014. [Google Scholar]
- Ben Saied, Y.; Olivereau, A. D-HIP: A Distributed Key Exchange Scheme for HIP-Based Internet of Things. In Proceedings of the IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), San Francisco, CA, USA, 25–28 June 2012; pp. 1–7. [Google Scholar]
- Ben Saied, Y.; Olivereau, A.; Zeghlache, D.; Laurent, M. Lightweight collaborative key establishment scheme for the Internet of Things. Comput. Netw. 2014, 64, 273–295. [Google Scholar] [CrossRef]
- Porambage, P.; Braeken, A.; Kumar, P.; Gurtov, A.; Ylianttila1, M. CHIP: Collaborative Host Identity Protocol with Efficient Key Establishment for Constrained Devices in Internet of Things. Wirel. Pers. Commun. 2017, 96, 15–29. [Google Scholar] [CrossRef]
- Kanuch, P.; Macko, D. E-HIP: An Energy-Efficient OpenHIP-Based Security in Internet of Things Networks. Sensors 2019, 19, 4921. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Meca, F.V.; Ziegeldorf, J.H.; Sanchez, P.M.; Morchon, O.G. HIP security architecture for the IP-based internet of things. In Proceedings of the 27th International Conference on Advanced Information Networking and Applications Workshops, Barcelona, Spain, 25–28 March 2013; pp. 1331–1336. [Google Scholar]
- Nan, L.; Dongxi, L.; Surya, N. Lightweight Mutual Authentication for IoT and Its Applications. IEEE Trans. Sustain. Comput. 2017, 2, 359–370. [Google Scholar]
- Barker, E. Recommendation for Key Management—Part 1:General (Revision 4). In Proceedings of the Special Publication 800-57, NIST, 4 May 2020. Available online: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf (accessed on 11 June 2021).
- Jia, X.; Hu, N.; Su, S.; Yin, S.; Zhao, Y.; Cheng, X.; Zhang, C. IRBA: An Identity-Based Cross-Domain Authentication Scheme for the Internet of Things. Electronics 2020, 4, 634. [Google Scholar] [CrossRef] [Green Version]
- Esfahani, A.; Mantas, G.; Matischek, R.; Saghezchi, F.B.; Rodriguez, J.; Bicaku, A.; Maksuti, S.; Tauber, M.G.; Schmittner, C. A Lightweight Authentication Mechanism for M2M Communications in Industrial IoT Environment. IEEE Internet Things J. 2019, 6, 288–296. [Google Scholar] [CrossRef]
- Hu, N.; Tian, Z.; Du, X.; Guizani, N.; Zhu, Z. Deep-Green: A Dispersed Energy-Efficiency Computing Paradigm for Green Industrial IoT. IEEE Trans. Green Commun. Netw. 2021, 5, 750–764. [Google Scholar] [CrossRef]
- Lara, E.; Aguilar, L.; Sanchez, M.A.; García, J.A. Lightweight Authentication Protocol for M2M Communications of Resource-Constrained Devices in Industrial Internet of Things. Sensors 2020, 2, 501. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Bormann, C. 6LoWPAN Generic Compression of Headers and Header-Like Payloads, Internet-Draft-Bormann-6lowpan-ghc-04. 8 September 2014. Available online: http://www.watersprings.org/pub/id/draft-ietf-6lo-ghc-04.html (accessed on 4 June 2021).
- Track, S.; Hui, J.; Thubert, P. Compression Format for IPv6 Datagrams Over IEEE 802.15.4-Based Networks, RFC 6282, Standards Track. September 2011. Available online: https://datatracker.ietf.org/doc/html/rfc6282l (accessed on 14 July 2021).
- Sahraoui, S.; Bilami, A. Efficient HIP-based approach to ensure lightweight end-to-end security on the Internet of things. Comput. Netw. 2015, 91, 26–45. [Google Scholar] [CrossRef]
- Ali Ahmed, A.; Ali Ahmed, W. An Effective Multifactor Authentication Mechanism Based on Combiners of Hash Function over Internet of Things. Sensors 2019, 19, 3663. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Pellikka, J.; Gurtov, A.; An Faigl, Z. Lightweight Host and User Authentication Protocol for All-IP Telecom Networks. In Proceedings of the IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), San Francisco, CA, USA, 25–28 June 2012. [Google Scholar]
- Henderson, T.R.; AhrenholzJae, J.M. Kim, Experience with the Host Identity Protocol for Secure Host Mobility and Multihoming. In Proceedings of the IEEE Wireless Communications and Networking (WCNC), New Orleans, LA, USA, 16–20 March 2003. [Google Scholar]
- Hossain, M.; Hasan, R. P-HIP: A Lightweight and Privacy-Aware Host Identity Protocol for Internet of Things. IEEE Internet Things J. 2021, 8, 555–571. [Google Scholar] [CrossRef]
- de Meulenaer, G.; Gosset, F.; Standaert, F.-X.; Pereira, O. On the energy cost of communication and cryptography in wireless sensor networks. In Proceedings of the IEEE International Conference on Wireless and Mobile Computing, Networking and Communications, Avignon, France, 12–14 October 2008. [Google Scholar]
- Arm Developer, Cortex-A8 Datasheet. Available online: https://developer.arm.com/ip-products/processors/cortex-a/cortex-a8 (accessed on 4 August 2021).
- AM3517, AM3505 Sitara Processors (Rev. F). Available online: https://www.ti.com/document-viewer/AM3505/datasheet (accessed on 2 August 2021).
- Low Power 2.4 GHz Transceiver for ZigBee, IEEE 802.15.4, 6LoWPAN, RF4CE, SP100, Wireless HART, and ISM Applications (Datasheet). Available online: http://ww1.microchip.com/downloads/en/DeviceDoc/doc8111.pdf (accessed on 10 April 2021).
- de Gorostiza, E.F.; Berzosa, J.; Mabe, J.; Cortiñas, R. A Method for Dynamically Selecting the Best Frequency Hopping Technique in Industrial Wireless Sensor Network Applications. Sensors 2018, 18, 657. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Raza, S.; Wallgren, L.; Voigt, T. SVELTE: Real-time intrusion detection of Things. Ad Hoc Netw. 2020, 11, 2661–2674. [Google Scholar] [CrossRef]
- Achka, R.; Kfoury, E.; Saab, J. A Self Organizing Map Intrusion Detection System for RPL Protocol Attacks. In Proceedings of the Wireless Telecommunications Symposium (WTS), Phoenix, AZ, USA, 18–20 April 2018. [Google Scholar]
- Ben Saied, Y.; Olivereau, A. HIP Tiny Exchange (TEX): A distributed key exchange scheme for HIP-based Internet of Things. In Proceedings of the Third International Conference on Communications and Networking, Hammamet, Tunisia, 9 March–1 April 2012. [Google Scholar]
HIP Solution | Layer | Technique | Com. Cost | Cpt. Cost | Translation in the 6BR | DoS Attack Resistance | F.T. |
---|---|---|---|---|---|---|---|
LHIP [16] | HIP Layer | Omitting public key cryptography | + | - | May be required | Very weak | - - |
E-HIP [22] | HIP layer | Removing messages and parameters | + | ++ | May be required | Supported | - - |
HIP DEX [5] | HIP layer/Data link | Assumption of ECC Diffie-Hellman method | - | ++ | May be required | Supported | - |
D-HIP [19] | HIP layer | Distribution messages | ++ | - - | Required | Server only | - - |
Slimfit [17] | HIP layer | Messages compression | - | + | May be required | Server only | - |
HIP DEX + AMIKEY [23] | HIP layer | Lightweight key management | ++ | + | May be required | Server only | + |
HIP DEX [8] | HIP layer/ Data link | HIP DEX implementation in WSN | - | - - | Required | Supported | + |
CHIP [21] | HIP layer | Compression | - | - - | Required | Supported | + |
HIP DEX [8] | HIP layer/Data link | HIP DEX implementation in IoT | - | - - | May be required | Supported | + |
CD-HIP [18] | HIP layer | Compressed and Distributed HIP BEX | ++ | ++ | Required | Supported | + |
Bettoumi et al. [9] | Data Link | Compressed HIP DEX/6LowPAN header | - | - | Required | Supported | + |
HIP DEX Header Field | Length Before Compression (bits) | Length After Compression (bits) |
---|---|---|
Next header | 8 | 0 or 8 |
Header length | 8 | 0 |
Packet type | 7 | 3 |
VER. | 4 | 0 |
RES. | 3 | 0 |
Fixed bits 0 and 1 | 2 | 0 |
Checksum | 16 | 0 |
Controls | 16 | 0 |
HIT_I | 128 | 96 |
HIT_R | 128 | 0 |
Header length | 40 bytes | Min header = 12 bytes, Max header = 13 bytes |
Component | Description |
---|---|
CPU | ARM Cortex-A8 with M3 co-microcontroller |
Speed | 72 Mhz |
RAM | 256 MB |
Transceiver | IEEE 802.15.4 |
Radio Bandwidth | 250 kbps |
Layer | Protocol |
---|---|
Application | CoAP |
Transport | TCP |
Network | 6LowPAN-RPL |
Link | IEEE 802.15.4 |
Packet | Packet’s Size before Compression | Packet’s Size after Compression [9] | Packet’s Size after Compression LC-DEX | Percentage Gain [9] | Percentage Gain with LC-DEX |
---|---|---|---|---|---|
I1 | 137 | 122 | 110 | 11% | 20% |
R1 | 228 | 213 | 201 | 7% | 12% |
I2 | 284 | 269 | 257 | 5% | 9.5% |
R2 | 193 | 178 | 166 | 8% | 14% |
Overall packets sizes | 842 | 782 | 734 | 7% | 13% |
Handshake | Messages | Exchanged Bytes | Percentage Gain of LC-DEX Comparing with Previous Works |
---|---|---|---|
E-HIP [22] | 4 | 1536 | 52% |
HIP BEX [34] | 4 | 968 | 24% |
PANA/EAP-TLS [35] | 13 | 7061 | 90% |
HIP-AKA [34] | 8 | 936 | 22% |
D-HIP [19] | 4 | 3580 | 79% |
HIP DEX + AMIKEY [23] | 6 | 744 | 1.3% |
Bettoumi et al. [9] | 4 | 782 | 6% |
LC-DEX | 4 | 734 | - |
Contribution | Transmission Time (s) |
---|---|
Bettoumi et al. [9] | 0.025 |
LC-DEX | 0.023 |
Percentage gain | 8% |
Packet | P-HIP | Bettoumi et al. [9] | LC-DEX |
---|---|---|---|
I1 | 133 | 3.9 | 3.5 |
R1 | 340 | 6.8 | 6.4 |
I2 | 418 | 8.6 | 8.2 |
R2 | 185 | 5.6 | 5.3 |
Overall transmission delay | 1076 | 24.9 | 23.4 |
Architecture | I1 + I2 Processing Delays (s) | R1 + R2 Processing Delays (s) |
---|---|---|
WSN based-IPv4-IoT [9] | 0.166 | 0.156 |
WSN based-6LoWPAN-IoT (Standard HIP DEX) [9] | 0.188 | 0.168 |
WSN based-6LoWPAN-IoT (Compressed-HIP DEX) [9] | 0.156 | 0.156 |
LC-DEX | 0.146 | 0.146 |
Results in [34] | Results in [35] | P-HIP [36] | Slimfit [17] | Bettoumi et al. [9] | LC-DEX | |
---|---|---|---|---|---|---|
Initiator | 0.95 | 1.799 | 0.3 | 1.88 | 0.156 | 0.146 |
Responder | 0.79 | 0.729 | - | 1.895 | 0.156 | 0.146 |
Architecture | Overall E2E HIP DEX Handshake’s Delay (s) |
---|---|
WSN based-IPv4-IoT | 0.57 |
WSN based-6LoWPAN-IoT (before compression) | 0.39 |
WSN based-6LoWPAN-IoT (after compression) | 0.34 |
HIP Solution | Handshake Latency Time (s) | Percentage Gain |
---|---|---|
P-HIP | 1.076 | 70% |
Bettoumi et al. [9] (after compression) | 0.34 | 6% |
LC-DEX (after compression) | 0.32 | - |
Handshake Packets | 1 Hop (mJ) | 4 Hop (mJ) | 8 Hop (mJ) | |||
---|---|---|---|---|---|---|
4 packets | 1.729 | 1.62 | 1.959 | 1.85 | 2.267 | 1.26 |
6 packets | 2.11 | 1.95 | 2.456 | 2.3 | 2.916 | 2.76 |
8 packets | 2.998 | 2.79 | 3.459 | 3.25 | 4.074 | 3.86 |
HIP Solutions | Computational Cost (mJ) | Communication Cost (mJ) | Total Energetic Cost (mJ) |
---|---|---|---|
Standard HIP DEX | 13.365 | 0.329 | 13.694 |
Ben-Saied et al. [20] | 3.43 | 94.55 | 97.98 |
D-HIP [19] | 15.17 | 86.59 | 101.76 |
C-HIP [18] | 63.622 | 47.186 | 110.808 |
CD-HIP [18] | 14.93 | 52.16 | 67.09 |
Slimfit [17] | 1.286 | not indicated | - |
Bettoumi et al. [9] | 4.182 | 1.729 | 5.911 |
LC-DEX | 3.931 | 1.62 | 5.551 |
Extension | RAM (KiB) | Memory Percentage Use |
---|---|---|
Linux OS | 7864 | - |
Initiator (I1 + I2) | 8140 (+276) | 3% |
Responder (R1 + R2) | 8136 (+272) | 3% |
Attack | Layer | Scenario | Defense |
---|---|---|---|
Collision attack | Link | A collision is triggered by the usage of the same channel frequency by the HIP peers. | HIP communicating peers should implement a solution to avoid collision attacks. |
Denial of Service (DoS) attack | Link | An attacker may produce a collision when transmitting the signaling CLOSE_ACK packet. A bombardment in transmitting repeatedly such resulting collision has a costly resource consuming on the victim node. | HIP peers must be protected against DoS attack. |
Flooding attack | Transport | An adversary try to flood the edge 6 BR to interrupt the communication between the peers. | Compressed HIP packets should be protected against the flooding attack on the 6LoWPAN edge router. |
Data freshness | Link | An adversary lunch a replay attack using an old shared key at the same time when a new key is being distributed to the nodes. The adversary stores exchanged HIP messages and then initiates the communication with the peers. | HIP peers do not receive new keys from an external appliance. HIP peers should be able to detect malicious packets during the handshake. |
MITM | Link | An attacker can store the HIP packets (I1, R1, I2, R2) and then replay a packet with the HIP peer as it is the legitimate target. | The exchanged HIP packets must be protected against MITM attacks. |
Node capture | An attacker may lunch node capture attacks on the gateways and get cryptographic keys and add other malicious nodes in the network as legitimate ones. | A defending strategy must take place. |
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2021 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 (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Bettoumi, B.; Bouallegue, R. LC-DEX: Lightweight and Efficient Compressed Authentication Based Elliptic Curve Cryptography in Multi-Hop 6LoWPAN Wireless Sensor Networks in HIP-Based Internet of Things. Sensors 2021, 21, 7348. https://doi.org/10.3390/s21217348
Bettoumi B, Bouallegue R. LC-DEX: Lightweight and Efficient Compressed Authentication Based Elliptic Curve Cryptography in Multi-Hop 6LoWPAN Wireless Sensor Networks in HIP-Based Internet of Things. Sensors. 2021; 21(21):7348. https://doi.org/10.3390/s21217348
Chicago/Turabian StyleBettoumi, Balkis, and Ridha Bouallegue. 2021. "LC-DEX: Lightweight and Efficient Compressed Authentication Based Elliptic Curve Cryptography in Multi-Hop 6LoWPAN Wireless Sensor Networks in HIP-Based Internet of Things" Sensors 21, no. 21: 7348. https://doi.org/10.3390/s21217348