Towards Formal Security Veriﬁcation of Over-the-Air Update Protocol:

Requirements, Survey and UpKit Case Study

Christophe Ponsard and Denis Darquennes

CETIC Research Centre, Charleroi, Belgium

Keywords:

Cybersecurity, Formal Modelling, Veriﬁcation, Update Protocol, Internet of Things.

Abstract:

The fast growing number of connected devices through the Internet of Things requires the capability of per-

forming secure and efﬁcient over-the-air updates in order to manage the deployment of innovative features

and to correct security issues. Pushing an updated image in a device requires a complex protocol exposed to

security threats which could be exploited to block, spy or even take control of the updated device. Hence, such

update protocols need to be carefully designed and veriﬁed. In the scope of this paper, we review some rep-

resentative update protocols and related threats based on MQTT, TUF (Uptane) and the blockchain. We then

show how the adequate management of those threats can be veriﬁed using a formal modelling and veriﬁcation

approach using the Tamarin tooling. Our work is applied to the concrete case of the UpKit protocol which

exhibits an interesting design.

1 INTRODUCTION

The Internet of Things (Iot) is a key driver of the

digitisation of our society and economy by provid-

ing global interconnection between objects and peo-

ple through communication networks. It is quickly

expanding to all domains, including consumers (e.g.

smart homes), transportation (e.g. connected cars,

railways signaling protocol) and manufacturing (In-

dustry 4.0). In 2020, the number of IoT endpoints will

reach 5.8 billion with an annual growth rate of about

20% which is expected to continue over the coming

years (Gartner, 2019).

Achieving an efﬁcient maintenance of such a large

network is critical to ensure the progressive deploy-

ment of applications and to update them with new

features, functional improvements or security patches

(Acosta Padilla et al., 2016). Physical maintenance

is cost-prohibitive and too much time-consuming for

most implementations, so remote updates are used to

ensure the evolution of the ﬁrmware code running in-

side the IoT devices. Such updates may even be car-

ried out over-the-air for mobile devices such as in

connected cars.

Of course, the update phase is a critical process

requiring to go through different steps. Key steps of

a typical update process are depicted in Figure 1: the

vendor (V) generates a new ﬁrmware which is made

available for distribution by speciﬁc repositories (R)

from which it is transferred to the target device (D),

possibly through some intermediary device (e.g. a

smartphone). Optionally, secondary devices (S) un-

der the control of the main device can also be updated

in the same process (e.g. secondary ECUs in a car).

The various communication links cannot be assumed

secured Hence, end-to-end security needs to be en-

forced to avoid any security threats which could be

exploited by an attacker to block the updated device

or to inject some malware to start spying, stealing data

or even to take control over the device.

Figure 1: Global overview of ﬁrmware update process.

This paper aims at giving a comprehensive overview

about existing ﬁrmware update protocols and how

the securely of such protocols can be assessed. Our

goal is not to perform an exhaustive survey but rather

to show commonalities and differences and also to

highlight useful tools to understand and analyse more

deeply those protocols using formal modelling and

veriﬁcation. For this purpose, we selected one of the

studied protocol called UpKit and used the Tamarin

tool to illustrate how typical security properties can

be speciﬁed and analysed. Based on this, we also dis-

cuss some lessons learned so far and identify some

800

Ponsard, C. and Darquennes, D.

Towards Formal Security Veriﬁcation of Over-the-Air Update Protocol: Requirements, Survey and UpKit Case Study.

DOI: 10.5220/0010431408000808

In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 800-808

ISBN: 978-989-758-491-6

research directions to deepen our work and the work

of others in this ﬁeld.

The paper is structured as follows. First, Section 2

reminds about the main security requirements for per-

forming ﬁrmware updates and reports about some

known attacks targeting those requirements. Section 3

then reviews how some representative implementa-

tions cope with those requirements and attacks by

providing informal justiﬁcation. Section 4 shows how

formal modelling and veriﬁcation can provide deeper

conﬁdence on the correctness of an update protocol

based on the Tamarin tool. Section 5 discusses some

lessons learned so far about designing and verify-

ing such protocols. Finally, Section 6 concludes and

presents our future work.

2 KEY SECURITY

REQUIREMENTS AND

RELATED ATTACKS

Firmware is a very sensitive information to protect.

The key requirements are that:

• Only Genuine Firmware may be Installed on

Managed Devices. This requirement relates to

integrity of the image and authentication of the

source, both can be achieved using digital signa-

tures.

• The Process Must be Transactional: either suc-

ceed with new version of keep old version but not

result in a bricked state of the updated device.

• Devices can Only Upgrade and Generally to the

Last Version. Downgrading can result in lost of

compatibility and also exposes to vulnerabilities

corrected in a more recent version.

• Devices Need to Updated in Some Deﬁned Time

Frame. It means the system must be available and

the freshness of the requests must be guaranteed.

• A Proof of Update May be Required, e.g. to make

sure all managed devices have been correctly up-

dated.

• In Case of Dependencies among Subsystems, All

Subsystems Must be Updated Consistently, hence

the need for a protocol involving primary/sec-

ondary devices. This is a consistency property.

• The Firmware Itself Shall not be Analysable by

Third Parties. This is a conﬁdentiality security

property and requires to secure communications

with encryption techniques.

An attacker targeting a ﬁrmware update system might

aim at trying to:

• Read the Firmware, in order to extract some infor-

mation from it. This may be designed secret but

also possibly as a preparation phase for a more

elaborated attack, e.g. to install a malware in the

IoT device.

• Block Updates, preventing the deployment of new

functions and keeping the infrastructure vulnera-

ble.

• Block the System, making the system unavailable

through some form of corrupted updates.

• Take Control of the System, through the instal-

lation of its own code, possibly to issue mali-

cious/harmful commands, to steal information or

to progress in the achievement of a larger attack.

Based on the above requirements and attacker goals,

a number of attacks on update systems are already

known:

• Arbitrary Software Installation. An attacker is

able to install its own image in response to down-

load request without being detected.

• Indeﬁnite Freeze Attacks. The attacker replaces

updates by current version preventing all update.

• Rollback Attacks: the attacker is able to install an

old version that may contain vulnerabilities.

• Fast-forward Attacks. The attacker increases the

version number and makes it difﬁcult to recover a

legitimate versions appearing as rollbacks.

• Distributed Denial of Service Attack. The attacker

is ﬂooding an update server with requests so it will

crash or won’t be able to serve legitimate requests.

• Endless Data Attacks. The attacker responds to

a ﬁle download request with an endless stream of

data, possibly causing failures if the case is not

well managed.

• Slow Retrieval Attacks. An attacker responds to

clients with a very slow stream of data preventing

update process to complete.

• Mix-and-Match Attacks. An attacker presents

clients with inconsistent bundles resulting in up-

date failures or other complications.

• Wrong Software Installation. An attacker pro-

vides a client with a trusted ﬁle that is just not

the one the client wanted.

• Vulnerability to Key Compromises. An attacker

can take control of private keys, especially in sys-

tem relying on a single key.

Towards Formal Security Veriﬁcation of Over-the-Air Update Protocol: Requirements, Survey and UpKit Case Study

801

Figure 3: TUF+Uptane Architecture (Asokan et al., 2018).

3 SURVEY OF FIRMWARE

UPDATE PROTOCOLS

This section reviews and compares different update

protocols. The aim is not to be exhaustive but more

representative of existing solutions in order to be able

to discuss them. A more systematic survey is pro-

posed by (Mtetwa et al., 2019).

3.1 MQTT-based Design

Message Queuing Telemetry Transport (MQTT) is

a lightweight, publish-subscribe network protocol to

transport messages between devices. It is an open

OASIS and ISO standard (ISO/IEC 20922) (OASIS,

2019) and is designed to ﬁt IoT needs with devices

with small code footprint and/or limited bandwidth.

Various ﬁrmware update implementations rely on this

protocol and some of its features such as the publish/-

subscribe protocol. As part of the FreeRTOS Real-

time operating system for microcontrollers, an over-

the-air (OTA) client library is available to manage the

notiﬁcation of a newly available update, download the

update, and perform cryptographic veriﬁcation of the

ﬁrmware update using MQTT, with also the ability to

manage secondary devices (AWS, 2020).

Figure 2: MQTT-based design.

An MQTT-based update protocol is also speciﬁed in

details in (Lo and Hsu, 2019) and depicted in Fig-

ure 2. The ﬁrst and second steps rely on MQTT to

mutually authenticate a ﬁrmware patch server and a

ﬁrmware broker server, to establish the session key

between them and to transfer a new ﬁrmware. Its in-

tegrity and source are then veriﬁed. The third and

fourth phases also utilize MQTT to mutually authen-

ticate the broker server and the gateway and then pub-

lish the new ﬁrmware to the gateway. Again, the

ﬁrmware integrity and source are veriﬁed. The ﬁ-

nal ﬁfth phase mutually authenticates the gateway and

the IoT device before dispatching the new version of

ﬁrmware to the corresponding IoT device where is is

installed.

3.2 TUF/Uptane Automotive Design

The Update Framework (TUF) is a ﬂexible frame-

work to secure new and existing software update sys-

tems. It was designed in 2010 to meet the needs of

a wide variety of software update systems, to eas-

ily integrate with existing software update systems

(Samuel et al., 2010). It is characterised by a high re-

silience against compromised keys and other attacks

that can spread malware in a repository or inside an

device. It is based on the deﬁnition of separate roles

which sign speciﬁc aspects of the metadata with their

own keys. In addition, TUF requires a threshold num-

ber of signatures, supports for explicit and implicit

revocation of keys, and can mandate the ofﬂine man-

agement of vulnerable keys.

Uptane is a variant of TUF which better ﬁts the

needs of consistently updating the several Engine

Control Unit (ECUs) found in cars (Kuppusamy et al.,

2018). It is organised in two levels: more power-

ful primary ECUs are managing simpler secondary

ECUs. The main addition is the introduction of a di-

rector repository to manage the update process and

two levels of veriﬁcation (full or partial). It is resilient

to the best efforts of nation state attackers and has be-

come the de facto standard in automotive. It is also

considered for adaptation in other domains, e.g. rail-

ways (Galibus, 2019).

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

802

Figure 4: UpKit Update Architecture (Langiu et al., 2019).

Figure 3 shows the sequence of events in Uptane. (1)

the primary ECU reports a vehicle version manifest

(i.e. its signed software conﬁguration) to the remote

director repository, along with the Vehicle Identiﬁca-

tion Number (VIN). (2) The director repository deter-

mines the correct, up-to-date software conﬁguration

for all ECUs of the target vehicle and signs director

metadata describing all software artifacts each ECU

must install. (3-5) The primary ECU retrieves and

veriﬁes all metadata and software artifacts on behalf

of secondary ECUs and (5) distributes them over the

vehicle’s local-area network along with the metadata.

Secondary ECU may only perform a partial veriﬁca-

tion of the director signature if not powerful enough

to perform a full veriﬁcation.

3.3 Lightweight UpKit Design

UpKit is a portable and lightweight software update

framework for constrained IoT devices (Langiu et al.,

2019). It proposes a reﬁned update architecture in-

dependent of the ﬁrmware distribution channels. It

covers all phases of the update process of Figure 1.

It is able to guarantee update freshness thanks to a

double-signature process and can reject invalid soft-

ware at an early stage to avoid an unnecessary reboot

which could impact availability.

The full process is detailed in Figure 4. It starts

with a classical generation phase where (1-2) the im-

age is transferred to the image repository together

with a manifest allowing its veriﬁcation. In the prop-

agation phase, (3) the new version is advertised for

availability and (4-6) target devices send back a re-

quest token which is used in (7) to generate a request

speciﬁc ﬁrmware image (possibly differential for re-

ducing footprint and processing needs) together with

the addition of a second signature from the repository

server. (8) The image and manifest can then be trans-

ferred to the device possibly through intermediary de-

vices such as a smartphone. In the IoT device, an up-

date module is running in front of the bootloader and

(9) performs an early check of the double manifest

signatures. Only in case of success (10), the image is

transferred (11-13) to go in the loading phase. In (16-

17), a ﬁnal veriﬁcation occurs just before (18) switch-

ing versions otherwise the current image is kept.

3.4 Blockchain-based Design

In contrast with the previous architectures based on

the client-server model, a blockchain architecture is

proposed in (Lee and Lee, 2017). Blockchain is an

open, distributed ledger that can record transactions

between two parties efﬁciently and in a veriﬁable and

permanent way (Iansiti and Lakhani, 2017). It is thus

interesting both for its ability to ensure integrity but

also for its distributed nature resulting in a high re-

silience compared to client-server architecture where

the server is a single point of failure that can undergo

Distributed Denials of Service (DDoS) attacks.

Figure 5 shows the blockchain-based ﬁrmware

update. The manifest is distributed through the

blockchain network and contains a unique hash value

of the ﬁrmware image. Images are stored in a dis-

tributed ﬁle system with hash values of ﬁrmware im-

ages being stored in the blockchain. To cope with

the limited computational of IoT devices, all veriﬁ-

cations are performed by blockchain nodes. Speciﬁc

blockchain nodes are conﬁgured to manage the reg-

istration, i.e. to upload the manifest and ﬁrmware

image) and the retrieval, i.e. to handle IoT devices

requests for manifest and ﬁrmware images.

Figure 5: Blockchain-based ﬁrmware update platform (Lee

and Lee, 2017).

The Update process is as follows:

1. author registration of a new ﬁrmware to a regis-

tration node.

2. registration check: the author is registered if not

yet and the manifest is checked against the author

Towards Formal Security Veriﬁcation of Over-the-Air Update Protocol: Requirements, Survey and UpKit Case Study

803

Table 1: Comparison summary.

Design Comm. Image

Integrity

Image

Freshness

Image

Availability

Secondary

Update

Other remarks

MQTT-

based

MQTT Signature Publish/

Server Yes for

OpenRTOS

TUF

Uptane

Generic Multiple

signatures

Timeserver Server Yes Multiple roles

Partial Verif.

UpKit Generic Double sig-

nature

Double sig-

nature

Server No Early check

Blockchain Generic Hash in

blockchain

Blockchain Distributed No Blockchain

processing (trust)

public key.

3. manifest stored in the blockchain which cannot be

deleted nor tampered.

4. ﬁrmware image stored on distributed ﬁle system

with control hashed kept in the blockchain.

5. IoT devices perform periodic check for updates

and blockchain provides last version information

which can trigger an update process.

6. manifest downloaded to the IoT device (assuming

secured channel).

7. image downloaded to the device from the P2P ﬁle

system and checked using the author public key.

Key advantages over client-server architecture are

that the repository cannot be tampered, that update

will stay available even if the vendor disappears and

that it can also cope with DDoS attack. It also moves

computation tasks to the blockchain provided a trust

assumption can be made.

3.5 Comparison Summary

Table 1 summarises the main security characteristics

of the presented update protocols. Note that conﬁ-

dentiality is not covered here although ﬁrmware anal-

ysis could help gaining knowledge about vulnerabil-

ities, the most important requirements are integrity

and availability. With respect to integrity MQTT pro-

vides simple signatures while Uptane/UpKit supports

more elaborated signatures schemes. Blockchain is

also very good to ensure image integrity, especially

avoiding the tampering of the repository itself. A

weak point of Uptane is the time server based de-

sign which is addressed by UpKit using a delivery

protocol on an instance basis. The blockchain de-

sign can provide trusted timestamping services at the

required precision although the precise timekeeping

on distributed system is known to be a harsh problem

(Hong, 2020). Image availability is also more reliable

on a blockchain design given the distributed nature

compared to the traditional server-based design of the

other solutions.

The rest of this paper will focus on UpKit protocol

as simple and lightweight protocol to illustrate how

to carry out a veriﬁcation activity against some of the

identiﬁed security requirements.

4 FORMAL MODEL AND

PARTIAL VERIFICATION OF

THE UpKit PROTOCOL

A striking fact is that some industrial protocols like

TUF and Uptane claim to be able to cope with at-

tacks at nation state level but the available papers

only provide informal arguments about how the pro-

tocol design is achieving such resistance (Kuppusamy

et al., 2018). When deploying security critical proto-

cols to manage large network of devices, it is interest-

ing to produce more rigorous analysis and evidence

that the protocol is able to ensure security require-

ments and resists known attack patterns described in

Section 2. Some generic formal tools have been ap-

plied to formal security veriﬁcation, e.g. Alloy (Gr-

isham et al., ). However, analysing security requires

to reason about knowledge, to model speciﬁc crypto-

graphic primitives (e.g. hashing, signing, PKI infras-

tructure) and to capture the attacker behaviours (e.g.

Dolev-Yao adversary model (Dolev and Yao, 1983)).

In the scope of this work, we selected the Tamarin

tool (Basin et al., 2017) which has proven its ability to

analyse complex protocol and to manage the tracking

of design changes. It was also already used to model

IoT protocols (Kim et al., 2017). Unbounded veriﬁca-

tion tools such as ProVerif (Blanchet et al., 2005) are

also reported to be efﬁcient, but without guarantee of

termination in the case of complex protocol.

This section ﬁrst introduces the general infrastruc-

ture and the attacker capabilities before performing

partial veriﬁcation on the generation and propagation

phases of the UpKit protocol presented in Section 3.3.

Various Tamarin constructs are also introduced.

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

804

4.1 Infrastructure Modelling

Listing 1 details how distribution actors can declare

a pair of public/private keys and a device can be at-

tributed an ID. Generic Tamarin rules are used for this

and take the form [ precondition ] --[ action

]-> [postcondition]. A fresh fact is used to gen-

erate new values, e.g. a fresh key Fr(˜ltkA), which

can be associated with speciﬁc public variables ($A)

using a speciﬁc fact to record that knowledge, e.g.

!Ltk($A,˜ltka). A public Out channel is available

to send information and make it known by everybody,

including attackers, e.g. Out(pk(˜ltkA)) is dis-

tributing the public key. In addition, the Reveal

ltk

rule shows how to model the fact and attacker might

compromise a private key.

Listing 1: Modelling: PKI and devices identiﬁcation.

/ / P u b l i c k e y i n f r a s t r u c t u r e

r u l e R e g i s t e r p k :

[ Fr (∼l tkA ) ] / / f r e s h p r i v a t e key

−−>

[ ! L tk ($A , ∼l t k A )

/ / p r i v a t e k e y known by o wner

, ! Pk ( $A , pk (∼l t k A ) )

/ / co r r e s p o n d i n g p u b l i c k e y

, Out ( pk (∼l t k A ) ) ] / / p u b l i c k e y i s p u b l i c

r u l e R e g i s t e r d e v i c e :

[ Fr (∼i d ) ] / / g e n e r a t e d e v i c e ID

−−>

[ ! I d ( $D ,∼i d ) / / ID known by d e v i c e

, Out (∼i d ) ] / / ID p u b l i c

/ / Co mp ro mi s in g an a g e n t ’ s p r i v a t e ke y

r u l e R e v e a l l t k :

[ ! L tk (A, lt k A ) ] / / k e y i n q u e s t i o n

−−[ R e v e al (A) ]−>

/ / r e v e a l a c t i o n ( f o r u s e i n lemma )

[ Out ( lt kA ) ] / / p r i v a t e k ey d i v u l g a t e d

4.2 Generation Phase

Listing 2 shows the generation phase which is based

on two rules respectively modelling the emission

by the vendor V 1 send img and reception by the

repository Repo 1 recv img of an image together

with its manifest (simply the signature here). Spe-

ciﬁc predicates capture the send and receive ac-

tions as well as the signature veriﬁcation. Signa-

ture primitives are directly available through the sign-

ing builtin package. Two proof lemmas are used:

the repo

update possible simply checks that the

model can produce traces for transferring an image

while the vendor authentication lemma captures

the security requirement that the repository can only

record a correctly veriﬁed image unless the private

key has been compromised (cf. attacker capabilities).

In order to perform the veriﬁcation, traces are re-

stricted only to those verifying the signature. Tamarin

autoprovers manage to prove both lemmas almost in-

stantly.

Listing 2: Veriﬁcation of the generation phase.

/ / Ven do r V s e n d s f i r m w a r e t o r e p o s e r v e r

r u l e V 1 s e n d im g :

l e t img = <V, ∼fw>

i n

[ Fr (∼fw )

, ! Lt k (V, l tk V )

, ! Pk ( R , pkR ) ]

−−[ SendToRepo ( V, img ) ]−>

[ Out(<img , s i g n ( img , l tk V )> ) ]

/ / Upd at e r e p o s e r v e r r e c e i v i n g f i r m w ar e

r u l e R e p o 1 r e cv i m g :

l e t img=<V, fw> i n

[ ! Pk (V, pkV )

, ! Lt k (R , l t k R )

, I n (<img , s i g >)

, F r (∼n e w Ver s i o n ) ]

−−[ R ecvIn Repo (R , img )

, Eq ( v e r i f y ( s ig , img , pkV ) , t r u e )

, A u t h e n t i c ( V, img ) , H o n e st (R ) , H o nest (V)

, RepoNewImage ( R , img ) ]−>

[ ! Repo ( R , fw , V , s i g ) ,

Out (∼n ewVe r s ion ) ]

r e s t r i c t i o n E q u a l i t y :

” A l l x y # i . Eq ( x , y ) @i ==> x = y ”

lemma r e p o u p d a t e p o s s i b l e :

/ / ch e c k i n g mo de l n o t v o i d

e x i s t s −t r a c e

”Ex S R img # i # j . SendToRepo ( S , img ) @i

& R ecvIn Repo (R , img ) @j”

lemma v e n d o r a u t h e n t i c a t i o n : / / s e c u r i t y p r o p e r t y

” A l l b m # i . A u t h e n t i c ( b ,m) @i

==> ( Ex # j . SendToRepo ( b ,m) @j & j<i )

| ( Ex B # r . Re v e a l ( B ) @r & Hon e s t ( B) @i & r < i ) ”

end

4.3 Propagation Phase

The propagation phase is described in Listing 3. Af-

ter advertising a new image is available, the mani-

fest is enriched with a second signature correspond-

ing to match a speciﬁc request from the device to en-

force freshness. The model is quite similar to the pre-

vious generation phase except the exchange is initi-

ated by the repository. Again two lemmas are used:

device check possible checks about the feasibil-

ity of the exchange to detect ﬂaws in the model and

double signature ok checks the second signature,

Towards Formal Security Veriﬁcation of Over-the-Air Update Protocol: Requirements, Survey and UpKit Case Study

805

again provided the attacker has not compromised the

repository private key. Note the model is simpliﬁed as

the intermediary smartphone is not modelled and the

ﬁrst signature is not checked given the image was not

yet requested. Again Tamarin autoprovers manage to

check the solution almost instantaneously.

Listing 3: Veriﬁcation of the generation phase.

r u l e D 3 Token :

[ I n ( n e wVer s i on ) ,

! I d (D, i d ) ,

Fr (∼r e q ) ]

−−[ D e vi c e Re qu es t (D,∼r e q ) ]−>

[ ! Token (D,∼r e q )

, Out (∼r e q ) ]

r u l e R 7 Up d a t e :

[ I n ( re q ) ,

! Repo ( R , fw , V, s i g ) ,

! Ltk (R , l tk R ) ]

−−>

[ Out(< s ig , s i g n (< s i g , req >, l t k R )>) ]

r u l e D 9 m a n i f e s t :

[ I n (< s i g , s i g 2 >) ,

! Token (D, t o k ) ,

! Pk ( R , pkR ) ]

−−[ Eq ( v e r i f y ( s i g 2 ,< si g , tok >,pkR ) , t r u e ) ,

Man ifest OK (D, s i g ) ]−>

[ ! Checked (D , s i g ) ]

r e s t r i c t i o n E q u a l i t y :

” A l l x y # i . Eq ( x , y ) @i ==> x = y ”

lemma d e v i c e c h e c k p o s s i b l e :

e x i s t s −t r a c e

”Ex R D s i g # i # j . RepoNewImage (R , s i g ) @i

& M anife stOK (D, s i g ) @j”

lemma d o u b l e s i g n a t u r e o k :

” A l l D s i g # i . Man if estOK (D, s i g ) @i

==> ( Ex R # j . RepoNewImage ( R , s i g ) @j & ( j<i ) )

| ( Ex B # r . Re v e a l ( B ) @r & ( r<i ) ) ”

5 DISCUSSION OVER RELATED

WORK

The comparison of our work with a systematic survey

(Mtetwa et al., 2019) reveals that we cover two key

categories of designs: server-based and block-chained

based. The survey identiﬁed 5 blockchain solutions

while we identiﬁed only 2 of them but we could cap-

ture all the important features of such solution. Over

the air update to vehicles is largely present in the sur-

vey and in our work, although the authors seems to

have missed TUF, Uptane and UpKit. On the techno-

logical side, we also detailed a MQTT-based solution

which is is more at implementation level but used in

frameworks such as OpenRTOS from Amazon.

Modelling using a formal language and tool as al-

ways a noticeable learning curve. In our case, the

Tamarin tooling is quite easy to install and beneﬁts

from a nice web interface. Many reference docu-

ments are available: manual, tutorial and an impor-

tant model repository together with explanatory pa-

pers (Tamarin Team, 2016). However, getting into the

notations with the correct state of mind requires some

effort. Developing a model is a progressive endeavor

relying of different progressive milestones where in-

termediary checks can be introduced. In our case, the

division into different logical phases was a natural de-

composition of the problem. During the work, we

also identiﬁed a number of modelling patterns, e.g.

to deal keys, identiﬁers, signatures, speciﬁc agents

which can be quite systematically reused to accelerate

the modelling and veriﬁcation of the remaining steps.

So far, the process mainly helped to clarify the

speciﬁcation and to precisely deﬁne what is required

as information in the various requests. The model is

still partial but can easily be extended to cover the

full update cycle. The knowledge gained can also be

applied to more complex processes than UpKit, for

example Uptane to cope with the split of responsibili-

ties across different roles with speciﬁc keys and more

complex conﬁguration including secondary updates.

Modelling the timeserver seems also possible using

the time ordering operators. Some attacks at techni-

cal level seem however beyond the reach of formal

validation tools such as the direct control of the com-

munication stream unless this is explicitly prohibited

through the use of secured channels.

Tamarin has been widely used for verifying secu-

rity protocols. Related to IoT, it has been applied to

the formal analysis of the Sigfox, LoRa and MQTT

protocols (Kim et al., 2017). Those authors show that

the majority of IoT protocols are vulnerable to cryp-

tographic DoS attacks and propose a protection based

on a server puzzle. In this work, we did not model

such attacks at this point but identiﬁed blockchain de-

sign providing a more intrinsic protection to such at-

tacks due to the absence of single pointer of failure at

server repositories. However, we did not investigate

possible performance or scalability issues related to

this technology.

Another formal veriﬁcation approach is to con-

sider statistical model checking where attack success

has some probability. A simulation-based approach is

used to reason about precise properties speciﬁed in a

stochastic temporal logic (Legay et al., 2019). How-

ever, these techniques are currently used to perform a

more abstract form of security analysis based on at-

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

806

tack and defense trees. This results in quantitative

analysis techniques using tools such as Uppaal (Ku-

mar and Stoelinga, 2017) or PRISM (Aslanyan et al.,

2016). In our work, we identiﬁed threats and coun-

termeasures but did not organise them in a systematic

attack-defense tree. This could be another comple-

mentary approach to analyse the system security.

6 CONCLUSION AND NEXT

STEPS

In this work, we reviewed a representative sample of

ﬁrmware update protocols and identiﬁed how they can

cope with security requirements and related attacks.

We highlighted the need of a more formal veriﬁca-

tion approach. We proposed a partial modelling of

the UpKit protocol and could successfully verify key

integrity and freshness properties. Although partial

and anchored in a speciﬁc protocol, our results so far

show several commonalities and the modelling and

veriﬁcation approach can be generalised to most pro-

tocols and security properties. The sketched approach

can also be used to verify security properties on the

MQTT or Uptane protocols. The distributed nature of

the blockchain design requires speciﬁc techniques to

get security assurance. They can however be captured

by assumptions to carry out proofs on the interaction

between the device and the blockchain.

In the next steps of our research, we plan to cover

the lasts steps of the UpKit protocol and then to model

the more complex Uptane protocol, including mul-

tiple roles with related keys, secondary ECUs and

the use of a timeserver. We also plan to investigate

more deeply the blockchain-based designs and to bet-

ter structure security requirements, attacks and design

countermeasures using an attack-defense tree.

REFERENCES

Acosta Padilla, F. J. et al. (2016). The Future of IoT Soft-

ware Must be Updated. In IAB Workshop on Internet

of Things Software Update (IoTSU). Internet Archi-

tecture Board (IAB).

Aslanyan, Z., Nielson, F., and Parker, D. (2016). Quanti-

tative veriﬁcation and synthesis of attack-defence sce-

narios. In Proc. 29th IEEE Computer Security Foun-

dations Symposium (CSF’16), pages 105–119. IEEE.

Asokan, N. et al. (2018). Assured: Architecture for secure

software update of realistic embedded devices. IEEE

Transactions on Computer-Aided Design of Integrated

Circuits and Systems, 37(11).

AWS (2020). FreeRTOS User Guide. https://docs.aws.

amazon.com/freertos/latest/userguide.

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

Symbolically Analyzing Security Protocols Using

Tamarin. ACM SIGLOG News, 4(4):19–30.

Blanchet, B., Abadi, M., and Fournet, C. (2005). Auto-

mated veriﬁcation of selected equivalences for secu-

rity protocols. In 20th Annual IEEE Symposium on

Logic in Computer Science (LICS’ 05), pages 331–

340.

Dolev, D. and Yao, A. (1983). On the security of public key

protocols. IEEE Transactions on Information Theory,

29(2):198–208.

Galibus, T. (2019). Securing software updates for trains.

In Critical Information Infrastructures Security - 14th

International Conference, CRITIS 2019, Link

oping,

Sweden, Sept. 23-25,, volume 11777, pages 137–148.

Springer.

Gartner (2019). IoT endpoints 2020: the industries and

use cases driving growth. https://www.i-scoop.eu/

internet-of-things-guide/iot-endpoints-2020.

Grisham, P. S., Chen, C. L., Khurshid, S., and Perry, D. E.

Validation of a security model with the alloy analyzer.

Hong, D. (2020). On decentralized clocks: How time be-

came the biggest security threat on blockchain sys-

tems. https://uniﬁedh.medium.com.

Iansiti, M. and Lakhani, K. R. (2017). The Truth About

Blockchain. Harvard Business Review https://hbr.org/

2017/01/the-truth-about-blockchain.

Kim, J. Y., Holz, R., Hu, W., and Jha, S. (2017). Auto-

mated analysis of secure internet of things protocols.

In Proc. of the 33rd Annual Computer Security Appli-

cations Conference, ACSAC 2017, page 238–249.

Kumar, R. and Stoelinga, M. (2017). Quantitative security

and safety analysis with attack-fault trees. In 2017

IEEE 18th International Symposium on High Assur-

ance Systems Engineering (HASE).

Kuppusamy, T. K., DeLong, L. A., and Cappos, J. (2018).

Uptane: Security and customizability of software up-

dates for vehicles. IEEE Vehicular Technology Maga-

zine, 13(1):66–73.

Langiu, A., Boano, C. A., Schuß, M., and R

omer, K.

(2019). Upkit: An open-source, portable, and

lightweight update framework for constrained iot de-

vices. In IEEE 39th Int. Conference on Distributed

Computing Systems (ICDCS), pages 2101–2112.

Lee, B. and Lee, J.-H. (2017). Blockchain-based se-

cure ﬁrmware update for embedded devices in an

internet of things environment. J. Supercomput.,

73(3):1152–1167.

Legay, A. et al. (2019). Statistical Model Checking, pages

478–504. Springer International Publishing, Cham.

Lo, N.-W. and Hsu, S.-H. (2019). A secure iot ﬁrmware

update framework based on mqtt protocol. In Proc.

of 40th Anniversary Int. Conf. on Information Systems

Architecture and Technology – ISAT 2019, pages 187–

198.

Mtetwa, N. S., Tarwireyi, P., Abu-Mahfouz, A. M., and Adi-

gun, M. O. (2019). Secure ﬁrmware updates in the

internet of things: A survey. In International Multi-

disciplinary Information Technology and Engineering

Conference (IMITEC), pages 1–7.

Towards Formal Security Veriﬁcation of Over-the-Air Update Protocol: Requirements, Survey and UpKit Case Study

807

OASIS (2019). MQTT Version 5.0. https://docs.oasis-open.

org/mqtt/mqtt/v5.0/mqtt-v5.0.html.

Samuel, J. et al. (2010). Survivable key compromise in soft-

ware update systems. In 17th ACM Conf. on Computer

and Communications Security, page 61–72.

Tamarin Team (2016). Tamarin-Prover Manual - Secu-

rity Protocol Analysis in the Symbolic Model. https:

//tamarin-prover.github.io/manual.

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

808