Establishing End-to-End Secure Channel for IoT Devices

through an Untrusted C-ITS Network

Simon Bouget

, Shahid Raza

and Martin Furuhed

RISE Research Institute of Sweden, Isafordsgatan 22, Kista 16440, Sweden

Technology Nexus Secured Business Solutions, Telefonv

agen 26, H

agersten 12626, Stockholm, Sweden

Keywords:

IoT, ITS, OSCORE, Network Security, Vehicular Network, Tamarin, Formal Veriﬁcation.

Abstract:

Critical infrastructure is becoming increasingly connected, with tighter integration to the Internet of Things

(IoT). Transportation systems in particular are getting smarter with increased cooperation between vehi-

cles and the supporting infrastructure (V2X communications), and with intelligent devices introduced in the

ecosystem, either tightly integrated to the vehicle (e.g. ECUs, cameras, ...) or external sensors (e.g. tem-

perature sensor in an attached container, smart trafﬁc light, ...). A number of communication and security

protocols are being standardized for this Cooperative Intelligent Transport Systems (C-ITS). However, using

the current C-ITS standards, the security of individual devices may terminate at the gateway of a vehicle, and

consequently in most existing vehicles, individual systems leak sensitive data across vendors.

In this paper, we propose an end-to-end security architecture between C-ITS devices and back-end servers,

in which sensitive data from individual devices can be transmitted without trusting third-parties providing the

communication infrastructure (e.g. proxies, vehicle gateways, routers). The proposed solution is a standard-

based integrated system that exploits recent IoT security standards and ensures inter-operability between C-

ITS protocols and conventional Internet protocols. We perform a formal analysis of our architecture using

the Tamarin Prover and show that it guarantees the secrecy and authenticity of the communications under

adversarial settings.

1 INTRODUCTION

Today’s environment in the automotive sector is very

heterogeneous, with various software stacks coexist-

ing and with various medium of communication in-

volved. Further, the current major standard on smart

vehicles —the Cooperative Intelligent Transport Sys-

tem (C-ITS) standard (Festag, 2014)— offers no secu-

rity guarantee by default for communication between

vehicles (or ITS Units), in order to give each Unit

more ﬂexibility on how to handle incoming commu-

nication and relay messages. Picture for instance the

following situation: a smart vehicle has external inter-

faces to multiple mutually un-trusted services/appli-

cations such as the infotainment platform, the OEM

servers, the vehicle sensors, etc., and serves as a sin-

gle gateway to put them in relation with each oth-

ers. To this purpose, it may need to translate mes-

sages between several incompatible protocol stacks,

repackage messages before forwarding them to their

intended destination, etc., thus breaking security ses-

sions in the process. A recent addition to the C-ITS

standard, ISO 21177, proposes an optional mecha-

nism to establish and authenticate a secure session

between ITS Units, but it relies on two crucial as-

sumptions: a) it requires (D)TLS 1.3 support; and b)

there is a pre-existing trust relationship between de-

vices (either directly or through brokering). Both of

these assumptions are problematic. First off, some

of the physical devices that interact in a C-ITS net-

work are extremely resource-constrained, with lim-

ited battery life and hardware capabilities, resulting

in very hard constraints on: processing power, mem-

ory, and communications. This makes (D)TLS not

properly suited for the context. Second, requiring a

pre-existing trust relationship in order to establish a

secure session only pushes the issue one step further.

Thus, even with ISO 21177, it is still challenging to

successfully secure a connection going through a C-

ITS vehicular network end-to-end: from the point of

view of an application trying to reach a distant back-

end server, even if its connection to the truck is secure,

it has no clear picture of how its messages will be pro-

cessed and routed beyond that point. They may be re-

562

Bouget, S., Raza, S. and Furuhed, M.

Establishing End-to-End Secure Channel for IoT Devices through an Untrusted C-ITS Network.

DOI: 10.5220/0010462305620570

In Proceedings of the 7th International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2021), pages 562-570

ISBN: 978-989-758-513-5

layed through other neighboring vehicles, or through

a nearby roadside unit, all third-party entities that the

application has no reason to trust. The OSCORE pro-

tocol (Object Security for Constrained RESTFul En-

vironment) (Selander et al., 2019), recently standard-

ized by the IETF, solves the ﬁrst point by replacing

(D)TLS with an application-layer encryption scheme

that is very resource-efﬁcient and compatible with a

large number of transport protocols. However, sim-

ilarly to ISO 21177, the OSCORE standard assumes

that the two parties trying to communicate have estab-

lished a common security context beforehand.

The traditional solution to establish this trust re-

lationship/security context would be to use a PKI

(Public Key Infrastructure), but this is in itself a

very resource-intensive process, relying on asymmet-

ric cryptography and large payload which are expen-

sive to send via radio communication. Consequently,

establishing an OSCORE security context between a

constrained IoT device and a distant back-end server

while going through a C-ITS vehicular network re-

quires to adapt the process to the limitations of this

speciﬁc ecosystem.

Motivating Example 1: Container with Sensi-

tive Material. Some sensitive material needs to be

shipped over a long distance. It is transported in a

container with built-in sensors to monitor some criti-

cal parameters, e.g. temperature for frozen food, no

tampering or excessive humidity for a piece of art,

level of radiation for nuclear wastes, etc. The man-

ifest of the container also needs to be securely stored

and transmitted, e.g. to customs. This container may

cross multiple countries using various transportation

methods (boat, rail, road, ...) and may not have ac-

cess to its own long-range communications and rely

on the transporting vehicle to serve as a relay. Being

designed with transportation in mind from the start, it

is reasonable to assume such a container would im-

plement the latest standards used in the transport in-

dustry, such as the ISO C-ITS family.

Motivating Example 2: Passenger Health Sensor.

A passenger with a serious health condition is us-

ing a wearable device to monitor health status. This

device handles private and sensitive data, and may

need access to the Internet for instance to store back-

up data on a distant server with more memory or to

alert healthcare professionals if the patient gets crit-

ical. This health sensor will have to cooperate with

the vehicle to establish a secure communication, but

still does not want the intermediaries (vehicle, road-

side infrastructure, etc.) to get access to the data, only

the ﬁnal end-point of the communication. In this case,

since the health sensor is not directly related to the

automotive sector, there is no reason to assume it im-

plements any of the relevant standards.

Contribution: In this paper, we present an architec-

ture and workﬂow that complements C-ITS security

standards (ISO 21177) and enables full end-to-end

security between a back-end server and an IoT de-

vice embedded in a smart vehicle, whether this de-

vice is compliant with the current C-ITS standard or

not, such as in the two use-cases above. Our solution

is fully standard-based, notably leveraging the recent

IETF standard OSCORE. We also performed a for-

mal security analysis of our solution and proved that

it achieves OSCORE prerequisites.

In the rest of this paper, we give relevant back-

ground on the state of the art for automotive networks

security and the various technologies we use (Section

2), we present the overall architecture of the proposal

(Section 3) and discuss the security guarantees it pro-

vides (Section 4), before concluding (Section 5).

2 STATE-OF-THE-ART AND

BACKGROUND

Security in automotive networks and transport infras-

tructures is a very active area. The stakes are im-

mense, with the value of the global intelligent trans-

port system market estimated at more than $20 bil-

lions in 2018 and expected to keep growing in fu-

ture years

, with national and international institu-

tions pushing for more concerted efforts and standard-

ization (Shan et al., 2019). Moreover, automotive net-

works require novel solutions to solve their speciﬁc

challenges, such as: very heterogeneous networks,

with a lot of stakeholders and competing vendors that

do not trust each others; difﬁculties to coordinate due

to communication nodes (vehicles) quickly moving

geographically; need to update over the air (Vasenev

et al., 2019); very large attack surface (Stabili et al.,

2018) and difﬁculties to use asymmetric cryptogra-

phy due to real-time constraints (La

stinec, 2017). On

top of that, integrating constrained devices in an au-

tomotive network adds another layer of compatibility

issues, since both domains developed separate tech-

nologies to solve their speciﬁc issues, without regards

for the other one.

2.1 Automotive Networks

Automotive networks are complex entities that gather

very different devices with varying capabilities and

Intelligent Transport System Market – Forecast (2020

- 2025), IndustryArc, 2018,

https://www.industryarc.com/Report/15024/intelligent-

transport-system-market.html

Establishing End-to-End Secure Channel for IoT Devices through an Untrusted C-ITS Network

563

constraints. Vehicles are the basic units, and can com-

municate either P2P in a mesh network composed

of other vehicles, or with a road-side infrastructure

which has a wired connection and can relay the com-

munication to its ﬁnal destination. The choice of

which type to use generally depends on the applica-

tion. For instance, safety information needs to be ex-

changed with close vehicles in real time, while trafﬁc

statistics can be sent to a central for aggregation and

analysis at a more relaxed rhythm.

To ensure that all these units can cooperate, var-

ious standardization organizations (ISO, ETSI, etc.)

have developed the C-ITS standards (Festag, 2014),

for Collaborative Intelligent Transport Systems, itself

based on the ITS standard (Nowacki et al., 2012).

While ITS focuses on the intelligence at the level of

a single unit (a vehicle or a roadside unit), C-ITS ex-

tends it to the communications between these systems

to provide additional beneﬁts, such as advanced warn-

ing in case of accident or reduced trafﬁc congestion.

C-ITS is built around the functional concept of

ITS Station (ITS-S), physically implemented in a Sta-

tion Unit (SU), itself composed of one or various Sta-

tion Communication Unit (SCU), each providing a

speciﬁc function. According to ISO 21217, a SCU is

organized in several modules, separated in 4 layers —

which can be loosely tied to the standard Communica-

tion layers deﬁned by the IETF (RFC 1122) used on

traditional Internet: Access (IETF Link layer), Net-

work & Transport (IETF IP and Transport layers), Fa-

cilities (no direct equivalent), and Application (IETF

Application layer)— and 2 cross-layers categories,

Security and Management, as illustrated by the var-

ious Stations in Figure 2. The two cross-layers mod-

ules are further deﬁned in ISO 21177 (Security) and

ISO 24102 (Management). C-ITS Stations Units and

SCUs are further classiﬁed based on the type of net-

work connections they possess: internal to a single

SU, to other C-ITS SU, or to an external (non C-ITS)

network. The last type in particular is designed as a

Station Gateway, and is in charge of the translation

between the C-ITS stack and other external protocol

stacks (such as OSI-based web stacks).

A notable limitation of the C-ITS model is that

security properties are by default only deﬁned for

point-to-point communications between two SCUs,

but each SCU is free to repackage incoming com-

munications before relaying them. Furthermore, the

optional mechanisms deﬁned in ISO 21177 rely on

(D)TLS 1.3 and are tailored for communications be-

tween two SCUs inside the same SU, or between the

ITS-SU and the proprietary network embedded in the

same smart vehicle, but not for transient IoT devices

which would connect at the edges of a C-ITS network.

This gives much needed ﬂexibility to the complex au-

tomotive ecosystem, but makes it hard to provide any

End-to-End security guarantees to IoT devices, and

further in this paper, we propose Application-layer

encryption as a solution (Section 3).

2.2 IoT Devices

A lot of the devices composing the Internet-of-Things

possess limited capabilities due to physical con-

straints, be it bandwidth, communication range, bat-

tery life, etc. To cater to those speciﬁc needs, new

protocols have been designed, tailored for machine-

to-machine communication and better efﬁciency. In

particular, two networks stacks have been standard-

ized by the IETF (Internet Engineering Task Force),

that we describe here.

2.2.1 CoAP

CoAP (Constrained Application Protocol) (Shelby

et al., 2014) is a subset of HTTP designed specif-

ically for machine-to-machine communication and

the Internet of Things, to be cheaper and more efﬁ-

cient. Security, if enabled at all, is established in the

transport layer, generally using DTLS (Rescorla and

Modadugu, 2012) over UDP (Postel, 1980), and a se-

cure CoAP session ran on top of it. This is cheaper

than the classic HTTPS stack using TLS over TCP,

but still too expensive, and more importantly it has

issues with heterogeneous networks, and security is

usually broken at proxies and relays.

2.2.2 OSCORE

Alternatively, the OSCORE (Selander et al., 2019)

stack establishes security in the application layer, us-

ing CBOR (Concise Binary Object Representation)

(Bormann and Hoffman, 2013) and COSE (CBOR

Object Signing and Encryption) (Schaad, 2017) on

top of raw CoAP. As this happen in the uppermost

layer, data can go through the translation process be-

tween proxies and relays using different stacks while

still remaining secure. Moreover, OSCORE uses

symmetric encryption, which is much less resource

intensive for the constrained devices comprising the

Internet of Things. In Table 1, we summarize the cor-

respondence between the C-ITS model and the proto-

col stacks developed for IoT devices.

VEHITS 2021 - 7th International Conference on Vehicle Technology and Intelligent Transport Systems

564

Table 1: Comparison between standard web and IoT-dedicated protocol stacks — IoT use speciﬁc protocols, tailored for

machine-to-machine communications and efﬁcient use of resources, but there is a loose correspondence between the various

systems.

Basic Web stack: IPv4/v6 → TCP → HTTP

Basic IoT stack: 6LowPAN → IPv6 → UDP → CoAP

Secure Web stack: IPv4/v6 → TCP → TLS → HTTPS → EST

Secure IoT stack (CoAP-S): 6LowPAN → IPv6 → UDP → DTLS → CoAP-S → EST-CoAPS

Secure IoT stack (OSCORE): 6LowPAN → IPv6 → UDP → CoAP → OSCORE → EST-OSCORE

ITS-Station design: Access → Network. & Transp. → Facilities

3 OSCORE USE IN C-ITS

NETWORKS

Securing end-to-end communications for a resource-

constrained IoT device participating in a vehicular

network cannot be done at the Network & Transport

layer because each C-ITS Unit relaying a message

might break the (D)TLS session. In this Section, we

describe how to use OSCORE as an Application-layer

encryption mechanism instead to provide End-to-End

security in automotive networks while being compat-

ible with C-ITS standards.

3.1 End-device as a C-ITS Station

In our ﬁrst motivating example in the Introduction,

a container with sensitive material would obviously

come in contact with a vehicular network while it

is being transported, so it would make sense for the

manufacturer to build its communication capabilities

as a C-ITS Station Unit. More generally, in cases

when the end-device is assumed to participate in a

vehicular network (container, trafﬁc monitor, etc.), it

should be made compliant with the C-ITS standards.

To secure its communications, such a device has

to include an OSCORE module in its Facilities layer

that the Applications can call on to encrypt their con-

tent, and a module to manage relevant Certiﬁcates and

Security Contexts in its Security section, as shown in

Figure 2 in the top-right. The encrypted OSCORE

payload is then sent out on the C-ITS network just as

any other message, and only the ﬁnal destination of

the message, which knows the corresponding Secu-

rity Context is able to decrypt the payload and access

its content. We give more details on establishing the

Security Context further in Section 3.3.

3.2 Connection through a Gateway

In our second motivating example, a health sensor

worn by a patient with a chronic condition that needs

to be continuously monitored, the sensor is not nec-

essarily used in a vehicle, and most of the time will

connect through the hospital or patient’s home WiFi,

so its manufacturer will not have strong incentives to

make the sensor compliant with the C-ITS standard.

However, the sensor may want to rely on a vehicu-

lar network advanced connectivity while the patient

is being transported. More generally, when a device

is not targeted for use in vehicular networks and does

not implement the C-ITS standard, but can sometimes

come in contact with one, it needs an entry point into

the C-ITS network to beneﬁt from its capabilities.

In that case, the device has to rely on the C-ITS

Station Gateway of the host vehicle. The Gateway

has to implement the translation process from the OS-

CORE stack used by the end-device to whichever pro-

tocol stack it uses to communicate with the rest of the

C-ITS network, as illustrated in Figure 1. After this,

the Gateway forwards the re-packaged encrypted OS-

CORE payload to the rest of the C-ITS network and

once again it is transmitted as any other message to

its ﬁnal destination, which is the only one able to de-

crypt it with the corresponding Security Context. As

in the ﬁrst case though, initially establishing the Se-

curity Context is still the responsibility of the end-

device, not of the Gateway.

3.3 Establishing a Security Context for

OSCORE

In both cases described previously, we mentioned that

encrypting and decrypting the OSCORE payload re-

lies on the two end-points sharing an OSCORE Se-

curity Context. It is needed since OSCORE uses

symmetric encryption, which is less resource inten-

sive than asymmetric encryption and better suited to

constrained IoT devices, but requires establishing a

shared secret between the two ends of the commu-

nication. The OSCORE speciﬁcation assumes that

the Security Context has already been established be-

tween the two end-points of a communication. The

IETF working group LAKE (Lightweight Authenti-

cated Key Exchange) is currently at work on standard-

izing this process, and has an active draft for a proto-

col named EDHOC (Ephemeral Difﬁe-Hellman Over

Establishing End-to-End Secure Channel for IoT Devices through an Untrusted C-ITS Network

565

IETF IoT stack (OSI-based)

UDP

CoAP (Constrained App. Prot.)

OSCORE EST-OSCORE EDHOC

Certificate

enrollment

Message

security

Key esta-

blishment

6LowPAN

...

Applications

ITS-SU

Net & Transp

Access

Applications

Facilities

Mangmnt

Security

Translation process

ITS station-internal network

External Network

Towards

IoT-capable

PKI

ITS Station Gateway

Figure 1: Translation needed to bridge the ITS and OSCORE worlds.

Net & Transp.

Access

Facilities

Management

Security

Applications

ITS station-internal network

Networking

& Transport

Access

Mangmnt

Security

ITS-S Router

ITS-S Host

(proprietary)

in-vehicle network

ECU

Passenger

health-sensor

Net & Transp.

Access

Facilities

Management

Security

ITS-S Gateway

OSI

layer 7

…

layer 1

Vehicle ITS Station

Net & Transp.

Access

Facilities

Management

Security

Applications

ITS-Compliant device

CoAP

OSCORE EDHOC

EST-oscore

ITS Transp UDP

6LoWPAN (IoT MSE)

Certificates

management

OSCORE

security contexts

management

Net & Transp.

Access

Facilities

Management

Security

Applications

ITS station-internal network

Networking

& Transport

Access

Mangmnt

Security

ITS-S Router

ITS-S Host

Vehicle ITS Station

Sensitive cargo

with built-in sensors

General

Internet

Net & Transp.

Access

Facilities

Management

Security

Applications

ITS-S Host

Roadside ITS Station

Networking

& Transport

Access

Management

Security

ITS-S Border Router

OSI

layer 3

…

layer 1

Networking

& Transport

Access

Mangmnt

Security

ITS-S Router

Service with an

OSCORE-enabled server

C-ITS Network

General ITS network

Figure 2: Example of a C-ITS automotive network integrating OSCORE-enabled devices — Two possibilities: a) the device

is ITS compliant, and can seamlessly integrate the C-ITS network (truck cargo with built-in sensors); or b) the device is not

ITS compliant and has to connect through a Gateway which can handle the translation process for it (health sensor worn by a

passenger in the car).

VEHITS 2021 - 7th International Conference on Vehicle Technology and Intelligent Transport Systems

566

Certificate Authority

Root CA

Manufacturer

Provides root

factory certificate

Device in use

EDHOC server

Securely pre-install

factory certificate

EST-OSCORE

server

Service/Application

REST API

C-ITS

network

General

Internet

Net & Transp

Access

Facilities

Management

Security

Vehicle C-ITS

Gateway Station

Net & Transp

Access

Mgmt

C-ITS Station

Border Router

(typically contained in a

roadside infrastructure)

Sec

(CoAP messages)

EDHOC client

(EST-)OSCORE

client

(e.g. wearable

health sensor)

EDHOC server

OSCORE

server

OSI stack

layer 3

…

layer 1

Figure 3: Architecture of an ITS/OSCORE system – A de-

vice is provisioned with a factory certiﬁcate by its man-

ufacturer. It connects to a C-ITS Network via a Gate-

way, which relays the CoAP messages containing ED-

HOC/EST/OSCORE payloads up to a Border Router con-

nected to the general Internet, where the messages can reach

their ﬁnal destination, either a Certiﬁcate Authority or a Ser-

vice.

COSE (Selander et al., 2020a)). EDHOC is a Key Ex-

change protocol, i.e. a method to securely establish

a shared secret known only by the two participants,

that is targeted towards IoT devices and optimized for

small message sizes, in order to save radio communi-

cation and power consumption. It also has the advan-

tage to be based on COSE, just like CoAP/OSCORE,

thus being able to share libraries with the other proto-

cols and to reduce the memory footprint of the stack.

Other Key Exchange protocols may be used if better

suited to a speciﬁc context, such as cTLS (compact

TLS, with an active draft in the TLS working group)

(Rescorla et al., 2020) in protocol stacks where TLS is

already used for another reason. But in general, using

EDHOC is the simplest way to establish an OSCORE

Security Context, and we will focus on this case in the

rest of this paper. The typical life-cycle of a device, as

illustrated in Figure 4, would be the following: (i) Ini-

tially, a manufacturer pre-installs a “factory” or “boot-

strap” certiﬁcate that will uniquely identify a device

for the entirety of its existence. (ii) When used for

the ﬁrst time, a device will use its factory certiﬁcate

to authenticate at a Certiﬁcate Authority (CA) of its

choice and enrolls for a new “working” certiﬁcate.

This CA should run an EDHOC server, which the de-

vice will contact to derive symmetric keys and estab-

lish an OSCORE context. This context is then used to

run a certiﬁcate enrollment procedure thanks to EST-

OSCORE (Selander et al., 2020b), a method using

the payloads deﬁned in the EST standard (Enrollment

over Secure Transport (Pritikin et al., 2013)) and pro-

tecting them with OSCORE. (iii) With the newly en-

rolled certiﬁcates, a device can then contact and au-

thenticate to any service they want and run EDHOC

to generate an OSCORE context, and then communi-

cate securely with the service using OSCORE. Dif-

ferent CAs can also be used to issue further certiﬁ-

cates, either re-using the factory certiﬁcate again, or

using one of the certiﬁcates enrolled through the ﬁrst

CA and executing the same EDHOC + EST-OSCORE

procedure.

In Figure 3, we summarize the relationships be-

tween the various actors involved in that life-cycle:

the Manufacturer is responsible for securely installing

on each Device a factory certiﬁcate provided by the

Root Certiﬁcate Authority. The Device ultimately

wants to establish a secure channel to a given Service

or Application, and can do so through the connectiv-

ity provided by the C-ITS Network. The Device typi-

cally connects through a Gateway Station and sends

CoAP messages (carrying EDHOC/OSCORE/EST

payloads) that are relayed by the C-ITS Networks un-

til they reach a Border Router, which can forward the

messages to the general Internet. The C-ITS network

serves as a bridge between the Device, the Service,

and the Certiﬁcate Authority that allows them to au-

thenticate each-others.

4 SECURITY ANALYSIS

We used the Tamarin prover (Meier et al., 2013) to

analyze our proposed architecture. Tamarin has been

widely used to analyze protocols’ security features,

such as TLS (Cremers et al., 2017), 5G (Basin et al.,

2018a), or voting protocols (Basin et al., 2018b).

4.1 Introduction to Tamarin

Tamarin is a symbolic analysis tool using multi-

set rewriting rules —to encode a protocol speciﬁca-

tion and the adversary’s capabilities— and ﬁrst-order

Establishing End-to-End Secure Channel for IoT Devices through an Untrusted C-ITS Network

567

1. Certificate Enrollment0. Factory set-up

2. Service Initialization 3. Active Use

IoT Device

Root CA

(Offline set-up)

Factory Cert.

IoT Device

EDHOC client

Cert. Auth.

EDHOC

server

Exchange of Key Material

with EDHOC

authenticated by Factory Cer

Cert. Auth.

EST-oscore

server

Enrollment for a

Security Context

IoT Device

EST-oscore

client

Security Context

Key Material

Factory Cert.

Working Cert.

IoT Device

EDHOC client

Service

EDHOC

server

Exchange of Key Material

with EDHOC

authenticated by Factory Cer

Service

OSCORE

server

Device has a secure

end-to-end channel

with Service

Security Context

IoT Device

OSCORE

client

Security Context

Key Material

Working Cert.

* Note: paired Security Contexts for OSCORE / EST-oscore are derived from the Key Material exchagned through EDHOC

Offline Comm. Communication possible through untrusted network

Secure channel

Figure 4: Typical life-cycle of an IoT device in our use-case — 1) A device contact a CA, using its pre-installed factory

certiﬁcate as authentication, and exchange key material with EDHOC; it derives an OSCORE security context and uses

it to enroll for a new working certiﬁcate with EST-oscore; 2) the previous procedure is repeated, now using the working

certiﬁcate to authenticate to a desired service instead; 3) in the end, the device and the service are connected with a secure and

authenticated channel protected by OSCORE.

logic formulas —to deﬁne security properties. These

rewriting rules induce a transition system describing

the potential executions of (unbounded numbers of)

protocol instances in parallel, allowing us to cover the

potential interactions of enrolling at many CAs and

using various services concurrently. Tamarin’s default

adversary model corresponds to a Dolev-Yao(Dolev

and Yao, 1983) adversary who has complete control

over the network. Users can also extend this default

model, either to give more capabilities to the adver-

sary or limit what it can do on the network.

Tamarin also includes an automatic solver that

can analyze this transition system and generate for-

mal proofs of the properties This automatic solver re-

lies on a formal semantics and is guaranteed to be

correct but may not always terminate. In that case,

the protocol speciﬁcations and/or the properties to

prove need to be modiﬁed until the tool is able to

reach termination. Alternatively, the user can man-

ually guide the tool instead of relying on the auto-

matic heuristics. When the solver reaches termina-

tion, it generates either a proof that a property is valid

or a counter-example that exhibits why it is invalid.

Counter-examples are presented in a graphical inter-

face and can be used to guide corrections or further

reﬁnements of the model. Proofs, however, are not

supposed to be human-readable and consist of hun-

dreds of lines of formal logic statements and exhaus-

tive enumeration of all possible cases. Consequently,

with correctness being guaranteed by the tool itself

added to the lack of readability, discussing the proofs

has little value, and the difﬁculty in such formal anal-

yses is to ensure that the model is a reasonable ap-

proximation of the reality and that the security prop-

erties deﬁned actually correspond to the real world at-

tacks a protocol aims to protect against. This is what

we will do in the rest of this section.

4.2 Model and Speciﬁcation

Our full speciﬁcation is available at https://github.

com/Simon-Bouget/tamarin-end2end-security/

blob/main/general.spthy and can be checked with

Tamarin auto-prover using the default heuristic in

a few seconds on a common laptop. We modeled

three different kind of actors: (a) Devices, with

a pre-installed factory certiﬁcate, modeled as a

private/public key pair. (b) Certiﬁcate authorities

(CA), which can deliver new working certiﬁcates,

modeled as a private/public key pair based on a fresh

nonce and signed by the CA. (c) Services that a

device may want to use, modeled as entities with

an easily veriﬁable public key and controlling the

corresponding private key. Additionally, we do not

assume any trust in the C-ITS network infrastructure,

which has been modeled as an attacker with full

control over network communications, which is

equivalent to the attacker being in control of any

relaying node in the C-ITS infrastructure. However,

we assume that the adversary cannot physically

tamper with the end-devices and access the long-term

keys stored there, nor can it corrupt the Certiﬁcate

Authorities. We modeled the workﬂow to establish a

secure OSCORE session starting with only a factory

VEHITS 2021 - 7th International Conference on Vehicle Technology and Intelligent Transport Systems

568

certiﬁcate, described in the previous Section 3.3. We

do not show the code here, but we remind the readers

that it is publicly available online.

4.3 Security Properties

In Tamarin, security properties are deﬁned as 1st-

order logic formulas, which we use to deﬁne the prop-

erties that must be true in order to guarantee ”end-

to-end security” for the communications protected by

OSCORE: (i) The OSCORE master secret actually

remains secret (from the point of view of the adver-

sary) during the certiﬁcate enrollment process and the

establishment of the Security Context. (ii) The mes-

sages between services and end-devices are secret, i.e.

no one except the destination of a message can de-

crypt its payload. (iii) The messages between services

and end-devices are authenticated, i.e. both the ser-

vice and the device are certain they talk to each other,

and replay-protected, i.e. an adversary cannot record

an encrypted message and send it a second time to

trick its recipient. Altogether, it ensures that a de-

vice can establish a secure end-to-end channel with

a service and that they can communicate safely even

through an untrusted C-ITS network. No man-in-the-

middle can spy on their communication or imperson-

ate them, and no replay attack is possible.

5 CONCLUSION

In this paper, we present a solution, compatible with

the C-ITS automotive standards and entirely based

on standardized (or soon-to-be standardized) open-

source protocols, to get end-to-end security between

a resource-constrained IoT device and a distant back-

end server, including through an un-trusted vehic-

ular network. It leverages the newly standardized

OSCORE protocol as an application-layer encryption

mechanism to secure a payload even through relays

and proxy forwarding, and it covers the whole life-

cycle of a device, from the original Certiﬁcate Enroll-

ment to the communication between service and end-

device through the initial OSCORE Security Context

establishment. Further, we analyzed our solution us-

ing the Tamarin Prover, a well-known and reputable

security analysis tool, and guarantee that our speciﬁ-

cations provide authenticity and secrecy even against

an adversary in full control of the network.

ACKNOWLEDGMENT

This research has partly been funded by the H2020

ECSEL SECREDAS (Grant ID: 783119) and partly

by the H2020 CONCORDIA (Grant ID: 830927).

REFERENCES

Basin, D., Dreier, J., Hirschi, L., Radomirovic, S., Sasse,

R., and Stettler, V. (2018a). A formal analysis of

5g authentication. In Proceedings of the 2018 ACM

SIGSAC Conference on Computer and Communica-

tions Security, pages 1383–1396. ACM.

Basin, D., Radomirovic, S., and Schmid, L. (2018b).

Alethea: A provably secure random sample voting

protocol. In 2018 IEEE 31st Computer Security Foun-

dations Symposium (CSF), pages 283–297. IEEE.

Bormann, C. and Hoffman, P. (October 2013). Concise Bi-

nary Object Representation (CBOR). RFC 7049, In-

ternet Engineering Task Force (IETF).

Cremers, C., Horvat, M., Hoyland, J., Scott, S., and van der

Merwe, T. (2017). A comprehensive symbolic analy-

sis of tls 1.3. In Proceedings of the 2017 ACM SIGSAC

Conference on Computer and Communications Secu-

rity, pages 1773–1788. ACM.

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

protocols. IEEE Transactions on information theory,

29(2):198–208.

Festag, A. (2014). Cooperative intelligent transport systems

standards in europe. IEEE Communications Maga-

zine, 52(12):166–172.

stinec, J. (2017). Security extension of automotive com-

munication protocols using ethernet/ip. Information

Sciences and Technologies Bulletin of the ACM Slo-

vakia, page 49.

Meier, S., Schmidt, B., Cremers, C., and Basin, D. (2013).

The tamarin prover for the symbolic analysis of secu-

rity protocols. In International Conference on Com-

puter Aided Veriﬁcation (CAV’13), pages 696–701.

Springer.

Nowacki, G., Krysiuk, C., Kopczewski, R., and Paszukow,

B. (2012). Development and standardization of in-

telligent transport systems. International Journal on

Marine Navigation and Safety of Sea Transportation,

6(3).

Postel, J. (August 1980). User Datagram Protocol. RFC

768, Internet Engineering Task Force (IETF).

Pritikin, M., Yee, P., and Harkins, D. (October 2013). En-

rollment over Secure Transport. RFC 7030, Internet

Engineering Task Force (IETF).

Rescorla, E., Barnes, R., and Tschofenig, H. (October

2020). Compact TLS 1.3. Active Internet-Draft, In-

ternet Engineering Task Force (IETF).

Rescorla, E. and Modadugu, N. (January 2012). Datagram

Transport Layer Security Version 1.2. RFC 6347, In-

ternet Engineering Task Force (IETF).

Establishing End-to-End Secure Channel for IoT Devices through an Untrusted C-ITS Network

569

Schaad, J. (July 2017). CBOR Object Signing and Encryp-

tion (COSE). RFC 8152, Internet Engineering Task

Force (IETF).

Selander, G., Mattsson, J., and Palombini, F. (August

2020a). Ephemeral Difﬁe-Hellman Over COSE (ED-

HOC). Active Internet-Draft, Internet Engineering

Task Force (IETF).

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

2019). Object Security for Constrained Restful Envi-

ronments (OSCORE). RFC 8613, Internet Engineer-

ing Task Force (IETF).

Selander, G., Raza, S., Furuhed, M., Vucinic, M., and

Claeys, T. (March 2020b). Protecting EST Payloads

with OSCORE. Active Internet-Draft, Internet Engi-

neering Task Force (IETF).

Shan, L., Sangchoolie, B., Folkesson, P., Vinter, J.,

Schoitsch, E., and Loiseaux, C. (2019). A survey on

the applicability of safety, security and privacy stan-

dards in developing dependable systems. In Inter-

national Conference on Computer Safety, Reliability,

and Security, pages 74–86. Springer.

Shelby, Z., Hartke, K., and Bormann, C. (June 2014). The

Constrained Application Protocol (CoAP). RFC 7252,

Internet Engineering Task Force (IETF).

Stabili, D., Ferretti, L., and Marchetti, M. (2018). Anal-

yses of secure automotive communication protocols

and their impact on vehicles life-cycle. In 2018

IEEE International Conference on Smart Computing

(SMARTCOMP), pages 452–457.

Vasenev, A., Stahl, F., Hamazaryan, H., Ma, Z., Shan, L.,

Kemmerich, J., and Loiseaux, C. (2019). Practical

security and privacy threat analysis in the automotive

domain: Long term support scenario for over-the-air

updates. In VEHITS, pages 550–555.

VEHITS 2021 - 7th International Conference on Vehicle Technology and Intelligent Transport Systems

570