Secure Ownership Transfer for the Internet of Things

Martin Gunnarsson

1,2

and Christian Gehrmann

Dept. of Electrical and Information Technology, Lund University, Lund, Sweden

RISE, Ole R

omers v

ag 5A, Lund, Sweden

Keywords:

IoT, Ownership Transfer, Constrained Devices.

Abstract:

With the increasing number of IoT devices deployed, the problem of switching ownership of devices is be-

coming more apparent. Especially, there is a need for transfer protocols not only addressing a single unit

ownership transfer but secure transfer of a complete infrastructure of IoT units including also resource con-

straint devices. In this paper we present our novel ownership transfer protocol for an infrastructure of IoT

devices. The protocol is light-weight as it only uses symmetric key operations on the IoT side. The ownership

transfer protocol is carefully security evaluated both using a theoretical analysis and with automatic protocol

veriﬁcation. In addition, we show the feasibility of the ownership transfer protocol through a proof of concept

implementation including performance ﬁgures.

1 INTRODUCTION

The amount of connected devices deployed are in-

creasing. Connected devices can take the form of

sensors and actuators in home, industrial or smart-

city settings. They can also be connected medical

devices or connected cars. In particular, we see a

trend towards usage of very large IoT infrastructures

consisting of a huge number of heterogeneous de-

vices (V

ogler et al., 2016) . Managing such heteroge-

neous infrastructures is challenging and an issue that

has been addressed in several recent research works

(Lanza et al., 2016) (D

Aaz et al., 2016).

Large IoT infrastructures must also be managed

and controlled from a security perspective. An expec-

tation of such a system is secure communication as

well as authentication and authorization, thus creden-

tials for the IoT devices must be issued and updated

(Roman et al., 2011). Credential management can be

done using standard protocols and procedures such as

IKE and HIP (Eronen et al., 2010)(Saied and Oliv-

ereau, 2012) and these procedures are working well

as long as a single organization is controlling the in-

frastructure.

However, transferring ownership of a complete in-

frastructure is more complicated. One core problem

is backward and forward secrecy with respect to the

old and new owners. The new owner of the system

shall not be able to deduce anything the old owner has

done before the transfer of ownership. Vice versa, the

old owner shall not be able to learn anything of what

the new owner does after the transfer of ownership.

Furthermore, there should not be any time slot when

a single IoT unit is under control of both the old and

new owners simultaneously.

The problem of IoT infrastructure ownership

transfer is related to the problem of transferring own-

ership of RFID tags, a topic that has been extensively

treated in the literature in the past (Taqieddin et al.,

2018). Especially, it is related to the problem of group

ownership transfer of RFID tags (Zuo, 2010)(Kapoor

et al., 2011)(He et al., 2014). Inspired by these ear-

lier works we have looked into the ownership transfer

problem again, now from the IoT infrastructure per-

spective. Similar to some previous work for tag own-

ership transfer, we are interested in ﬁnding symmetric

key solutions not being dependent on public key sup-

port on the IoT side. This allows ownership transfer

also for very resource constrained IoT units in the sys-

tem(Eisenbarth et al., 2007). By analyzing the secu-

rity expectations for such scenario, we have identiﬁed

the main security requirements for IoT infrastructure

ownership transfer. The requirements then allowed us

to suggest a suitable ownership transfer model based

on the assumption of trusted third party, or what we

refer to as a ‘’Reset Server” (RS) present in the sys-

tem. We present a protocol for ownership transfer

under this model. Our ownership transfer protocol

meets the identiﬁed requirements, and has not previ-

ously presented in the literature. Our suggested ap-

Gunnarsson, M. and Gehrmann, C.

Secure Ownership Transfer for the Internet of Things.

DOI: 10.5220/0008928300330044

In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 33-44

ISBN: 978-989-758-399-5; ISSN: 2184-4356

proach does not need active involvement of the RS

during normal operation, a property we see as a ma-

jor advantage. Furthermore, the RS does not need to

store individual IoT device keys, reducing the storage

requirements of the RS.

The main contributions of the paper are the fol-

lowing

• We analyse the IoT infrastructure ownership

transfer problem and conclude that it has simi-

lar but not equal security requirements compared

with those identiﬁed in previous analyses of group

ownership transfer for tags.

• We suggest a novel IoT infrastructure ownership

transfer model and protocol for symmetric keys

based on the usage of an RS in the system.

• We present a proof of concept implementation and

performance evaluation of the proposed owner-

ship transfer scheme.

• We make a security analysis of the proposed

ownership transfer protocol using both Tamarin

Prover and logical reasoning.

We proceed as follows: we discuss related work

(§2), we introduce our system model (§3), iden-

tify security requirements and give a problem deﬁni-

tion (§4), we present our ownership transfer model

and protocol design (§5), we describe our proof-

of-concept implementation including performance

benchmarks (§6), we perform security analysis of the

proposed transfer protocol (§7) and conclude (§8).

2 RELATED WORK

Protocols for ownership transfer have been studied

in several ﬁelds. Both recently for IoT devices and

earlier for RFID-tags. IoT infrastructures and RFID

systems are not equal but share some characteris-

tics. RFID-tags and IoT systems are deployed in large

numbers and efﬁcient management of a large num-

ber of devices is necessary. IoT devices might have

constrained resources and RFID-tags typically even

less resources for computation and storage. IoT units

though have connectivity, usually wireless, and the

ability to initiate communication with external enti-

ties. RFID-tags however are only capable of respond-

ing to requests. RFID-tags can only be read and writ-

ten to locally, a reader must be in physical proximity

to the RFID-tag to be able to communicate with the

device. An IoT device can however receive commu-

nication originating practically anywhere, this creates

a bigger attack surface on IoT devices since an attack

on the system can, in theory, originate from anywhere

on the planet.

2.1 IoT Ownership Transfer

Internet of Things (IoT) are a very wide category of

devices with the common property that they are con-

nected to a network in some way. When ownership

transfer is studied in the realm of IoT devices authors

often have different views of what types of devices

constitute an IoT device. Devices considered can be

connected medical equipment, wearables, smart con-

sumer electronics such as fridges and CCTV-cameras.

Other devices that are often grouped into IoT are

sensor networks, building automation and connected

equipment for industry.

Tam and Newmarch state the problem of trans-

ferring ownership in (Tam and Newmarch, 2004) for

Ubiquitous Computing Networks, a term that predates

IoT. They deﬁne the term ownership and provide re-

quirements for an ownership system. They also pro-

vide an example of an ownership transfer protocol.

The protocol is based on public-key cryptography and

deﬁnes how two parties transfer the ownership of a

device.

Khan et. al. discuss ownership transfer for con-

nected consumer products(Khan et al., 2019) . The

focus of the ownership transfer process is less about

re-keying the device and more about preserving pri-

vacy for information stored on the device. They also

propose a novel idea of how to automatically start the

ownership transfer process by detecting changes in

the environment to determine if the device has been

sold or given away.

Pradeep and Singh propose a protocol in (Pradeep

and Singh, 2013) utilizing a trusted third party that

they call a Central Key Server. The protocol requires

physical proximity when the ownership transfer pro-

cess is about to take place. The protocol does not

specify exactly what type of IoT device that is con-

sidered, but only one device is transferred during each

execution of the protocol.

2.2 Ownership Transfer Protocols for

RFID-tags

The subject of secure ownership transfer has been

studied in the ﬁeld of RFID technology since 2005

(Saito et al., 2005). In the paper ”Tag Ownership

in RFID systems: Survey of Existing Protocols and

Open Challenges”(Taqieddin et al., 2018) the authors

list the research done in the ﬁeld from 2005 to 2018.

The authors also group protocols by features; Group

transfer protocols and individual tag transfer proto-

cols, trusted Third Party (TTP) protocols, and proto-

cols where only the new and current owner take part.

Lastly EPC-C1G2 (Inc., 2008) compliant protocols

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

and protocols that require more resources from the

tags. The ﬁrst papers for RFID-tag ownership transfer

generally suffered from not satisfying some important

security requirements. The early Satio paper (Saito

et al., 2005), does for instance not provide forward

and backwards secrecy for the owners.

We are considering a model with IoT ownership

transfer with the assistance of a trusted third party

node, the so-called ”Reset Server” (RS) (see Section

3 and Section 5). This entity has a very similar role

as a TTP in RFID ownership transfer solutions. How-

ever, different from prior art work, we think that for

IoT infrastructures, one would like to avoid the TTP

to actual choose the credentials for the devices in the

system but merely ”supervise” the transferring pro-

cess. This has the main advantage that the RS, unlike

the TTP in prior-art solutions, will not have complete

knowledge of the ﬁnal device credential after com-

pleting the ownership transfer process. TTP based

protocols in prior-art are the ones that most closely

resemble the model we consider and we will in the re-

lated work summary below, focus on TTP based pro-

tocols.”

2.3 RFID Single Ownership Transfer

Much work has been done for owner transfer of sin-

gle RFID-tags. Since we consider group transfer of

IoT devices these protocols are mainly mentioned for

completeness sake. Protocols that are intended for

EPC-compliance are often forced to use non-standard

solutions due to the extremely constrained nature of

EPC-compliant RFID-tags. One such scheme can be

found in (Cao et al., 2016). The protocols that are

not restricted by EPC-compliance often make use of

standard cryptological functions such as symmetric

ciphers and hash functions. One example of an own-

ership transfer protocol using a TTP can be found in

(Zhou et al., 2012).

2.4 RFID Group Ownership Transfer

Several group transfer protocols with a TTP have been

proposed in the literature (Kapoor et al., 2011) (Zuo,

2010) (Sundaresan et al., 2015) (He et al., 2014)

(Bagheri et al., 2018). The design goals of the differ-

ent protocols are not uniform. They do not work with

the very same security requirements. They also dif-

fer with respect to that one solution wants to achieve

EPC-C1G2 compliance (Sundaresan et al., 2015) and

another want to have a group of nodes to switch own-

ership simultaneously for instance (Zuo, 2010).

A core characteristic we expect from an ownership

transfer protocol, is backward and forward secrecy.

This is not offered by the protocol suggested by Sun-

daresan et al. (Sundaresan et al., 2015). The group

transfer protocol by Kapoor (Kapoor et al., 2011) is

an extension of an earlier variant for singe tag transfer

(Kapoor and Piramuthu, 2008). Even if this is a sim-

ple and rather straightforward protocol, these proto-

cols were later shown by Bagheri et al (Bagheri et al.,

2018) to be vulnerable to de-synchronization attacks

(due to the simple fact that the message exchange be-

tween the TTP and the tag was not authenticated).

The authors in (Bagheri et al., 2018) also showed how

to ﬁx these shortcomings, but unlike our suggested

protocol, their solution is dependent on a direct ses-

sion between the tag (the IoT unit in our case) and

the TTP. They also give the full power to the TTP that

must have access to all key information (both the old

and the new).

Inspired by an earlier work on grouping proofs for

RFID tags (Burmester et al., 2008), Zuo proposed a

new TTP based protocol for RFID ownership trans-

fer (Zuo, 2010). Similar to the earlier grouping proof

protocols, the design goal is to provide a proof of the

ownership transfer of all tags in a group simultane-

ously, i.e., without the need of having connection to

the back-end system representing the tag owner dur-

ing the ownership switch. This means that the own-

ership transfer interactions only take place locally be-

tween the tag reader and the tags in the group con-

nected to this reader. Later, the back-end system just

can verify that the transfer has occurred. In and RFID

system scenario this has some communication over-

head reduction advantages but not in a system sce-

nario with distributed IoT units. Hence, the off line

requirement makes the ownership transfer unneces-

sarily complex for the IoT scenario we are consider-

ing. Furthermore, similar to other ownership proto-

cols, the TTP is given full power by selecting all the

new credentials using the solution in (Zuo, 2010).

In (He et al., 2014) another group ownership trans-

fer protocol was proposed. This protocol shares our

design goals with respect to forward and backward

secrecy. Furthermore, it allows arbitrary location and

grouping of tags based on group keys. This is a prop-

erty most suitable also for IoT infrastructures. How-

ever, similar to other prior art, the solution in (He

et al., 2014) gives the TTP full knowledge of the key

information. It also must has active sessions with all

tags taking part in the ownership transfer process. Our

protocol does not have these two limitations.

Secure Ownership Transfer for the Internet of Things

Figure 1: An overview of the considered system.

3 SYSTEM MODEL AND

ASSUMPTIONS

This paper considers IoT deployments as seen in Fig-

ure 1, comprised by a large number of IoT nodes

deployed managed by a Device Management Server

(DMS) owned and operated by some entity. The con-

sidered system can be part of an Internet connected in-

dustrial automation system or smart sensors deployed

to monitor the environment for e.g. pollution. The

IoT nodes communicate with the DMS through in-

termediate parties and the last hop to the IoT nodes

can be assumed to be wireless communication. The

IoT nodes can be resource constrained nodes, this

means that their hardware capabilities; such as pro-

cessing power and memory are limited. The IoT de-

vices are capable of symmetric cryptography, asym-

metric cryptography is not feasible for these devices,

mainly due to the increased bandwidth required. The

used wireless communication technology is limited in

bandwidth and latency. The DMS is assumed to be a

server, in a cloud environment or located on premise

in the organization.

In the scenario depicted in Figure 1, the differ-

ent IoT units are connected to the Internet and con-

sequently vulnerable to all kinds of network based at-

tacks. Hence, it is important that the IoT units are

properly authenticated and that only well protected

communications are allowed over the Internet and

over the wireless network. In particular, independent

of Internet access technology, there must be creden-

tials in place on the IoT units so that they can securely

perform mutual authentication with the back-end sys-

tem. For an ownership transfer to take place we as-

sume that there exists another organization, with its

own DMS, to transfer the ownership to.

We furthermore assume the existence of a trusted

third party in the form of an RS. RS i operated by

an organization that both organizations trust to a high

degree. The RS will facilitate the ownership trans-

fer process. The RS and DMS are not constrained in

what types of cryptographic operations they can do

i.e. asymmetric cryptography is possible. We also as-

sume that the DMS servers and RS can exchange keys

and authenticate each other, possibly with a PKI. The

cryptographic functions are assumed to be secure.

4 ADVERSARIAL MODEL AND

PROBLEM DESCRIPTION

4.1 Adversarial Model

Similar to many existing work in IoT and cloud secu-

rity, we assume that the adversary is acting according

to the Dolev-Yao adversarial model (Dolev and Yao,

1981). This means that an attacker is able to inter-

cept, delete, change order or modify all messages sent

over the communication channel between any entity.

The adversary can also destroy messages, but is not

able to break cryptographic functions. Furthermore,

we assume the IoT nodes are placed into an environ-

ment such that physical attacks from an insider adver-

sary (such as the current owner) have to be considered

while the DMS and the RS are assumed to be in a

secure location or in protected isolated environments

protected from both external and insider software at-

tacks.

With respect to the direct physical attacks on the

IoT units, we assume that an adversary as well as the

old and new DMS are able to compromise, with a

given effort, some or a limited number of IoT units

through direct physical attacks on the devices. Here a

compromised node refer to a node where the attacker

has full control of the execution environment as well

as volatile and persistent storage units of the device.

Such a model is motivated by the fact that the needed

effort for direct physical attacks is at least propor-

tional to the number of compromised units. Attacks

from the current or new owner on a large scale can

be very hard to perform in practice due to hardware

protection mechanisms on the IoT units for instance.

4.2 Trust Model

The RS is assumed to be ‘’honest but curious” (Oded,

2009), which means the RS will be a legitimate par-

ticipant in protocol interactions. It will not deviate

from the deﬁned protocol, but will attempt to learn all

possible information from legitimately received mes-

sages. The Old Owner and the New Owner are as-

sumed to not fully trust each other, i.e. the Old Owner

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

has interest in learning the secrets used by the New

Owner. Similar, the New Owner would like to get

hold of the secrets used by the Old Owner.

4.3 Requirements

Given the previously introduced adversary model, we

have looked over the general ownership transfer secu-

rity requirements identiﬁed in previous work on RFID

tags (Taqieddin et al., 2018) and adapted them to our

system and adversary model:

R1. IoT Unit Impersonation Security: The proto-

col shall not allow an adversary to impersonate

legitimate IoT units during or after ownership

transfer.

R2. Old DMS Impersonation Security: The pro-

tocol shall not allow an adversary or the new

DMS to impersonate the old DMS.

R3. New DMS Impersonation Security: The pro-

tocol shall not allow an adversary or the old

DMS to impersonate the new DMS.

R4. RS Impersonation Security: The protocol

shall not allow an adversary, any IoT unit or any

DMS in the system to impersonate the RS.

R5. Reply Attack Resistance: The protocol shall

be resistant against attacks where an adversary

tries to complete sessions with any entities in

the system by replaying old, observed mes-

sages.

R6. Resistance to Man-in-the-Middle Attacks

(MitM): The protocol shall not allow insertion

or modiﬁcation of any messages sent between

trusted entities in the system.

R7. Resistance to De-synchronization Attack:

The protocol should not allow the IoT units and

the new or old DMS to enter a state where nec-

essary secure communications is prevented by

a credential mismatch.

R8. Backward Security: During and after an IoT

ownership transfer, the new owner shall not be

given access to any secrets allowing the new

owner to get access to any identities or con-

ﬁdential information used in past sessions be-

tween the old DMS and the IoT units.

R9. Forward Security: During and after an IoT

ownership transfer, the old owner shall not be

given access to any secrets allowing the old

owner to get access to any identities or con-

ﬁdential information used in sessions between

the new DMS and the IoT units.

R10. No Double Ownership: There shall not be any

time period during the ownership transfer pro-

cess when both the old and the new owner has

control over an IoT unit in the system.

In addition to these requirements, our adversary

model does not imply full trust in the RS and we also

take into account the risk of that IoT units might be

compromised through direct physical attacks. These

two assumptions give the following additional two re-

quirements:

R11. Protection of New Credentials: After the

completion of the ownership transfer, the RS

shall not have knowledge of the new IoT cre-

dentials and shall not be able to set impersonate

the new DMS or have access to secure sessions

between the new DMS and the IoT units in the

system.

R12. IoT Compromise Resilience: A successful

compromise of an IoT unit by an external or in-

ternal adversary shall only give the adversary

the power to impersonate this single IoT unit in

the system and not impersonate or break any se-

cure sessions between other, non-compromised

IoT units in the system and the new DMS.

In many IoT infrastructures, some IoT units are

placed in local networks not publicly open but they

are accessible by the owner system only. In our case,

this means that the current DMS can access the units

but not for instance an external entity like the RS.

Opening up the system and allowing direct interac-

tions between all IoT units in the system and the RS

is a potential security risk. Hence, we have the follow-

ing additional requirement on the system solution:

R13. IoT Unit Isolation: An ownership transfer

shall not require any direct interactions between

the IoT unit and the RS but only between the

IoT unit and the DMS (old or new) in the sys-

tem.

4.4 Problem Statement

We want to transfer the ownership of a set of deployed

IoT devices from one entity to another. Each IoT de-

vice has some form of credentials that it shares with

a remote entity. Ownership is deﬁned as holding the

credentials of the individual IoT-nodes. Ownership

transfer then is the process of updating the credentials

from keys shared with the old owner to keys shared

with the new owner. We want to ﬁnd an ownership

transfer protocol and solution secure under the previ-

ously deﬁned threat model and which meets the iden-

tiﬁed security requirements in Section 4.3.

Secure Ownership Transfer for the Internet of Things

5 IoT INFRASTRUCTURE

OWNERSHIP TRANSFER

MODEL AND PROTOCOL

DESIGN

The ownership transfer process can, according to our

solution, be divided into three phases:

• Deployment

• Ownership transfer preparation

• Ownership transfer

In the deployment stage the RS and the ﬁrst owner

provisions keys to the individual devices, the devices

are then deployed.

In the ownership-transfer preparation phase, the

owner, now called old owner, and the new owner signs

a list of all devices that shall be transferred and for-

wards this list to the RS. The RS then distributes the

needed keys for the transfer and generates an owner-

ship transfer token as well as the individual keys to

the new owner.

In the ﬁnal ownership transfer stage, the old owner

sends the ownership transfer token to the IoT units.

After receiving the token the IoT devices verify and

decrypt the token. The information in the token is

used to contact the new owner. The new owner and

the IoT units then authenticate each other and new

credentials are provisioned to the IoT devices. The

detailed protocol description is done in the subsection

below, using terminology deﬁned in Table 1, and il-

lustrated in Figure 2. The steps from Figure 2 are

references by bold numbers e.g. (1.1).

5.1 Deployment

RS generates the keys KR

, KR

and K

. RS pro-

vides each IoT device with a unique identiﬁer ID

is then used to generate K

for each IoT

by calcu-

lating K

= PRF(K

||ID

). Each device IoT

is pro-

vided with the corresponding KR

, KR

, ID

and K

After transferring the keys RS can discard all keys K

RS sets its counter Ctr

= 0 and all IoT devices coun-

ters Ctr

are also set to zero. These counters are used

to verify the freshness of the ownership tokens later

on. The ﬁrst owner, DMS

old

, takes control of the sys-

tem and provides the owner-key KO

= {KO

, KO

}

to each device IoT

. The system is then ready for de-

ployment and regular use, with KO

used for securing

the communication with DMS

old

5.2 Ownership Transfer Preparation

The ownership transfer process starts with a prepara-

tion phase with interactions between the RS, DMS

old

Table 1: Notations used in protocol description.

DMS

old

Old Device Management Server

DMS

new

New Device Management Server

RS Reset server

Sign(P, d) Digital signature of data d by party P.

E(k, m)

Symmetric encryption of message m

with key k.

D(k, c)

Symmetric decryption of ciphertext c

with key k.

MAC(k, m)

Message Authentication Code of mes-

sage m with key k.

PRF(s)

Pseudo-random function with seed s,

generating

a pseudo random key.

IoT

IoT device number i.

Identiﬁer of IoT device i.

new

Identiﬁer of DMS

new

URL

new

Uniform resource locator to DMS

new

Key for IoT device number i, shared

with RS

Reset-key used for encryption.

Reset-key used for message authentica-

tion.

Owner-key for IoT device number

i, divided into two parts KO

{KO

, KO

}

Master-key for RS used for deriving K

N Ownership-transfer nonce.

Ctr

Counter for node i is used for verifying

freshness of nonces.

Ctr

Counter for RS, incremented at every

ownership transfer. Used for verifying

freshness of nonces.

Ownership transfer key for node i com-

posed by: KS

= PRF(K

||N||Ctr

)

Ownership-transfer token, calculated

by:

T = E(KR

, ID

new

||URL

new

||N||Ctr

MAC(KR

, ID

new

||URL

new

||N||Ctr

))

PSK

DLTS-PSK for IoT device i, generated

by PSK

= PRF(KS

||KO

)

List of IoT device identities ID =

{ID

, ID

, ..., ID

}

ID-K

List of pairs of IoT device identities and

ID-K = {(ID

, KO

), ..., (ID

, KO

)}

K List of keys K

K = {K

, K

, ..., K

}

List of owner-keys KO

, KO =

{KO

, KO

, ..., K O

}

List of keys KS

, KS =

{KS

, KS

, ..., KS

}

ID-KS List of IoT device identities and keys:

ID-KS = {(ID

, KS

), ..., (ID

, KS

)}

and DMS

new

. DMS

old

creates a list of all IoT de-

vice identities ID

called ID and a list of identities

and partial keys {ID

, KO

} called ID-K that shall

switch owner (1.1). The list of identities is signed

Sign(DMS

old

, ID). Both lists are sent to DMS

new

(1.2), DMS

new

ﬁrst veriﬁes the signature of the list,

the list of identiﬁers are then signed by DMS

new

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

The result is Sign(DMS

new

, Sign(DMS

old

, ID)), the

list ID-K is kept by DMS

new

(1.3). The list ID is sent

to RS, to prove that ownership transfer shall take place

and that both DMS

old

and DMS

new

are agreeing to the

transfer (1.4). DMS

new

also sends its identiﬁer and

URL to RS. After verifying that the list ID is cor-

rectly signed by both DMS

old

and DMS

new

(1.5), RS

can start the ownership transfer protocol.

5.3 Ownership Transfer

RS start the ownership transfer process by re-

generating the keys K

. A nonce N is gener-

ated, that together with Ctr

is used to gener-

ate the individual ownership transfer keys KS

PRF(K

||N||Ctr

) (2.1). The list of ownership trans-

fer keys ID-KS is sent to DMS

new

(2.2). The RS

creates the ownership transfer token T , with infor-

mation needed by the IoT devices, authorizing an

ownership transfer and information for how to do it.

T = E(KR

, ID

new

||URL

new

||N||Ctr

MAC(KR

, ID

new

||URL

new

||N||Ctr

)) RS sends the

token T to DMS

old

(2.3). DMS

old

forwards the Own-

ership Transfer Token T to all IoT devices (2.4).

The devices decrypts T with KR

and veriﬁes the

MAC with KR

. If the MAC veriﬁcation succeed,

the freshness of the nonce is checked by verifying

Ctr

> Ctr

(2.5). After these checks each IoT de-

vice IoT

can compute the ownership transfer key

= PRF(K

||N||Ctr

) (2.6). With KS

and KO

the IoT devices can connect to DMS

New

using DTLS-

PSK(Tschofenig, 2016). The parameters used are

PSK-ID = ID

and PSK = PRF(KS

||KO

) (2.7). Af-

ter a successful contact has been made with DMS

new

IoT

destroys KO

(2.8). DMS

new

then generates a

new key KO

(2.9). The new key KO

is sent to IoT

that also sets Ctr

to the received value Ctr

(2.10).

After DMS

new

has provisioned new keys to all IoT

devices the ownership transfer process is concluded.

DMS

new

can securely communicate with all IoT de-

vices using the new keys KO

5.4 Handling of Ownership Transfer

Failures

In the previous sections we have described the own-

ership transfer process in detail. However, there is a

risk that the ownership transfer succeeds for one set of

IoT units but not for another set due to communica-

tion errors or similar. Such situation will be detected

by the DMS

New

as it will notice that it has not been

able get in contact and authenticate some units part of

the IoT transfer list given in step 1.2. DMS

New

can

ﬁrst retransmit the ownership transfer token T to the

devices that has not changed ownership. Some proto-

cols provide a mechanism of notifying a sender that

a message has been received. Such a mechanism can

be used to verify the proper delivery of T . If T has

been delivered but an IoT device still does not con-

nect to DMS

New

the issue lies with the device IoT

that situation will have to be resolved by DMS

Old

be-

fore a new attempt can be made. In such situation, it

is possible is for DMS

New

to issue a ”recovery” pro-

cedure by sending a signed list of missing units back

to DMS

Old

, which then will be requested to contact

each of the missing IoT units (still under ownership

of DMS

Old

) over a mutual authenticated DTLS chan-

nel re-sending the transfer token, T . Such procedure

can be repeated, until the whole set of IoT units are

successfully transferred to DMS

New

6 IMPLEMENTATION AND

EXPERIMENTAL

EVALUATIONS

We have implemented our proposed protocol for an

IoT environment running Contiki-NG

. Contiki-NG

is a light-weight operating system designed for con-

strained devices. We have used some other proto-

cols to structure our data. Most signiﬁcantly we

use COSE (Schaad, 2017) to encode and encrypt the

ownership transfer tokens. We assume secure com-

munication between the RS, DMS

old

and DMS

new

The connections to the IoT devices are secured with

DTLS(Rescorla and Modadugu, 2012).

We have designed the system to use the REST-

model(Fielding, 2000). Sending the ownership trans-

fer token to the IoT device is done with a PUT op-

eration to /transfer-ownership. The IoT device then

sends a GET message to /key to receive the new keys

and KO

6.1 Test Setup

The evaluated scenario is executed on the following

setup. One Desktop PC running the RS, DMS

Old

and DMS

New

. The PC is connected to a Border-

Router that acts as an IEEE 802.15.4 network inter-

face. We have used four Zolertia Fireﬂy-A develop-

ment boards

that are going to transfer from owner

Old to New. The IoT devices are based on the cc2538

system on chip made by Texas Instruments(Texas In-

struments, 2015). They have an ARM Cortex-M3

CPU clocked at 32MHz together with 32KB of RAM

https://github.com/contiki-ng/contiki-ng

https://github.com/Zolertia/Resources/wiki/Fireﬂy

Secure Ownership Transfer for the Internet of Things

ResetServer DMS

old

DMS

new

IoT

GenerateK

GeneratenonceNand

KS.

GeneratetokenT.

Compileandsignlistof

IDsID.Createlistof

PartialKO

andID



ID-K.

ID,ID-K

Sign(DMS

old

,ID)

ExtractURIandIDfor

DMS

new

ComputeKS

ComputePSK

ConnecttoDMS

new

Decrypttoken,verify

MACandverifyCtr

DestroyKO

GenerateKO'

, KR

CtrRS, P

old

, P

new

old

, S

new

, KO

, KR

, Ctr

Verify signature of ID

Sign ID,

Save ID-K.

ID,Sign(DMS

new

,

Sign(DMS

old

,ID))

VerifysignaturesofID.

ID-KS

Forward token T to

all IoT devices

(1.1)

(1.2)

(1.3)

(1.4)

(1.5)

(2.1)

(2.2)

(2.3)

(2.4)

(2.5)

(2.6)

(2.7)

(2.8)

(2.9)

(2.10)

Authenticate with

DTLS-PSK=PSK

PSK-ID=ID

KO'

Figure 2: Messages and computations done during the ownership transfer.

and 512KB of ﬂash. Connectivity is provided by

an IEEE 802.15.4 radio providing about 100Kb/s of

bandwidth.

6.2 Test Scenario

The test scenario consists of an initial setup phase

where keys are distributed to the individual IoT nodes

and an ownership transfer phase. The initial setup

phase is not in scope for the performance evaluation,

only the ownership transfer process is included. We

ran the ownership transfer scenario, of the four IoT

devices, ten times.

6.3 Ownership Transfer Time

In order to evaluate the efﬁciency of our proposed

scheme from a system perspective we timed the entire

ownership transfer process. We measured the time

elapsed from that the RS sends out the token T to

when all IoT devices has been provisioned with new

owner keys KO

. The time taken for the ownership

transfer process is measured to a mean of 4.7s with a

95% conﬁdence interval between 4.4s and 5s.

6.4 Energy Consumption

Since the devices considered for this protocol usually

are powered by a battery it is important that the en-

ergy consumed by the IoT device when executing the

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

ownership transfer protocol is reasonable.

We have measured the energy usage on the con-

strained nodes for both the radio modem and the

CPU. The total energy consumption was measured to

a mean of 0.18mJ. With a 95% conﬁdence interval of

the mean between 0.14mJ and 0.22mJ. For compar-

isons sake, the mean energy consumption of 0.18mJ

is equal to the energy consumed by the CPU execut-

ing at full power for four seconds.

7 SECURITY ANALYSIS

We will now analyze our proposed ownership transfer

protocol in the scope of the system model presented

in Section 3 and the threat model from Section 4. We

will address each requirement from 4.3 except R13

that is a functional requirement. We give special at-

tention to the requirements R8, R9 and the require-

ment for PSK

to be secure. We formally prove these

requirements with Tamarin Prover(Basin et al., 2017).

The requirement to protect PSK

from an outside ad-

versary is important for requirements R1, R3 and R6

while backward (R8) and forward (R9) secrecy are a

core features of the suggested protocol.

R1. IoT Unit Impersonation Security: Each IoT

unit i holds a unique key K

. The nonce and

counter in the token together with this key are

used to calculate KS

. In turn, KS

and the

second part of KO

are used to calculate the

PSK, used to authenticate the connection be-

tween the IoT unit and DMS

New

. Both key parts

needed to calculate the PSK are only known to

DMS

New

apart from the IoT unit as long as the

RS and old owner do not collude, which con-

tradicts the trust assumption regarding the reset

server. Hence, given that the IoT unit itself can

securely store and keep K

, IoT impersonation is

not possible for an external attacker or DMS

Old

R2. Old DMS Impersonation Security: The own-

ership transfer is triggered by letting DMS

Old

send a signed list of IoT identities (step 1.2).

This signature is veriﬁed by the RS at step

1.5. As long as the signature scheme is se-

cure and the private key of the DMS

Old

not is

compromised, an attacker cannot impersonate

the DMS

Old

at the ownership transfer ”trigger-

ing moment”. As we do not require protected

transfer of the token (step 2.4), DMS

Old

imper-

sonation at this step is possible. However, it

is not crucial for the protocol that it is indeed

DMS

Old

that sends the token but it can be trans-

ferred in arbitrary way, as the IoT unit does

not ﬁnally accept the token unless the authen-

tication in step 2.7 is performed successfully.

The latter requires the genuine key KO

from

old owner, and this key is sent protected to the

DMS

New

at step 1.2.

R3. New DMS Impersonation Security: Similar

to the DMS

Old

, DMS

New

signs the list of IoT

IDs subject to ownership transfer (step 1.3).

This signature is veriﬁed by the RS at step

1.5. As long as the signature scheme is se-

cure and the private key of the DMS

New

not is

compromised, an attacker cannot impersonate

the DMS

New

at the ownership transfer ”triger-

ing moment”. Mutual authentication applies

at step 2.7 when the IoT unit connects to the

DMS

New

. Impersonation at this step requires

knowledge of the PSK, which (similar to the

reasoning regarding R1 above), requires knowl-

edge of both KS

and KO

, and if not the RS

and old owner collude, these two values are

only known to DMS

New

and the IoT unit itself.

Hence, DMS

New

impersonation is not possible

unless DMS

New

is compromised such that the

secure keys leaks or the secure key transfers at

step 1.2 or step 2.2 are broken. The latter is

not possible if not the mutually authenticated

secure channel is weak.

R4. RS Impersonation Security: Only DMS

New

and DMS

Old

communicate directly with RS.

They do so over a secure channel that protects

against impersonation of RS.

R5. Reply Attack Resistance: All messages be-

tween RS, DMS

Old

and DMS

New

are sent over

secure channels that provides protection against

replay attacks (steps 1.2, 1.4, 2.2 and 2.3). The

Token T transferred from DMS

Old

to IoT

(step

2.4) contains Ctr

that is veriﬁed against Ctr

by IoT

. This provides replay attack resistance

since a replayed T will be rejected due to the

counter check. When IoT

connects to DMS

New

(step 2.7) it is done with DTLS protected by

PSK

, which is only known to DMS

New

and

IoT

. This DTLS channel is also used to pro-

tect the transfer of the new credentials KO

(step

2.10).

R6. Resistance to Man-in-the-Middle Attacks

(MitM): All messages between RS, DMS

Old

and DMS

New

are sent over secure channels that

provides mutual authentication (steps 1.2, 1.4,

2.2 and 2.3) and thus prevents against MitM

attacks. Communication with the IoT devices

and DMS

New

(steps 2.7 and 2.10) is done over

DLTS-PSK that provides mutual authentication

Secure Ownership Transfer for the Internet of Things

and with MitM protection. An attacker with

knowledge of the keys KR

and KR

, can per-

form a successful man-in-the-middle substitu-

tion attack at step 2.4. Potential values to sub-

stitute are ID

new

, U RL

new

, N or Ctr

. The

IoT unit will not accept a wrong Ctr

as it is

checked against the internal counter. Further-

more, substituted ID

new

or N will not match the

PSK values used in the mutual authentication in

step 2.7 and the MitM substitution attack will

fail. A substitution of URL

new

will have no af-

fect as long as the IoT unit still reach the legit-

imate DM

new

with the given URL. If this not is

the case,the ownership transfer for the affected

unit will simple be aborted (see also the recov-

ery discussion in Section 5.4).

R7. Resistance to De-synchronization Attack: If

DMS

Old

should send a modiﬁed token, T

(through access to the keys KR

and KR

with modiﬁed nonce N

, in step 2.4, the key KS

will not match the key KS

held by DMS

New

Hence, in this case, the IoT device will not re-

move the KO

key, and will remain in the own-

ership of DMS

Old

R8. Backward Security: All trafﬁc sent between

the DMS

Old

and the IoT devices is sent over a

channel protected by the key KO

, the IoT de-

vices destroy KS

when contact is made with

DMS

New

. DMS

New

can not recover KO

and is

unable to learn any previous secrets (see also

the Tamarin proof of Section 7.1).

R9. Forward Security: After DMS

New

has made

contact with the IoT devices and the old key

has been destroyed, DMS

New

provisions a

new key KO

and sends it to the IoT devices

over a secure channel protected by the key KS

that DM S

Old

does not hold. DMS

Old

is thus un-

able to decrypt any future message sent to the

IoT devices (see also the Tamarin proof of Sec-

tion 7.1).

R10. No Double Ownership: The ownership hand-

over is made when the IoT device connects

to DMS

New

with PSK

and removes ownership

from DMS

Old

by removing KO

. DMS

New

takes

ownership when it provisions KS

to IoT

. Fail-

ure in any protocol step might results in that

some IoT units are still owned by the DM

old

However, as we discuss in Section 5.4 below,

such situation can be detected by DMS

New

and

a recovery process can be initiated.

These keys are included not to give protection against

IoT compromise but to make denial-of-service type of at-

tacks less likely.

R11. Protection of New Credentials: After the

ownership transfer process IoT

is provided

with new credentials KO

. The only way RS

can gain access to the system is by launching a

MitM attack on the DLTS connection between

IoT

and DMS

New

. Thus this property hinges on

PSK

, RS does not know KO

needed to derive

PSK

. As long as RS does not gain access to

by collusion with DMS

Old

, the new cre-

dentials are protected.

R12. IoT Compromise Resilience: If an adversary

compromises an IoT device IoT

it will gain the

following keys: KO

, KR

and K

. KO

is only shared with the current owner and used

for securing communication between the owner

and IoT device, the adversary can not imperson-

ate or compromise any other IoT device. KR

and KR

are shared with all IoT devices, an ad-

versary could try to spoof an ownership transfer

token T . Since the adversary only have KO

is impossible for the adversary to complete a

malicious ownership transfer with an other IoT

device IoT

since the adversary does not know

, thus providing resilience against compro-

mises.

7.1 Tamarin Prover

Tamarin Prover is a tool for formal analysis of secu-

rity protocols. By creating a symbolic model of a pro-

tocol, stating security lemmas and then using the au-

tomatic reasoning to analyse the model the prover can

show that the security lemmas hold or show a counter-

example of when they do not hold. Tamarin repre-

sents protocols as a multi-set rewrite rules using ﬁrst

order logic. The automatic prover represent the state

of the execution as a bag of multi-set of Facts. The

adversary model used in Tamarin is the Dolev-Yao

model.

7.2 Modeling the Ownership Transfer

Protocol

We have modeled a simpliﬁed version of our proposed

Ownership Transfer Protocol in Tamarin. We have ex-

cluded the steps 1.1 - 1.5 and 2.7 - 2.10 to prove the

correctness of the core ownership transfer steps. Dur-

ing our process to verify the security of our proposed

protocol we have introduced four lemmas. We have

created one lemma, Protocol Correctness, to verify

that our protocol can execute with a successful con-

clusion of the ownership transfer process. We have

created another lemma, Outsider secrecy, to prove

that PSK

is secret from an outside adversary. The

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

next two lemmas Old Owner Secrecy and New Owner

Secrecy are lemmas about attacks done by a party in

the protocol that misbehaves. These types of attacks

are not included in a standard Dolev-Yao model. To

solve this problem, we have chosen to give the Dolev-

Yao adversary all keys and secrets from the malicious

party. The Dolev-Yao adversary then has all the ca-

pabilities to intercept, replay and send any message

together with the capability to decrypt, encrypt and

sign messages with the keys from the malicious party.

We argue that this is a stronger attacker than a real-

world malicious Old owner or New owner would be.

We have assumed that to provide New Owner secrecy

PSK

has to be kept secret from DMS

Old

. To Provide

Old Owner Secrecy the two keys KO

and KO

have

to remain secret from DMS

New

. For the Outsider Se-

crecy Property we state that no outside party can learn

PSK

. Our Tamarin model of our proposed protocol

can be found here

Below we list the four lemmas:

L1 Protocol Correctness. The modeled protocol shall

execute as speciﬁed.

lemma protocol correctness :

exists trace

”∃ PSK1 PSK2 #i # j.

((New owner PSK(PSK1)@ #i ) ∧

(IoT PSK(PSK2 )@ # j )) ∧

(PSK1 = PSK2)”

L2 Outsider Secrecy. The Ownership Transfer pro-

tocol shall be secure against outside attackers.

No outside party shall be able to learn PS K

lemmaoutsider secrecy :

all −traces

”∀ PSK #i # j.

((((IoT PSK(PSK )@ #i ) ∧

(New owner PSK(PSK ) @ # j )) ∧

(¬(∃Old owner #k. Reveal(Old owner ) @ #k))) ∧

(¬(∃New owner #l.Reveal( New owner )@ #l))) →

(¬(∃ #k. K(PSK)@ #k))”

L3 Old Owner Secrecy. The New Owner shall not be

able to learn anything that has been sent before the

ownership transfer, thus KO

and KO

has to be

secure against an adversary that knows everything

DMS

New

knows. lemmabackwards secrecy :

all −traces

”∀ New owner PSK #i # j #k.

((((IoT PSK(PSK )@ #i ) ∧

(New owner PSK(PSK ) @ # j )) ∧

(Reveal(New owner )@ #k)) ∧

(¬(∃Old owner #l. Reveal(Old owner )@ #l))) →

(¬(∃ OwnerKey1 OwnerKey2 #m #n.

(K(OwnerKey1)@ #m) ∧ (K(OwnerKey2)@ #n)))”

https://github.com/Gunzter/

iot-ownership-transfer-protocol-tamarin-model

L4 New Owner Secrecy. The Old owner shall not be

able to learn anything that occurs after the ownership

transfer is complete. No adversary that knows every-

thing DMS

Old

shall be able to learn PSK

lemma f orward secrecy :

all −traces

”∀ Old owner PSK #i # j #k.

((((IoT PSK(PSK )@ #i ) ∧

(New owner PSK(PSK ) @ # j )) ∧

(Reveal(Old owner )@ #k )) ∧

(¬(∃New owner #l. Reveal(New owner )

@ #l))) → (¬(∃ #m.K(PSK)@ #m))”

Using our modeled protocol we let Tamarin prove

the four stated lemmas. All of them were found to

hold. We conclude that our protocol gives us the re-

quired security properties.

8 CONCLUSION

In this paper we have identiﬁed the need for a light-

weight, i.e. symmetric key based, ownership trans-

fer protocol for IoT devices. We have studied the re-

lated ﬁeld of ownership transfer for RFID tags and, in-

spired by previous work, identiﬁed the main security

requirements for IoT infrastructure ownership trans-

fer. A novel protocol was then constructed. We be-

lieve the proposed scheme fulﬁls all the identiﬁed re-

quirements. The protocol was veriﬁed in a proof-of-

concept implementation and shown to be indeed as

light-weight as expected. The transfer-time is non-

negligible for resource constrained IoT units, but on

the other hand, ownership transfer typically happens

quite rarely. We performed a security analysis of the

proposed scheme with special attention to the back-

ward and forward secrecy with respect to old and

new owner. These security properties were formally

proven using the Tamarin Prover.

Since the ﬁeld of ownership transfer protocols and

mechanisms in IoT is relatively unexplored we see

many approaches for further work. Evaluating the

performance of protocols in very large infrastructures,

i.e. in the order of ten to hundred thousand IoT units.

We would also like to verify the protocol in real sys-

tems such as industrial control systems or building au-

tomation. Investigating other approaches to the solu-

tion where no trusted third party is involved is also an

interesting avenue of research. Lastly, since the ﬁeld

of IoT is in its infancy it would be interesting to look

into more complex ownership models with multiple

owners and the ability to temporary transfer owner-

ship and control, i.e. to lend or rent, the IoT devices

to another entity for a limited time.

Secure Ownership Transfer for the Internet of Things

REFERENCES

Bagheri, N., Aghili, S. F., and Safkhani, M. (2018). On the

security of two ownership transfer protocols and their

improvements. Int. Arab J. Inf. Technol., 15(1):87–93.

Basin, D., Cremers, C., Dreier, J., and Sasse, R. (2017).

Symbolically Analyzing Security Protocols using

Tamarin. ACM SIGLOG News.

Burmester, M., de Medeiros, B., and Motta, R. (2008).

Provably secure grouping-proofs for rﬁd tags. In Gri-

maud, G. and Standaert, F.-X., editors, Smart Card

Research and Advanced Applications, pages 176–190,

Berlin, Heidelberg. Springer Berlin Heidelberg.

Cao, T., Chen, X., Doss, R., Zhai, J., Wise, L. J., and Zhao,

Q. (2016). Rﬁd ownership transfer protocol based on

cloud. Computer Networks, 105:47 – 59.

Aaz, M., Mart

An, C., and Rubio, B. (2016). State-of-

the-art, challenges, and open issues in the integration

of internet of things and cloud computing. Journal of

Network and Computer Applications, 67:99 – 117.

Dolev, D. and Yao, A. C. (1981). On the security of pub-

lic key protocols. In Proceedings of the 22Nd An-

nual Symposium on Foundations of Computer Sci-

ence, SFCS ’81, pages 350–357, Washington, DC,

USA. IEEE Computer Society.

Eisenbarth, T., Kumar, S., Paar, C., Poschmann, A.,

and Uhsadel, L. (2007). A survey of lightweight-

cryptography implementations. IEEE Design Test of

Computers, 24(6):522–533.

Eronen, P., Nir, Y., Hoffman, P. E., and Kaufman, C. (2010).

Internet Key Exchange Protocol Version 2 (IKEv2).

RFC 5996.

Fielding, R. (2000). Representational state transfer. Ar-

chitectural Styles and the Design of Netowork-based

Software Architecture, pages 76–85.

He, L., Gan, Y., and Yin, Y. (2014). Secure group ownership

transfer protocol with independence of old owner for

rﬁd tags. Computer modelling and new technologies,

18(12B):209 – 214.

Inc., E. (2008). Epc radio-frequency identity protocols

class-1 generation-2 uhf rﬁd protocol for communica-

tions at 860 mhz – 960 mhz. Report 1.2.0, EPCglobal

Inc.

Kapoor, G. and Piramuthu, S. (2008). Protocols for objects

with multiple rﬁd tags. In 2008 16th International

Conference on Advanced Computing and Communi-

cations, pages 208–213.

Kapoor, G., Zhou, W., and Piramuthu, S. (2011). Multi-

tag and multi-owner rﬁd ownership transfer in supply

chains. Decision Support Systems, 52(1):258–270.

Khan, M. S. N., Marchal, S., Buchegger, S., and Asokan,

N. (2019). chownIoT: Enhancing IoT Privacy by Au-

tomated Handling of Ownership Change, pages 205–

221. Springer International Publishing, Cham.

Lanza, J., Sotres, P., S

anchez, L., Galache, J. A., Santana,

J. R., Guti

errez, V., and Mu

noz, L. (2016). Manag-

ing large amounts of data generated by a smart city

internet of things deployment. Int. J. Semant. Web Inf.

Syst., 12(4):22–42.

Oded, G. (2009). Foundations of Cryptography: Volume 2,

Basic Applications. Cambridge University Press, New

York, NY, USA, 1st edition.

Pradeep, B. H. and Singh, S. (2013). Ownership authenti-

cation transfer protocol for ubiquitous computing de-

vices. In 2013 International Conference on Computer

Communication and Informatics, pages 1–6.

Rescorla, E. and Modadugu, N. (2012). Datagram Trans-

port Layer Security Version 1.2. RFC 6347.

Roman, R., Najera, P., and Lopez, J. (2011). Securing the

internet of things. Computer, 44(9):51–58.

Saied, Y. B. and Olivereau, A. (2012). D-hip: A distributed

key exchange scheme for hip-based internet of things.

In 2012 IEEE International Symposium on a World

of Wireless, Mobile and Multimedia Networks (WoW-

MoM), pages 1–7.

Saito, J., Imamoto, K., and Sakurai, K. (2005). Reassign-

ment scheme of an rﬁd tag’s key for owner transfer.

In International Conference on Embedded and Ubiq-

uitous Computing, pages 1303–1312. Springer.

Schaad, J. (2017). Cbor object signing and encryption

(cose). RFC 8152, RFC Editor.

Sundaresan, S., Doss, R., Zhou, W., and Piramuthu, S.

(2015). Secure ownership transfer for multi-tag

multi-owner passive rﬁd environment with individual-

owner-privacy. Computer Communications, 55:112 –

124.

Tam, P. and Newmarch, J. (2004). Protocol for ownership

of physical objects in ubiquitous computing environ-

ments. In IADIS international conference E-Society,

volume 2004, pages 614–621.

Taqieddin, E., Al-Dahoud, H., Niu, H., and Sarangapani,

J. (2018). Tag ownership transfer in radio frequency

identiﬁcation systems: A survey of existing protocols

and open challenges. IEEE Access.

Texas Instruments, I. (2015). Cc2538 powerful wire-

less microcontroller system-on-chip for 2.4-ghz ieee

802.15. 4, 6lowpan, and zigbee applications. CC2538

datasheet (April 2015).

Tschofenig, H. (2016). and t. fossati,” transport layer

security (tls)/datagram transport layer security (dtls)

proﬁles for the internet of things. Technical re-

port, RFC 7925, DOI 10.17487/RFC7925, July 2016,¡

http://www. rfc-editor. org/info . . . .

ogler, M., Schleicher, J. M., Inzinger, C., and Dustdar, S.

(2016). A scalable framework for provisioning large-

scale iot deployments. ACM Trans. Internet Technol.,

16(2):11:1–11:20.

Zhou, W., Yoon, E. J., and Piramuthu, S. (2012). Simul-

taneous multi-level rﬁd tag ownership & transfer in

health care environments. Decision Support Systems,

54(1):98–108.

Zuo, Y. (2010). Changing hands together: a secure group

ownership transfer protocol for rﬁd tags. In System

Sciences (HICSS), 2010 43rd Hawaii International

Conference on, pages 1–10. IEEE.

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy