Enhanced Inf-TESLA Protocol: A Continuous Connectivity and Low Overhead Authentication Protocol via IoT Devices

Continuous and low-cost broadcast authentication is a fundamental security service for distributed sensor networks. This paper presents a novel development of a continuous and low-overhead broadcast authentication protocol named enhanced Infinite timed-efficient stream-loss tolerant authentication (enhanced Inf-TESLA) protocol, based on the Inf-TESLA protocol, whose continuous authentication is limited to the duration of its keychains. The enhanced Inf-TESLA protocol satisfies important security properties, including lower communication and computational overhead; a continuous generation of keychains without the need to establish synchronization packets; scalability to a large network; and resistance to masquerading, modification, man-in-the-middle, and replay attacks. We also highlighted an unaddressed authentication issue in the last packets of the original TESLA protocol and proposed a corresponding solution. We performed a simulation analysis using JAVA and proved that, compared to the Inf-TESLA protocol, the enhanced Inf-TESLA protocol can continuously authenticate packets for the entire lifetime of the receiver. We also compared the enhanced Inf-TESLA protocol with the original TESLA protocol in terms of time complexity and critical authentication processes. The results revealed the superiority of the enhanced Inf-TESLA protocol over the original TESLA protocol in terms of the message authentication code (MAC) value generation time and packet authentication time, which we believe can significantly improve the lifetime and lower the energy expenditure of Internet of Things devices with limited power sources.


I. INTRODUCTION
The development of the Internet of Things (IoT) technology has enabled billions of devices around the world to be connected to the Internet to collect and share data, create a level of digital intelligence, and support real-time communication The associate editor coordinating the review of this manuscript and approving it for publication was Chunsheng Zhu . of data [1]. Majority of devices that contribute to the IoT are constrained devices that have access to user information and daily life changes, which makes them vulnerable to cybersecurity attacks. Counter actions include using IoT devices as entry points to access other parts of the network or as a bait to turn down the attacker's system down. Constrained devices, such as sensors or smart devices, have limited CPU, memory, and power resources, which restricts the use of security protocols in protecting the privacy of their transferred data [1], [2].
The main challenges in securing broadcast communication are source and integrity authentication, verifying that the received data comes from a legitimate source and has not been altered en-route [3]. Furthermore, maintaining continuous authentication between the source and destination during its lifetime is another security and resource management challenge to avoid wasting energy while needlessly repeating the source verification process [4], [5]. Consequently, security protocols have begun to focus on important services to be protected while maintaining a reliable lifetime of the devices. The development of the TESLA (timed efficient stream loss-tolerant authentication) protocol in [6] and its variants introduced broadcast authentication protocols for constrained devices with low communication and computational overhead, relying on symmetric cryptographic functions (symmetric keychains and message authentication code (MAC) functions) to be exchanged for authentication of the sender and its data [7]. TESLA protocols also enable asymmetric properties by establishing a loose synchronization between the sender and the receiver [8] and with the disclosure delay available to protect the exchanged keys. However, the issue of continuous authentication between the sender and the receiver has not been addressed properly in any variant of the TESLA protocol.
It is claimed that a variant of the TESLA protocol named Inf-TESLA [9] provides continuous authentication by using two keychains in offset alignment, allowing one keychain to authenticate the data while the other is being generated. It only synchronizes the time at the beginning of the connection and relies on alternation between the keychains to authenticate the packets. However, once the two keychains expire, the synchronization between both parties needs to be restarted, which wastes energy, memory space, and time while communicating with the same sender. Moreover, there is an unaddressed issue in authenticating the last packets in the variant TESLA protocols, which we revealed for the first time. These challenges motivated us to propose a continuous and low-overhead authentication protocol for IoT devices.
In this paper, we present a new variant of the Inf-TESLA protocol named enhanced Inf-TESLA protocol, which allows continuous communication and authentication between the sender and the receiver by regenerating new offset keychains during their communication time window without the need to establish a new synchronization. Our proposed protocol relies on the inclusion of an additional symmetric key, called the master key, to be exchanged between the sender and the receiver during their first synchronization, performing one-way hashing and symmetric encryption to protect the secret keys exchanged between the parties to generate new keychains. While the Inf-TESLA protocol tends to cut the connection between the sender and the receiver after the expiration of the first two keychains, the enhanced Inf-TESLA protocol can keep the communication channel between the sender and the receiver available for authenticating the broadcasting packets, starting from a single synchronization packet, and regenerating the keychains as long as the communication between the parties is not terminated. We also propose a solution for the authentication issue of the last packets in variant TESLA protocols, with no additional computational overhead. Therefore, we listed the contributions of our study as follows: 1. Developing an enhanced Inf-TESLA protocol to provide continuous authentication and low computational overhead to the receiver during the generation of the keychains, without re-establishing synchronization packets between the sender and the receiver. 2. Exposing the unaddressed issue of authenticating the last packets in the existing TESLA protocols and proposing a minimal computational overhead solution. 3. Analyzing the time complexity of the original TESLA and enhanced Inf-TESLA protocols through simulation results and proving it theoretically. 4. Performing comparative analysis between the original TESLA and enhanced Inf-TESLA protocols in terms of the computational overhead on the sender and receiver sides. 5. Studying resistance against cybersecurity attacks including masquerading, modification, man-in-the-middle, and replay attacks. The remainder of this paper is organized as follows: Section II discusses a related-work review of variant TESLA protocols. Section III demonstrates the discontinuity problem of TESLA protocols, including the Inf-TESLA protocol. Section IV discusses the proposed enhanced Inf-TESLA protocol. Section V explains the authentication issue of the last packets in existing TESLA protocols and our proposed solution. Section VI presents a comparative analysis between the enhanced Inf-TESLA protocol and the original TESLA protocol. Finally, Section VII summarizes the conclusions.

II. RELATED WORK
The TESLA protocol is a broadcast authentication protocol that possesses important properties that allow it to be implemented in constrained IoT devices [6]. It relies on symmetric cryptography, wherein there is a symmetric key shared between the sender and the receiver, and the MAC function that uses the symmetric key to output an MAC number with the original message as an input. The broadcasted packets contain the original message and its MAC value to allow the receiver to authenticate the sender and maintain the integrity of the message. TESLA also provides asymmetric cryptography through a time-delay interval to disclose the symmetric key between the sender and the receiver. In other words, the symmetric key will not be disclosed when the message is being sent, but there is a certain time-delay called disclosure delay (d), during which the receiver needs to wait until the sender reveals the key to be used for authentication of the previous message. Moreover, the loose synchronization time provided between the sender and the receiver helps reduce the computational demands and energy consumption VOLUME 10, 2022 of constrained devices [8]. Recent implementation of TESLA protocols involved the authentication of GPS navigation messages and event-driven traffic between the VANET network members [10]- [12]. TESLA protocol is proposed to be used during the real-time nature of VANETs as it uses symmetric key encryption schemes, which are verified by the receiver in a shorter time as compared to using asymmetric digital signatures [13].
The drawbacks of the TESLA protocol lie in the lack of scalability of new IoT devices joining the network or the loss of predefined keychain packets, due to weak communication. It also tends to waste time and energy while establishing synchronization with the same sender, owing to the expiration of the keychain during the communication time window associated with the receiver. Therefore, improvements and updates have been proposed for the original TESLA protocol to increase security, connectivity, and scalability.
Tesla ++ was developed to simplify the messages being transferred between the sender and the receiver to reduce the computational overhead and packet loss [14]. The MAC value is first sent to the receiver, and after the disclosure delay, the original message and disclosed key are sent for authentication purposes. An attacker will not have prior knowledge about the message before the key disclosure and, therefore, will be incapable of manipulating the message. It also reduces the buffering size of messages waiting until the key disclosure. However, the protocol still follows the synchronization establishment between network members upon termination of the keychain, which lacks immediate and continuous authentication.
Staggered TESLA was proposed to reduce the time required to filter the received packets and the probability of buffering overflow while waiting for the key to be disclosed [15]. Additional MAC values of non-authenticated messages are included in the broadcast packet to protect it from being manipulated. These MAC values are related to the time intervals for which their keys are not yet disclosed, and the number of extra MAC values added depends on the network applicability. The inclusion of the MAC values can partially authenticate the packet before disclosing the key by recognizing a familiar pattern. If unusual MAC values are received, the receiver immediately drops the packet without buffering it until the disclosure of the key, which can reduce the buffer overflow in the system. Although staggered TESLA improves the scalability of the IoT network, it increases buffering issues and packet losses when an attacker floods the buffer with replicas of MAC numbers. In addition, it does not support continuous authentication between network members as the key chain terminates.
The µTESLA protocol aims to simplify the functionality of the Tesla protocol from a broadcast authentication into a unicast authentication, where the sender authenticates one receiver at a time [1], [9], [16]. This process reduces the computational power and the communication bandwidth usage of the receiver receiving unnecessary authentication packets that do not belong to them. An enhancement to the µTESLA protocol introduces a third trusted party (key server) between the sender and the receiver, responsible for sending the symmetric key while the sender sends the message [17]. This increases the difficulty for the attacker while forging, especially because the key server is hard to compromise. Nevertheless, unicasting the initial key and security parameters delays the joining of new members to the network, which does not support scalability. Moreover, it does not resolve the lack of immediate and continuous authentication presented in the original TESLA protocol.
Multilevel µTESLA is introduced to reduce the authentication time-delay between the sender and the receiver and the probability of having a denial of service attack [18], [19]. Two keychains are generated, where the high-level keychain is directly connected to the base station, and the low-level keychain is responsible for authenticating the packets transferred between the sender and the receiver. The high-level keychain has a long-time interval to cover the entire lifetime of the receiver without requiring the establishment of a new keychain to reduce the computational complexities and demands. Each time interval in the high-level key chain is further divided into short intervals that correspond to the lowlevel keychain. The advantage of short time intervals is that they reduce the time required to receive and authenticate the packet, so that the time-delay is tolerable. However, multilevel µTESLA does not support continuous authentication among the network members. Moreover, the inclusion of two-level keychains increases the computational overhead in the network.
The last improvement to the TESLA protocol is called infinite TESLA protocol (Inf-TESLA), which claims to provide continuous authentication between the sender and the receiver even after the keychain has expired [9]. Inf-TESLA introduces two keychains that are in offset alignment with each other so that if one keychain expires, the other chain continues working and maintains synchronization between the sender and the receiver. These two keychains can follow either the two key modes, where both keys will be sent in the broadcast packet, or an alternating mode, where a key from either chain is presented alternately; if one keychain corresponds to the odd intervals, then the other chain corresponds to the even intervals. The drawback of Inf-TESLA is the limited authentication period between the sender and the receiver, which depends on the keychain duration. In other words, once the two keychains expire, the overall authentication is terminated, and a new synchronization must be established if the sender is still communicating with the receiver. This leads to the absence of continuous authentication between the sender and the receiver during the communication time window. Hence, we propose our enhanced Inf-TESLA protocol that guarantees continuous authentication and regeneration of the required offset keychains as long as the communication channel is running between the sender and the receiver, without the need to establish a synchronization process that drains the battery and buffer space of constrained devices. Table 1 in section VI summarizes the advantages and disadvantages of the previously discussed variant TESLA protocols, and the proposed Enhanced Inf-TESLA protocol that is discussed later in section IV. A more detailed explanation of the security properties provided by these protocols can be found in [20].

III. DISCONTINUITY PROBLEM IN THE INF-TESLA PROTOCOL
In variant TESLA protocols, when the key level reaches the last key element, the system must re-establish a new synchronization between the same sender and receiver as if they are new to the connection. These unnecessary establishments increase computational demands and energy wastage. To overcome this problem, Infinite-TESLA introduces two keychains that are in offset alignment with each other, so that if one keychain expires, the other chain still works, maintaining synchronization between the sender and the receiver. The commitment keys of the two keychains are sent within the synchronization packet, which is sent only once to the receiver, to reduce the time and energy wasted while signing the packet with a digital signature and verifying the packet at the receiver side. This leads to the condition wherein all receivers that want to connect to the sender need to be available at the beginning of the connection to receive the desired synchronization packet and achieve the necessary security parameters; otherwise, they will miss the opportunity to authenticate the received packets. Once the two keychains of the Inf-TESLA expire, the connection is terminated, and a new synchronization message is required when the receiver wants to reconnect to the server [21]. This is because during the exchange between the end of the keychain and the generation of another keychain, to continue authentication, a commitment key must be exchanged between the sender and the receiver every time a new keychain is to be generated. Recall that in the Inf-TESLA protocol, the synchronization packet is only sent once at the beginning of the simulation; therefore, the claim of continuous resynchronization in the Inf-TESLA is not valid for more than two keychains.

IV. ENHANCED INF-TESLA PROTOCOL
In this study, we propose a new enhancement to the Inf-TESLA protocol, named enhanced Inf-TESLA, which allows the protocol to maintain communication continuity between the generated keychains without the need to always distribute the synchronization packet to the receiver. The enhanced Inf-TESLA protocol relies on symmetric encryption and hashing functions, which have low computational demands on protocol performance.
Our enhancement begins by generating a master key (K m ) to be shared between the sender and the receiver in the synchronization packet, where this master key is going to be among the master keychains responsible for encrypting and decrypting the commitment keys that will be hidden in the last packets of the keychains throughout the lifetime of the receiver. Let us assume that the enhanced Inf-TESLA protocol is processing ''keychain m'' and ''keychain m-1,'' as depicted in Fig.1; once the enhanced Inf-TESLA keychains reach the last elements used to exchange messages, the sender will start generating two new keychains and extracting their commitment keys.
The last packet from keychain m-1 and keychain m is used to send the commitment key of the next keychain (K m+1 0 and K m+2 0 ) encrypted with the master key ( e Km ). The last packets will contain four elements as follows: where msg i is the message sent during the ith interval, msg i+1 is the message sent during the (i + 1)th interval, d is the disclosure delay assigned by the protocol, K m−1 i is the key used to generate the MAC value of the message at the ith interval, K m i+1 is the key used to generate the MAC value of the message at (i + 1)th interval, K m−1 i−d is the key to be used to authenticate the message sent at (i − d)th interval, and K m i+1−d is the key to be used to authenticate the message sent at (i + 1 − d)th interval. One needs to note that P i and P i+1 are each sent using alternating keychains. Fig.2 shows the last packets of the keychains that contain the hidden commitment keys encrypted using the master key.  During packet reception, the receiver checks the number of elements sent in the packets to distinguish the upcoming encrypted commitment keys from those of the normal packets sent during the authentication process. The receiver also checks the time at which the packet is received; if the packet is received during the disclosure delay, it is considered as a forged packet and is dropped, otherwise it is saved in the buffer. The master key received in the synchronization packet is then used to decrypt the commitment keys needed to authenticate incoming packets.
To avoid sniffing attacks by malicious users and revealing the original master key value during the broadcasting process, every time the sender needs to use the master key, it is first hashed using a one-way hash function to generate a new master key for encrypting the commitment key. The receiver side performs the same procedure by hashing its master key to generate a new key whenever the master key is required to decrypt the commitment key. This process helps to secure the original value of the master key from being sniffed, as it is protected by the irreversible hashing process and avoids breaking the encryption process of the hidden commitment keys. Fig.3 illustrates the hashing process performed at the sender and receiver sides when the last interval of the two keychains is reached. At the end of keychain 1, the sender hashes the master key K m using a one-way hash function to generate the hashed master key h 1 K m that will act as the secret key of the symmetric encryption. After encrypting the new commitment key, the ciphertext will be sent within the last packet to the receiver. Once the packet is received by the receiver, the number of elements will be counted to distinguish the last packet from a normal broadcasted packet.
The fourth element will then be extracted for the decryption process. Subsequently, the receiver will apply the hashing process to its master key to generate the same hashed master key (h 1 K m ) used in the encryption process by the sender side. The hashed key will be the secret key used by the receiver to decrypt the ciphertext and extract the new commitment key. At the end of the second keychain from the sender side, the hashed master key h 1 K m will be hashed again to generate a new hashed key h 2 K m used for the next encryption process. This process is followed every time an encryption process is needed to broadcast new commitment keys. The receiver side will also hash its hashed master key to generate the same hashed key used during the encryption process. This way the sender and the receiver are in explicit synchronization with each other regarding the generation of the hashed master keys used in the encryption and decryption processes.

V. AUTHENTICATION ISSUE OF THE LAST D PACKETS IN THE VARIANT TESLA PROTOCOLS
An unaddressed issue exists in the previously discussed variant TESLA protocols related to the last d packets (recall that ''d'' is the disclosure delay). During the broadcasting process, the last d packets received by the receiver are not authenticated, as the chain from the sender side ends before disclosing its corresponding keys.
From the example in Fig.4, the last packet received by the receiver contains msg n , MAC n , which are generated using the key, and the disclosed key K n−d is used to authenticate. This indicates that any message sent after the (n-d)th interval will be buffered at the receiver side without being authenticated. To overcome this issue in the enhanced Inf-TESLA protocol, we propose adding additional d intervals to the sender's keychain to send the last d keys to authenticate the remaining buffered packets at the receiver side before starting a new keychain. Fig.5 shows the authentication process of the last d packets on the receiver side. The last n + d interval packet contains the disclosed key, which is the last key element used to protect the nth packet sent to the receiver for buffering. Hence, all the n packets sent by the sender are verified by the receiver with the inclusion of additional d packets to the existing keychain. Moreover, the overal computational overhead will not change at the sender or the receiver side, as the number of d packets added to the choveral ain is much smaller compared to the size of the keychain. This solution is also implemented in the original TESLA protocol for further comparative analysis.

VI. COMPARATIVE ANALYSES BETWEEN THE ENHANCED INF-TESLA AND ORIGINAL TESLA PROTOCOLS
We performed a simulative comparative analysis between our enhanced Inf-TESLA and the original TESLA protocols by discussing the time complexity analyses of the protocols for 54916 VOLUME 10, 2022  the first time and the computational overhead at the sender and receiver sides.

A. TIME COMPLEXITY ANALYSIS
In this section, we analyze the time complexity of the original and enhanced Inf-TESLA protocols from a mathematical and simulation point of view. We used the Big O notation to indicate the time complexity of an algorithm, as it quantifies the amount of time taken by an algorithm to execute as a function of the length of the string representing the input.

1) SIMULATION ANALYSIS
In the time complexity analysis, the most time-consuming part is a repetitive operation that is controlled by the input for which its size can grow/change according to the application specifications. Therefore, we investigated a part of the TESLA algorithm containing a loop, which is related to the keychain size, and studied the effect of changing the keychain length on the overall generation time. We varied the keychain between 100-1000 keys and recorded its generation time.
An average simulation data of 30 iterations were recorded for each keychain length, and curve fitting was performed to best describe the resulting data.
From the simulation data and the curve fitting results shown in Fig.6(a) and Fig. 6(b) for both algorithms, we observed that the generation time of the keychain increases linearly with an increase in the number of keys required in the chain. Consequently, the linear relationship in the Big O notation is described by O(n), where n is the number of keys in the chain. The linear relation represents an acceptable level of computation demands for constraint devices.

2) MATHEMATICAL ANALYSIS
We initially considered the original TESLA protocol and discussed earlier that one keychain must be generated for each connection between the sender and the receiver. Therefore, the Big O notation O(n) describes the original TESLA protocol. According to the enhanced Inf-TESLA protocol, two keychains must be present per connection. These two keychains operate in parallel; therefore, the mathematical VOLUME 10, 2022 representation of each keychain generation is as follows: where n is the number of keys in the chain. In the time complexity analysis, the constants are neglected; hence, the final Big O notation is represented as O(n). The representation is also applicable to the Inf-TESLA protocol, as we did not change the number of keychains required in the authentication process.

B. COMPUTATIONAL OVERHEAD ANALYSIS
We compared the computational overhead of the enhanced Inf-TESLA algorithms with that of the original TESLA from the sender and receiver perspectives. We studied the time complexity at the sender side by varying the keychain length. We also checked the effect of changing the authentication key size on the generation time of the keychain on the sender side.
The key length was varied between 80 and 200 bits, and the simulation data resulted from an average of 50 iterations. The result of the comparison is presented Fig.7. According to the results, we observed that the generation time of the keychain in the enhanced Inf-TESLA protocol was higher than that of the original TESLA protocol. This result was expected because the enhanced Inf-TESLA protocol requires two keychains to be generated, whereas the original TESLA protocol requires only one keychain for the authentication process to occur. We also observed that as the key length size increased, the enhanced Inf-TESLA generation time of the keychain approached the original TESLA generation time until they became equal at a key length size of 200. This observation significantly helps in choosing a sufficiently large key length size to help increase the immunity against brute-force attacks and in reducing the probability of the keychain being broken by attackers, without increasing the computational overhead of the system [22]. The next analysis monitors the computational overhead at the receiver side, where two critical parameters are computed: the generation time of the MAC value and the authentication time of the message. Fig.8 illustrates a comparison between the original and enhanced Inf-TESLA protocols in terms of the generation time of the MAC value. The results revealed that the generation time of the MAC value for the enhanced Inf-TESLA is lower than that of the original TESLA, which proves that the proposed Inf-TESLA reduces the computation complexity of the authentication process [9]. We further observed that the overall increase in the generation time of the MAC values for both protocols was within a small range (∼10 ms), which indicates a systematic behavior among the protocols. Another important observation is that the generation time of the MAC values in the enhanced Inf-TESLA protocol stabilizes as the key length size increases, which is another supporting evidence of the applicability of increasing the key length size for better immunity against brute-force attacks without increasing the computational overhead on the network. The last analysis is related to the authentication time of the packets at the receiver side and compares the performance of the original and enhanced Inf-TESLA protocols. Fig.9 shows the simulation results related to the change in the authentication time of the packets with respect to the change in the key length size. The first observation is that the authentication time behavior in the enhanced Inf-TESLA protocol is similar to that in the original TESLA protocol, which is another indication for the systematic behaviour between the protocols. Furthermore, the authentication time in the enhanced Inf-TESLA protocol is lower than that in the original TESLA by 0.5 ms. Moreover, as the key length increases, the authentication time of the packets increases until it reaches a turning point (around 150 bits key size), after which the authentication time decreases until it reaches its lowest value of approximately 1.6 ms. These results ensure that by using a relatively large key size, the authentication time of the packets would be low enough for a better lifetime of the receivers.

C. CYBERSECURITY ANALYSIS
Our final analysis considered cybersecurity attacks and studied the resistance of the protocol and its ability to mitigate authentication risks. We also performed a theoretical comparative analysis between our enhanced Inf-TESLA and the previous variant TESLA protocols in Table 1 discussing their advantages and disadvantages to IoT constrained devices.
The most common attacks include the man-in-the-middle and masquerading attacks, where an attacker listens to the broadcasted packets and tries to forge its key while pretending to be a legitimate user to have complete control of the keychain. To overcome these issues, two keychains are used with their keys alternating during the broadcast of the packets in Inf-TESLA and the enhanced Inf-TESLA protocols. Hence, the probability of an attacker breaking two keychains in a short time is extremely low.
An alternative way to forge an attack is for the attacker to listen to the packets sent at the end of the keychain, where it is possible to substitute the message and MACs in the packets, causing a modification attack. However, any attempt to forge a key by an attacker during the disclosure delay time will be a violation of the protocol because the protocol does not allow any alternation between keychains during the disclosure delay time [9]. This is because the receiver checks the forged key against the commitment keys related to the new keychains secretly sent in the enhanced Inf-TESLA. If the forged key is not authenticated by any of the commitment keys, the packets are dropped. Another attempt is to flood the receiver using replay packets. Such an attack is solved by including a time stamp for each packet; once the disclosed key of a packet is authenticated, any replays of the same packet containing the same key will be rejected to avoid replay attacks.

VII. CONCLUSION
In this study, we developed a continuous and low-overhead broadcast authentication protocol, named the enhanced Inf-TESLA protocol, to provide continuous authentication between the sender and the receiver while regenerating the necessary offset keychains without re-establishing a new synchronization process that drains the energy and buffer size of the receiver. Symmetric encryption and a hashing function are the only additional processes required to ensure the continuous generation of keychains in the enhanced Inf-TESLA protocol. They have relatively low computational demands, compared to the generation of the synchronization packet. Therefore, the enhanced Inf-TESLA protocol overcomes the discontinuity issue and enhances the lifetime of the network by avoiding unnecessary computations and synchronizations. We also revealed an unaddressed issue in authenticating the last d packets in the previously existing TESLA protocols and proposed a considerable solution by adding d extra packets that send only the required authentication keys, which does not increase the computational demand on the protocol.
The simulation analysis performed using JAVA ensured that the enhanced Inf-TESLA protocol can authenticate packets continuously for the entire lifetime of the receiver, in contrast to the Inf-TESLA protocol. Furthermore, we demonstrated a comparative analysis between the enhanced Inf-TESLA and the original TESLA protocols in terms of the time complexity and critical authentication processes at the sender and receiver sides. The results revealed that both the original TESLA and enhanced Inf-TESLA protocols follow the linear time complexity behavior of O(n), which represents an acceptable level of computational demands to constrained devices. We also showed that the generation time of the MAC values and the authentication time of the packets at the receiver side are lower in the enhanced Inf-TESLA protocol compared with that in the original TESLA protocol.
Finally, we studied the resistance of the enhanced Inf-TESLA protocol against cybersecurity attacks including masquerading, man-in-the-middle attacks, modifications, and replay attacks, which proves the superiority of the enhanced Inf-TESLA in improving the lifetime and performance of the constrained devices. Our future plan is to perform packet loss analysis on the original TESLA, Inf-TESLA, and enhanced Inf-TESLA protocols to study the superiority of the proposed protocol over the existing protocols. He has published more than 140 journal articles and conference papers, nine book chapters, and ten international patent applications. He also works on the editorial board of multiple international journals and on the steering committee of international conferences.
ERNESTO DAMIANI (Senior Member, IEEE) is currently a Full Professor with the Università degli Studi di Milano, Italy, the Senior Director of the Robotics and Intelligent Systems Institute, and the Director of the Center for Cyber Physical Systems (C2PS), Khalifa University, United Arab Emirates. He is also the Leader of the Big Data Area, Etisalat British Telecom Innovation Center (EBTIC) and the President of the Consortium of Italian Computer Science Universities (CINI). He is also part of the ENISA Ad-Hoc Working Group on Artificial Intelligence Cybersecurity. He has pioneered model-driven data analytics. He has authored more than 650 Scopus-indexed publications and several patents. His research interests include cyber-physical systems, big data analytics, edge/cloud security and performance, artificial intelligence, and machine learning. He was a recipient of the Research and Innovation Award from the IEEE Technical Committee on Homeland Security, the Stephen Yau Award from the Service Society, the Outstanding Contributions Award from IFIP TC2, the Chester-Sall Award from IEEE IES, the IEEE TCHS Research and Innovation Award, and a Doctorate Honoris Causa from INSA-Lyon, France, for his contribution to big data teaching and research.
VICTOR MATEU received the Ph.D. degree in computer science from the University of Lleida, Spain. He is currently working as a Principal Cryptography Researcher at the Technology Innovation Institute (TII). His research interests include post-quantum cryptography looking for new standards resistant to quantum computers and cryptographic protocols both from the design and implementation side.
YOUSOF AL-HAMMADI received the bachelor's degree in computer engineering from the Khalifa University of Science and Technology (previously known as the Etisalat College of Engineering), Abu Dhabi, United Arab Emirates, in 2000, the M.Sc. degree in telecommunications engineering from The University of Melbourne, Australia, in 2003, and the Ph.D. degree in computer science and information technology from the University of Nottingham, U.K., in 2009. He is currently the Acting Dean of graduate studies and an Associate Professor with the Electrical and Computer Engineering Department, Khalifa University of Science and Technology. His main research interests include the area of information security which include intrusion detection, botnet/bots detection, viruses/worms detection, machine learning and artificial intelligence, RFID security, and mobile security. VOLUME 10, 2022