Formal Analysis of EDHOC Key Establishment for Constrained IoT

Devices

Karl Norrman

1, 2 a

, Vaishnavi Sundararajan

and Alessandro Bruni

KTH Royal Institute of Technology, Stockholm, Sweden

Ericsson Research, Security, Stockholm, Sweden

University of California Santa Cruz, U.S.A.

IT University of Copenhagen, Copenhagen, Denmark

Keywords:

Formal Veriﬁcation, Symbolic Dolev-Yao Model, Authenticated Key Establishment, Protocols, IoT.

Abstract:

Constrained IoT devices are becoming ubiquitous in society and there is a need for secure communication

protocols that respect the constraints under which these devices operate. EDHOC is an authenticated key

establishment protocol for constrained IoT devices, currently being standardized by the Internet Engineering

Task Force (IETF). A rudimentary version of EDHOC with only two key establishment methods was formally

analyzed in 2018. Since then, the protocol has evolved signiﬁcantly and several new key establishment meth-

ods have been added. In this paper, we present a formal analysis of all EDHOC methods in an enhanced

symbolic Dolev-Yao model using the Tamarin tool. We show that not all methods satisfy the authentication

notion injective of agreement, but that they all do satisfy a notion of implicit authentication, as well as Per-

fect Forward Secrecy (PFS) of the session key material. We identify other weaknesses to which we propose

improvements. For example, a party may intend to establish a session key with a certain peer, but end up

establishing it with another, trusted but compromised, peer. We communicated our ﬁndings and proposals to

the IETF, which has incorporated some of these in newer versions of the standard.

1 INTRODUCTION

As IoT devices become more prevalent and get in-

volved in progressively sensitive functions in soci-

ety, the need to secure their communications be-

comes increasingly important. Most security anal-

ysis has focused on computationally strong devices,

such as cars and web-cameras, where existing pro-

tocols like (D)TLS sufﬁce. Constrained devices, on

the other hand, which operate under severe band-

width and energy consumption restrictions, have re-

ceived much less attention. These devices may be

simple sensors, which only relay environment mea-

surements to a server every hour, but need to function

autonomously without maintenance for long periods

of time. The IETF standardized the Object Security

for Constrained RESTful Environments (OSCORE)

protocol to secure communications between con-

strained devices (Selander et al., 2019). However,

the OSCORE protocol requires a pre-established se-

curity context. The IETF has been discussing re-

https://orcid.org/0000-0003-0164-1478

quirements and mechanisms for a key exchange pro-

tocol, named Ephemeral Difﬁe-Hellman Over COSE

(EDHOC), for establishing OSCORE security con-

texts. Naturally, EDHOC must work under the same

constrained requirements as OSCORE itself. While

not all use cases for EDHOC are ﬁrmly set, the overall

goal is to establish an OSCORE security context, un-

der message size limitations. It is therefore important

to ensure that EDHOC satisﬁes fundamental security

properties expected from a key exchange protocol.

The ﬁrst incarnation of EDHOC appeared in

March 2016. It contained two different key estab-

lishment methods, one based on a pre-shared Difﬁe-

Hellman (DH) cryptographic core

and a second

based on a variant of challenge-response signatures

in the style of OPTLS (Krawczyk and Wee, 2016).

EDHOC is therefore a framework of several key es-

tablishment methods. In May 2018, the core based

By a cryptographic core, or simply core, we mean an

academic protocol, without encodings or application spe-

ciﬁc details required by an industrial protocol. A key estab-

lishment method is a core with some such details added.

210

Norrman, K., Sundararajan, V. and Bruni, A.

Formal Analysis of EDHOC Key Establishment for Constrained IoT Devices.

DOI: 10.5220/0010554002100221

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 210-221

ISBN: 978-989-758-524-1

on challenge-response signatures was replaced by

one based on SIGMA (SIGn-and-MAc) (Krawczyk,

2003; Selander et al., 2018). Since then the proto-

col has undergone signiﬁcant changes. Three new

cores, mixing challenge-response signatures and reg-

ular signatures for authentication, were added (Se-

lander et al., 2020).

We formulate and formalize a security model cov-

ering all four key establishment methods, which is

important especially since the speciﬁcation (Selander

et al., 2020) lacks a clear description of the intended

security model and overall security goals.

We perform the analysis in a symbolic Dolev-Yao

model. In this framework, we model messages as

terms in an algebra, with operations such as encryp-

tion modelled as functions on these terms. These

functions are assumed perfect, e.g., one cannot de-

crypt an encrypted message without access to the key.

The adversary, while unable to break encryption or

reverse hashing, is modelled as the network. That is,

the adversary, can block reroute, replay and modify

messages at will. A symbolic model like this, while

slightly severe an abstraction, still allows us to ana-

lyze EDHOC for logical ﬂaws without incurring the

complexity of a computational model. The standard-

ization process is ongoing, with the authors releasing

newer versions of the speciﬁcation (see Section 5 for

more detail about how these versions differ from the

one analyzed here).

1.1 Contributions

In this paper, we formally analyze the EDHOC pro-

tocol (with its four key establishment methods) using

the Tamarin tool (Meier et al., 2013). We present a

formal model we constructed of the protocol as given

in the speciﬁcation (Selander et al., 2020).

We give an explicit adversary model for the proto-

col and verify properties such as session key material

and entity authentication, and perfect forward secrecy,

for all four methods.

The model itself is valuable as a basis for verifying

further updates in the ongoing standardization. It is

publicly available (Norrman et al., 2020). It took sev-

eral person-months to interpret the speciﬁcation and

construct the model. Termination requires a hand-

crafted proof oracle to guide Tamarin.

We show that not all EDHOC’s key establishment

methods provide authentication according to the in-

jective agreement deﬁnition on the session key ma-

terial, and none on the initiator’s identity. However,

we show that all methods fulﬁll an implicit agreement

property covering the session key material and the ini-

tiator’s identity. We identify a number of subtleties,

ambiguities and weaknesses in the speciﬁcation. For

example, the authentication policy requirements al-

low situations where a party establishes session key

material with a trusted but compromised peer, even

though the intention was to establish it with a differ-

ent trusted party. We provide remedies for the identi-

ﬁed issues and have communicated these to the IETF

and the speciﬁcation authors, who have incorporated

some of our suggestions and are currently considering

how to deal with the remaining ones.

1.2 Comparison with Related Work

The May 2018 version of EDHOC was formally an-

alyzed by (Bruni et al., 2018) using the ProVerif

tool (Blanchet, 2001). Their analysis covered a

pre-shared key authenticated core and one based on

SIGMA. The properties checked for therein were se-

crecy, PFS and integrity of application data, identity

protection against an active adversary, and strong au-

thentication.

In contrast to the key establishment methods ana-

lyzed by Bruni et al., which were based on the well-

understood pre-shared key DH and SIGMA protocols,

the three newly added methods combine two unilat-

eral authentication protocols with the goal to con-

structing mutual authentication protocols. Combin-

ing two protocols, which individually provide uni-

lateral authentication, is not guaranteed to result in

a secure mutual authentication protocol (Krawczyk,

2016). Consequently, even though the framework is

similar to the one analyzed by Bruni et al., the cryp-

tographic underpinnings have signiﬁcantly increased

in complexity, and is using mechanisms which have

not previously been formally analyzed. The set of

properties we check for is also different. Our analy-

sis is further carried out using a different tool, namely

Tamarin; different kinds of strategies to formulate and

successfully analyze the protocol are required when

working with this tool.

2 THE EDHOC PROTOCOL

We now present the structure of the protocol using

notation for key material, elliptic curve operations

and identities mostly adopted from NIST SP 800-56A

Rev. 3 (Barker et al., 2018). One notable difference is

that we refer to the two roles executing the protocol as

the initiator I and the responder R. We do this to avoid

confusing roles with the parties taking them on. Val-

ues in the analysis are subscripted with I and R when

necessary to distinguish which role is associated with

the values.

Formal Analysis of EDHOC Key Establishment for Constrained IoT Devices

211

2.1 Preliminaries

Private/public key pairs are written hd

t,id

, Q

t,id

where d is the private key, Q the public key, t ∈ {e, s}

denotes whether the key is ephemeral or static, and id

is the role or party controlling the key pair. When

irrelevant, we drop the subscript or parts thereof.

Ephemeral key pairs are generated fresh for each in-

stantiation of the protocol and static key pairs are

long-term keys used for authentication. Static key

pairs are suitable for either regular signatures or

challenge-response signatures. When a party uses

regular signatures for authentication, we say that they

use the signature based authentication method, or SIG

for short. When a party uses challenge-response sig-

natures for authentication, we say that they use the

static key authentication method, or STAT for short.

The latter naming may appear confusing since signa-

ture keys are equally static, but is chosen to make the

connection to the speciﬁcation clear. We adopt the

challenge-response terminology for this style of au-

thentication from (Krawczyk, 2005).

EDHOC relies on COSE (Schaad, 2017) for el-

liptic curve operations and transforming points into

bitstrings, and we therefore abstract those as follows.

Signatures and veriﬁcation thereof using party A’s key

pair are denoted by sign

(·) and vf

(·) respectively.

The DH-primitive combining a private key d and a

point P is denoted by dh(d, P). We abuse notation

and let these function symbols denote operations on

both points and the corresponding bitstrings.

2.2 Framework Structure

EDHOC’s goal is to establish an OSCORE security

context, including session key material denoted Z,

and optionally transfer application data ad

, ad

and

. To accomplish this, the speciﬁcation (Selander

et al., 2020) gives a three-message protocol pattern,

shown in Figure 1. We ﬁrst describe this pattern and

the parts that are common to all key establishment

methods. Then we describe authentication and deriva-

tion of keys in more detail. The latter is what differen-

tiate the key establishment methods from each other.

2.2.1 Protocol Pattern

The ﬁrst two messages negotiate authentication meth-

ods M and a ciphersuite S

. In M, the initiator I pro-

poses which authentication method each party should

use. These may differ, leading to four possible com-

binations: SIG-SIG, SIG-STAT, STAT-SIG and STAT-

STAT. We refer to these combinations of authenti-

cation methods simply as methods to align with the

speciﬁcation terminology. The ﬁrst authentication

method in a combination is the one proposed for the

initiator and the last is the one proposed for the re-

sponder. The responder R may reject the choice of

method or cipher suite with an error message, result-

ing in negotiation across multiple EDHOC sessions.

Our analysis excludes error messages.

EDHOC’s ﬁrst two messages also exchange con-

nection identiﬁers C

and C

, and public ephemeral

keys, Q

e,I

and Q

e,R

. The connection identiﬁers C

and

, described in Section 3.1 of the speciﬁcation, de-

serve some elaboration. The speciﬁcation describes

these identiﬁers not as serving a security purpose for

EDHOC, but only as aiding message routing to the

correct EDHOC processing entity at a party. Despite

this, the speciﬁcation states that they may be used

by OSCORE, or other protocols using the established

security context, without restricting how they are to

be used. Because EDHOC may need them in clear-

text for routing, OSCORE cannot rely on them be-

ing secret. Section 7.1.1 of the speciﬁcation requires

the identiﬁers to be unique. Uniqueness is deﬁned

to mean that C

6= C

for a given session and the

speciﬁcation requires parties to verify that this is the

case. The same section also require that OSCORE

must be able to retrieve the security context based on

these identiﬁers. The intended usage of C

and C

OSCORE is not made speciﬁc and therefore it is not

clear which properties should be veriﬁed. We verify

that the parties agree on the established values.

The two last messages provide identiﬁcation and

authentication. Parties exchange identiﬁers for their

long-term keys, ID

and ID

, as well as informa-

tion elements, Auth

and Auth

, to authenticate that

the parties control the corresponding long-term keys.

The content of Auth

and Auth

depends on the au-

thentication method associated with the correspond-

ing long-term key. For example, if M = SIG-STAT,

the responder R must either reject the offer or provide

an ID

corresponding to a key pair hd

s,R

, Q

s,R

i suit-

able for use with challenge-response signatures, and

compute Auth

based on the static key authentication

method STAT. In turn, the initiator I must provide an

corresponding to a key pair hd

s,I

, Q

s,I

i suitable

for a regular signature, and compute Auth

based on

the signature based authentication method SIG.

2.2.2 Authentication

Regardless of whether STAT or SIG is used to com-

pute Auth

, a MAC is ﬁrst computed over ID

, Q

s,R

a transcript hash of the information exchanged so

far, and ad

if included. The MAC is the result of

encrypting the empty string with the Authenticated

Encryption with Additional Data (AEAD) algorithm

from the ciphersuite S

, using the mentioned infor-

SECRYPT 2021 - 18th International Conference on Security and Cryptography

212

mation as additional data. The MAC key is derived

from the ephemeral key material Q

e,I

, Q

e,R

, d

e,I

and

e,R

, where I computes dh(d

e,I

, Q

e,R

) and R computes

dh(d

e,R

, Q

e,I

), both resulting in the same output in the

usual DH way.

In case R uses the SIG authentication method,

Auth

is R’s signature over the MAC itself and

the data that the MAC already covers. In case R

uses the STAT authentication method, Auth

is sim-

ply the MAC itself. However, when using STAT,

the key for the MAC is derived, not only from the

ephemeral key material, but also from R’s long-term

key hd

s,R

, Q

s,R

i. For those familiar with OPTLS, this

corresponds to the 1-RTT semi-static pattern comput-

ing the MAC key sfk for the sﬁn message (Krawczyk

and Wee, 2016). The content of Auth

is computed

in the corresponding way for the initiator I. In Fig-

ure 1, we denote a MAC using a key derived from

both hd

s,R

, Q

s,R

i and hd

e,I

, Q

e,I

i by MAC

, and a

MAC using a key derived from both hd

s,I

, Q

s,I

i and

e,R

, Q

e,R

i by MAC

Parts of the last two messages are encrypted and

integrity protected, as indicated in 1. The second mes-

sage is encrypted by XORing the output of the key

derivation function HKDF (see Section 2.2.3) on to

the plain text. The third message is encrypted and in-

tegrity protected by the AEAD algorithm determined

by the ciphersuite S

Initiator

Responder

: M, S

, Q

e,I

, C

, ad

: C

, Q

e,R

, C

, {ID

, Auth

, ad

}

: C

, {ID

, Auth

, ad

}

M Auth

Auth

SIG-SIG sign

(·) sign

(·)

SIG-STAT sign

(·) MAC

(·)

STAT-SIG MAC

(·) sign

(·)

STAT-STAT MAC

(·) MAC

(·)

Figure 1: Structure of EDHOC: {t} means t is encrypted

and integrity protected.

2.2.3 Key Schedule

At the heart of EDHOC is the key schedule depicted

in Figure 2. EDHOC uses two functions from the

HKDF interface (Krawczyk and Eronen, 2010) to de-

rive keys. HKDF-extract constructs uniformly dis-

tributed key material from random input and a salt,

while HKDF-expand generates keys from key mate-

rial and a salt.

The key schedule is rooted in the ephemeral DH

key P

, which is computed as dh(d

e,I

, Q

e,R

) by I and as

dh(d

e,R

, Q

e,I

) by R. From P

, three intermediate keys

PRK

, PRK

3e2m

and PRK

4x3m

are derived during the

course of protocol execution. Each of them is used

for a speciﬁc message in the protocol, and from these

intermediate keys, encryption and integrity keys (K

, K

3ae

, and K

) for that message are derived. The

salt for generating PRK

is the empty string.

The protocol uses a running transcript hash th,

which includes the information transmitted so far.

The value of the hash, denoted th

for the ith message,

is included in key derivations as shown in Figure 2.

Successful protocol execution establishes the ses-

sion key material Z for OSCORE. Z can be con-

sidered a set that always includes P

. If the ini-

tiator uses the STAT authentication method, Z also

includes dh(d

e,R

, Q

s,I

) = dh(d

s,I

, Q

e,R

), which we

denote by P

. If the responder uses the STAT au-

thentication method, it also includes dh(d

e,I

, Q

s,R

) =

dh(d

s,R

, Q

e,I

), which we denote by P

. From the ses-

sion key material, a key exporter (EDHOC-Exporter)

based on HKDF is used to extract keys required for

OSCORE.

As an illustrative example of the entire process,

we refer to Figure 3, which depicts the protocol pat-

tern, operations and key derivations for the SIG-STAT

method in more detail.

3 FORMALIZATION AND

RESULTS

The EDHOC speciﬁcation (Selander et al., 2020)

claims that EDHOC satisﬁes many security proper-

ties, but these are imprecisely expressed and moti-

vated. In particular, there is no coherent adversary

model. It is therefore not clear in which context prop-

erties should be veriﬁed. We resolve this by clearly

specifying an adversary model, in which we can ver-

ify properties.

3.1 Adversary Model

We verify EDHOC in the symbolic Dolev-Yao model,

with idealized cryptographic primitives, e.g, en-

crypted messages can only be decrypted using the

key, no hash collisions exist etc. The adversary con-

trols the communication channel, and can interact

with an unbounded number of sessions of the proto-

col, dropping, injecting and modifying messages to

their liking.

In addition to the basic Dolev-Yao model, we

also consider two more adversary capabilities, namely

long-term key reveal and ephemeral key reveal. Long-

term key reveal models the adversary compromising a

Formal Analysis of EDHOC Key Establishment for Constrained IoT Devices

213

PRK

R uses STAT?

PRK

3e2m

I uses STAT?

PRK

4x3m

HKDF-extract

HKDF-expand

HKDF-expandEDHOC-Exporter

HKDF-expand

3ae

Enc (XOR)

in m2

MAC

(signed if

R uses SIG)

AEAD in m3

MAC

(signed if

I uses SIG)

HKDF-extract

Salt

Figure 2: Key schedule: Light blue boxes hold DH keys (P

, P

), orange boxes intermediate key material (PRK

PRK

3e2m

, PRK

4x3m

), and dark blue boxes keys for AEAD or XOR encryption (K

, K

3ae

, K

). Dashed boxes are

conditionals.

party A’s long-term private key d

s,A

at time t, and we

denote this event by A

LTK

(A). The event A

Eph

(A, k)

represents that the adversary learns the ephemeral pri-

vate key d

e,A

used by party A at time t in a session

establishing key material k. These two capabilities

model the possibility to store and operate on long-

term keys in a secure module, whereas ephemeral

keys may be stored in a less secure part of a device.

This is more granular and realistic than assuming that

the adversary has equal opportunity to access both

types of keys.

We now deﬁne and formalize the security proper-

ties we are interested in, and then describe how we

encode them into Tamarin. The adversary model be-

comes part of the security properties themselves.

3.2 Formalization of Properties

We use the Tamarin veriﬁcation tool (Meier et al.,

2013) to encode the model and verify properties. This

tool uses a fragment of temporal ﬁrst order logic to

reason about events and knowledge of the parties and

of the adversary. For conciseness we use a slightly

different syntax than that used by Tamarin, but which

has a direct mapping to Tamarin’s logic.

Event types are predicates over global states of

system execution. Let E be an event type and let t be

a timestamp associated with a point in a trace. Then

)

i∈N

denotes an event of type E associated with a

sequence of parameters (p

)

i∈N

at time t in that trace.

In general, more than one event may have the same

timestamp and hence timestamps form a quasi order,

which we denote by t

l t

when t

is before t

in a

trace. We deﬁne

= analogously. However, two events

of the same type cannot have the same timestamp, so

= t

implies E

= E

. Two events having the same

timestamp does not imply the there is a fork in the

trace, only that the two events happen simultaneously.

This notation corresponds to Tamarin’s use of action

facts E(p

)

i∈N

@t.

The event K

(p) denotes that the adversary knows

a parameter p at time t. Parameters are terms in a term

algebra of protocol speciﬁc operations and generic

operations, e.g., tuples h·i. Intuitively, K

(p) eval-

uates to true when p is in the closure of the parame-

ters the adversary observed by interacting with parties

using the protocol, under the Dolev-Yao message de-

duction operations and the advanced adversary capa-

bilities up until time t. For a more precise deﬁnition

of knowledge management, we refer to (Meier et al.,

2013). An example of a formula is

∀t, k, k

. K

(hk, k

i) → K

(k) ∧ K

expressing that if there is a time t when the adversary

knows the tuple hk, k

i, then the adversary knows both

k and k

at the same point in time.

An initiator I considers the protocol run started

when it sends a message m

(event type I

) and the

run completed after sending a message m

(event type

). Similarly, a responder R considers the run started

upon receiving a m

(event type R

), and completed

upon receiving a m

(event type R

3.2.1 Perfect Forward Secrecy (PFS)

Informally, PFS captures the idea that session key ma-

terial remains secret even if a long-term key leaks in

the future. We deﬁne PFS for session key material Z

as PFS in Figure 4.

The ﬁrst parameter I of the I

event represents the

initiator’s identity, and the second, R, represents that

I believes R to be playing the responder role. The

third parameter, Z, is the established session key ma-

terial. The parameters of the R

event are deﬁned

analogously. Speciﬁcally, the ﬁrst parameter of R

represents the identity of whom R believes is playing

SECRYPT 2021 - 18th International Conference on Security and Cryptography

214

Initiator

Knows hd

s,I

, Q

s,I

i, ID

, ID

, ad

Responder

Knows hd

s,R

, Q

s,R

i, ID

, ad

Generates M, S

, C

, hd

e,I

, Q

e,I

: M, S

, Q

e,I

, C

, ad

Generates C

, hd

e,R

, Q

e,R

= dh(d

e,R

, Q

e,I

)

= dh(d

s,R

, Q

e,I

)

= h(m

, hC

, Q

e,R

, C

PRK

= HKDF-extract(“”, P

)

PRK

3e2m

= HKDF-extract(PRK

, P

)

= HKDF-expand(PRK

3e2m

, th

)

MAC

= AEAD(K

;hID

, th

, Q

s,R

, ad

i;“”)

= HKDF-expand(PRK

, th

)

: C

, Q

e,R

, C

CIPHERTEXT 2

z }| {

XOR hID

, MAC

, ad

= dh(d

e,I

, Q

e,R

)

PRK

= HKDF-extract(“”, P

)

= dh(d

e,I

, Q

s,R

)

PRK

4x3m

= PRK

3e2m

= HKDF-extract(PRK

, P

)

3ae

= HKDF-expand(PRK

3e2m

, th

)

= h(th

, CIPHERTEXT 2, C

)

= HKDF-expand(PRK

4x3m

, th

)

MAC

= AEAD(K

;hID

, th

, Q

s,I

, ad

i;“”)

Sig

= sign

(hhID

, th

, Q

s,I

, ad

i, MAC

: C

, AEAD(K

3ae

;th

;hID

, Sig

, ad

= h(th

, CIPHERTEXT 2, C

)

= HKDF-expand(PRK

3e2m

, th

)

3ae

= HKDF-expand(PRK

3e2m

, th

)

Figure 3: The SIG-STAT method. Tuples are denoted h·i, and the hash function h is as determined by S

the initiator role. The essence of the deﬁnition is that

an adversary only knows Z if they compromised one

of the parties long-term keys before that party com-

pleted the run, or if the adversary compromised any

of the ephemeral keys at any time after a party starts

its protocol run. One way the deﬁnition slightly dif-

fers from the corresponding Tamarin lemma is that

Tamarin does not allow a disjunction on the left-hand

side of an implication in a universally quantiﬁed for-

mula. In the lemma, therefore, instead of the disjunc-

tion I

(I, R, Z) ∨ R

(I, R, Z), we use a single action

parametrized by I, R, and Z to signify that either party

has completed their role.

3.2.2 Authentication

We prove two different ﬂavors of authentication, the

ﬁrst being classical injective agreement following

Lowe (Lowe, 1997), and the second being an implicit

agreement property. Informally, injective agreement

guarantees to an initiator I that whenever I completes

a run ostensibly with a responder R, then R has been

engaged in the protocol as a responder, and this run

of I corresponds to a unique run of R. In addition, the

property guarantees to I that the two parties agree on a

set S of parameters associated with the run, including,

in particular, the session key material Z. However, we

will treat Z separately for clarity. On completion, I

knows that R has access to the session key material.

The corresponding property for R is analogous.

Traditionally, the event types used to describe in-

jective agreement are called Running and Commit, but

to harmonize the presentations of authentication and

PFS in this section, we refer to these event types as I

and I

respectively for the initiator, and R

and R

for the responder. For the initiator role we deﬁne in-

jective agreement as given by InjAgree

in Figure 4.

The property captures that for an initiator I, either

the injective agreement property as described above

holds, or the long-term key of the believed responder

R has been compromised before I completed its role.

Had the adversary compromised R’s long-term key,

they could have generated a message of their liking

(different from what R agreed on) and signed this or

computed a MAC

based on Q

e,I

, d

s,R

and their own

chosen ephemeral key pair hd

e,R

, Q

e,R

i. This places

no restrictions on the ephemeral key reveals, or on the

reveal of the initiator’s long-term key. For the respon-

der we deﬁne the property InjAgree

as in Figure 4.

Unlike PFS, not all EDHOC methods enjoy the

injective agreement property. Hence, we show for all

methods a form of implicit agreement on all the pa-

rameters mentioned above. We take inspiration from

Formal Analysis of EDHOC Key Establishment for Constrained IoT Devices

215

PFS , ∀I, R, Z, t

, t

. K

(Z) ∧ (I

(I, R, Z) ∨ R

(I, R, Z)) →

(∃t

. A

LTK

(I) ∧t

l t

) ∨ (∃t

. A

LTK

(R) ∧t

l t

) ∨ (∃t

. A

Eph

(R, Z)) ∨ (∃t

. A

Eph

(I, Z))

InjAgree

, ∀I, R, Z, S, t

. I

(I, R, Z, S) →

(∃t

. R

(R, Z, S) ∧ t

l t

) ∧ (∀I

. I

, R

, Z, S) → t

= t

) ∨ (∃t

. A

LTK

(R) ∧t

l t

)

InjAgree

, ∀I, R, Z, S, t

. R

(I, R, Z, S) →

(∃t

. I

(I, R, Z, S)∧ t

l t

) ∧ (∀I

. R

, R

, Z, S) → t

= t

) ∨ (∃t

. A

LTK

(I) ∧t

l t

ImpAgree

, ∀I, R, Z, S, t

. I

(I, R, Z, S) →

(∀I

, R

, S

, t

. R

, R

, Z, S

) → (I = I

∧ R = R

∧ S = S

))

∧ (∀I

, R

, S

, t

.(I

, R

, Z, S

) → t

= t

)

∨ (∃t

. A

LTK

(R) ∧t

l t

) ∨ (∃t

. A

Eph

(R, Z)) ∨ (∃t

. A

Eph

(I, Z)).

Figure 4: Formalization of security properties and adversary model.

the computational model deﬁnitions of implicit au-

thentication, proposed by (Delpech de Saint Guilhem

et al., 2020), to modify classical injective agreement

into an implicit property. A small but important dif-

ference between our deﬁnition and theirs, is that they

focus on authenticating a key and related identities,

whereas we extend the more general concept of agree-

ing on a set of parameters, starting from the idea of

injective agreement (Lowe, 1997). We use the term

implicit in this context to denote that a party A as-

sumes that any other party B who knows the session

key material Z must be the intended party, and that

B (if honest) will also agree on a set S of parame-

ters computed by the protocol, one of which is Z.

When implicit agreement holds for both roles, upon

completion, A is guaranteed that A has been or is en-

gaged in exactly one protocol run with B in the oppo-

site role, and that B has been or will be able to agree

on S . The main difference from injective agreement

is that A concludes that if A sends the last message

and this reaches B, then A and B have agreed on I,

R and S. While almost full explicit key authentica-

tion, as deﬁned by (Delpech de Saint Guilhem et al.,

2020), is a similar property, our deﬁnition does not

require key conﬁrmation, so our deﬁnition is closer

to their deﬁnition of implicit authentication. In the

Tamarin model we split the property into one lemma

for I (ImpAgree

) and one for R (ImpAgree

) to save

memory during veriﬁcation. We show only the deﬁ-

nition for I in Figure 4, because it is symmetric to the

one for R.

For implicit agreement to hold for the initiator I,

the ephemeral keys can never be revealed. Intuitively,

the reason for this is that the implicit agreement relies

on that whomever knows the session key material is

the intended responder. An adversary with access to

the ephemeral keys and the public keys of both parties

can compute the session key material produced by all

methods. However, the responder R’s long-term key

can be revealed after I completes its run, because the

adversary is still unable to compute P

. The initiator’s

long-term key can also be revealed at any time with-

out affecting I ’s guarantee for the same reason.

3.2.3 Agreed Parameters

The initiator I gets injective and implicit agreement

guarantees on the following partial set S

of parame-

ters:

• the roles played by itself and its peer,

• responder identity,

• session key material (which varies depending on

EDHOC method),

• context identiﬁers C

and C

, and

• cipher suites S

Because EDHOC aims to provide identity protection

for I, there is no injective agreement guarantee for I

that R agrees on the initiator’s identity. For the same

reason, there is no such guarantee for I with respect

to the P

part of the session key material when I uses

the STAT authentication method. There is, however,

an implicit agreement guarantee for I that R agrees on

I’s identity and the full session key material. Since

R completes after I, R can get injective agreement

guarantees on more parameters, namely also the ini-

tiator’s identity and the full session key material for

SECRYPT 2021 - 18th International Conference on Security and Cryptography

216

all methods. The full set of agreed parameters S

∪{I, P

} when P

is part of the session key material,

and S

∪ {I} otherwise.

3.2.4 Inferred Properties

From the above, other properties can be inferred to

hold in our adversary model. Protocols where a

party does not get conﬁrmation that their peer knows

the session key material may be susceptible to Key-

Compromise Impersonation (KCI) attacks (Blake-

Wilson et al., 1997). Attacks in this class allow an ad-

versary in possession of a party A’s secret long-term

key to coerce A to complete a protocol run believing

it authenticated a certain peer B, but where B did not

engage with A at all in a run. Because both our above

notions of agreement ensure agreement on identities,

roles and session key material, all methods passing

veriﬁcation of those are also resistant to KCI attacks.

If a party A can be coerced into believing it com-

pleted a run with B, but where the session key ma-

terial is actually shared with C instead, the protocol

is vulnerable to an Unknown Key-Share (UKS) at-

tack (Blake-Wilson et al., 1997). For the same rea-

son as for KCI, any method for which our agreement

properties hold is also resistant to UKS attacks.

From the injective agreement properties it follows

that each party is assured the identity of its peer upon

completion. Therefore, the agreement properties also

capture entity authentication.

3.3 Tamarin

We chose Tamarin to model and verify EDHOC in

the symbolic model. It is an interactive veriﬁcation

tool in which models are speciﬁed as multi-set rewrite

rules that deﬁne a transition relation. The elements of

the multi-sets are facts representing the global sys-

tem state. Rules are equipped with event annotations

called actions. Sequences of actions make up execu-

tion traces, over which logic formulas are deﬁned.

Multi-set rewrite rules are written l −[e]→ r, where

l and r are multi-sets of facts, and e is a multi-set of

actions. Facts and actions are n-ary predicates over

a term algebra, which deﬁnes a set of function sym-

bols, variables and names. Tamarin checks equality

of these terms under an equational theory E. For

example, one can write dec(enc(x, y), y) =

x to de-

note that symmetric decryption reverses the encryp-

tion operation under E. The equational theory E is

ﬁxed per model, and hence we omit the subscript.

Tamarin supports let-bindings and tuples as syntactic

sugar to simplify model deﬁnitions. It also provides

built-in rules for Dolev-Yao adversaries and for man-

aging their knowledge. We implement events using

actions, and parameters associated with events using

terms of the algebra.

3.3.1 Protocol Rules and Equations

Tamarin allows users to deﬁne new function symbols,

equational theories and rules, which are added to the

set of considered rules during veriﬁcation. For exam-

ple, in our model we have a symbol to denote authen-

ticated encryption, for which Tamarin produces a rule

of the following form:

[!KU(k), !KU(m), !KU(ad), !KU(ai)] --[]->

[!KU(aeadEncrypt(k, m, ad, ai))]

to denote that if the adversary knows a key k, a mes-

sage m, the authenticated data ad, and an algorithm ai,

then they can construct the encryption, and thus get to

know the message aeadEncrypt(k, m, ad, ai).

3.4 Tamarin Encoding of EDHOC

We model all four methods of EDHOC, namely SIG-

SIG, SIG-STAT, STAT-SIG and STAT-STAT. Because

the methods share a lot of common structure, we de-

rive their Tamarin-models from a single speciﬁcation

written with the aid of the M4 macro language. To

keep the presentation brief, we only present the STAT-

SIG metohod, as it illustrates the use of two different

asymmetric authentication methods simultaneously.

The full Tamarin code for all models can be found

at (Norrman et al., 2020). Variable names used in

the code excerpts here are sometimes shortened com-

pared to the model itself to ﬁt the paper format.

3.4.1 Primitive Operations

Our model uses the built-in theories of exclusive-

or and DH operations, as in (Dreier et al., 2018;

Schmidt et al., 2012). Hashing is modeled via the

built-in hashing function symbol augmented with a

public constant as additional input, modelling dif-

ferent hash functions. The HKDF interface is rep-

resented by expa for the expansion operation and

extr for the extraction operation. Signatures use

Tamarin’s built-in theory for sign and verify oper-

ations. For AEAD operations on key k, message m,

additional data ad and algorithm identiﬁer ai, we use

aeadEncrypt(m, k, ad, ai) for encryption. De-

cryption with veriﬁcation of the integrity is deﬁned

via the equation

aeadDecrypt(aeadEncrypt(m, k, ad, ai),

k, ad, ai) = m.

The integrity protection of AEAD covers ad, and this

equation hence requires an adversary to know ad even

if they only wish to decrypt the data. To enable the

adversary to decrypt without needing to verify the in-

tegrity we add the equation

decrypt(aeadEncrypt(m, k, ad, ai), k, ai) = m.

The latter equation is not used by honest parties.

Formal Analysis of EDHOC Key Establishment for Constrained IoT Devices

217

3.4.2 Protocol Environment and Adversary

Model

We model the binding between a party’s identity and

their long-term key pairs using rules for SIG- and

STAT-based methods separately.

rule registerLTK_SIG:

[Fr(˜ltk)] --[UniqLTK($A, ˜ltk)]->

[!LTK_SIG($A, ˜ltk),

!PK_SIG($A, pk(˜ltk)),

Out(<$A, pk(˜ltk)>)]

rule registerLTK_STAT:

[Fr(˜ltk)] --[UniqLTK($A, ˜ltk)]->

[!LTK_STAT($A, ˜ltk),

!PK_STAT($A, ’g’ˆ˜ltk),

Out(<$A, ’g’ˆ˜ltk>)]

The fact Fr(˜ltk) creates a fresh term ltk, repre-

senting a long-term secret key, not known to the ad-

versary. The fact Out(<$A, pk(˜ltk)>) sends the

identity of the party owning the long-term key and

the corresponding public key to the adversary. The

event UniqLTK together with a corresponding restric-

tion models the fact that the each party is associated

with exactly one long-term key. Consequently, an ad-

versary cannot register additional long-term keys for

an identity. In line with the EDHOC speciﬁcation,

this models an external mechanism ensuring that long

term keys are bound to correct identities, e.g., a cer-

tiﬁcate authority.

We rely on Tamarin’s built-in message deduction

rules for a Dolev-Yao adversary. To model an ad-

versary compromising long-term keys, i.e., events of

type A

LTK

, and revealing ephemeral keys, i.e., events

of type A

Eph

, we use standard reveal rules. The timing

of reveals as modelled by these events is important.

The long-term keys can be revealed on registration,

before protocol execution. The ephemeral key of a

party can be revealed when the party completes, i.e.,

at events of type I

and R

3.4.3 Protocol Roles

We model each method of the protocol with four

rules: I1, R2, I3 and R4 (with the method sufﬁxed

to the rule name). Each of these represent one step

of the protocol as run by the initiator I or the respon-

der R. The rules correspond to the event types I

, I

, and R

, respectively. Facts preﬁxed with StI

carry state information between I1 and I3. A term

unique to the current thread, tid, links two rules to

a given state fact. Similarly, facts preﬁxed with StR

carry state information between the responder role’s

A stronger, and perhaps more realistic, model would

reveal ephemeral keys upon creation at the start of the run,

but we failed to get Tamarin to terminate on this.

rules. Line 28 in the R2 STAT SIG rule shown below

illustrate one such use of state facts.

We do not model the error message that R can send

in response to message m

, and hence our model does

not capture the possibility for R to reject I’s offer.

We model the XOR encryption of CIPHERTEXT 2

with the key K 2e using Tamarin’s built in theory for

XOR, and allow each term of the encrypted element to

be attacked individually. That is, we ﬁrst expand K 2e

to as many key-stream terms as there are terms in the

plaintext tuple by applying the HKDF-expand func-

tion to unique inputs per term. We then XOR each

term in the plaintext with its own key-stream term.

This models the speciﬁcation closer than if we would

have XORed K 2e as a single term onto the plaintext

tuple. The XOR encryption can be seen in lines 19–22

in the listing of R2 STAT SIG below.

1 rule R2_STAT_SIG:

2 let

3 agreed = <CS0, CI, ˜CR>

4 gx = ’g’ˆxx

5 data_2 = <’g’ˆ˜yy, CI, ˜CR>

6 m1 = <’STAT’, ’SIG’, CS0, CI, gx>

7 TH_2 = h(<$H0, m1, data_2>)

8 prk_2e = extr(’e’, gxˆ˜yy)

9 prk_3e2m = prk_2e

10 K_2m = expa(<$cAEAD0, TH_2, ’K_2m’>,

11 prk_3e2m)

12 protected2 = $V // ID_CRED_V

13 CRED_V = pkV

14 extAad2 = <TH_2, CRED_V>

15 assocData2 = <protected2, extAad2>

16 MAC_2 = aead(’e’, K_2m, assocData2,

$cAEAD0)

17 authV = sign(<assocData2, MAC_2>, ˜ltk)

18 plainText2 = <$V, authV>

19 K_2e = expa(<$cAEAD0, TH_2,

’K_2e’>, prk_2e)

20 K_2e_1 = expa(<$cAEAD0, TH_2,

’K_2e’, ’1’>, prk_2e)

21 K_2e_2 = expa(<$cAEAD0, TH_2,

’K_2e’, ’2’>, prk_2e)

22 CIPHERTEXT_2 = <$V XOR K_2e_1,

authV XOR K_2e_2>

23 m2 = <data_2, CIPHERTEXT_2>

24 exp_sk = <gxˆ˜yy>

25 in

26 [!LTK_SIG($V, ˜ltk), !PK_SIG($V, pkV),

In(m1), Fr(˜CR), Fr(˜yy), Fr(˜tid)]

27 --[ExpRunningR(˜tid, $V, exp_sk, agreed),

R2(˜tid, $V, m1, m2)]->

28 [StR2_STAT_SIG($V, ˜ltk, ˜yy, prk_3e2m,

TH_2, CIPHERTEXT_2, gxˆ˜yy,

˜tid, m1, m2, agreed),

29 Out(m2)]

To implement events and to bind them to pa-

rameters, we use actions. For example, the action

ExpRunningR(˜tid, $V, exp_sk, agreed) in

line 27 above implements binding of an event of type

to the parameters and session key material.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

218

As explained in Section 3.2.3, it is not possi-

ble to show injective agreement on session key ma-

terial when it includes P

(not visible in the rule

R2 STAT SIG). Therefore, we use certain actions to

implement events that include P

in the session key

material and other actions that do not. Session key

material which includes (resp. does not include) P

referred to as imp sk (resp. exp sk) in the Tamarin

model. In the case of SIG-SIG and SIG-STAT, there-

fore, imp sk is the same as exp sk.

3.5 Tamarin Encoding of Properties

The properties and adversary model we deﬁned in

Section 3.2 translate directly into Tamarin’s logic, us-

ing the straightforward mapping of events to the ac-

tions emitted from the model. As an example, we

show the lemma for verifying the property PFS.

1 lemma secrecyPFS:

2 all-traces

3 "All u v sk #t3 #t2.

4 (K(sk)@t3 & CompletedRun(u, v, sk)@t2) ==>

5 ( (Ex #t1. LTKRev(u)@t1 & #t1 < #t2)

6 | (Ex #t1. LTKRev(v)@t1 & #t1 < #t2)

7 | (Ex #t1. EphKeyRev(sk)@t1))"

The action CompletedRun(u, v, sk) in line 4 is

emitted by both the rules I3 and R4, and corresponds

to the disjunction of events I

∨ R

in the deﬁnition

of PFS in Section 3.2.1. Similarly, EphKeyRev(sk)

in line 7 models that the ephemeral key is revealed for

either I or R, or both.

4 DISCUSSION

There are a few places where EDHOC can be im-

proved, which we found during this work and com-

municated to the authors. We discuss them below.

4.1 Unclear Intended Use

The EDHOC speciﬁcation lists several security goals,

but they are imprecise and difﬁcult to interpret due

to lack of context and intended usage descriptions.

Without knowing how the protocol is to be used, it

is not clear whether the listed security goals are the

most important ones for constrained IoT devices.

The abstract goal of EDHOC is simple: establish

an OSCORE security context using few roundtrips

and small messages. From that, the design of EDHOC

is mainly driven by what can be achieved given the

technical restrictions. Focusing too much on what can

be achieved within given restrictions, and paying too

little attention to the use cases where the protocol is

to be used and their speciﬁc goals, risks resulting in

sub-optimal trade-offs and design decisions.

EDHOC is intended to cover a variety of use

cases, many of which are difﬁcult to predict today.

However, this does not prevent collecting typical use

cases and user stories to identify more speciﬁc secu-

rity goals that will be important in most cases.

While constructing our model, we made up simple

user stories to identify security properties of interest.

Several of these revealed subtleties and undeﬁned as-

pects of EDHOC. We informed the EDHOC authors,

who addressed these aspects in the speciﬁcation.

4.1.1 (Non-)Repudiation

An access control solution for a nuclear power-plant

may need to log who is passing through a door,

whereas it may be undesirable for, say, a coffee ma-

chine to log a list of users along with their coffee pref-

erences. Via this simple thought experiment, we real-

ized that the speciﬁcation did not consider the concept

of (non)-repudiation. In response, the authors of the

speciﬁcation added a paragraph discussing how dif-

ferent methods relate to (non)-repudiation.

4.1.2 Unintended Peer Authentication

According to Section 3.2 of the speciﬁcation, parties

must be conﬁgured with a policy restricting the set of

peers they run EDHOC with. However, the initiator

is not required to verify that the ID

received in the

second message is the same as the one intended. The

following attack scenario is therefore possible.

Suppose someone has conﬁgured all devices in

their home to be in the allowed set of devices, but that

one of the devices (A) is compromised. If another de-

vice B, initiates a connection to a third device C, the

compromised device A may interfere by responding

in C’s place, blocking the legitimate response from C.

Since B does not verify that the identity indicated in

the second message matches the intended identity C,

and device A is part of the allowed set, B will com-

plete and accept the EDHOC run with device A in-

stead of the intended C. The obvious solution is for

the initiator to match ID

to the intended identity in-

dicated by the application, which we included in our

model. We have communicated this to the EDHOC

authors and they are considering a resolution.

4.2 Unclear Security Model

We argue that the speciﬁcation gives too little infor-

mation about what capabilities an adversary is as-

sumed to have, and that this leads to unclear design

goals and potentially sub-optimal design.

Formal Analysis of EDHOC Key Establishment for Constrained IoT Devices

219

Table 1: Veriﬁed properties. S

contains roles, responder identity, session key material (excluding P

), C

, C

, and S

. S

, the initiator identity, and P

SIG-SIG SIG-STAT STAT-SIG STAT-STAT

Injective agreement for I S

Injective agreement for R S

Implicit agreement for I S

Implicit agreement for R S

PFS for session key material X X X X

Even though EDHOC incorporates cryptographic

cores from different academic security protocols, its

design does not take into account the adversary mod-

els for which these protocols were designed. For ex-

ample, OPTLS, whose cryptographic core is essen-

tially the same as the STAT authentication method, is

designed to be secure in the CK model (Canetti and

Krawczyk, 2002). The CK security model explicitly

separates the secure storage of long-term keys from

storage of session state and ephemeral keys. This is

appropriate for modelling the use of secure modules.

The EDHOC authors indicated to us that it was not

necessary to consider compromised ephemeral keys

separately from compromised long-term keys. The

rationale is that SIGMA cannot protect against com-

promised ephemeral keys (EDHOC authors, 2020).

That rationale is presumably based on the fact that the

SIG-SIG method is closely modeled on the SIGMA-I

variant of SIGMA, and that it would be preferable

to obtain a homogeneous security level among the

EDHOC methods. That is only true, however, when

restricting attention to session key conﬁdentiality of

an ongoing session. Secure modules provide value

in other ways, for example, by allowing construc-

tions with Post-Compromise Security (PCS) guaran-

tees. We discussed this with the authors, and the latest

version of the speciﬁcation (Selander et al., 2021) in-

cludes recommendations on storage of long-term keys

and operations on these inside a secure module.

4.3 Session Key Material

EDHOC establishes session key material, from which

session keys can be derived using the EDHOC-

Exporter. The session key material is affected by P

and if a party uses the STAT authentication method,

also by that party’s secret static long-term key. As

shown in Section 3, mutual injective agreement can-

not be achieved for P

. If this property is not impor-

tant for constrained IoT devices which cannot use any

of the other methods, then one can simply accept that

the methods have different authentication strengths.

Otherwise, this is a problem.

We identiﬁed three alternatives for resolving this.

One alternative is to include ID

, or its hash, in the

ﬁrst and second messages. This would, however,

increase message sizes and prevent initiator identity

protection, which are grave concerns for EDHOC. A

second alternative is to not derive the session key ma-

terial from P

. Doing so, however, deviates from the

design of OPTLS (and similar protocols from which

the STAT-based methods are derived), where the in-

clusion of P

plays a crucial part in the security proof

of resistance against initiator ephemeral key compro-

mise. The third alternative is to include a fourth

message from responder to initiator, carrying a MAC

based on a key derived from session key material in-

cluding P

. Successful MAC veriﬁcation guarantees

to the initiator that the responder injectively agrees

on P

. We presented the options to IETF, and they de-

cided to add a fourth message as an option in the latest

version of the speciﬁcation (Selander et al., 2021).

We veriﬁed that all methods enjoy a common, but

weaker, property: mutual implicit agreement on all of

, P

and P

, where applicable.

5 CONCLUSIONS AND FUTURE

WORK

We formally modeled all four methods of the EDHOC

speciﬁcation using Tamarin. We formulated several

important security properties and identiﬁed precise

adversary models in which we veriﬁed these. The

properties are shown in Table 1. Mutual injective

agreement covers the set of parameters S

: respon-

der identity, roles, session key material (except for P

when initiator uses the STAT authentication method),

context identiﬁers C

and C

, and cipher suites S

. The

responder in addition is ensured agreement on the ini-

tiators identity and P

, i.e., on the set S

. Implicit

agreement covers all previously mentioned parame-

ters for both peers. Veriﬁcation of all lemmas, includ-

ing model validation lemmas, took 42 minutes on an

Intel Core i7-6500U 2.5GHz using two cores. Mutual

entity authentication, UKS- and KCI resistance can

be inferred from the veriﬁed properties.

Further, we identiﬁed a situation where initiators

may establish an OSCORE security context with a

SECRYPT 2021 - 18th International Conference on Security and Cryptography

220

different party than the application using EDHOC in-

tended, and proposed a simple mitigation. We dis-

cussed how the IETF may extract and better deﬁne

security properties to enable easier veriﬁcation.

We veriﬁed each method in isolation. Verifying

security under composition is left as future work.

In this work, we have analyzed the EDHOC ver-

sion as of July 2020 (Selander et al., 2020). There

are newer versions, with the most recent version as of

February 2021 (Selander et al., 2021). However, the

changes to the protocol over these versions are not

particularly signiﬁcant for our analysis.

ACKNOWLEDGEMENTS

This work was partially supported by the Wallen-

berg AI, Autonomous Systems and Software Program

(WASP) funded by the Knut and Alice Wallenberg

Foundation. We are grateful to G

oran Selander, John

Mattsson and Francesca Palombini for clariﬁcations

regarding the speciﬁcation.

REFERENCES

Barker, E., Chen, L., Roginsky, A., Vassilev, A., and

Davis, R. (2018). SP 800-56A Rev. 3: Recommenda-

tion for Pair-Wise Key-Establishment Schemes Using

Discrete Logarithm Cryptography. Technical report,

NIST.

Blake-Wilson, S., Johnson, D., and Menezes, A. (1997).

Key agreement protocols and their security analysis.

In Proc. of IMA Cryptography and Coding, pages 30–

45.

Blanchet, B. (2001). An efﬁcient cryptographic proto-

col veriﬁer based on prolog rules. In Proc. of IEEE

CSFW-14, pages 82–96.

Bruni, A., Jørgensen, T. S., Petersen, T. G., and Sch

urmann,

C. (2018). Formal veriﬁcation of ephemeral Difﬁe-

Hellman over COSE (EDHOC). In Proc.of SSR, pages

21–36.

Canetti, R. and Krawczyk, H. (2002). Security analysis

of IKE’s signature-based key-exchange protocol. In

Proc. of CRYPTO, pages 143–161.

Delpech de Saint Guilhem, C., Fischlin, M., and Warinschi,

B. (2020). Authentication in key-exchange: Deﬁni-

tions, relations and composition. In Proc. of IEEE

CSF, pages 288–303.

Dreier, J., Hirschi, L., Radomirovic, S., and Sasse, R.

(2018). Automated unbounded veriﬁcation of stateful

cryptographic protocols with exclusive OR. In Proc.

of IEEE CSF, pages 359–373.

EDHOC authors (2020). Personal communication.

Krawczyk, H. (2003). SIGMA: The ‘SIGn-and-

MAc’approach to authenticated Difﬁe-Hellman and

its use in IKE protocols. In Proc. of CRYPTO, pages

400–425.

Krawczyk, H. (2005). HMQV: A high-performance secure

difﬁe-hellman protocol. In Shoup, V., editor, Proc. of

CRYPTO, volume 3621 of Lecture Notes in Computer

Science, pages 546–566.

Krawczyk, H. (2016). A unilateral-to-mutual authentication

compiler for key exchange (with applications to client

authentication in TLS 1.3). In Proc. of ACM CCS,

pages 1438–1450.

Krawczyk, H. and Eronen, P. (2010). HMAC-based extract-

and-expand key derivation function (HKDF). RFC

5869.

Krawczyk, H. and Wee, H. (2016). The OPTLS protocol

and TLS 1.3. In Proc. of IEEE EuroS&P 2016, pages

81–96.

Lowe, G. (1997). A hierarchy of authentication speciﬁca-

tion. In Proc. of IEEE CSFW-10, pages 31–44.

Meier, S., Schmidt, B., Cremers, C., and Basin, D. A.

(2013). The TAMARIN prover for the symbolic anal-

ysis of security protocols. In Proc. of CAV, pages 696–

701.

Norrman, K., Sundararajan, V., and Bruni, A. (2020).

EDHOC model. https://github.com/hoheinzollern/

EDHOC-Veriﬁcation/tree/master/models/edhoc/

secrypt21-tamarin.tgz.

Schaad, J. (2017). CBOR Object Signing and Encryption

(COSE). RFC 8152.

Schmidt, B., Meier, S., Cremers, C. J. F., and Basin, D. A.

(2012). Automated analysis of Difﬁe-Hellman pro-

tocols and advanced security properties. In Proc. of

IEEE CSF, pages 78–94.

Selander, G., Mattsson, J., and Palombini, F. (2020).

Ephemeral Difﬁe-Hellman Over COSE (ED-

HOC). IETF Internet-Draft draft-selander-lake-

edhoc-00. https://datatracker.ietf.org/doc/html/

draft-ietf-lake-edhoc-00.

Selander, G., Mattsson, J., Palombini, F., and Seitz, L.

(2019). Object Security for Constrained RESTful En-

vironments (OSCORE). RFC 8613.

Selander, G., Mattsson, J. P., and Palombini, F.

(2018). Ephemeral Difﬁe-Hellman Over COSE

(EDHOC). IETF Internet-Draft draft-selander-ace-

cose-ecdhe-08. https://datatracker.ietf.org/doc/html/

draft-selander-ace-cose-ecdhe-08.

Selander, G., Mattsson, J. P., and Palombini, F.

(2021). Ephemeral Difﬁe-Hellman Over COSE

(EDHOC). IETF Internet-Draft draft-ietf-lake-

edhoc-05. https://datatracker.ietf.org/doc/html/

draft-ietf-lake-edhoc-05.

Formal Analysis of EDHOC Key Establishment for Constrained IoT Devices

221