Empirical Studies of TESLA Protocol: Properties, Implementations, and Replacement of Public Cryptography Using Biometric Authentication

This study discusses the general overview of Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol, including its properties, key setups, and improvement protocols. The discussion includes a new proposed two-level infinite <inline-formula> <tex-math notation="LaTeX">$\mu $ </tex-math></inline-formula>TESLA (TLI <inline-formula> <tex-math notation="LaTeX">$\mu $ </tex-math></inline-formula>TESLA) protocol that solves the authentication delay and synchronization issues. We theoretically compared TLI <inline-formula> <tex-math notation="LaTeX">$\mu $ </tex-math></inline-formula>TESLA with the previously proposed protocols in terms of security services and showed that the new protocol prevents excessive use of the buffer in the sensor node and reduces the DoS attacks on the network. In addition, it accelerates the authentication process of the broadcasted message with less delay and assures continuous receipt of packets compared to previous TESLA Protocols. We also addressed the challenges faced during the implementation of TESLA protocol and presented the recent solutions and parameter choices for improving the efficiency of the TESLA protocol. Moreover, we focused on utilizing biometric authentication as a promising approach to replace public cryptography in the authentication process.

communication bandwidth to avoid a high communication and computation overhead [4].
Therefore, the maintenance of all the security services is becoming a challenge to researchers in the design of cryptographic protocols, and the services are required to be prioritized by focusing on the confidentiality and authentication of users along with providing multiple layers of authorization [5]. However, the integrity of the message, especially for constrained devices, is still a weak property that needs to be maintained during the implementation of simple lightweight cryptographic schemes, where users should be allowed to verify whether the received data is transmitted from a legitimate claimed source and is not being manipulated during the transmission process [5]. All the previous challenges have motivated us to focus on developing a lightweight cryptographic protocol feasible for constrained devices, aiming to achieve user/device authentication and integrity properties, while considering their limited power resources, limited memory space and limited computational capabilities.
In this study, we focused our analysis on the Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol, which is a lightweight cryptography capable of providing the existing security services with low cost [6]. Additionally, the protocol has the following specific requirements: 1-Simple functions that are understandable and adaptable to several types of IoT devices are implemented to enable appropriate cryptographic properties. 2-The power of the constrained IoT devices is not expensed. 3-A smaller RAM size is occupied during its implementation in IoT devices.
Although the TESLA protocol provides important functionalities, it relies heavily on public key infrastructure (PKI) for initiating the authentication channel between the network members, which increases its vulnerability toward quantum attacks [7]. Our contribution toward the enhancement of the TESLA protocol initiated with the design of a new hybrid TESLA protocol called two-level infinite µTESLA (TLI µTESLA), where we theoretically established its ability to provide security services within the acceptable levels of computation and communication demands as compared to previous TESLA protocols [8]. This study aims to further improve and provide simulation analysis to the proposed TLI µTESLA, considering the suitable implementation environments for TESLA protocol, selecting parameters that provide optimum performance, and introducing an alternative to PKI using biometric authentication methods to establish the first line of authentication among the IoT members. We therefore listed our contribution as follows: 1. Establishing security analysis of TLI µTESLA protocol and time complexity comparison with variant TESLA protocols.
2. Performing theoretical analysis on the selection of parameters that help in achieving best performance for TLI µTESLA protocol. 3. Introducing an alternative to PKI for Initiating the authentication channel between the network members using biometric authentication for generating the Initial authentication parameters in TLI µTESLA µTESLA protocol. The remainder of this paper is organized as follows. The fundamental properties of the TESLA protocol along with its general functionality are presented in Section II. In addition, the list of updates of TESLA protocol is introduced in Section III, wherein the compatibility aspects of the previously proposed hybrid TESLA protocols are discussed in terms of the scalability of IoT. In Section IV, the TESLA protocols are compared in terms of the security services they provide, and the possible implementations of TESLA protocol in IoT systems are summarized. Moreover, the recent challenges faced during the implementation of TESLA protocol along with the proposed solutions and selection of parameters are discussed in Section V. Subsequently, the importance of establishing Root of Trust among IoT members to implement authentication protocols is highlighted in Section VI. Thereafter, in Section VII, the biometric authentication is introduced as a replacement to the public cryptography used for sharing the commitment key and initial security parameters among the IoT members. Finally, a conceptual summary of the proposed methods to secure the biometric data during the authentication process is provided in Section VIII, and the overall discussion along with the conclusions of the current research are presented in Section IX.

II. TESLA PROTOCOL: GENERAL OVERVIEW AND IMPORTANT PROPERTIES
TESLA is a broadcast authentication protocol used in wireless sensor networks (WSNs)/IoT with a single source of trust. In addition, it uses lightweight primitives to realize important properties for implementing the constrained IoT devices [6]. First, it relies on symmetric cryptography with a symmetric key shared between two parties (e.g., sender and receiver). It relies on the message authentication control (MAC) function, which is a pseudorandom function that uses the symmetric key with the original message as an input to generate a MAC value as an output to be used with the original message for transmission to the receiver. Subsequently, the receiver side uses the symmetric key with the original message received as input to calculate its own MAC value from the MAC function that has already been established between the sender and receiver. Therefore, the receiver can review if the calculated number corresponds to the received number for authenticating the sender and the message.
The second vital property of the TESLA protocol is the presence of a delay interval to disclose the symmetric key between the sender and receiver. Thus, the symmetric key will not be disclosed during the transmission period, but a certain delay is present during which the receiver is required to wait until the sender reveals the key to authenticate the previous message [6]. The delay aids in providing data authentication and integrity review as the attacker will be unable to accurately predict the period until the key is revealed, and consequently, the receiver side would be secured by the time the key is disclosed. This process reduces the probability of the attacker sniffing the key to manipulate and force malicious messages.
The third essential property of the TESLA protocol is the loose synchronization established between the sender and receiver to reduce the computational demands and the energy drain of the constrained devices. The synchronization between the sender and receiver is established to initiate a communication channel, as presented in Fig.1. Generally, the synchronization and sharing of important security properties rely on asymmetric cryptography [9]. The receiver initiates a request message, including the receiver time t R , and generates a nonce-a number used only once to avoid replay back attacks. Thereafter, the sender receives the message at time t S and replays back with t S , and the received nonce is encrypted with the sender private key. At the receiver side, the receiver will authenticate the message by decrypting it using the sender's public key and inspect the nonce in the message. Upon authenticating the message, the receiver records t S , t R , and the current time t to calculate the upper bound time expressed as t − t R + t S . This represents the maximum synchronization error for the receiver to wait until the message is received by the sender and respond back [10].
The security of TESLA protocol relies on a one-way hash chain, which is a chain containing a sequence of keys generated using a one-way hash function [6]. Upon deciding the channel between the sender and receiver, the sender will divide it into sub-time intervals of the same duration. The time-window duration is agreed between the sender and receiver. Each time interval will be protected by a symmetric key from the corresponding key chain. The sender will randomly select a value representing the last key element in the chain and apply it to the one-way hash function for generating the previous key element in the chain. This process continues until the first key element is generated in the chain, which is called the commitment key, K 0 This keychain exhibits important properties: first, the commitment key can generate and verify any key element in the chain; second, we can verify and generate key K j from the chain using another key K i from the chain for any i th value less than the j th value. This is because the lower key elements can be used to generate and verify higher key elements in case one of the keys is lost. During the authentication between the sender and receiver, the disclosure of the keys will be in reverse order-initiating by disclosing the first key element, and thereafter, the second key element, and so on, as presented in Fig.2.

III. UPDATED TESLA PROTOCOLS
Although the TESLA protocol exhibits symmetric properties, it does not support the scalability of new IoT devices joining a system or the loss of the predefined keychain packets owing to weak communication [11]. Therefore, improvements and updates are proposed to the original TESLA protocol to achieve more security services and scalability.
A. TESLA ++ TESLA ++ was developed to simplify the messages transmitting between the sender and receiver to reduce the computation overhead and the loss of packets [12]. In the original TESLA, the calculated MAC value and the original message are sent to the receiver, and after a certain delay, the key is disclosed to be used by the receiver to generate its own MAC value and verify the sender's message. However, once the sender calculates the MAC value in TESLA ++, it will be transmitted only with the index of the time interval that the sender is talking to the receiver, and after a certain delay, the key and original message will be disclosed to the receiver for generating the MAC value and verifying the message. The advantage of this protocol is that if the packet containing the key and message is lost, the attacker will not have prior knowledge of the message before disclosing the key, and therefore, the message cannot be manipulated. Moreover, this reduces the buffering size of the messages waiting until key disclosure.

B. STAGGERED TESLA
Staggered TESLA is proposed to reduce the time required to filter the packets being received by the receiver side and reduce the probability of buffering overflow while waiting for key disclosure [13]. This protocol aims to include several MAC values within the transmitted packet, and these MAC values are related to the time intervals corresponding to the VOLUME 10, 2022 undisclosed keys to ensure that an attacker cannot manipulate the packet. The number of MAC values included in the message depends on the type of application and the level of security it can manage. This protocol is advantageous because the inclusion of the MAC values in the message can partially authenticate the packet before disclosing the key. For instance, once the receiver can detect a pattern from the MAC values being received from prior authenticated packets, the receiver can authenticate the packet arriving from a legitimate source. In case unusual MAC numbers are received, the receiver will immediately drop the packet without buffering it until key disclosure, which reduces the buffer overflow in the system. C. µTESLA PROTOCOL µTESLA protocol aims to simplify the functionality of the TESLA protocol from a broadcast authentication into a unicast authentication, where the sender (base station) authenticates the receivers individually [1], [11], [14]. The protocol relies on the condition that the receiver should review a value related to the time interval of the transmitting base station, to ensure that the key is not disclosed yet. Otherwise, an outside attacker can manipulate the message. This process reduces the computational power and communication bandwidth usage of the receiver receiving unnecessary authentication packets that do not belong to the receiver and can aid in limiting the authenticated users.

D. UPDATED µTESLA PROTOCOLS
To overcome the scalability issue in the µTESLA protocol, researchers improved the scheme through the inclusion of a third trusted party between the base station and receiver [15]. Instead of a single party (base station) sending the message and symmetric key to the receiver, a third trusted party called the key server, responsible for sending the symmetric key, is included, whereas the base station is only required to send the authentication message. This protocol is advantageous in that it includes two parties transmitting key information that cannot be easily forged by the attacker.
An additional advantage of this protocol is considered through the following example: an attacker succeeds in forging its key to the receiver, and any message or key sent for authentication suffers from that single point of failure. In the protocol, the receiver will initiate a threshold value for the maximum error failures of authentication messages arriving from the base station. Moreover, on every instance of an authentication failure, an encounter will start adding these failures until the threshold value is reached. Upon reaching the threshold value, the receiver will initiate a request to the key server to update the key. Thereafter, the key server will review the time interval at which the base station is communicating to that receiver and will transmit the key corresponding to that interval. Subsequently, the receiver will use the received key to authenticate the message transmitted from the base station. In such cases, the successful authentication of the message indicates that the already saved key is malicious, and the protocol will replace it with a new key.
An important stage is securing the communication link between the receiver and key server. As the receiver initiates a request to the key server, the latter will notify the base station regarding the request for updating the key. Thereafter, the base station will broadcast a message containing a new symmetric key used to communicate the key server with the receiver, but this message will be encrypted with a symmetric key that will be disclosed by the key server at a later stage. After a certain delay, the key server will reveal the key to allow the receiver to authenticate both parties and extract the new key for communicating the receiver with the key server.
Furthermore, an additional improvement to the µTESLA protocol is called multilevel µTESLA that provides the advantages of authenticating the base station and reducing the authentication delay between the sender and receiver to reduce the probability of DoS attack [16]. This protocol introduces two keychain levels: a high-level keychain directly connected to the base station, and a low-level keychain responsible for authenticating the messages transferred between the sender and receiver. In particular, the high-level keychain exhibits a long-time interval to cover the entire lifetime of the receiver without requiring an additional establishment of a new keychain, which reduces the computational complexity and demands of the process. Moreover, each time interval in the high-level key chain will be further divided into short time intervals corresponding to the low-level key chain. The use of short time intervals reduces the time required to receive the message from the receiver and to authenticate the message, so that the delay can be within tolerable range to diminish the probability of a DoS attack.
A vital property of this protocol is that the high-level keychain is connected to the low-level keychain such that the low-level keys can be generated from the high-level keys using the one-way hash function in case several low-level packets are lost. The authentication message transmitted from the base station to the receiver is called the commitment distribution message (CDM), which contains the time interval of communication between the receiver and base station, the commitment key of the low-level keychain, the MAC value for the receiver for verification, and the high-level key for authenticating the previous message from the prior time interval. In addition, the CDM packet is periodically transmitted by the base station to reduce the probability of loss, as high-level key packets require a long time to re-establish synchronization between the sender and receiver. Contrarily, this causes buffer overflow on the receiver, including communication and computational overhead.
Owing to the problems discussed for multilevel µTESLA, an improvement protocol called efficient fault-tolerant multilevel µTESLA protocol contributes toward shortening the recovery period of lost high-level packets by acting on a single high-level time interval, which reduces the buffering time and the risk of experiencing memory-based DoS attacks [17]. In context, another improvement to the multilevel µTESLA is called enhanced DoS-resistant protocol that contributes to tolerating packet loss by reducing the authentication time of CDM packets through adding an image value to these packets and maintaining continuity in occurrence of a packet loss [17]. For instance, if the receiver is receiving the CDM i at i th time interval, it will contain an image value of the CDM i+1 packet. Upon receiving the second packet, the image value will be calculated and compared with the value transmitted in the previous packet for authentication. In case the CDM i+1 packet is lost, the receiver will wait for CDM i+2 and use the high-level key of the CDM i packet to verify the key in the CDM i+2 packet, as the lower keys from the keychain can verify the higher keys in the chain. In case the verification is achieved, the receiver can utilize the image of the lost CDM i+1 packet that is available in the CDM i packet to provide continuous authentication of the packets.

E. INF-TESLA PROTOCOL
An additional improvement to TESLA Protocol is called the infinite-TESLA, which considers providing continuous resynchronization between the sender and receiver in case the keychain level is terminated [11]. In the original TESLA protocol, when the key level attains the last key element, the system needs to re-establish a new synchronization between the same sender and receiver, such as they are new to the connection. Those unnecessary establishments increase the computational demands and energy wastage. Thus, the Infinite-TESLA introduced two key chains in offset alignment between each other, which maintains the functioning of a chain and the synchronization between the sender and receiver in case a key chain has been terminated. The way these two keys are included in the CDM packet can follow either the two-key mode, where both keys are transmitted in the CDM packet, or they can follow an alternating mode, where a key from either of the chains is presented alternatingly as if one key chain is corresponding to the odd intervals and the other chain is corresponding to the even intervals.
We proposed a hybrid TESLA protocol called two-level infinite µTESLA (TLI µTESLA), which combines both the multilevel µTesla and the infinite-Tesla to combine the benefits of reducing the authentication delay as well as providing continuous synchronization between the sender and receiver [8]. The theoretical process of this protocol relies on the hash function and the establishment of loose synchronization between the sender and receiver. Similar to the multilevel-µTESLA, two keychain levels are introduced, where the high-level keychain has a long-time interval to cover the lifetime of the receiver. This keychain will be further divided into sub-intervals to represent the low-level keychain, where the infinite-TESLA protocol is implemented. Additionally, the low-level keychain will contain two keychains in offset alignment to each other; the CDM packet will contain two commitment keys for the low-level keychain with their MAC numbers for verification, including the high-level key related to the previous CDM packet. Similar to the multilevel-µTESLA, the low-level commitment keys in TLI-µTESLA can be derived from the high-level commitment key through a special one-way hash function F 01 .

IV. SECURITY ANALYSIS AND SERVICES DISCUSSION
Evaluating the computational security of TESLA Protocols relies on the security capability of their respected hash functions: one-way hash function used to generate the keys in the keychain and MAC function used to encrypt the message with Its corresponding key. The design goals of one-way hash function Is to possess preimage resistance (Inability to reverse the output to extract the Input) and collision resistance (considering a low probability of generating the same output from two different Inputs).
Therefore, the best guidance toward ensuring the security of hash function is analyzing the complexity of attacking the previous goals. For an n-bit hash function, an adversary would require 2 n number of operations to produce preimage and 2 n/2 number of operations to produce a collision [18]. By the time the adversary breaks the hash function, the key would be authenticated at the receiver side and the message is received successfully. Regarding MAC function, two Important security properties need to be obtained: key non-recovery and computation resistance of the MAC value. For an adversary to determine the MAC key, exhaustive research is required by checking all possible t number of keys to find a value that agrees with the sent one, which requires a 2 t number of operations. As for guessing the MAC value of a preimage of a given MAC value requires about 2 −n number of operations for n-bit MAC algorithm [18]. however, this guessed value cannot be verified without a prior knowledge of either the text message or the key, which makes the probability of forging a malicious MAC value nearly Impossible within the given short authentication time in variant TESLA protocols.
Let us now consider proving the position and integrity properties of the packets delivered by the TESLA protocol. Such discussion applies to all versions of the TESLA protocol, including the one put forward in this paper (TLI-µTESLA protocol discussed in [8] and In section III-F) as they all share the same key-checking provisions. In principle, the properties can be proven by following the hash-chain to verify the relation between the disclosed key and the commitment key. If the relation holds, the received packet occupies in the receiving order the same position it had in the sending order. Also, the disclosed key is the one originally used to encrypt the packet; as a consequence, the packet delivered was not modified after its encryption, and integrity is proven. 1 This proof can be formalized by modeling the TESLA protocol as a finite state automaton where each step along the hash chain corresponds to a transition. The properties can thus be proven for any fixed hash-chain, i.e., for any fixed distance between the delivered packet and the initial one. In the general case, however, an infinite state system would be needed to represent the inductive relationship between an arbitrary i-th packet and the initial packet. In timed automata, transitions may be put local timing constraints called invariants. An automaton can pass through an invariant transition an arbitrary number of times. For such reasons, TAME, a proof engine for timed finite state models, was used in [19] to model TESLA protocol as timed automaton with an invariant, the transition modeling a step along the hash-chain. TAME invariant analysis proves that the TESLA protocol can guarantee the order and data integrity of packets coming at an arbitrary distance from the initial one. The above-mentioned proofs of correctness apply also to our TLI-µTESLA since the core of the authentication process the same and our modifications to the mechanisms did not affect the correctness of the protocol.
Regarding the security of the disclosed key, guessing attacks are not feasible [19], [20] as there is no a strategy that an attacker can use to guess the disclosed key that is better than random guessing. Moreover, the generation of the keys is done using one-way hash function, which is impossible to be inverted, likewise the MAC function, which is designed to be non-invertible. Therefore, choosing a relatively large key size, will decrease the probability of brute force attack to disclose the key and break the keychain to a significate low value [21]. So, by expanding the key space, the protocol can achieve a low-key guessing probability. This proof is also applicable to our TLI-µTESLA which has the same keychecking provisions as the original TESLA protocol proven In [19].
The services properties of the proposed scheme were analyzed by discussing the essential security services and comparing them with the limitations of the previous TESLA protocols. The limitations of TESLA protocol include its inability to support the scalability of IoT devices, as the oneway key chain should be predefined. However, this poses communication and computational demands and can cause loss of packets. Upon the termination of the key chain, a new synchronization process is required to be established between the sender and receiver, which does not support immediate and continuous authentication, and thus, results in vulnerability toward DoS attacks.
The improvement of TESLA++ over TESLA is in terms of buffering of MAC and its index to occupy less memory as compared to the buffering of MAC and message in the TESLA protocol, which aims to reduce the DoS attacks. However, the protocol does not support the scalability of IoT network and follows the synchronization establishment between the network members upon the termination of the key chain, which lacks immediate and continuous authentication.
Although the staggered TESLA improves the authentication process by including the MAC numbers and enhances the scalability of the IoT network, it augments the buffering issues and packet loss if an attacker floods the buffer with replicas of MAC numbers. In addition, it does not support continuous authentication between the network members as the key chain terminates.
The properties of µTESLA are beneficial in saving computation power, communication bandwidth, and memory requirements by reducing the size of the transmitted packets. However, unicasting the initial key and security parameters will delay the joining of new members to the network, which does not support scalability. Moreover, it does not resolve the problems of the original TESLA protocol, such as the lack of immediate and continuous authentication and the vulnerability toward DoS attacks.
The improved µTESLA protocol improves the resistance against DoS attacks but increases the communication overhead by requiring several exchanges of messages between the key server and base station. Moreover, it does not support immediate and continuous authentication as it requires resynchronization after the termination of the key chain.
Relatively, multilevel µTESLA introduces several improvements including supporting scalability of IoT devices and fault-tolerance toward the loss of packets, as the low-level key chains can be derived from the high-level key chains. Additionally, multilevel µTESLA provides immediate authentication to the CDM message, as several copies of CDM packets are frequently transmitted to reduce the risk of losing high-level packets. However, the copy of the subsequent CDM included in the current CDM increases the size of the CDM as well as the buffering on the sensor nodes, because the copy of the subsequent CDM might be of similar length to the current CDM, which is buffer consuming. Moreover, the inclusion of two-level key chains increases the computation overhead in comparison to the original µTESLA. In addition, multilevel µTESLA does not support continuous authentication between the network members.
In context, enhanced multilevel µTESLA aims to reduce the computation overhead of the multilevel µTESLA by shortening the recovery period of lost high-level packets using a single high-level time interval. Additionally, it tolerates packet loss by reducing the authentication period of CDM packets via adding an image value to these packets and maintaining continuity in the occurrence of packet loss. However, this continuity assumption was not evaluated and analyzed to avoid any high demand of memory resource for the long key chains.
Inf-TESLA provides continuous authentication between the network members, as it reduces the resynchronization process by including dual offset keychains. This reduces the risks of man-in-the-middle attacks in case an attacker attempts to inject the attacker key over the network key chain, wherein the algorithm will notify the receiver regarding the violation of the key-chain exchange procedure. However, Inf-TESLA does not support the scalability of the network members owing to the number of keychains required to be specified prior to the synchronization packets.
In comparison, the proposed TLI-µTESLA protocol enhances the original TESLA with two commitment keys in the CDM message and two low-level key chains and using image value of upcoming CDM instead of using the copy of the subsequent CDM in the current CDM. This allows the protocol to avoid increasing the size of the buffer in the sensor node and reduce the DoS attacks on the network. The lowlevel key chain exhibits short time intervals to accelerate the authentication process of the broadcasted message with less delay. Additionally, the dual-offset key-chain mechanism is used in the low-level key chains to assure continuous receipt of packets from the high-level key chain. All the services are discussed in detail as follows: Immediate Authentication: In addition to the symmetric property in TESLA protocol, the proposed protocol relies on the two commitment keys in the low-level keychain for authentication instead of sending a copy of the CDM packet on every instance of transmission between the sender and receiver, which reduces the authentication delay to a tolerable value.
Data Integrity: The originality of the message is maintained by ensuring that it is not altered during transmission, and a higher security level is achieved with the implementation of two keychain layers and offset alignment keychains as compared to alternative TESLA protocols.
Communication and computation overhead: The implementation of two offset alignment keychains realizes the continuous authentication instead of sending copies of CDM packets during transmission, which considerably reduces the communication overhead and computation complexity in comparison to previous TESLA protocols.
Scalability: The successful application of IoT technology to daily-life scenarios involves security schemes that are required to display their ability for adapting to the variations in the environment and the inevitable growth in the amount of work and the number of network members [22]. The implementation of two-level keychains in TLI-µTESLA enhances the broadcasting of the messages to a scalable number of devices and increases the number of messages broadcasted between the members.
Resistance to DoS attacks: The authentication protocols implemented on constrained devices are highly targeted at increasing their immunity against various forms of DoS attacks, including buffer overflow attacks and lack of continuity in the authentication process [23]. In TESLA protocols, a buffering process occurs in the CDM packets until the subsequent packet is received to authenticate the previous message. In particular, the authentication will not occur if the receiver does not have adequate buffer space to wait until key disclosure. This can create network traffic that forces the receiver to drop the packets, thereby increasing the vulnerability of the receiver to DoS attacks. Moreover, a high probability of experiencing communication overhead exists in a constrained network that can result in lost keys and lack of continuity in the authentication process. In the proposed TLI µTESLA protocol, two commitment keys in the low-level keychain are presented to authenticate the message after the disclosure of the high-level key instead of sending a copy of the CDM packet, which reduces the excessive usage of the buffer, and consequently, reduces the vulnerability toward DoS attacks. The short interval in the low-level keychains allows the key to be authenticated immediately without buffering. In addition, the offset alignment of the commitment keys in the low-level keychain allows continuous authentication of the packets received from the high-level keychain, as the low-level keys are used in an alternate manner. The first keychain index covers the period of the high-level interval, while the second keychain index covers half between the first high-level interval and the next high-level interval, where both commitment keys of the low-level keychains can be derived from the high-level commitment key.
Let us consider an example where both the authentication delay and continuous authentication are solved in TLI µTESLA protocol. At i th time interval, the receiver receives CDM i packet containing the high-level key K i−1 . To authenticate the CDM i packet, the receiver needs to buffer it until receiving the CDM i+1 to use the key K i disclosed in it. The receiver needs to authenticate K i by applying the one-way hash function K i−1 = F 0 (K i ). if the first condition is satisfied, the receiver needs to authenticate the MAC number of the CDM i packet to authenticate the commitment keys of the low-level keychain. If the first condition is not met, the receiver will drop the packet. On the other side, if the CDM i+1 packet is lost, the receiver will wait until CDM i+2 is received to use the one-way hash function F 0 to authenticate the high-level key. Consequently, the low-level keychains will be derived from the authenticated high-level key using the oneway function F 01 . Using the short time intervals in the lowlevel keychains, the authentication process can be accelerated with less delay, allowing the packets and their keys to be immediately authenticated without oversizing the buffering. Moreover, the presence of the two offset low-level keychains instead of one keychain allow a continuous initialization and authentication of the sensor nodes. Once the first low-level index chain Is expired, the second low-level index chain will continue covering half of the next high-level index chain.
The security services offered by the proposed protocol and the previous improvements to TESLA Protocol in addition to the time complexity of each protocol are comparatively presented in Table 1. Based on a theoretical perspective, we can observe that the core of the TLI-µTESLA protocol is not changed compared to the original TESLA protocol, considering the exchange of the commitment key and other essential security parameters between the server and its clients, to the usage of the one-way hash function and the MAC function to process the security computations during the authentication process. Furthermore, the authenticity of the coming packets in TESLA protocols depend on the previous packets being legitimate as discussed in [19], [21] which indicates a recursive authentication. Therefore, the whole authentication scheme in TESLA must be bootstrapped by guaranteeing that the initial packet is authentic. This is assumed to be done by the sender using the more expensive method of digitally signing the first packet [6].
the additional Improvements proposed In TLI µTESLA protocol can achieve the required services within acceptable computation and communication overhead and with similar time complexity as compared to the existing protocols. Thus, our future step is to verify and prove that the proposed protocol can achieve the security services by performing simulation and numerical analysis. Our first step in this paper is investigating the most suitable environments for implementing the proposed TESLA protocol.

V. CHALLENGES IN THE TESLA PROTOCOL AND PROPOSED SOLUTIONS
Throughout the implementation of TESLA protocol in GPS navigation messages and VANET networks, researchers were concerned about two critical weaknesses: the disclosure delay of the key and the loose time synchronization between the sender and receiver. As discussed in Section II, the disclosure delay is used to introduce the asymmetric property in TESLA Protocol to protect the keys used in authenticating the communication between the network members, whereas the loose synchronization provides simplicity and light-weighted functionality to the protocol. Nevertheless, a long disclosure delay and loose synchronization time error can introduce vulnerability to the protocol by allowing attackers to use the time gap for spoofing the messages with the previously disclosed keys [21]- [25].
The issue of loose synchronization is a critical weakness of the VANET network in implementing the TESLA protocol. Therefore, researchers suggested increasing the awareness of the loose synchronization delay at the sender side to limit the option of sending messages to necessary neighboring vehicles as well as prevent a probable attack [25]. Moreover, the risks of the previous challenges can be reduced and the most suitable performance can be achieved from the TESLA protocol by analyzing the decisions based on certain parametric selections [21]. For instance, the suitable hash function (e.g., SHA-256) must be selected to provide preimage resistance for reducing the ability of reversing the output inside the hash function and generating the input. In addition, the hash function should permit collision resistance to reduce the probability of generating the same output from two distinct inputs.
Regarding the selection of the hash function, the bruteforce attack should be identified; this is a scenario where the attackers perform hash-chain computations to break the keychain by matching their key with the latest released key in the chain. A proposed suggestion to avoid this precomputation and breaking of the keychain is to introduce a type of cryptographic randomness called salt, which is added to the key before it is hashed to generate the previous key in the chain [21]. The salt value can be added to the key following two major approaches: using a timestamp of the key release, which requires a time-varying hash function to be used in a deterministic agreement between the network members and adding a fixed random number to the key before being hashed. The addition of the salt value is required to be the same for all the keys belonging to the same keychain but is required to be altered in case the sender and receiver initiate an additional keychain between each other.
Apart from the addition of the salt value, certain parameters can be controlled in TESLA to reduce the brute-force attack and the probability of success in breaking the keychain.
In context, the key length and keychain length are the most important parameters that strongly influence the reduction in the probability of predicting the key in the chain and the probability of calculating the number of hash functions that the attacker needs to perform to break the key chain. Researchers in [21] studied the influence of various key and keychain sizes on the probability of brute-force attack and determined that the linear increase in the key length is exponentially related to the increase in the immunity toward the brute-force attack. Therefore, they deduced that the keychain size does not need to be quite long if the key length is adequately large. In particular, [26] proposed that a minimum of 128 bits is necessary for maintaining a secure chain. Another study in [21] reviewed the variations in the authentication delay and computation speed upon increasing the key size to achieve a certain level of immunity against brute-force attacks. The results revealed that a shorter authentication time delay allows the algorithm to use smaller key lengths and key sizes. However, the large variations in the authentication delay and computation speed resulted in only small variations in the required key lengths, which maintained the security level of the algorithm even with a long authentication delay.
Regarding the key length size, [24] analyzed the computational load required by the user to apply a TESLAbased navigation-message authentication scheme. TESLA protocol was implemented in four mobile devices with varying processing power and capability to study the effect of the processor on the performance of the TESLA protocol and its energy expenditure. The analysis was related to monitoring the time required for verifying the commitment key, the time required to process the MAC number and message, and the time required to authenticate the last key element in the chain using the commitment key by altering the number of subintervals in the communication channel. The results revealed that the time required for verifying the commitment key or the MAC number was not significantly influenced by the devices as compared to that resulting from variations in the keychain length (time distance between a certain key and the commitment key). The processing required for verifying a key using the commitment key increases with the time distance, which further increases the battery drainage in the network. This indicates that there exists a tradeoff between increasing the key length to achieve higher security levels against brute-force attacks and increasing the computation complexity in the network that affects the power consumption and the lifetime. Therefore, a compromise value must be selected for the key length size to balance the security and energy expenditure in the network. The selection of the parameter values that pose the most influence on TESLA protocol and its performance are summarized in Table 2.
Recent implementation of TESLA protocols involved the authentication of GPS navigation messages and event-driven traffic between the VANET network members [25]- [28]. 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 [25], [27]. In addition, the TESLA protocol was considered as a favorable option to authenticate the one-way navigation messages owing to its hybrid properties (symmetric/asymmetric functionalities), reduced authentication message size, and the simplicity of symmetric key transfer [28], [29].
With reference to GPS navigation system, TESLA protocol can also be Implemented In location-based services (LBS) to offer an unconditional privacy to the user's query and protects the services offered by the service provider [30]- [32] without revealing the location of the service provider or the user. LBS can be found In VANET where privacy-preserving mechanisms are essential to avoid having a malicious vehicle among the members causing Intentional accidents [33]. therefore, TESLA protocol allows the vehicle to request for services from the location server without revealing the query content to the location server.
TESLA protocol can also be used in urban aircraft mobility (UAM) systems, which have been developed from unmanned aircraft vehicles and have provided the opportunity of highly automated aircrafts operating and transporting passengers or cargo at lower altitudes within urban and suburban areas [28], [29]. Unlike conventional drones flying over unoccupied areas, UAM members are designed to operate over metropolitan areas with high density of population and property. Consequently, an aircraft failure will certainly result in substantial damage. Moreover, the design of such network architecture, including the sensors and the autopilot systems, are more complicated than that in drones. Thus, the UAMs are more exposed to attacks that can target specific data and affect the integrity and availability of the services [29]. Such security requirements are certainly achieved with the TESLA protocols that assure its lightweight property and flexibility between the network members. The implementation of the TESLA Protocol to secure the authentication of the network members will aid in protecting critical navigation data along with providing command and control components with sensor information.

VI. ROOT OF TRUST
During the discussion of existing TESLA protocols, researchers assumed that the initial security parameters, e.g., the hash function, commitment key, and disclosure delay, were already shared between the two parties. However, to simulate the proposed TESLA protocol, we need to understand the initialization process and transmission of the initial security parameters and the initial symmetric key between the sender and the receiver before establishing the TESLA protocol process. Thus, the concept of the Root of Trust (RoT) is important as it provides the foundational security component of a connected device and is a set of implicitly trusted functions that the remainder of the system or device can use to ensure security [34]- [36]. As IoT is more concerned with wireless sensor network (WSN), we need to understand that WSN is a distributed infrastructure that establishes a trust routine between the members to ensure the security of the communication and integrity of the messages. Typically, RoT exhibits multiple forms depending on the type of the implementation network [35]. For instance, there is a centralized node distributing various hierarchical trust values among the members in the centralized network. Nonetheless, this form can be affected by the central point of failure, e.g., if an attacker manages to attack the central node the entire system will become dysfunctional. An alternative form of trust is in the distributed network, where each node monitors the other nodes in the system and evaluates their trust based on the performance and behavior of the network. However, this addressed value must be frequently updated, which increases the computational demands and depletes the energy of the network.
Another form of trust that seamed feasible to most networks and systems is the certificate-based trust model, wherein a trust party generates the certificates to the users signed by the private key of this trusted party and each node can verify the others' certificates in the system using the public key of the trusted party. This concept forms the basics of PKI that creates the digital certificates to authenticate the members in the network [37]. The types of PKI include the RSA and elliptic curve cryptography, where the latter demonstrated the ability to provide the same security performance but with a shorter key size as compared to the RSA, to enhance its feasibility in application in constrained devices [36].
Although PKIs appear to be highly secured as they rely on three hard mathematical problems (integer factorization problem, discrete logarithm problem, and elliptic-curve discrete logarithm problem), they are vulnerable toward quantum attacks as the evolution of quantum computing improves the processing speed to alleviate the previous problems [37]. Therefore, the primary objective is to replace the PKI that is used for transmitting the initial security parameters and reduce the risk of quantum attacks. For instance, in the implementation of the TESLA protocol on mobile applications, PKI can be replaced by using the SIM platform as the trusted party for transmitting the symmetric key and initial security parameters. However, in sensor devices such as RFID or wireless sensor nodes, we can replace the PKI with biometric tools and biometric authentication schemes that will aid in sending the initial security parameters between the two parties. The following section contains a thorough explanation about biometric authentication and its securing methods that are helpful to generate the root of trust for TLI-µTESLA protocol.

VII. BIOMETRIC AUTHENTICATION
Biometric authentication is rapidly replacing traditional authentication methods and is becoming a part of everyday life, including accessing banking and government services. It has shown significant advantages in the field of security since it is difficult to lose, forget, copy, forge, and break [38]. The main objective behind using biometric authentication is to try to generate the symmetric key between the two parties from biometrics samples or features for a secure message transmission without revealing sensitive information and without using public cryptography. Examples of biometric tools are electro-cardio diagram (ECG), electroencephalogram, fingerprint, face, iris, and voice-based recognition, as shown in Fig.3.
The most popular type used is the ECG, which allows the user to live monitor the body signals during authentication and is used for different purposes such as in hospitals, security checks, and in wearable devices [38]. Hospitals use ECG data to track patients' health history by registering the patients with their identities and the ECG signals, which need to be sufficiently monitored to perform subsequent identifications. Some security checkpoints are now using ECG authentication to increase their security level. Employees usually register their identities using their ECG that must be stabilized for subsequent recognitions within a short period. Wearable devices can continuously authenticate users; however, in this case, the wearable devices must be able to differentiate between different users' modes such as awake, anger, and sleep modes. All these modes have different signals and different energy demands in addition to the noise generated when monitoring the signal; these must be normalized when analyzing each user to help improve the quality of authentication. Biometric authentication has been combined with machine learning techniques to train the models on biometric data, thereby improving the accuracy and efficiency of the authentication process [38]. Machine learning allows systems to perform tasks without being explicitly programmed to do so. Machine learning is therefore being widely used in areas including image processing and biometrics, as it can effectively analyze and interpret large datasets [39]. Machine learning models such as regression models are being used to predict the patterns in the data and generate output based on the identified patterns, or to make decisions using classifiers and pattern recognition models. Fig.4 shows a traditional machine learning process.
Biometric authentication has been discussed in [38], [39] in which ECG data from hospitals and security check points were analyzed for authentication purposes. The first stage involves feature extraction of the ECG signals to identify which case each data sample belongs to. The next stage involves cleaning the data before being imported to the training model, through checking and adjusting the drift between the different data samples, normalizing the different amplitudes of the signal, removing the noise generated during the monitoring process, and correcting flipped signals, if any. The next stage involves dividing the data into subintervals based on the peak-to-peak levels of the ECG signals with a time window determined based on the minimum heartbeat of a certain heart rate to ease the computational process. The following stage involves passing the adjusted data through the training model; in [40], [41], the decision tree was used because of its flexibility in dealing with data of different sizes and frequencies.
Fingerprint biometrics are also very commonly used for authentication and have been discussed in [42] as having two processing phases: user registration phase, which enables the user to use his fingerprint to generate his own private key for later use for authentication; and user authentication phase, which enables authentication between the user and server through the generation of a session key and a message authenticator. A brief explanation of the two phases is provided as follows.

A. USER REGISTRATION
This stage is responsible for registering the user by capturing his fingerprint using feature extraction and selecting minutiae points from the consistent region, which is mostly captured through feature extraction. These points are then applied through convolutional computations to generate the private key.

B. USER AUTHENTICATION
When authentication takes place between the user and server, the fingerprint is first captured and encrypted; it is then sent to the server for verification. The server uses another synthetic fingerprint from its own database to extract the minutiae points, add randomness, and generate security values to create the session key. These values will be sent to the user to generate a similar session from his side. To ensure that both sides generate the same session key, the server generates a certain value ''B,'' encrypts it as ''B''' with the session key and sends both B and B' to the user. The user then receives the values, encrypts B using his generated session key, and compares the result with the received B.' The authentication using fingerprint biometrics has shown an accuracy of approximately 95% [42].
A hybrid multimodal authentication protocol was presented in [43], wherein face recognition, fingerprint, and ECG data were used to authenticate the user and achieve gender reveal features. The proposed model uses feature extraction for each dataset, as each set can have distinctive characteristics and requires its own cleaning procedure. Specifically, a deep learning model was used instead of a machine learning one, to ensure that the analysis and classification processes are robust against the noises generated from the different and large biometric datasets. Since these three features (face recognition, fingerprint, and ECG) can be captured using a single device and can be used simultaneously, the model provides high security and immunity to attacks.
Our previous discussion showed the importance of biometric templates in declaring and authenticating the identity of the user during real-time monitoring process. Therefore, by extracting the minutiae points out of the fingerprints, or by generating the cleaned sampled ECG data, we can use them to represent the identity token of the user. The identity token will then be applied to a cryptographic function (e.g.: oneway hash function) to produce the commitment key, which is the essential parameter used for generating the keychain of TESLA protocol and for authenticating the communication channel between the network members, without relying on PKI to transfer the commitment key. The challenging process is protecting the biometric templates from being exposed and from revealing the identity of the user. We therefore discussed in the below section the proposed techniques used to secure the biometric data during the authentication process.

VIII. SECURING BIOMETRIC DATA DURING AUTHENTICATION
Biometrics authentication is widely used in mobile applications to allow access to several sensitive services including banking and government services; hence, it is important to VOLUME 10, 2022 consider how the biometrical datasets (biometric samples and templates) can be protected from being spoofed by attackers and used to relate them back to the real identity of the user. As such, there were concerns regarding developing protocols to reduce exposing the biometrical identities/samples when performing authentication between the user and server. Among the proposed protocols was the zero-knowledge proof of knowledge protocol, which allows the user, called the ''prover,'' to prove to the other server, called the ''verifier,'' that he knows the value of ''x'' without revealing it but provides proof that he does. The method presented in [44] relies on a trusted party responsible for receiving the biometric identities and protecting them to protect the user identity and its sensitive information from being revealed and sniffed by an attacker during the process. The method consists of two phases to provide secure biometric authentication: Enrolment phase: In this phase, the user receives an identity token from the identity provider (trusted party) containing three secrets related to the user; one secret is derived from his biometric identity, such as miniature points from his fingerprint or from his ECG signal or from face recognition; another secret is derived from the password; and the third secret is derived from the cryptographic salt value or artifact that will be used in case one of the previous secrets are lost. After establishing the identity token, the biometric templates will pass through the training classifier model to generate the classifier parameters that will be later used to authenticate the user with the server.
Authentication phase: During this phase, the server needs to check the originality of the identity token as well as the identity of the user. The identity token is authenticated by checking the signature of the identity provider by decrypting it using the identity provider public key. The server will then challenge the user by sending a challenge value to be used at the user side with its biometric templates extracted from the feature extraction, his password, and the classifier parameters to perform zero knowledge computations and generate proof values. The proof values will be sent to the server to perform another set of zero knowledge computations and generate results that will determine whether the user is legitimate or not. An additional verification step is then added from the server side to establish a session key to perform a handshake with the user to avoid man-in-the-middle attacks. Random numbers are generated from the server side and sent to the user to use them with his own secrets and establish a session key; the server uses the random numbers generated with the user identity token to generate the same session key, and so, they can initiate the handshake. The primary feature of this method is that it avoids saving the user's biometric templates in either the identity provider or the server. Moreover, the identity provider is not involved in the authentication process; this protects the sensitive information of the user. Furthermore, the addition of the handshake helps in reducing the possibility of a man-in-the-middle attack.
Upgrading the authentication process of mobile services is another matter, as several services based on a single authentication process must be accessed. This concept was introduced in [45], where mutual authentication and key agreement were performed using a single sign in to a trusted party called the token service provider. In this method, the user and the service providers are registered to the token provider; the user uses his biometric samples and password to generate zero knowledge proof values, which are then sent to the token provider to register and receive a token. The service providers also send their certificates and proof of identities for registration and to receive the token from the token provider. After establishing the tokens, the user and the service providers can mutually authenticate each other and communicate without performing an authentication process per service. The advantages of this method are as follows: reduction in the computation and communication overhead through the use of a single authentication process by the token provider; use of a centerless authentication process where the token provider is not included during communication with the service providers, thereby ensuring that sensitive information of the users are well protected, and avoiding the center point of failure on the token provider; and provision of a remote biometric-based authentication process between several services simultaneously, thereby increasing the scalability and usability of the system.
Finally, another method for protecting biometric identities and templates was proposed in [46] to provide blind authentication to both the user and the server side. The proposed method aims to protect the users' biometric identities from the servers and protects the servers' classifiers parameters from the users. A trusted party called the enrolment server will be responsible for establishing the blind authentication between the parties. The user will send the biometric templates from his feature extraction to the enrollment server to pass them through the training model to generate the classification parameters, which will then be sent to the server. During authentication between the user and server, the user will encrypt his biometric identity with his public key and send it to the server to compute the products of the encrypted biometrics and the encrypted classifier parameters and randomize the results for security purposes. The randomized products will then be sent to the user to unlock them and calculate the sum of the products. The resulting sum will be resent to the server to derandomize it and find the result to check it against a threshold value to determine whether to accept or reject that user. The advantage of this method relies on the ability of keeping the sensitive information (user's identity and server's classification parameters) hidden from both parties while still being able to authenticate each other. The method does not involve the use of the enrollment server, which contains all the sensitive information, in the authentication process, thereby avoiding serious losses if the server or the client are compromised.
A conductive numerical proof of ZKP applicability is discussed deeply in [47], [48] to achieve confidential transactions and private smart contracts in blockchain technology. Moreover, they emphasized on ZKP ability to provide a verifiable proof of the user's identity using remote biometric authentication, without leaking the biometric modalities to untrusted parties. The mentioned proofs can guarantee us that the usage of ZKP during the generation of the biometric commitment key in TLI-µTESLA can help in securing the identity of the user.

IX. CONCLUSION
In summary, we discussed an important lightweight cryptography protocol used in IoT-constrained devices-the TESLA protocol. In addition, the updates and improvements developed were presented, including our proposed TLI-µTESLA, and they were theoretically compared in terms of security services. We highlighted the important parameters of the TESLA protocol, for example, symmetric cryptography, presence of the disclosure delay, reduced message size, and loose synchronization between the network members. Moreover, we discussed the recent implementations of TESLA in the VANET network and GPS navigation message authentication and proposed a new implementation of TESLA in UAMs. The challenges faced during the implementation of the protocol were considered along with the suggested solutions and parameter selections, which will assist in the simulation stage of TLI µTESLA. Our study demonstrated that the determination of an adequately large key length strongly impacts the reduction of brute-force attack during the disclosure delay or the establishment of the loose synchronization between the network members. The addition of the salt value to the key chain aids in reducing the probability of attackers breaking the keychain. Furthermore, the challenges of reducing the involvement of public cryptography during the authentication process is required in the TESLA protocol to avoid quantum attacks through the utilization of biometric authentication to generate the session key. Finally, the authentication schemes using biometric templates revealed the importance of protecting the biometric templates during authentication of other parties in the network.