Scrutinizing the Vulnerability of Ephemeral Diffie–Hellman over COSE (EDHOC) for IoT Environment Using Formal Approaches

Kim, Jiyoon; Duguma, Daniel Gerbi; Lee, Sangmin; Kim, Bonam; Lim, JaeDeok; You, Ilsun

doi:https://doi.org/10.1155/2021/7314508

Mobile Information Systems

On this page

Abstract Introduction Results and Discussion Conclusions Data Availability Conflicts of Interest Acknowledgments Supplementary Materials References Copyright Related Articles

Special Issue

Distributed Secure Computing for Smart Mobile IoT Networks 2021

View this Special Issue

Research Article | Open Access

Volume 2021 | Article ID 7314508 | https://doi.org/10.1155/2021/7314508

Scrutinizing the Vulnerability of Ephemeral Diffie–Hellman over COSE (EDHOC) for IoT Environment Using Formal Approaches

Jiyoon Kim,¹Daniel Gerbi Duguma,¹Sangmin Lee,¹Bonam Kim,¹JaeDeok Lim,²and Ilsun You¹

Academic Editor: Zengpeng Li

Received09 Jul 2021

Revised04 Aug 2021

Accepted16 Aug 2021

Published13 Sept 2021

Abstract

Most existing conventional security mechanisms are insufficient, mainly attributable to their requirements for heavy processing capacity, large protocol message size, and longer round trips, for resource-intensive devices operating in an Internet of Things (IoT) context. These devices necessitate efficient communication and security protocols that are cognizant of the severe resource restrictions regarding energy, computation, communication, and storage. To realize this, the IETF (Internet Engineering Task Force) is currently working towards standardizing an ephemeral key-based lightweight and authenticated key exchange protocol called EDHOC (Ephemeral Diffie–Hellman over COSE). The protocol’s primary purpose is to build an OSCORE (Object Security for Constrained RESTful Environments) security environment by supplying crucial security properties such as secure key exchange, mutual authentication, perfect forward secrecy, and identity protection. EDHOC will most likely dominate IoT security once it becomes a standard. It is, therefore, imperative to inspect the protocol for any security flaw. In this regard, two previous studies have shown different security vulnerabilities of the protocol using formal security verification methods. Yet, both missed the vital security flaws we found in this paper: resource exhaustion and privacy attacks. In finding these vulnerabilities, we leveraged BAN-Logic and AVISPA to formally verify both EDHOC protocol variants. Consequently, we described these security flaws together with the results of the related studies and put forward recommended solutions as part of our future work.

1. Introduction

IoT refers to a network environment in which all surrounding objects are connected to wired and wireless networks to interact and exchange information over the Internet. These objects (also referred to as “things”) can range from a simple soil moisture sensor in a field to a complex implanted device in a human body. With continuous developments in low-cost electronics (such as sensors), fast progress in mobile communication (especially with the introduction of 5G), and significant advances in data analytics (e.g., machine learning and lightweight deep learning), IoT has become one of the most demanded technologies in our time [1, 2]. Currently, IoT serves as an instrumental platform to host many applications in manufacturing, healthcare, energy, cities, and many more. In the next four years (by 2025) only, the total market share of IoT can stretch to reach up to 3 trillion USD [3], while the number of devices operating in an IoT environment can cross 42 billion with over 73 ZB of generated data [4].

Despite the vast expansion of IoT-enabled devices and their widespread applications, IoT still has several challenges that needs to be tackled. Some of the issues are tightly related to the severe computing resource constraints concerning storage, processing, and communication [5–7]. Such tight requirements call for efficient mechanisms to enable devices operating within IoT environments to function through unstable channels with constrained bandwidth and varying topology [8]. To realize these stringent conditions, essential protocols, such as [9–11], have been standardized by IETF. In addition, because IoT devices transport several sensitive information, security problems can threaten the inability to provide services and the user's personal information. Some potential security attacks are device software malfunction, prying, malevolent code infusions, device tampering, and unauthorized access [12]. Furthermore, studies such as [13, 14] investigated the security issues of integrating LPWAN in the 5G ecosystem, as well as the practical evaluation of compression and fragmentation of standard protocols as applied to IoTs in LPWAN, respectively. Hence, IoT devices require more capable security schemes that work in tandem with the communication protocols to mitigate these security attacks.

Even though IoT applications anticipate solid security assurance, securing IoT frameworks is challenging. It is mainly because of their intrinsic nature of resource constraint and absence of “security aware” design. Although there are various security solutions designed for conventional networks, such as IKEv2 [15], TLS [16], and DTLS [17], they are not suitable for the IoT environment due to their high degree of processing power and memory space. For instance, the footprint in bytes for a DTLS is six times heavier than the EDHOC + CoAP (Constrained Application Protocol) [8]. Fortunately, there are now efforts in designing standard security protocols mainly intended to serve in IoT environments. One such application layer security protocol is the OSCORE [18]. The protocol is efficient for severely constrained networks as it maintains the minor communication overhead possible. Using OSCORE, however, requires preshared keys to establish a security context. For this purpose, the IETF is in the process of standardizing an authenticated Diffie–Hellman key exchange protocol known as EDHOC [19]. The protocol is aforesaid to provide essential security properties such as mutual authentication, perfect forward secrecy, identity protection, and cipher suite negotiation.

EDHOC will most certainly dominate IoT security once it becomes a standard, which is why it is critical to analyse it for security vulnerabilities thoroughly. Since its inception in March 2016, it passed through 26 different versions, among which only two of its versions ([20] in 2018 and [21] in 2020) were formally analysed by [22, 23] using ProVerif [24] and Tamarin [25], respectively. While these studies bring numerous essential security issues to light, there are still security flaws that they have not yet discovered. Furthermore, evaluating security protocols using several formal approaches increases our confidence in the protocols’ resilience to various security threats since one can compensate for the weakness of the other. Accordingly, in this paper, we formally analysed both the symmetric and asymmetric variants of the EDHOC protocol by using BAN (Burrows, Abadi, and Needham)-Logic [26] and AVISPA (Automated Validation of Internet Security Protocols and Applications) [27] to uncover other security issues. The formal verification results indicate that the protocols suffer from resource exhaustion and privacy attacks. While the former vulnerability is related to a class of attacks known as (distributed) denial-of-service attacks, where excessive and unnecessary requests deplete a node’s resource, the latter pertains to privacy violations due to ID_PSK and ID_CRED_R (in symmetric and asymmetric variations, respectively). Both security issues are described in detail in Section 4 of the paper. The core contributions of this paper are summarized as follows:(i)We carried out a formal security verification of the asymmetric and symmetric variants of the EDHOC protocol using two formal approaches: BAN-Logic and AVISPA(ii)We pointed out two novel potential security vulnerabilities that may lead to resource exhaustion and privacy attacks(iii)We described a concise summary of the principal security threats found by former related studies together with those identified by us

The remainder of the paper is organized as follows. Section 2 describes the EDHOC protocol along with the related studies on its formal security analysis. The formal verification of the protocol and results, respectively, are presented in the subsequent two sections. Finally, Section 5 concludes the paper.

2. The EDHOC Protocol

2.1. Protocol Overview

The increasing usage of IoT devices in vertical applications, such as energy, smart factory, healthcare, and transportation, calls for more efficient approaches to power, communication, storage, and processing. Given their severe constraint concerning these requirements, it is not possible (or inefficient) to apply existing security protocols. The main reason is due to the heavy cryptography algorithms, message sizes, and total round trips involved with these schemes. Implementing security on the application layer of the IoT communication systems is especially beneficial when there is insufficient security at the transport layer or when considering the performance of the communication is required. To this point, there are fundamental advances in providing application-aware security solutions. Some of these schemes are the CoAP [9] and its lightweight extension to provide sufficient object security, OSCORE [18].

Another vital protocol that serves as a lightweight authenticated key exchange mechanism for OSCORE is the EDHOC. The EDHOC protocol provides session key establishment while supporting fundamental security properties like perfect forward secrecy and mutual authentication [19]. The protocol involves essential components like Elliptic Curve Diffie–Hellman (ECDH) for key exchange, CBOR (Concise Binary Object Representation) [10] for data encoding, COSE (CBOR Object Signing and Encryption) [28] for protecting the CBOR encoded messages, and CoAP for message transportation. In summary, the primary intent of EDHOC is to leverage the OSCORE initiated security so that the message footprints and the round trips are small. Figure 1 shows the IoT protocol stack with the EDHOC protocol located in the application layer.

2.2. Related Works

Formal security analysis of various authentication protocols has been performed to guarantee the resilience of different security schemes against numerous attacks. Concerning EDHOC, there are two significant studies that analysed the security of this protocol with a formal approach.

In [22], the authors formally analysed both symmetric-key and asymmetric-key options of the EDHOC protocol using ProVerif [24]. This research inspected the protocol against various security characteristics like identity protection against an active attacker, application data confidentiality and perfect forward secrecy, and robust authentication. Consequently, the authors highlighted the risk of leaking the responder’s identity, although the initiator’s identity is secured. Furthermore, by utilizing the same preshared key identifier ID_PSK, an attacker may link several sessions and launch various assaults to the symmetric variant of the protocol. Concerning the application data (AD₁ to AD₃), the authors also showed that only AD₃ (for both symmetric and asymmetric variants) satisfies secrecy, perfect forward secrecy, and integrity at both the time of message arrival and conclusion of the protocol.

Another paper [23] that analysed the EDHOC security using the Tamarin prover [25] verification tool found various improvement points. The authors, among other issues, identified the following flaws by the time they analysed the protocol: absence of nonrepudiation security property and lack of verification of ID_CRED_R of Msg2 by the initiator. The authors also showed that a security threat due to a prolonged metasession covering several sessions of the EDHOC protocol can happen when the responder rejects proposed cipher suites. The paper also recommended the use of a trusted execution environment (TEE) for security hardening.

2.3. Protocol Description

The initiator and responder of the EDHOC protocol can encrypt and protect the integrity of information communicated between them by following a similar construction as SIGMA-1 [29]. The initiator and responder exchange three messages to establish Diffie–Hellman’s shared secrets and perform encryption using Authenticated Encryption with Associated Data (AEAD) [30]. Unique to EDHOC, however, new parameters like connection identifiers, transcript hashes, methods, and others exist. Moreover, EDHOC protocol works in two modes: asymmetric-key-based authentication technique that provides mutual authenticity via Diffie–Hellman shared ciphers and symmetric-key-based authentication that relies on preshared symmetric keys. Table 1 shows the parameters used in the EDHOC protocol.

2.3.1. Asymmetric-Key-Based EDHOC Protocol

The execution steps of an EDHOC protocol that uses asymmetric-keys are shown in Figure 2. Furthermore, to better understand and visualize the operations of both variants of the EDHOC protocol, we presented a state diagram as shown in Figures 3 and 4 . Take note that the figures show one session connection between the initiator and the responder.

(1) Initiator ⟶ Responder. Before the commencement of the protocol, the initiator I stores the domain parameters for the agreed elliptic curve, ID_CRED_I, AD₁, and AD₂. Firstly, the caller generates a method that identifies the authentication method and the associated correlation (corr) of the transport mechanism. Here, “method” and “corr” take values from 0 to 3 as described in [19]. The initiator also chooses SUITES_I from the list of cipher suites that an EDHOC protocol recognizes and select the connection identifier C_I. It then picks a number x to serve as an ECDH private key. Once the preliminary information is ready, it computes the ECDH public key G_X (=G.x) and TYPE (=4 method + corr). Finally, it constructs and sends Msg₁ containing TYPE, SUITES_I, G_X, C_I, and AD₁ to the responder. Note that AD₁, at this time, cannot guarantee security as it is transmitted in plaintext.

(2) Responder ⟶ Initiator. Once it receives Msg1, the responder selects a cipher suite SUITES_R and the connection identifier C_R, and calculates the ECDH public key G^Y (=G.y) the same way the initiator calculated G^X. It then calculates the ECDH shared key G^XY (=G^X.y). Subsequently, the transcript hash TH₂ is computed by hashing the received message Msg1 and data₂, where data₂ consists of the session identifiers C_I, C_R, and the ECDH public G^Y. The responder uses TH₂ for authentication. It then computes an encryption key K₂ (HKDF (PRK, G^XY)) from the pseudorandom key PRK (HKDF (“0x,” G^XY)) and the transcript hash TH₂. Next, the responder constructs Msg2 by concatenating CIPHERTEXT₂ and data₂.

The former message is formed by first signing CRED_R and TH₂ with the responder’s private key, followed by encrypting the signature, ID_CRED_R, and AD₂ with K₂. The latter message is simply the concatenation of C_I, C_R, and G^Y. Finally, the responder sends Msg2 to the initiator.

(3) Initiator ⟶ Responder. When Msg2 reaches the initiator, it computes the ECDH shared key G^XY (=G^Y.x), PRK, TH₂, and K₂, like the responder. Then, it uses K₂ to decrypt CIPHERTEXT₂ and retrieve ID_CRED_I, the signature, and AD₂. It then validates the signature, and if the result succeeds, it generates TH₃ and K₃. The former is constructed by first hashing CIPHERTEXT₂ with TH₂ and then rehashing the result with C_R. The latter is computed by using HKDF (PRK, TH₃). Finally, the initiator constructs a message CIPHERTEXT₃ by signing CRED_I and TH₃ with its private key and encrypting it together with ID_CRED_R and AD₃ using the computed session key K₃; it forms Msg3 by concatenating C_R and CIPHERTEXT₃ and sends it to the responder. The asymmetric-key-based EDHOC protocol concludes by removing the Diffie–Hellman key pairs used to generate the encryption keys K₂ and K₃ to support perfect forward secrecy.

2.3.2. Symmetric-Key-Based EDHOC Protocol

The symmetric-key-based EDHOC protocol, shown in Figure 5, is very similar to the asymmetric-key-based protocol, with the following exceptions:(1)The public key identifiers ID_CRED_I and ID_CRED_R are not used as part of the authenticated encryption(2)Authentication happens via preshared key PSK (identified by ID_PSK) rather than the digital signatures used in the previous protocol(3)The protocol session keys K₂ and K₃ are derived based on Diffie–Hellman shared keys, transcript hashes, and preshared keys PSK

3. Formal Security Verification for EDHOC Protocol

This section describes the formal security verification of both variants of the EDHOC protocol. First, we leverage BAN-Logic to analyse any security flaw that may exist in the protocol. Next, to further strengthen the verification result and complement the weakness of the first approach, we will use the AVISPA tool.

3.1. BAN-Logic-Based Formal Verification

BAN-Logic is a modal logic of beliefs (proposed by Burrows, Abadi, and Needham) used to verify authentication protocols in a formal manner [26, 31]. The formal description of the authentication process, participants’ knowledge, and beliefs serve as a foundation for analysing the changes at each level of the protocol. BAN-Logic is the most utilized approach for examining various security protocols due to its simplicity and robustness.

Verification of security protocols using this method starts with converting the protocol into an idealized form through idealization. Here, only protected messages, traversing from one participant to another, are of interest. Then, realistic assumptions and security objectives that the protocol should guarantee proceed. Subsequently, the derivation of the security goals continues by applying different BAN-Logic rules, the premises, and the intermediate results of the derivation. Tables 2 and 3 describe the symbols and formulas used in the BAN-Logic formalization process, respectively.

3.1.1. The Asymmetric-Key Option

Idealization. An idealized version of the asymmetric form of the EDHOC protocol is shown below. Note that the idealized form only comprises encrypted (protected) communications, which is why Msg1 is left out.

Goals. The following objectives are established for verifying mutual authentication and key exchange between I and R. Consequently, while the goals in (5) and (6) show the beliefs I has on R’s trust concerning its credential identity and the associated data (respectively), (9) and (10) show the opposite. About key exchange, the goals in (3) and (4) show I’s belief on the session key, and (7) and (8) assert R’s belief on the same key.

Assumptions. There are some assumptions and hypotheses we need to set to derive the above goals. Accordingly, the assumptions in (11), (15), and (16) show R’s belief in its ECDH public key, the long-term public key of I, and the freshness of its ECDH public key. On the other hand, while (12) and (14) point out I’s belief in its ECDH public key and its freshness, (13) indicates the belief “I” has in R’s long-term public key. Finally, the two hypotheses (17) and (18) imply that R trusts that I sent its ECDH public key and vice versa, respectively.

Derivations. As a final step of the formal analysis, derivation of goals proceeds. To do so, we leverage the BAN-Logic rules (shown in Table 3), idealizations, assumptions, and the intermediate results of the derivation process. Therefore, if all goals can be derived, the target protocol is considered secure. Otherwise, the protocol may be vulnerable to threats.

Note that, without the two hypotheses in (17) and (18), this derivation should stop before (22). In other words, only if both hypotheses are true, the proposed protocol can achieve the goals in (3)∼(10). Unfortunately, they cannot hold because the two parties have no trust in each other’s ECDH public key. Therefore, we conclude that asymmetric-key option is not secure.

3.1.2. The Symmetric-Key Option

Idealization. The idealization forms of the symmetric-key option of EDHOC protocol are shown as follows:

Goals. In general, the goals involve the guarantee of secure key exchange and mutual authentication. In the former case, while (41) and (42) form the belief of I in the ECDH session key, (44) and (45) represent the same case for R. In the latter point, the goals in (43), (46), and (47) serve to verify the mutual authentication.

Assumptions. While the assumptions in (49) and (50) show I’s belief concerning its ECDH public key and its freshness (respectively), (48) and (51) do the same for R (respectively). Moreover, the symmetric-key option of the EDHOC protocol also requires the same additional hypotheses in (52) and (53) as the asymmetric-key option.

Derivations. The derivations of this variant of the EDHOC protocol proceed as follows:

Similar to the asymmetric-key option, the symmetric-key option can achieve the goals in (41)∼(47) in the case that the two hypotheses in (52) and (53) are true. Thus, the hypotheses, which cannot be proved to be true, show that this option fails to satisfy the goals in (41)∼(47). On the other hand, the last goal (47) indicating the privacy property cannot be achieved because is sent without being encrypted in the first message as shown in Figure 5.

To realize mutual authentication between “I” and “R,” the former must believe the latter’s ECDH public key, and it also must believe that the latter believes this key, and vice versa. That is, the derivations [(54), (55), (61), and (65)] of the asymmetric-key option and [(54), (55), (61), and (65)] of the symmetric-key option need to be satisfied. However, since all these derivations are entirely dependent on the fact that “I” (“R”) believes “R” (“I”) sent the ECDH public keys, it automatically follows that mutual authentication can only be fulfilled when these hypotheses are satisfied.

Messages Msg2 and Msg3, as illustrated in the idealizations in (39) and (40), use the ECDH session key to derive the AEAD encryption keys K₂ and K₃. Consequently, this can only happen through the hypotheses in (52) and (53) and is illustrated in derivations (59) and (64). Consequently, it is impossible to conclude that the session key is successfully communicated in the present asymmetric-key form of the protocol. Similarly, the symmetric version of the EDHOC protocol also fails to successfully exchange the session key without the hypotheses in (52) and (53). Thus, the derivations in (54) and (55) for “I” and “R” to believe the session key, respectively, require the use of the hypotheses.

Perfect forward secrecy is a characteristic of robust protocols because it protects previous sessions from future key compromise attempts. Accordingly, the asymmetric variant of the EDHOC protocol leverages the unique generation of ECDH private keys for each session of the protocol run to realize perfect forward secrecy. Likewise, in the symmetric-key option of the EDHOC protocol, the generation of the secret keys K₂ and K₃ uses the nonstatic Diffie–Hellman session key between “I” and “R.” Thus, the symmetric-key option of the EDHOC protocol also provides perfect forward secrecy.

For both symmetric and asymmetric alternatives of EDHOC protocol to provide confidentiality and integrity, secure session key exchange must be in place. However, “I” and “R” may fail to transfer this key securely, as described earlier. As a result, the protocol cannot guarantee both confidentiality and integrity security properties.

Finally, due to the absence of authentication for the initial message, the anonymity of the responder’s identifier for the public authentication keys (ID_CRED_R, for asymmetric-key option) and preshared key (ID_PSK, for the symmetric-key option) can be exposed.

Table 4 summarizes the result of the BAN-Logic derivation process for both options of the EDHOC protocol. As illustrated in the table and explanation above, both options of the protocol are insecure.

3.2. AVISPA-Based Formal Verification

AVISPA is an automation tool for modelling and analysing security protocols [27]. The description of the formal verification process using AVISPA proceeds as follows. First, we use a High-Level Protocol Specification Language (HLPSL) [32] to model the protocol. The HLPSL2IF component then converts the HLPSL-modelled protocols to Intermediate Format (IF). Finally, using the On-the-Fly Model-Checker (OFMC) [33], CL-based Attack Searcher (CL-AtSe) [34], SAT-based Model-Checker (SATMC) [35], and Tree-Automata-based Protocol Analyzer (TA4SP) [36], the IF is transformed to Output Format (OF). Figure 6 shows the general system architecture of the tool, highlighting the main processes from HLPSL to OF.

HLPSL is composed of different roles such as Basic Role, Session Role, and Environment Role:(i)Basic Role. This is a role that models protocol participants in a function with parameters. It consists of steps such as header expression, local variable declaration, and initialization. Additionally, it identifies communication modelling, which specifies the channel for communication between the modelled participants and indicates real-world protocol behaviour. It also defines, together with these parameters, transitions that denote message reception and the corresponding reply of the agent.(ii)Session Role. This function receives the agents and other parameters to activate the previous role. It is executed via a composition to instantiate the parts in a parallel manner. /\ represents such parallel execution of prior roles.(iii)Environment Role. It is a role that comprises global constants with the agents and sessions defined in the above two roles. In addition, it outlines an attacker’s knowledge of the protocol’s communication. The intruder’s knowledge concerning the execution of the protocol is also defined. Like the Session Role, parallel execution of sessions executes with the intruder’s information considered. Once the Environment Role completes, the security goals follow, and their verification proceeds with OFMC and CL-AtSe submodules.

3.2.1. The Asymmetric-Key Option

At first, the asymmetric-key option of EDHOC protocol is modelled in HLPSL code. The code specifies the initiator and the responder roles with their security goals, Session Role to activate the basic roles, and finally the Environment Role. The source code for the AVISPA verification for both asymmetric and symmetric variants can be found in the Supplementary Materials (available here), while the pseudocodes are presented in Figure 7 (for asymmetric variant) and Figure 8 (for symmetric variant). The obtained verification results for the asymmetric option based on OFMC module and CL-AtSe module are also shown in Figure 9. The attack simulation of the asymmetric-key option of EDHOC protocol is illustrated in Figure 10.

As shown in Figure 10, the attack simulation shows the asymmetric-key option of EDHOC protocol is vulnerable due to the fact that the message is sent without any verification of the sender. In other words, when the intruder sends the message of step 2, the responder should generate and calculate all the elements for communication without any proof to the user. It seems to be able to induce resource exhaustion attacks in R due to Msg2 created or modified by the attacker.

3.2.2. The Symmetric-Key Option

Like the previous case, once we translate the protocol into an HLPSL form, the AVISPA tool passes the code through the modules (such as CL-AtSe and OFMC) to check for any security flaws. Figure 11 presents the outcome of this process. According to the verification result, the symmetric-key option of the EDHOC protocol is unsafe. Figure 12 shows the possible attack simulation for the identified security flaw.

In Figure 12, when an intruder sends a message in step 2, the responder should create all the elements for communication without user authentication as Figure 10. This may deplete R’s resource due to responses to numerous authentication requests from unauthorized users.

4. Results and Discussion

The results of the formal security analysis of both variants of the EDHOC protocol show some security-related shortcomings. In this section, we discuss these flaws.

The complete security analysis of the asymmetric-key EDHOC protocol depends on the assumption that the responder trusts the ephemeral ECDH public key G^X is from the initiator. Furthermore, the initiator also must believe that the responder sends the ephemeral ECDH public key G^Y. As shown in the BAN-Logic analysis, the hypotheses in (17) and (18) represent these two claims, respectively. Without these assumptions, mainly hypothesis (17), it is impossible to derive the goals we set. Moreover, it is worth mentioning that both hypotheses are merely there to complete the proof. Hence, it is crucial to realize them to guarantee the evidence.

Similarly, the AVISPA results for both asymmetric and symmetric variants of the protocol also show that an attack can happen (Figures 10 and 12). The responder’s failure to ensure the integrity of Msg1 and the difficulty of the initiator in validating Msg2 are the significant reasons for this attack. Especially for the latter point, given that the generation of the secret key K₂ depends on the ECDH session key G^XY, the initiator has no option but to trust the responder’s ECDH public key G^Y transmitted in plaintext to verify Msg2.

Another critical security threat refers to the denial-of-service attacks (more specifically, the resource exhaustion attack). Given the IoT devices’ severe resource limitations concerning computation, storage, and communication, an attacker can send a significant amount of Msg1 to the responder. The responder then performs expensive operations such as encryption, signature, and key derivation functions for each of these messages before authenticating the initiator. Consequently, the responder can get easily overwhelmed by the traffic, deplete its energy, and finally cease communicating with the other end.

A second serious threat with the asymmetric-key-based EDHOC protocol, which we referred to as a partial privacy attack, is related to the privacy of ID_CRED_R. The access of the credentials containing the public authentication keys of both initiator and responder is via their identities. These identities (ID_CRED_I and ID_CRED_R), although they do not have any cryptographic purpose in the protocol, serve an essential purpose by facilitating the retrieval of the public authentication keys. Moreover, according to the standard, their privacy is protected by the session key computed by the initiator and responder. Thus, an attacker can easily break the privacy of ID_CRED_R as it can establish the session key K₂ with the responder. Therefore, it implies a privacy disclosure of one of the two identities, hence a partial privacy attack. Concerning the symmetric variant, a clear violation of privacy also happens as ID_PSK in Msg1 is transmitted in plain text.

It is important to note that if an attacker exploits these vulnerabilities, the results might be disastrous. For example, a medical IoT device attempting to obtain a remote service, perhaps for remote diagnostics, may fail owing to a resource depletion assault on the other end. Moreover, in cases where the responder is a sensitive medical IoT device, its identity (the identity of the credentials containing the public authentication keys) can be traced by an attacker that he/she may use to track and localize the patient eventually. Both resource exhaustion and privacy attacks (as part of transporting EDHOC via CoAP message exchanges) are shown in Figure 13. In addition, Table 5 summarizes the security issues identified by the related works together with the ones we identified.

It is critical to fix the highlighted security vulnerabilities before using EDHOC as a lightweight authenticated key exchange mechanism. Privacy-related threats are mainly initiated because the first message, from the initiator to the responder, is not authenticated. Hence, a preliminary authentication mechanism must be implemented. The responder and initiator can additionally guarantee the validity of Msg1 and Msg2 by using public-key certificates. In the case of a protracted metasession spanning several EDHOC sessions due to cipher suite rejection, the responder shall provide a mechanism that prevents the same initiator from resubmitting a new cipher suite proposal in the same session more than twice. Leveraging HMAC and timestamps can serve a good purpose in thwarting resource exhaustion attacks, as they let the responder first check the validity of the received message before performing computationally demanding instructions.

5. Conclusions

Although the rapid growth of the Internet of Things (IoT) technology is bringing a significant impact on society, efficient security protocols that are aware of the unique characteristics of IoT devices are still in their infant stage. With this regard, IETF is in progress to standardize one application layer protocol (known as EDHOC) that can assist secure communication across IoT devices while remaining lightweight. Consequently, in this paper, we formally analysed the security of this protocol using BAN-Logic and AVISPA to investigate its resilience to withstand attacks. The results show that both variants of the protocol have some serious security and privacy flaws. Primarily, a resource exhaustion attack that violates the availability of a responder’s service by depleting its resources over expensive cryptographic operations such as encryption and signature can result. Next, an attacker can easily break the privacy of ID_CRED_R as it can establish the session key K₂ with the responder, which results in partial privacy disclosure of the responder’s identity. A similar attack can happen when an attacker captures ID_PSK in the symmetric-key option of the protocol. Furthermore, an attacker can use the responder’s failure to verify the integrity of Msg1 and the difficulties of the initiator in validating Msg2. Finally, we recommend that the protocol should consider authenticating the first message and provide a way to validate the second message while offering a solution to protect against resource exhaustion attacks. In future works, the authors would like to develop efficient solutions to mitigate these attacks while maintaining the lightweight nature of the EDHOC protocol.

Data Availability

No data were used to support this study.

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.

Acknowledgments

This work was partly supported by the Institute of Information and Communications Technology Planning and Evaluation (IITP) grant funded by the Korea government (MSIT) (no. 2018-0-00231, Development of Context Adaptive Security Autonomous Enforcement Technology to Prevent Spread of the IoT Infrastructure Attacks, 95%) and the Soonchunhyang University Research Fund (5%).

Supplementary Materials

The AVISPA validation codes written in HLPSL for asymmetric and symmetric options are provided as separate files. (Supplementary Materials)

References

V. Korzhuk, A. Groznykh, A. Menshikov, and M. Strecker, “Identification of attacks against wireless sensor networks based on behavior analysis,” Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications, vol. 10, no. 2, pp. 1–21, 2019.
View at: Google Scholar
Z.-K. Zhang, M. C. Yi Cho, C.-W. Wang, C.-W. Hsu, C.-K. Chen, and S. Shieh, “IoT security: ongoing challenges and research opportunities,” in Proceedings of the 2014 IEEE 7th International Conference on IEEE, pp. 230–234, Matsue, Japan, November 2014.
View at: Publisher Site | Google Scholar
Machina Research, in Press Release: Global Internet of Things Market To Grow to 27 Billion Devices, Generating USD3 Trillion Revenue in 2025, Machina Research, Stamford, CT, USA, 2021, https://bit.ly/3aHu1QG.
IDC Corporate USA, IoT Growth Demands Rethink of Long-Term Storage Strategies, Says IDC, IDC Corporate USA, Needham, MA, USA, 2021, https://www.idc.com/getdoc.jsp?containerId=prAP46737220.
J. Kim, J. Lee, J. Kim, and J. Yun, “M2M service platforms: survey, issues, and enabling technologies,” IEEE Communications Surveys & Tutorials, vol. 16, no. 1, pp. 61–76, 2014.
View at: Publisher Site | Google Scholar
M. Alizadeh, K. Andersson, and O. Schelén, “A survey of secure Internet of things in relation to blockchain,” Journal of Internet Services and Information Security, vol. 10, no. 3, pp. 47–75, 2020.
View at: Google Scholar
Y. M. Khamayseh, W. Mardini, M. Aldwairi, and H. T. Mouftah, “On the optimality of route selection in grid wireless sensor networks: theory and applications,” Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications, vol. 11, no. 2, pp. 87–105, 2020.
View at: Google Scholar
B. Sim and D. Han, “A study on the side-channel analysis trends for application to IoT devices,” Journal of Internet Services and Information Security, vol. 10, no. 1, pp. 2–21, 2020.
View at: Google Scholar
Z. Shelby, K. Hartke, and C. Bormann, The Constrained Application Protocol (CoAP), IETF RFC 7252, Fremont, CA, USA, 2014, https://datatracker.ietf.org/doc/html/rfc7252.
C. Bormann and P. Hoffman, Concise Binary Object Representation (CBOR), IETF RFC 8949, Fremont, CA, USA, 2020, https://datatracker.ietf.org/doc/html/rfc8949.
A. Minaburo, L. Toutain, C. Gomez, D. Barthel, and JC. Zuniga, SCHC: Generic Framework for Static Context Header Compression and Fragmentation, IETF RFC 8724, Fremont, CA, USA, 2020, https://datatracker.ietf.org/doc/html/rfc8724.
T. Alladi, V. Chamola, B. Sikdar, and K.-K. R. Choo, “Consumer IoT: security vulnerability case studies and solutions,” IEEE Consumer Electronics Magazine, vol. 9, no. 2, pp. 17–25, 2020.
View at: Publisher Site | Google Scholar
J. Sanchez-Gomez, D. Garcia-Carrillo, R. Sanchez-Iborra et al., “Integrating LPWAN technologies in the 5G ecosystem: a survey on security challenges and solutions,” IEEE Access, vol. 8, 2020.
View at: Google Scholar
J. Sanchez-Gomez, J. Gallego-Madrid, R. Sanchez-Iborra, J. Santa, and A. Skarmeta, “Impact of SCHC compression and fragmentation in LPWAN: a case study with LoRaWAN,” Sensors, vol. 20, no. 1, p. 280, 2020.
View at: Publisher Site | Google Scholar
C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, Internet Key Exchange Protocol Version 2 (IKEv2), IETF RFC 7296, Fremont, CA, USA, 2014, https://datatracker.ietf.org/doc/html/rfc7296.
E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3, IETF RFC 8446, Fremont, CA, USA, 2018, https://datatracker.ietf.org/doc/html/rfc8446.
E. Rescorla, H. Tschofenig, and N. Modadugu, The Datagram Transport Layer Security (DTLS) Protocol Version 1.3, IETF Internet-Draft draft-ietf-tls-dtls13-43, Fremont, CA, USA, 2021, https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/.
G. Selander, J. Mattsson, F. Palombini, and L. Seitz, Object Security for Constrained RESTful Environments (OSCORE), IETF RFC 8613, Fremont, CA, USA, 2019, https://www.rfc-editor.org/rfc/rfc8613.html.
G. Selander, J. Mattsson, and F. Palombini, Ephemeral Diffie-Hellman over COSE (EDHOC), IETF Internet-Draft Draft-Ietf-Lake-Edhoc-07, Fremont, CA, USA, 2021, https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-07.
G. Selander, J. Mattsson, F. Palombini, and L. Seitz, Ephemeral Diffie-Hellman over COSE (EDHOC), IETF Internet-Draft Draft-Selander-ace-cose-ecdhe-08, Fremont, CA, USA, 2018, https://tools.ietf.org/pdf/draft-selander-ace-cose-ecdhe-08.pdf.
G. Selander, J. Mattsson, F. Palombini, and L. Seitz, Ephemeral Diffie-Hellman over COSE (EDHOC), IETF Internet-Draft Draft-Selander-Lake-Edhoc-01, Fremont, CA, USA, 2020, https://tools.ietf.org/pdf/draft-selander-lake-edhoc-01.pdf.
A. Bruni, T. S. Jørgensen, T. G. Petersen, and C. Schürmann, “Formal verification of ephemeral Diffie-Hellman over COSE (EDHOC),” in Proceedings of the 4th International Conference on Research in Security Standardisation, pp. 21–36, Darmstadt, Germany, November 2018.
View at: Google Scholar
K. Norrman, V. Sundararajan, and A. Bruni, “Formal analysis of EDHOC key establishment for constrained IoT devices,” 2020, https://arxiv.org/abs/2007.11427.
View at: Google Scholar
B. Blanchet, B. Smyth, V. Cheval, and M. Sylvestre, “Proverif 2.00: automatic cryptographic protocol verifier, user manual and tutorial,” 2018, https://bensmyth.com/publications/2010-ProVerif-manual-version-2.00.
View at: Google Scholar
S. Meier, B. Schmidt, C. Cremers, and D. Basin, “The TAMARIN prover for the symbolic analysis of security protocols,” Computer Aided Verification, vol. 8044, pp. 696–701, 2013.
View at: Publisher Site | Google Scholar
M. Burrows, M. Abadi, and R. Needham, “A logic of authentication,” ACM Transactions on Computer Systems, vol. 8, no. 1, pp. 18–36, 1990.
View at: Publisher Site | Google Scholar
A. Armando, D. Basin, Y. Boichut et al., “The AVISPA tool for the automated validation of Internet security protocols and applications,” Computer Aided Verification, vol. 3576, pp. 281–285, 2005.
View at: Publisher Site | Google Scholar
J. Schaad, “CBOR Object Signing and Encryption (COSE), IETF RFC 8152, Fremont, CA, USA, 2017, https://datatracker.ietf.org/doc/html/rfc8152 accessed on.
H. Krawczyk, “SIGMA: the “SIGn-and-MAc” approach to authenticated Diffie-Hellman and its use in the IKE protocols,” in Proceedings of the 23rd Annual International Cryptology Conference (CRYPTO’03), vol. 2729, pp. 400–425, Santa Barbara, CA, USA, August 2003.
View at: Publisher Site | Google Scholar
P. Rogaway, “Authenticated-encryption with associated-data,” in Proceedings of the 9th ACM Conference on Computer and Communication Security (CCS’02), pp. 98–107, ACM, Washington, DC, USA, November 2002.
View at: Publisher Site | Google Scholar
P. Syverson and I. Cervesato, “The logic of authentication protocols,” in Foundations of Security Analysis and Design, vol. 2171, pp. 63–137, Springer, Berlin, Germany, 2001.
View at: Publisher Site | Google Scholar
Y. Chevalier, L. Compagna, J. Cuellar et al., “A high level protocol specification language for industrial security-sensitive protocols,” in Proceedings of the 2004 Workshop on Specification and Automated Processing of Security Requirements (SAPS’04), Austrian Computer Society, Linz, Austria, September 2004.
View at: Google Scholar
D. Basin, S. Mödersheim, and L. Viganò, “OFMC: a symbolic model checker for security protocols,” International Journal of Information Security, vol. 4, no. 3, pp. 181–208, 2005.
View at: Publisher Site | Google Scholar
M. Turuani, “The CL-atse protocol analyser,” in Lecture Notes in Computer Science, vol. 4098, pp. 277–286, Springer, Berlin, Germany, 2006.
View at: Publisher Site | Google Scholar
A. Armando and L. Compagna, “SATMC: a SAT-based model checker for security protocols,” in Logics in Artificial Intelligence, vol. 3229, pp. 730–733, Springer, Berlin, Germany, 2004.
View at: Publisher Site | Google Scholar
Y. Boichut, P.-C. Héam, O. Kouchnarenko, and F. Oehl, “Improvements on the genet and Klay technique to automatically verify security protocols,” in Proceedings of the 3rd International Workshop on Automated Verification of Infinite State Systems (AVIS’04), pp. 1–11, Barcelona, Spain, April 2004.
View at: Google Scholar

Copyright

Copyright © 2021 Jiyoon Kim et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

PDF Download Citation

Download other formats

Order printed copies

Views

751

Downloads

576

Citations