S6AE: Securing 6LoWPAN Using Authenticated Encryption Scheme.

IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN) has an ample share in the Internet of Things. Sensor nodes in 6LoWPAN collect vital information from the environment and transmit to a central server through the public Internet. Therefore, it is inevitable to secure communications and allow legitimate sensor nodes to access network resources. This paper presents a lightweight Authentication and Key Exchange (AKE) scheme for 6LoWPAN using an authenticated encryption algorithm and hash function. Upon successful authentication, sensor nodes and the central server can establish the secret key for secure communications. The proposed scheme ensures header verification during the AKE process without using IP security protocol and, thus, has low communication and computational overheads. The logical correctness of the proposed scheme is validated through Burrows-Abadi-Needham logic. Furthermore, automatic security analyses by using AVISPA illustrate that the proposed scheme is resistant to various malicious attacks in 6LoWPANs.

1. Introduction

Low Power Wireless Personal Area Networks (LoWPANs) are an essential part of the Internet of Things (IoT) and are composed of resource-constrained devices tractable with the IEEE 802.15.4 standard. LoWPAN is a promising technology [1,2] having potential applications in smart grids, home automation, e-health-care, battlefield, and security surveillance. Such networks are constricted in storage capacity, transmission range, computational capabilities, power resources, and data rate. To provide Internet connectivity to LoWPAN devices, IPv6 is considered to be the most accordant solution [3,4]. However, IPv6 is a resource-intensive protocol originally designed for desktop and server environments and has a maximum frame size of 1280 bytes, whereas the maximum physical layer frame size for IEEE 802.15.4 is 127 bytes [5,6].

To make IPv6 frame size tractable with the IEEE 802.15.4 physical layer, the Internet engineering task force has standardized an IPv6 over LoWPAN (6LoWPAN) adaption layer [7]. This layer provides IPv6 packet fragmentation, encapsulation, reassembly, and header compression mechanisms [5,8]. In addition, 6LoWPAN renders the functionality for seamless transmission of IPv6 packets across networks and provides a mechanism for stateless addressing.

Sensor nodes deployed in a 6LoWPAN network are used to accumulate vital information from surrounding environments and transmit the collected information to a central location. Thus, for a streamlined operation of 6LoWPANs, confidentiality and integrity of the transmitted information must be ensured [9,10]. However, the original 6LoWPAN design does not include security and privacy features. The following subsection reviews eminent proposals for securing 6LoWPANs.

1.1. Related Work

Cryptographic encryption techniques and message validation mechanisms are applied for securing communications in 6LoWPANs. For this purpose, an Authentication and Key Exchange (AKE) scheme is essential before applying the cryptographic algorithms. An AKE scheme ensures the legitimacy of sensor nodes deployed in 6LoWPANs and also establishes a secret session key to protect communications between sensor nodes and the server from an attacker [11].

The authors in [12] propose a lightweight IP Security (IPsec) based scheme for 6LoWPANs to achieve secure end-to-end communication. The scheme introduces a pre-shared key concept for AKE, but it does not provide any information about the session initialization and secure mobility. In [13], the authors present a scheme, called scalable security with symmetric keys, to achieve secure communication among end-devices in IoT. However, the scheme is not feasible for large 6LoWPANs because of its higher computational overhead and complex key management process. The authors in [14] propose a Secure Password Authentication Mechanism (SPAM), which supports a secure handover process in the proxy mobile IPv6 networks. However, the main drawback of the SPAM mechanism is the higher transmission delay incurred as a result of the re-authentication process. In [15], the authors propose a mechanism that renders security for wireless sensor networks by deriving the key from a pre-distributed master key. However, the scheme is computationally expensive for resource-constrained devices. The authors in [16] propose a Secure Authentication and Key Establishment Scheme (SAKES), which is based on public-key cryptography, but it is computationally expensive for resource constricted devices. Additionally, SAKES does not provide secure mobility and is vulnerable to the node compromised attack. To reduce the computational burden on sensor nodes, SAKES performs most of the computation at gateway nodes and sends the computed key to sensor nodes in the 6LoWPAN environment. Therefore, to perform the handover, it is necessary for sensor nodes to start the new key establishment process. Furthermore, SAKES assumes all sensor nodes in the 6LoWPAN environment to be static. The authors in [17] propose an Efficient Authentication Key Exchange for 6LoWPAN (EAKES6Lo) based on the Elliptic Curve Cryptography (ECC) and Advance Encryption Standard Counter Mode (AES-CTR-128). EAKES6Lo ensures secure session key establishment and provides mutual authentication between sensor nodes and the server. However, EAKES6Lo is computationally expensive and does not provide privacy. In [18], the authors propose a Lightweight Authentication Protocol (LAUP), which is based on the symmetric key cryptosystem while using the pre-shared key mechanism. LAUP is time efficient and consumes low power during the AKE process. However, the scheme does not provide effective measures for secure mobility.

The authors in [19] propose a communication security and privacy support based on the public key cryptography and pre-shared key mechanism to achieve secure communication in 6LoWPANs. The authors in [20] propose a 6LowPSec security protocol that provides end-to-end security among 6LoWPAN nodes using the existing hardware security mechanism specified by IEEE 802.15.4 Media Access Control (MAC) sub-layer. However, their proposed security protocol does not provide mobility support and header verification.

1.2. Contribution and Paper Organization

This paper proposes a lightweight AKE scheme, called Securing 6LoWPAN using Authenticated Encryption Scheme (S6AE), which provides mutual authentication between the server and sensor nodes and also ensures header verification during the authentication process without employing the IPSec protocol. S6AE employs the well-known ASCON algorithm for authenticated encryption in 6LoWPANs. To the best of our knowledge, ASCON has never been employed in the literature for securing 6LoWPANs. Additionally, S6AE employs SHA-256 hash function and bit-wise XOR operations to achieve AKE in 6LoWPANs. SHA-256 is used to generate unique output strings by using the S6AE secret parameters. To decrease the communication overhead by means of reducing the message size, the length of the SHA-256 output string must be reduced to 64-bits with minimum computational cost and without compromising performance. For this purpose, we use bit-wise XOR operations. The key contributions of this paper are listed below.

The proposed scheme provides end-to-end security, mobility support, and header integrity.

Informal security analysis and formal validations using Burrows–Abadi–Needham (BAN) logic and Automated Validation of Internet Security Protocols and Applications (AVISPA) illustrate that S6AE secures 6LoWPANs against various malicious attacks.

Comparative analysis with eminent existing schemes demonstrates that S6AE is more efficient and provides better security features with less computational and communication overheads, memory utilization, and energy consumption.

The remainder of the paper is organized as follows. System models and preliminaries are discussed in Section 2. Section 3 details the proposed S6AE scheme, and Section 4 provides security analysis of S6AE scheme. Performance evaluation is presented in Section 5. Finally, the paper is concluded in Section 6.

2. System Models

This section presents the models and preliminaries used in the proposed scheme.

2.1. Network Model and Security Assumptions

This paper considers the network model shown in Figure 1 for the authentication process. The 6LoWPAN network model consists of sensor nodes (s), domain router 6LDR, the access router (6LAR), and the central server (). s are used to accumulate information from the surrounding environment and transfer the collected data to for further processing. Moreover, 6LDR provides Internet connectivity by s in a domain. 6LAR provides inter-connectivity with in IPv6 cloud. It is assumed that the communications among 6LAR, 6LDR, and are secure. Besides, it is assumed that is reachable by s, 6LDR, and 6LAR. 6LDR registers itself with through a secure channel. Additionally, s and 6LDR exchange their pseudo-identities (SIDs) through neighbor discovery (ND) protocol. Furthermore, each 6LDR registers itself with 6LAR. All the devices in 6LoWPAN learn about the global routing prefix of through 6LAR. Moreover, each generates an IPv6 address using an IEEE extended unique identifier mechanism or by using the personal area network identity [21].

Figure 1

6LoWPAN network architecture.

2.2. Threat Model

The Dolev-Yao (DY) model [22] is the threat model used in S6AE. According to the DY model, an intruder can intercept and record the messages exchanged between two communicating entities in 6LoWPAN. Communications among the entities in 6LoWPAN are public in nature. If an adversary has the knowledge about the private key, it can encrypt and decrypt messages and perform unlawful activities, such as modifying or forging the captured messages. The communicating entities, such as s and 6LDRs, are considered to be untrusted under the DY model. An adversary can capture an due to its hostile environment and can extract the sensitive information stored its memory by employing the power analysis attack. However, is a central and vital component in the 6LoWPAN environment, and it cannot be compromised by an adversary.

2.3. Preliminaries

2.3.1. Hash Function

A hash function can take a variable size input string, and return the output with a fixed size string. Each hash function must obey the following properties.

The output of the hash function with two different inputs, n and m, can never be the same, i.e., .

It is not possible to compute the input, z, from the output of a hash function, , i.e., .

2.3.2. ASCON

ASCON is an authenticated encryption with associated data scheme [23] that works on the design principle of duplex sponge architecture. Moreover, ASCON is a symmetric, inverse free, single pass, and online block cipher. Broadly speaking, there are two versions of ASCON: (i) ASCON-128 that takes 64 bits data block and generates 64 bits ciphertext along with 128 bits of authentication , and (ii) ASCON-128a that takes 128 bits data block and generates 128 bits of ciphertext along with 128 bits of authentication . The architecture of ASCON is given in Figure 2, which works under the following four stages [23]. Initialization: In this stage, ASCON computes the initial input to ASCON state by combining the Initialization Vector (IV), nonce, and key. The size of ASCON state is 320 bits. Associated Data (AD) Processing: This stage processes AD that represents the data block to be transmitted in an un-encrypted form, while at the same time ensuring the integrity of the transmitted data block. Plaintext Processing: In this stage, ASCON takes plaintext as an input and generates the ciphertext as output. Finalization: In the final stage, ASCON generates the authentication , which ensures the integrity and authenticity of the ciphertext and AD. Furthermore, the substitution and permutation network of ASCON comprises 5-bit S-Box, bit-wise XOR, and rotation operations. Thus, ASCON is suitable for resource-constrained devices, such as embedded systems and radio frequency identifier tags, because of its lightweight property and minimal overheads [24,25,26]. For securing 6LoWPANs, the proposed S6AE scheme in this paper borrows the standard ASCON encryption design, which provides confidentiality and authenticity of data simultaneously. Additionally, S6AE employs SHA-256 hash function, and bit-wise XOR operations to achieve AKE in 6LoWPANs.

Figure 2

ASCON architecture.

3. The Proposed S6AE Scheme

S6AE verifies the legitimacy of s at the , and validates the integrity and authenticity of messages exchanged between s and the in 6LoWPANs. In S6AE, after verifying the authenticity of s, and s establish secret keys using ASCON as the encryption scheme. SHA-256 is used to generate unique output strings by using the S6AE secret parameters, and bit-wise XOR operations are used to reduce the computational and storage costs. S6AE consists of the registration phase, the AKE phase, and the handover phase. It is necessary for a static or mobile to execute the first two phases, whereas only a mobile requires to execute the handover phase. The notations used in this paper are listed in Table 1.

Table 1

List of notations.

Notation	Description
CS, SN	Central server and 6LoWPAN sensor node
SID_sn, SID_ldr,	Pseudo-identities of sensor node and 6LDR, respectively
ID_sn, SP_1, SP1n	Secret real-identities of 6LoWPAN sensor nodes and secret parameter used in authentication process
E_k(x), D_k(x)	Encryption and decryption of message “x” using the secret-key “k”
〈Tag_sn,Tagsn^′〉, 〈Tag_g,Tag_cs〉	Authentication parameter generated by encryption and decryption algorithm at SN and CS, respectively
T_sn, T_cs, T_lar	Timestamps at SN, CS and 6LAR, respectively.
〈IV_sn,IVsn^′〉, 〈IV_cs,IVcs^′〉	Initialization vectors at SN and CS, respectively
〈S_k,Sk^‴〉, 〈Sk^′,Sk^″〉	ASCON initialization states at SN and CS, respectively
Skh, Sk^′h	Initialization states at CS and SN in the handover phase, respectively.
K_sn, R_n and R_s1, R_s2	Keys for SN and random number used in authentication process
MACsn, MACcs	MAC addresses of SN and CS, respectively
T_h, R_h	Timestamp and random number used in handover phase, respectively
H(.), ⊕, ‖	Cryptographic hash-function, bit-wise XOR, and concatenation, respectively

3.1. Sensor Registration Phase

This phase deals with the registration of before its deployment in 6LoWPAN. performs the following operations to register s. It

calculates the master key by computing , where is the real identity of and is a random number. divides into four equal chunks of 64 bits, namely , , , and , and computes , where is a temporary key for .

assigns a unique of 64 bits for .

picks a key of 64 bits for and computes the pseudo-identity .

computes and derives security parameter by computing , where , , , and are four equal chunks of 64 bit .

Finally, stores related secret information, i.e., {, , , , } into its database and {, , , , } in the memory of while making use of a secure channel. also stores into 6LDR memory through a secure channel.

3.2. Sponge State Generation

The initialization phase of ASCON consists of 320 bits, known as initialization states . In the proposed scheme, can be derived as follows.

generates a random number of 64 bits and time stamp of 32 bits,

computes , where is an initialization vector for ,

computes and derives , where is the first 24 bytes of . The size of is 320 bits ( = 24 bytes + = 16 bytes), which is served as input to the encryption algorithm during the initialization phase.

3.3. Associative Data Generation

The proposed S6AE scheme generates AD while incorporating the compressed IPv6 and User Datagram Protocol (UDP) headers [8,21]. The header size is 10 bytes after compression. The subsequent Immutable Fields (IF) are used to generate AD. This includes parameters such as dispatch, internet protocol header compression, context identifier, next header compression, destination interface identifier, UDP Ports, UDP Checksum, Global routing prefix of 6LoWPAN (G6), and Global routing prefix of (GC). stores the MAC of and stores the MAC of . Moreover, the hop limit parameter is mutable, which is not incorporated in AD generation. The following operations are performed to generate AD.

computes . It then divides into two equal parts, i.e., and each of 128 bits.

computes and divides into two equal parts, i.e., and , each of 64 bits.

The encryption algorithm takes and as the inputs at the associative data processing phase to preserve their integrity.

During the registration process of

3.4. Authentication and Key Exchange

In this phase, achieves the anonymous authentication and key agreement with via the intermediate nodes, 6LDR and 6LAR. After establishing a secret key, and can exchange data securely. S6AE exchanges four messages to accomplish the authentication process. The detail of the messages exchanged in the proposed scheme is given below.

3.4.1. Step AKE-1

generates a random number of 64 bits and timestamp of 32 bits for computing , and , where the sizes of X and Y are 64 bits. The encryption algorithm takes as shared secret inputs during the initialization phase, at the associative data processing phase, which is computed in Section 3.3, at the plaintext processing phase, and produces ciphertext and that is generated automatically by ASCON. ensures the confidentiality of the plaintext . The generated guarantees the authenticity and integrity of the ciphertext at the receiving end. provides the same functionality as Message Authentication Code (MAC). also computes , where is the temporary identity of 6LDR. After performing the above operations, constructs a message M1: and forwards it to 6LDR to be processed further.

There are various encryption algorithms, such as the Advanced Encryption Standard (AES), which provides confidentiality features. However, AES does not provide authentication of data. To achieve the required authentication, another algorithm is required, such as the MAC algorithm. Thus, all authenticated encryption schemes can be used to achieve confidentiality and authenticity of the communicated message because these schemes generate ciphertext as well as authentication

The main idea here is to use ASCON to achieve the cumulative functionality of AES + MAC by using a single algorithm (i.e., ASCON), which generates its own MAC to be validated at the destination. To check the integrity of transmitted messages, we do not to employ any other MAC. In this way, we are able to reduce the computational cost, as shall be demonstrated in the performance evaluation section.

3.4.2. Step AKE-2

After receiving M1 from , 6LDR picks out Z from the received message and computes . 6LDR compares with the stored in its memory. If the contents of both the and are the same, 6LDR appends its with the received M1 for generating and forwarding the new message M2: to 6LAR. Contrarily, 6LDR aborts the AKE process and sends an error message back to .

3.4.3. Step AKE-3

6LAR receives the newly generated M2 from 6LDR and checks in the current list of the registered devices. If 6LAR does not find in the list, it will abort the AKE process and add unverified in the blacklist. On the contrary, upon successful verification of the for M2, 6LAR picks a timestamp and computes , where is the pre-shared key between 6LAR and , and is the temporary identity of 6LAR. 6LAR then generates and forwards message M3: to for further processing.

3.4.4. Step AKE-4

Upon receiving M3 from 6LAR, retrieves secret information related to 6LAR, such as a using . also checks the validity of by verifying if M3 is received within the maximum transmission delay () limit by computing , where is the received timestamp of M3. To verify the integrity of M3, computes . If the computed and the received are not identical, aborts the AKE process and adds 6LAR to the current list of fake devices. After checking the integrity of M3, retrieves M2 from M3, and checks if the condition holds. If the condition does not hold, then rejects M2. Moreover, also checks whether a valid exists in the current list of 6LDR devices. On successful verification of , picks Z from M2, derives by computing , and checks if exits in its database. After the verification of the , retrieves the information stored in its database, such as , , , and .

3.4.5. Step AKE-5

generates by concatenating with , which are attached with the received M2. also computes to derive . It is important to mention here that 320 bits of is the concatenation of and , i.e., , where are the first 24 bytes of the (which is of 32 byte. The size of is 40 bytes. Moreover, determines AD by using the received header information and the stored in ’s database by computing , and divides into two parts, i.e., and . AD is the input to the encryption algorithm and its purpose is to ensure the integrity of header information. The detailed process of computing AD is given in the Section 3.3. In addition, performs the decryption operation , where is the input at the initialization phase, and are the inputs at associative data processing phase, and is the input at the ciphertext processing phase, as shown in Figure 2. Moreover, the decryption algorithm generates before extracting the plaintext information. ASCON generates the authentication tag automatically after processing AD and ciphertext. Then checks the condition , where is received with . An inverse free authenticated encryption scheme generates the same authentication during the encryption and decryption process, if there is no modification in AD and ciphertext. However, if there is any modification in the communicated message, the generated authentication will be different, which causes the failure of authentication process in the proposed AKE. If the condition holds, decryption process will reveal the plaintext information. Otherwise, will abort the AKE process. The revealed plaintext, after the decryption of , includes X and Y. picks the retrieved and performs operation to determine for computing . Furthermore, in order to check the legitimacy of , checks the condition . If the condition holds, registers as a legitimate device, otherwise, will abort the AKE process.

3.4.6. Step AKE-6

After verifying the legitimacy of , picks timestamps of 32 bits. picks three random numbers , , and each of 64 bits. then computes and calculates a new security parameter by computing , where are four equal chunks of each of 64 bits. calculates , , and , where is the initialization vector at and is the random number of 64 bits. To generate , computes , where the size of is 256 bits and calculates , where are the first 24 bytes of . Next, calculates AD by computing , and divides into two parts, i.e., and . For secure communication in future, computes a session key by calculating . Moreover, for secure handover from one domain to another domain as shown in Figure 1, calculates a unique ticket for by computing . will make use of the generated during the handover process. also picks ’s expiry time (32 bits). In addition, the encryption algorithm takes into account during the initialization phase, and during the associative data processing phase, and during the plaintext information processing phase, in order to generate and . Moreover, constructs the message M4:, and forwards it to 6LAR. 6LAR and 6LDR simply relay M4 to . Furthermore, stores the parameters , , , , , } in its memory.

3.4.7. Step AKE-7

After receiving M4, checks the validity of timestamp by checking the condition , where is the maximum allowed time TD and is the period in which M4 is received. Significantly, will reject M4 if exceeds the maximum allowed delay. picks , from the received M4 and calculates . also computes , and , where is the first 24 bytes of . Next, calculates AD by computing , and divides into two parts, i.e., and . The decryption algorithm takes as the input during the initialization phase, and during the associative data processing phase, during the ciphertext processing phase, and performs the decryption operation , to generate . In the final step, checks the condition . If the condition holds then decryption algorithm will reveal the plaintext information, i.e., 〉. Additionally, computes the session key by computing to secure future communications with . In addition, calculates a unique ticket , which will be used during the handover process. Finally, stores the parameters {, , , , , } in its memory. The AKE phase of the proposed scheme is summarized in Figure 3.

Figure 3

S6AE authentication and key establishment phase.

3.5. Handover Phase

In the proposed scheme, a sensor node can move from network Domain-1 to another Domain-2, as shown in Figure 1. Hence, it is essential to verify the authenticity of a roaming with minimal overhead complexity. Importantly, utilizes the ticket , generated during the AKE phase, to accomplish fast authentication. More specifically, performs the following operations during the handover process.

3.5.1. Step HP-1

When an moves from the communication range of 6LDR1 in Domain-1 to the communication range of 6LDR2 in Domain-2, sends a handover request to 6LDR2. checks of , which is stored in s memory. If is not expired then picks the timestamp and computes . then constructs a message : and forwards to 6LDR2. 6LDR2 checks if is fresh or not. To check integrity of , 6LDR2 computes and checks the condition . If the condition holds, 6LDR2 stores in its memory and forwards to . Contrarily, aborts the handover process and adds into blacklist in its database. After receiving , computes and checks the condition . If the condition holds, checks if exists in its database and verifies the condition . If the condition holds, continues the handover process, otherwise marks as a compromised node and broadcasts in the network. also sends a message to 6LDR1 to delete from its memory. 6LDR1 sends an acknowledgment to . is the stored ticket at and .

3.5.2. Step HP-2

picks two random numbers , each of 64 bits, and timestamps and each of 32 bits. It also computes and , where the size is 64 bits. calculates and by using the encryption algorithm. The ensures the authenticity of the transmitted information. It also computes the new session key as . constructs a message : and forwards to 6LDR2. Upon receiving , 6LDR2 looks up in 6LDR2’s memory. If exists in the memory of 6LDR2, 6LDR2 forwards to .

3.5.3. Step HP-3

After receiving the message from , performs the decryption using , where . The decryption process reveals the plaintext, which is and also it generates the . checks the condition . If the condition holds then considers valid, otherwise it rejects . indicates new expiry time of the . checks the condition . If the condition holds, then computes and . Authentication will be successful if the stored and the computed are the same. generates a symmetric key between and by computing . Finally, replaces the stored session key with the new session key in the memory and updates the expiry time in the tuple {, , , , , }. Figure 4 shows the message exchange during the handover phase.

Figure 4

The S6AE handover process.

4. Security Analysis

This section analyzes the security properties of our proposed S6AE scheme in three different phases. In the first phase, the characteristics and capabilities of the S6AE scheme against malicious attacks are described. In the second phase, BAN logic is incorporated to show the logical correctness of the S6AE scheme. In the final phase, AVISPA tool is used for automatically verifying the security properties of the proposed strategy.

4.1. Informal Security Analysis

4.1.1. Header Verification

Header Verification (HV) is an effective mechanism to mitigate the replay and Denial-of-Service (DoS) attacks. In the proposed scheme, to provide IPv6/UDP header verification, computes , , where and are the two equal chunks each of 128 bits of . divides into two equal parts, i.e., and each of 64 bits, which are the inputs at the associative data processing phase of the encryption algorithm. After receiving the message M1, computes and the decryption algorithm takes at the associative data processing phase. If there is no modification in the IPv6/UDP header, then the condition will hold. This condition will not hold if an adversary modifies the IPv6/UDP header during the AKE process. The same procedure holds for the message transmitted from to . In this way, the proposed scheme ensures IPv6/UDP header integrity (origin verification).

In this paper, HV means verification of the IPv6 header at the receiving end. We achieve HV by generating AD through the Hash function SHA-256, as discussed in

4.1.2. DoS Attack

By a DoS attack, an attacker can perform malicious activities and prevent a legal user from accessing the network resources [11]. A DoS attack can degrade the performance of the network. An IP spoofing attack is used to launch the DoS attack in the network by generating a large amount of data packet with fake IP addresses. S6AE can provide protection against the IP spoofing attack by ensuring the integrity of the IPv6 header. To perform a DoS attack, an adversary needs to calculate , , , 〈, 〉, , and . Then checks the condition . The condition will not hold after capturing the IPv6/UDP header information because requires the parameters, such as , , and , which are secrets to and . Thus, S6AE can protect against DoS attacks.

4.1.3. Replay Attack

A sort of network attack in which attacker wiretaps or captures the valid transmitted data and retransmits the seized data in the network for harmful intention [27]. During the authentication process (Section 3.4), all the transmitted messages M1:, M2:, M3:, and M4: include timestamps, and random numbers. The verification of the timestamps, such as , , and , ensure the freshness of the received message. Usually, is very small. Therefore, within , the probability of replaying M1, M2, M3, and M4 for adversary is negligible. A similar situation holds for the handover phase messages. S6AE also prevents the replay attack by ensuring the IPv6/UDP header integrity. Any modification in the IPv6/UDP header during the transmission of a message through the public Internet makes the decryption and authentication unsuccessful at the respective communicating entities, such as and . Hence, S6AE is secure against the replay attacks.

4.1.4. Man-in-the-Middle (MITM) Attack

MITM is an action of an intruder in which the intruder somehow conjoins the communication between the two communicating network nodes while both the nodes believe that they are communicating directly [28]. Let an adversary captures all the transmitted messages M1, M2, M3, and M4 during the communication between and . Suppose attempts to forge M1 to generate a valid message to force to believe that the forged message is from an authentic source. For this purpose, needs to guess the real identity of , which is an infeasible task for . Therefore, it not possible for to generate a bogus message M1. A similar condition holds for all other transmitted messages. This clearly indicates that S6AE is protected against MITM attack.

4.1.5. Sensor Impersonation Attack

By using an impersonation attack, the attacker can impersonate as an authentic to perform malicious activities in the network [11]. To execute this attacks, an adversary picks the current timestamp , and random number and then attempts to transmit the message M1 to on behalf of . However, to construct a legitimate , must know the real identity of , and . Without knowing these parameters, it is hard for to generate valid and . For , it is computationally hard to generate , and . Therefore, cannot generate a legitimate M1 and, thus, the proposed scheme provides protection against the impersonation attack.

4.1.6. Server Impersonation Attack

In this attack, adversary can send M4 to on behalf of . To compute a valid and , it is necessary for to know the secret parameters , , , and . However, for , it is computationally hard to generate these parameters, which are known only to . Therefore, S6AE can mitigate impersonation attacks.

4.1.7. Identity Privacy Preservation

Normally, utilizes the pseudo-identity during the transmission of the authentication messages, which is computed as , where all the parameters are secret to and . Therefore, it is hard for to generate without knowing these parameters. This demonstrates that the proposed scheme ensures the identity privacy of .

4.1.8. Unlinkability/Anonymity

S6AE renders the unlinkable and anonymous session during the AKE process. Each time when a new session starts, picks a fresh random number and generates an . The newly generated is the input to the initialization phase of the encryption algorithm. The encryption algorithm produces different ciphertext each time even with the same secret parameters , , and . The ciphertext also includes another fresh random number , which in turn enhances the randomness of the ciphertext. Therefore, it is hard for an adversary to correlate the two sessions form the same node. S6AE is untraceable, and it is not possible for an attacker to create a link between two different AKE processes. Since each AKE session utilizes a new , this makes the AKE session anonymous. Hence, S6AE ensures unlinkability and anonymity during the AKE process.

4.1.9. Sybil Attack

In a Sybil attack, the adversary can generate multiple counterfeit identities of real nodes. S6AE can prevent the Sybil attack because each in the network authenticates itself with [11]. If discover any duplicate of an during the AKE process in the database, then considers that particular ID as a compromised node. adds these IDs to the blacklist and forwards the list to 6LDR1 and 6LDR2, which in turn broadcast these IDs in the network. Thus, S6AE protects against the Sybil attack.

4.1.10. Forward/Backward Secrecy

Forward/backward secrecy means that if an adversary reveals the current session key, it does not enable an intruder to compromise the privacy of the past and future session keys [11]. S6AE determines session key by computing for each AKE session. A new AKE process establishes a session key by incorporating fresh parameters, such as , , , and . If an adversary breaches the security of the current session key , it does not allow to compromise the future session key. Therefore, it is hard for an adversary to construct the past or future session keys.

4.1.11. Ephemeral Secret Leakage (ESL) Attack

Pre-computed Ephemeral Secrets (ES), which are stored in insecure memory, can be compromised by . By using these compromised ES (short term) and long term parameters, can breach the session key security. Such types of attacks are known as ESL [29]. In S6AE, and establish a secret session key during the AKE process for the future secure communication. The established session key incorporates ephemeral terms, such as , , and long terms, such as . If compromises the ephemeral terms and , still requires the long term to breach the the security of the session key . To compromise the security of , must know the valid long and ephemeral terms, which are hard for to know. Therefore, the proposed S6AE is resilient to the ESL attack.

4.2. Crypt-Analysis Using BAN Logic

The BAN logic [30] is a logic of belief and action. It is a well defined formal method to test the logic correctness of a security protocol and determines the trustfulness of agreement among the participants in the AKE process of S6AE. The BAN logic is employed here to validate the mutual authentication properties of the proposed S6AE scheme as a whole. The notations used in the BAN logic are listed in the Table 2, which are used to describe different inference rules. A list of BAN logic inference rules are listed in Table 3, which are used to determine the goal of the proposed scheme.

Table 2

Ban Logic notations.

Feature	Description
S∣≡X	S believes if the formula X is true
S∣∼X	S once said X
S⊲X	S sees X
S↔kH	k is a shared-secret between S and H
S⇔KH	K is a secret parameter known only S and H
#(X)	X is fresh.
{X}_k	X is encrypted with the secret key k
〈X〉Y	X is combine with secret Y
S⇒X	S has jurisdiction over X
SH	If S is true then H is also true

Table 3

Ban Logic inference rules.

Notation			Description
Message-Meaning-Rule			S∣≡S↔kH,S⊲{X}_kS∣≡H∣∼X
Jurisdiction-Rule			S∣≡H→X,S∣≡H∣≡XS∣≡X
Belief-Rule			S∣≡(X,Y)S∣≡X
Nonce-Verification-Rule			S∣≡#(X),S∣≡H∣∼XS∣≡H∣≡X
Freshness-Rule			S∣≡#(X)S∣≡#(X,Y)

4.2.1. Assumptions

S6AE makes the following assumptions at the outset to investigate the AKE properties of our scheme.

AS-1:

AS-2:

AS-3:

AS-4:

AS-5:

AS-6:

AS-7:

AS-8:

AS-9:

AS-10:

AS-11:

AS-12:

AS-13:

AS-14:

AS-15:

4.2.2. Goals

To verify the AKE process of S6AE, it must achieve the following goals.

G1:

G2:

G3:

G4:

4.2.3. Protocol Idealized Form

The idealized form of the proposed scheme can be expressed as follow.

IF1: :

IF2: :

4.2.4. Formal Verification

In this phase of the BAN logic, the inference rules, listed in Table 3, are used to determine if S6AE has achieved its security goals.

VF-1: From IF1, AS-7, AS-8, and by applying Message-Meaning-Rules, it is possible to achieve

VF-2: From IF1, AS-2 and by applying Freshness-Rule concludes

VF-3: Using VF-1, VF-2 and by applying the Nonce-Verification-Rule, it is possible to obtain

VF-4: From VF-3 and by applying the Belief-Rule, the goal G1 can be achieved as

VF-5: The goal G2 can be accomplished by utilizing VF-4, AS-13, and by employing the Jurisdiction-Rule from

VF-6: From IF2, AS-11, and by applying Message-Meaning-Rules, it is possible to derive

VF-7: By using IF2, AS-1, and utilizing the Freshness-Rule, we get

VF-8: Using VF-6, VF-7 and by applying the Nonce-Verification-Rule, it is possible to obtain

VF-9: G3 can be achieved by using VF-8 and by employing the Belief-Rule from

VF-10: From (11) G4 can be derived by utilizing AS-12 and by employing Jurisdiction-Rule

4.3. Crypt-Analysis Using AVISPA

Crypt-analysis of S6AE is conducted using the AVISPA tool [31], which obeys the DY attack model and is commonly used by the research community to examine the capabilities of the security algorithms. AVISPA comprises four back-end models, known as CL-AtSe, TA4SP, OFMC, and SATMC. These back-ends perform various automatic analyses to detect vulnerabilities in the security scheme. It uses perfect cryptography, which means that the adversary cannot derive the messages or plaintext from ciphertext without perceiving the secret key. It uses formal language High-Level Protocol Specification Language (HLPSL) to code a specified security algorithm. A translator known as HLPSL2IF is used to convert the HLPSL code into the Intermediate Form (IF). AVISPA uses four back-end techniques defined in [32] for the automatic analysis and the capabilities of a security algorithm against various attacks. The XOR operation is not supported by SATMC and TA4SP back-end. Therefore, the simulation of S6AE using these two back-ends is not possible.

Figure 5 shows the Output Format (OF) generated by AVISPA’s OFMC and CL-AtSe back-ends. A generated OF has different sections, including SUMMARY, DETAILS, PROTOCOL, GOAL, BACKEND and STATISTICS, as shown in Figure 5. SUMMARY shows whether a security scheme being tested is safe or unsafe. PROTOCOL describes the HLPSL specification of the scheme in IF. GOALS is the analysis of the goals conducted by AVISPA as specified in HLPSL. BACKEND is used for the backend analysis of the scheme. In S6AE implementation, there are 4 basic roles, i.e., , , 6LDR, and 6LAR, and two compulsory roles, i.e., environment & goals and session defined in HLPSL. Figure 5 illustrates that the proposed S6AE scheme is secure and protects against MITM and replay attacks.

Figure 5

AVISPA OFMC and CL-AtSe back-end simulation results.

5. Performance Evaluation

This section presents the performance evaluation of S6AE in comparison with eminent 6LoWPAN security schemes, namely, SAKES [16] and EAKES6Lo [17].

S6AE server-side has been implemented in Python 2.7 and each is consigned with a unique , , and by utilizing a random number generator. Simulations are conducted on a computer with Intel(R) Core(TM) i7-6700 CPU @ 3.40 GHz, Ubuntu (64-bit) and 8-GB RAM. A list of configuration parameters is given in the Table 4.

Table 4

Simulation parameters.

Parameter					Size (Bits)
Encryption Algorithm					ASCON-128a
ID_sn					64
SP_					64
ID_cs					64
SID_sn					64
SID_ldr					64
timestamp					32
HASH Function					SHA-256
Random numbers					64

5.1. Security Comparison

The security functionalities of the proposed scheme, compared with the existing security schemes, are given in Table 5. EAKES6Lo and SAKES do not provide any header verification mechanism to mitigates various malicious attacks, such as DoS and replay attacks. EAKES6Lo does not offer identity privacy preservation of the sensor node. However, S6AE is more reliable than other security schemes for 6LoWPAN, as can be seen in Table 5.

Table 5

Comparison of security properties.

	SAKES	EAKES6Lo	S6AE
Header Verification	×	×	✓
Replay attack	✓	✓	✓
Compromised attack	×	✓	✓
IP-Spoofing attack	×	×	✓
Unlinkability	×	✓	✓
Forward secrecy	×	✓	✓
Sybil attack	✓	✓	✓
Impersonation attack	✓	✓	✓
DOS attack	✓	✓	✓
MITM attack	✓	✓	✓
Identity Privacy Preservation	×	×	✓
Mutual authentication	✓	✓	✓
Mobility	×	✓	✓

5.2. Computational Overhead

The proposed S6AE scheme renders protection against well-known and various covert attacks. However, during the AKE process, many unforeseen attacks, such as a jamming attack, may interfere with the execution of S6AE and may introduce delay during the progress of the AKE process. To estimate the computational overhead, the total execution time delay of S6AE can be calculated as where is the total time for 5000 runs, where is the time required for the execution of S6AE and . SAKES is a hybrid security scheme and applies the Diffie-Hellman (DH) key exchange mechanism. Four DH groups provide different levels of security. To achieve the security level of 128-bits, we use the DH group 15 [33]. AES-CTR-128 bits, SHA-256, and ECDSA-160, are the cryptographic operations used by EAKES6Lo during the AKE process. S6AE utilized SHA-256 and ASCON cryptographic operations. The average time consumed by S6AE, SAKES, and EAKES6Lo are ms, ms, and ms, respectively, as shown in Figure 6. Thus, S6AE has the lowest overall computational time.

Figure 6

Computational overhead.

Furthermore, Table 6 presents the comparison of the computational overheads of SAKES, EAKES6Lo, and S6AE. To compute the computational overheads, this paper considers the average time required for SHA-256, i.e., ms, and for the AES-128 is ms. The time needed for the signature generation/verification is ms and the time required for ECC public/private key generation is ms. The average time required for ASCON is ms (10 MHz) [23,24] and ms is the time required for the modular exponentiation (DH). The computational costs of SAKES, EAKES6Lo, and S6AE are ms, ms, and ms, respectively. Thus, SAKES and EAKES6Lo are computationally more expensive as compared to the S6AE.

Table 6

Computational overheads.

Scheme	SN	6LDR	6LAR	CS	Total Time
SAKES	3T_aes+T_sha	2T_exp+2T_aes+T_sha	-	T_exp+3T_aes+2T_sha	3T_exp+8T_aes+4T_sha≈58.6044 ms
EAKES6Lo	2T_aes+T_sha+T_sg	T_sv	T_sha+T_aes	3T_aes+2T_sha+T_sv	5T_aes+4T_sha+2T_sv+T_sg≈17.2494 ms
S6AE	2T_ascon+5T_sha+7T_xor	T_xor	T_sha	2T_ascon+7T_sha+14T_xor	4T_ascon+13T_sha+22T_xor≈0.6643 ms

5.3. Communication Overhead and Energy Consumption

Optimization of energy consumption is a critical parameter of interest for 6LoWPAN. It is imperative to minimize the transmitted message size to reduce the energy consumption of sensor nodes. 6LAR, , and 6LDR are powerful devices with ample energy resources. Therefore, S6AE considers the energy consumption in the wirelessly connected constrained devices, and the energy consumption outside 6LoWPAN is not evaluated. To evaluate the transmission overhead in the proposed scheme, we consider 10 bytes overhead of the compressed form of IPv6/UDP header defined in [21]. The energy consumption during sending and receiving of a single bit is J and J, respectively [34]. The transmission overhead of S6AE is given in Table 7 and energy consumption in Table 8. S6AE has been compared with EAKES6Lo and SAKES. It is observed that S6AE utilizes fewer energy resources.

Table 7

Communication overhead.

	Security Schemes
Exchanged Messages	EAKES6Lo	SAKES	S6AE
SN→6LDR	672 bits	688 bits	496 bits
6LDR→SN	784 bits	2176 bits	528 bits

Table 8

Transmission energy consumption.

Proposed Scheme					Energy Consumption
S6AE					0.785 mJ
EAKES6Lo					1.11888 mJ
SAKES					2.25792 mJ

The average energy cost for AES encryption/decryption is J, SHA-256 needs J/byte, ECDSA-160 consumes mJ in signature generation, and ASCON requires J [24]. Total energy cost overhead of the EAKESLo, SAKES, and S6AE are mJ, mJ, and mJ, respectively. If an adversary interrupts the execution of the protocol, it may increase energy consumption. Figure 7 shows the total energy utilization in the presence of jamming attacks.

Figure 7

Energy consumption overhead.

5.4. Storage Overhead Comparison

In the proposed scheme, is required to store the tuple {, , , , }, which requires (64 + 64 + 64 + 128 + 48 + 32) = 400 bits. needs to store the parameters {, , , , , , }, which requires (64 + 64 + 64 + 64 + 128 + 48 + 32) = 464 bits. Table 9 shows the comparison of storage cost of SAKES, EAKES6Lo, and S6AE. It is observed that the proposed scheme requires more storage at the server and less storage at as compared to the EAKESLo and needs less storage at and as compared to SAKES.

Table 9

Storage cost comparison.

Storage Cost	SAKES	EAKES6Lo	S6AE
Sensor (SN)	272 bytes	88 bytes	46 bytes
Server (CS)	272 bytes	80 bytes	54 bytes

5.5. Handover Phase Comparison

This section presents the computational and communication overhead during the handover phase. The computational overhead of EAKES6Lo and S6AE are ms, and ms, respectively, during handover phase. Table 10 shows the communication and computational overheads during the handover phase. The results manifest that the proposed scheme is efficient as compared to the existing schemes.

Table 10

Handover overhead.

	Computational Overhead		Communication Overhead
Scheme	Computational Time	Time Cost (ms)	SN→6LDR2	6LDR2→SN	No. of Messages	Energy Cost (mJ)
EAKES6Lo	6T_aes+4T_m+T_sg+T_sv+2T_sha	11.9366	704 bits	672 bits	6	1.05
S6AE	2T_ascon+4T_sha	0.2544	480 bits	418 bits	6	0.68
SAKES	n/a	-	n/a	n/a	n/a	n/a

5.6. Discussion

6LoWPANs are at the core of IoT. However, the original 6LoWPAN design does not offer security services, including data confidentiality, integrity and authentication. To address this issue, we have presented an AKE scheme, called S6AE, for 6LoWPANs. For this purpose, we have employed ASCON, which is a lightweight general-purpose encryption algorithm, in conjunction with SHA-256 hash function, to enable the required confidentiality, integrity and authenticity in 6LoWPANs. To the best of our knowledge, ASCON has never been employed in the literature for securing 6LoWPANs.

In S6AE, after verifying the authenticity of s, and s establish secret keys using ASCON as the encryption scheme. ASCON has been employed to achieve data confidentiality and authenticity simultaneously without using a separate MAC. Using AES renders confidentiality, and to achieve the authenticity of the encrypted information it is imperative to use MAC. The main idea in this paper is to use ASCON to achieve the cumulative functionality of AES + MAC by using a single encryption algorithm, i.e., ASCON, which generates its own MAC. To check the integrity of transmitted messages, we do not need to employ any other MAC. In this way, we reduce the computational cost, as compared with the benchmarks.

We use SHA-256 to generate unique output strings by using the S6AE secret parameters. To decrease the communication overhead by means of reducing the message size, the length of the SHA-256 output string must be reduced to 64-bits with minimum computational cost and without compromising performance. For this purpose, we use bit-wise XOR operations. Through BAN logic and AVISPA, we have validated S6AE to be logically complete and offering the required security services in 6LowPANs. We have demonstrated that S6AE reduces the computational and communicational overheads, energy consumption and storage costs, in comparison with the benchmarks.

Results demonstrate that the proposed scheme provides better features in comparison with the benchmarks, namely, EAKES6Lo and SAKES. EAKES6Lo is a hybrid scheme, which uses ECC and AES-CTR and is computationally expensive as compared to S6AE because ECC is resource intensive for the resource constrained 6LoWPANs. Table 6 and Figure 6 show that S6AE requires less resources as compare to EAKES6Lo. Table 5 shows that EAKES6Lo does not provide the identity privacy and header verification. Moreover, SAKES is insecure against the 6LAR gateway compromised attack and does not ensure the header integrity in 6LoWPANs, as shown in Table 5. SAKES employs DH key exchange mechanism and also uses AES as a encryption and decryption scheme, which is computationally expensive in comparison to S6AE, as shown in Table 6 and Figure 6. Table 9 shows that S6AE requires less memory as compared SAKES and EAKES6Lo. Moreover, Table 7 indicates that S6AE is less expensive. Furthermore, S6AE requires less energy resources as compared to the EAKES6Lo and SAKES because S6AE uses lightweight and authenticated encryption that requires less energy and computational resources. In a nutshell, we have found that the implementation of ASCON, in conjunction with SHA-256, in 6LoWPANs is promising to secure communications.

6. Conclusions

6LoWPAN is a providential technology having a vital share in IoT and is commonly deployed in a variety of applications. Originally, 6LoWPAN does not provide any security and privacy mechanism. To address this issue, this paper has presented an authentication and key exchange scheme. The proposed scheme establishes a session key after the mutual authentication, which ensures secure communication and prevents an attacker from accessing the transmitted information. The proposed scheme also renders the header verification or origin verification of the message simultaneously without using the IPSec protocol. The employed BAN logic analysis indicates that S6AE is logically complete. Moreover, the security verification using AVISPA illustrates that the proposed scheme is secure against various malicious attacks. Finally, the performance evaluation reveals that, as compared to eminent schemes, S6AE has less communication, computational handover, energy, and storage overheads. As a future work, S6AE can be extended to varying security levels using secure cryptographic algorithms.