Project acronym: OVERSEE

Project title: Open Vehicular Secure Platform

Project ID: 248333
Call ID: FP7-ICT-2009-4
Programme: 7th Framework Programme for Research and Technological Development
Objective: ICT-2009.6.1: ICT for Safety and Energy Efficiency in Mobility
Contract type: Collaborative project
Duration: 01-01-2010 to 30-06-2012 (30 months)

Deliverable D5.2:
Proof of Concept Use Case Specification

Authors: Thomas Enderle (Escrypt)

Rafael Grote (TUB)
Jan Holle (Uni Siegen)
Martin Förster (Volkswagen)
Reviewers: Florian Friederici (FOKUS)
Jan Holle (Uni Siegen)
Hakan Cankaya (Escrypt)
Dissemination level: Public
Deliverable type: Report
Version: 1.0 Draft – Waiting for Approval
Submission date: 20 November 2019
D5.2: Proof of Concept Use Case Specifications

Abstract
This document contains the specifications of the proof of concept (PoC) use cases selected
and described in Deliverable D5.1 in order to demonstrate the capabilities of the OVERSEE
platform.
The specified use cases include application use cases, which demonstrate the functionality of
a certain application on the OVERSEE platform, as well as validation use cases, which
demonstrate a specific property of the OVERSEE platform, such as security, isolation and
dependability properties. Each use case is specified in terms of involved data, software
modules, peripherals and the application flow.

ii
D5.2: Proof of Concept Use Case Specifications

Contents
Abstract..............................................................................................................................ii
Contents.............................................................................................................................iii
List of Figures.....................................................................................................................vi
List of Abbreviations...........................................................................................................vi
Document History..............................................................................................................vi
1 Introduction.................................................................................................................6
1.1 Scope and Objective of the Document.......................................................................6
1.2 Document Outline.......................................................................................................6
2 Use Case Specifications.................................................................................................6
2.1 USB Flash Drive Media Access....................................................................................6
2.1.1 Introduction....................................................................................................6
2.1.2 Initial State......................................................................................................6
2.1.3 Involved Data..................................................................................................6
2.1.4 Used Modules and Services............................................................................6
2.1.5 Sequence Diagram..........................................................................................6
2.1.6 Description......................................................................................................6
2.2 Emergency Vehicle Warning........................................................................................6
2.2.1 Introduction....................................................................................................6
2.2.2 Initial State......................................................................................................6
2.2.3 Involved Data..................................................................................................6
2.2.4 Used Modules and Services............................................................................6
2.2.5 Sequence Diagrams........................................................................................6
2.2.6 Description......................................................................................................6
2.2.7 Notable Changes and Justification..................................................................6
2.3 Sending an Emergency Call.........................................................................................6
2.3.1 Introduction....................................................................................................6
2.3.2 Initial State......................................................................................................6
2.3.3 Involved Data..................................................................................................6
2.3.4 Used Modules and Services............................................................................6
2.3.5 Sequence Diagrams........................................................................................6
2.3.6 Description......................................................................................................6

iii
D5.2: Proof of Concept Use Case Specifications

2.3.7 Notable Changes and Justification..................................................................6

2.4 Update Partition or OVERSEE Component..................................................................6
2.4.1 Introduction....................................................................................................6
2.4.2 Initial State......................................................................................................6
2.4.3 Involved Data..................................................................................................6
2.4.4 Used Modules and Services............................................................................6
2.4.5 Sequence Diagrams........................................................................................6
2.4.6 Description......................................................................................................6
2.4.7 Notable Changes and Justification..................................................................6
2.5 Cooperative Platoon Automation System...................................................................6
2.5.1 Introduction....................................................................................................6
2.5.2 Initial State......................................................................................................6
2.5.3 Involved Data..................................................................................................6
2.5.4 Used Modules and Services............................................................................6
2.5.5 Sequence Diagram..........................................................................................6
2.5.6 Description......................................................................................................6
2.5.7 Notable Changes and Justification..................................................................6
2.6 Active Brake.................................................................................................................6
2.6.1 Introduction....................................................................................................6
2.6.2 Initial State......................................................................................................6
2.6.3 Involved Data..................................................................................................6
2.6.4 Used Modules and Services............................................................................6
2.6.5 Sequence Diagram..........................................................................................6
2.6.6 Description......................................................................................................6
2.6.7 Notable Changes and Justification..................................................................6
3 Validation Use Case Specification..................................................................................6
3.1 USB Flash Drive Media Access....................................................................................6
3.1.1 Introduction....................................................................................................6
3.1.2 Attacker Model................................................................................................6
3.1.3 Additional Components..................................................................................6
3.1.4 Sequence Diagram..........................................................................................6
3.1.5 Description......................................................................................................6
3.2 Emergency Vehicle Warning / E-Call...........................................................................6
3.2.1 Introduction....................................................................................................6

iv
D5.2: Proof of Concept Use Case Specifications

3.2.2 Attacker Model................................................................................................6

3.2.3 Additional Components..................................................................................6
3.2.4 Sequence Diagram..........................................................................................6
3.2.5 Description......................................................................................................6
3.3 Update Partition..........................................................................................................6
3.3.1 Introduction....................................................................................................6
3.3.2 Attacker Model................................................................................................6
3.3.3 Additional Components..................................................................................6
3.3.4 Sequence Diagram..........................................................................................6
3.3.5 Description......................................................................................................6
3.4 Platoon........................................................................................................................6
3.4.1 Introduction....................................................................................................6
3.4.2 Attacker Model................................................................................................6
3.4.3 Additional Components..................................................................................6
3.4.4 Message Sequence Diagram...........................................................................6
3.4.5 Description......................................................................................................6
3.5 Active Break.................................................................................................................6
3.5.1 Introduction....................................................................................................6
3.5.2 Attacker Model................................................................................................6
3.5.3 Additional Components..................................................................................6
3.5.4 Message Sequence Diagram...........................................................................6
3.5.5 Description......................................................................................................6
References...................................................................................................................................6

v
D5.2: Proof of Concept Use Case Specifications

List of Figures
Figure 1: Media player sequence diagram..................................................................................6
Figure 2: Graphical representation of the EVW..........................................................................6
Figure 3: Emergency vehicle sends CAMs sequence diagram....................................................6
Figure 4: Proof of concept car generates warning sequence diagram.......................................6
Figure 5: Trigger and send an eCall sequence diagram..............................................................6
Figure 6: Software update sequence diagram............................................................................6
Figure 7: Permission request sequence diagram........................................................................6
Figure 8: Verify software update list sequence diagram............................................................6
Figure 9: Execute software update sequence diagram...............................................................6
Figure 10: Message sequence chart of the Platooning use case................................................6
Figure 11: Platooning from the view of a follower vehicle.........................................................6
Figure 12: Detection and broadcasting of warning events.........................................................6
Figure 13: Incoming V2X messages lead to safety reaction........................................................6
Figure 14: Attack on the software update process.....................................................................6
Figure 15: Attack trying to hijack a platoon................................................................................6
Figure 16: Replay attack to fake a hard braking vehicle..............................................................6

vi
D5.2: Proof of Concept Use Case Specifications

List of Abbreviations
ADAS Advanced Driver Assistance Systems
AES Advanced Encryption Standard
APEX Application Executive
API Application Programming Interface
ARINC Aeronautical Radio Incorporated
BT Basic Task
C2C-CC Car to Car Communication Consortium
CALM Communications Access for Land Mobiles
CAM Cooperative Awareness Message
CAN Controller–area Network
CAP Capability
CC Common Criteria
CEN European Committee for Standardization
CF Configuration File
CPU Central Processing Unit
CT Configuration Table
CTR Constraint
DEN Decentralized Environmental Notification
DENM Decentralized Environmental Notification Message
DNS Domain Name System
DSA Digital Signature Algorithm
DSRC Dedicated Short-range Communications
EAP Extensible Authentication Protocol
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
ECU Electronic Control Unit
EFC Electronic Fee Collection
ELF Executable and Linkable Format
ET Extended Task
ETSI European Telecommunications Standards Institute
EVW Emergency Vehicle Warning

vii
D5.2: Proof of Concept Use Case Specifications

FLOSS Free/Libre Open Source Software

FPGA Field Programmable Gate Array
GNSS Global Navigation Satellite System
GPOS General Purpose Operating System
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communications
HAL Hardware Abstraction Layer
HM Health Monitoring
HMI Human Machine Interface
HSM Hardware Security Module
HTTP Hypertext Transfer Protocol
HW Hardware
ID Identity
IP Internet Protocol
ISO International Organization for Standardization
ISP Internet Service Provider
IT Information Technology
ITS Intelligent Transportation System
JVM Java Virtual Machine
LBS Location Based Service
LDM Local Dynamic Map
MOST Media Oriented Systems Transport
MSD Minimum Set of Data
NAT Network Address Translation
NFC Near Field Communication (see RFID)
NIC Network Interface Card
NMEA National Marine Electronics Association
NPS Network Provisioning Service
OBD On Board Diagnosis
OBEX Object Exchange (Bluetooth Profile)
OBU On-Board Unit
OEM Original Equipment Manufacturer
OS Operating System

viii
D5.2: Proof of Concept Use Case Specifications

OSEK Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug
OSGi Open Service Gateway initiative
OVERSEE Open Vehicular Secure Platform
PAN Personal Area Network
PCIe Peripheral Component Interconnect Express
PCO Point of Control and Observation
PER Packed Encoding Rules
PKI Public Key Infrastructure
PLMN Public Land Mobile Network
PoC Proof of Concept
POI Point Of Interest
PoS Positioning Service
Pos-X-Link Positioning Data Exchange Link
POSIX Portable Operating System Interface (for UNIX)
PP Protection Profile
PPP Point-to-Point Protocol
PSAP Public-Safety Answering Point
QoS Quality of Service
RF Radio Frequency
RFID Radio-frequency identification
RSA Rivest, Shamir and Adleman algorithm for public-key cryptography
RSU Roadside Unit
RTOS Real-time Operating System
S&D Security and Dependability
SAP Service Access Point
SAR Security Assurance Requirements
SecS Security Service
SFR Security Functional Requirements
SKPP Separation Kernel Protection Profile
SLAP SLAP is a Lightweight Asynchronous Protocol
SMP Symmetric Multi-Processing
SMS Short Message Service
SPP Serial Port Profile (Bluetooth Profile)
SRS Software Requirements Specification

ix
D5.2: Proof of Concept Use Case Specifications

SSL Secure Sockets Layer

SVAS Secure Vehicle Access Service
SW Software
TC Technical Committee
TCP Transmission Control Protocol
TECOM Trusted Embedded Computing
Tetra Terrestrial Trunked Radio
TGC Trusted Computing Group
TLS Transport Layer Security
TOC Traffic Operations Centre
TPM Trusted Platform Module
UC Use Case
UMTS Universal Mobile Telecommunications System
USB Universal Serial Bus
V2I Vehicle-to-Infrastructure
V2V Vehicle-to-Vehicle
V2X Vehicle-to-X
VM Virtual MachineVMM Virtual Machine Manager
WAVE Wireless Access for Vehicular Environment
WEP Wired Equivalent Privacy
WG Working Group
Wi-Fi Wireless Fidelity
WP Work Package
WPA Wi-Fi Protected Access
XML Extensible Markup Language

x
D5.2: Proof of Concept Use Case Specifications

Document History

Version Date Changes

0.7 09-02-2012 Corrections according to TUB review comments
0.8 10-02-2012 Merged Modification from VW
0.9 10-02-2012 Several modifications according to comments from FOKUS
1.0 13-02-2012 Final design corrections

xi
D5.2: Proof of Concept Use Case Specifications

1 Introduction

1.1 Scope and Objective of the Document

This document contains the results of Task 5.2, the specification of use cases.
In Task 5.1, use cases have been selected and described, as written in Deliverable D5.1. In
this document, the selected use cases are specified providing a detailed description for the
implementation of these use-cases.
Use cases are divided into two categories, first, application use cases, which refer to
applications running on the OVERSEE platform to demonstrate the capabilities of the
platform. The second category, validation use cases, demonstrate the security and isolation
properties of the OVERSEE platform.

1.2 Document Outline

The rest of the document is structured as follows:
 Section 2 contains the application use case specifications. Each use case is specified in
terms of its initial state, involved data, which modules and services of the OVERSEE
base system are used, and a detailed sequence description.
 Section 3 contains the validation use case specifications. These are similar to the
specific application use case, with the adjustment that an attacker model is included.

1
D5.2: Proof of Concept Use Case Specifications

2 Use Case Specifications

Section 2 contains the application use case specifications. The aim is to provide a detailed
description of each use case by defining the involved data, software modules, peripherals
and the application flow. These use cases will be implemented by the consortium within the
task 5.3 and prepared for the demonstration within the work-package 6.
In detail, the following information is given for each use case specification:
 Introduction
The whole use case is briefly described in this section to provide an overview for the
reader.
 Initial state
The initial state of the OVERSEE platform, and other preconditions that must be
fulfilled, before the use case can be started.
 Involved data
Any data that is needed for the use case is listed in this section.
 Used modules and services
Involved modules and services of the OVERSEE platform that are needed as
dependencies.
 Sequence diagram
The exact process is described here as a sequence diagram.
 Description
A detailed textual description of the use-case is provided in this section.
 Notable Changes and Justification
This section serves to notify the reader of any specifications in the use case which do
not comply with previous design specifications or descriptions in other OVERSEE
documents. This may happen due to e.g. technical issues or to highlight special
properties.

2.1 USB Flash Drive Media Access

2.1.1 Introduction

One of the main goals of OVERSEE is to provide a platform which is suitable for infotainment
applications1, e.g., multimedia player. The media files, typically the focus is on audio files to
avoid driver distraction, could be provided either via wireless networks, e.g., 2G/3G or WiFi,
or on a nomadic device, typically an USB memory stick. The current use-case describes the

1
C.f. satements from the OEMs at the first Advisory Board meeting of OVERSEE.

2
D5.2: Proof of Concept Use Case Specifications

connection of an USB memory stick to the OVERSEE platform and forwarding of the access to
the media files to a partition running an appropriate media player.

2.1.2 Initial State

The OVERSEE platform is running and one of the user partitions is executing a media player,
suitable for playing audio files in MP3 format. The user partition has the appropriate access
rights to a nomadic device connected via USB and containing the audio files.

2.1.3 Involved Data

2.1.3.1 OVERSEE configuration

The configuration of OVERSEE will be used to check whether a partition is allowed to access
files on a nomadic device or not. The list of partitions, which are allowed to access nomadic
devices, will be presented to the user for selecting the favored partition.

2.1.3.2 Media files on nomadic device

The audio files on the USB storage device will be accessed and played by the media player.

2.1.3.3 User authentication and user access rights

The operator of the platform has to be authenticated (in general this is the driver with
appropriate authentication via the car key) and, according to the security policy of OVERSEE,
authorized to allow forwarding of access to USB equipped memory devices to distinct
partitions. The authentication and authorization policies have to be present and suitable for
this use-case.

2.1.4 Used Modules and Services

Module or Service Tasks

USB Module Will be connected with the USB equipped nomadic device

Will be informed about the new USB device

USB Manager
Assign the memory of the USB device to the selected partition

Security Service User authentication and authorization

Virtual storage device Provide access to the memory of the USB device as a legacy
driver in the selected mass storage device to the applications
partition

3
D5.2: Proof of Concept Use Case Specifications

Show the available media files and playback options to the user
Media Player
Play media files from attached USB storage device

2.1.5 Sequence Diagram

Figure 1: Media player sequence diagram

2.1.6 Description

A USB flash drive will be connected to the OVERSEE platform. The user has to be either
already authenticated in this moment (e.g. by car key) or requested for authentication (e.g.
by password based authentication). The user will be asked which partition should access the
files stored on the nomadic device. Therefore, the user selects the partition serving the
media player application. Finally the media player accesses the stored files and plays the
audio content.

4
D5.2: Proof of Concept Use Case Specifications

2.2 Emergency Vehicle Warning

2.2.1 Introduction

The use case “Emergency Vehicle Warning” describes an

application running in one of the OEM partitions of the
OVERSEE platform responsible for highly reliable and
highly available functions. This V2V-application generates
a warning within the instrument cluster of the OVERSEE’s
proof of concept vehicle when an emergency vehicle
approaches. This warning, which is addressed to the
driver, includes the course and the distance of the
approaching emergency vehicle.

Figure 2: Graphical
representation of the EVW

2.2.2 Initial State

The emergency vehicle is situated at a greater distance to the proof of concept vehicle and
starts heading towards it. The “Emergency Vehicle Warning” application is running on top of
the OVERSEE platform and subscribes on the ITS Manager for incoming CAMs and on the
SVAS for its own location, heading and vehicle speed.

2.2.3 Involved Data

2.2.3.1 Cooperate Awareness Messages

The emergency vehicle sends out CAMs with its position, heading, speed and status of the
light bar and siren.

2.2.3.2 Vehicle Dynamics and Positioning

To calculate the emergency vehicle warning, the application subscribes on the SVAS to read
the following data objects:
 GeoPosition
 VehicleSpeed
 Course

5
D5.2: Proof of Concept Use Case Specifications

2.2.3.3 Positioning Metadata

To avoid bogus warnings, more detailed information about the position of the emergency
vehicle and the proof of concept car could be needed. This information can be derived out of
the vehicle’s navigation system, also provided by the SVAS. The following data objects give
more detailed information about the vehicle’s position, e.g. street name, road number or
point of interest and roadway classification regulated by national laws, e.g. Motorway,
Freeway, Highway or Local:
 PositionInfo
 RoadClass

2.2.3.4 Emergency Vehicle Warning Trigger Message

To initiate the emergency vehicle warning, the emergency vehicle warning application
triggers a function call including all necessary information on the SVAS that updates a CAN
message the instrument cluster is listen to. This function call is executed when a potential
concourse with the emergency vehicle occurs within the next fifteen seconds, including the
following information read by the instrument cluster:
 Distance to the emergency vehicle
 Course to the emergency vehicle

2.2.4 Used Modules and Services

Module or Service Tasks

ITS Manager Receive CAMs

Send application specific messages
SVAS Provides the following Information:
 GeoPosition
 VehicleSpeed
 Course
 PositionInfo (optional)
 RoadClass (optional)
Provides a function call to initiate the EVW within the
instrument cluster

6
D5.2: Proof of Concept Use Case Specifications

2.2.5 Sequence Diagrams

Figure 3: Emergency vehicle sends CAMs sequence diagram

7
D5.2: Proof of Concept Use Case Specifications

Figure 4: Proof of concept car generates warning sequence diagram

2.2.6 Description

Figure 3 shows how the emergency vehicle sends out CAMs described in 2.2.3.1 every 100
milliseconds. The sending part of the emergency vehicle subscribes for emergency vehicle’s
dynamics and positioning data described in 2.2.3.2 on the Secure Vehicle Access Service. A
CAM is generated and sent out.
Figure 4 shows how the proof of concept car generates an emergency vehicle warning. CAMs
are received and checked for authenticity by the OVERSEE’s security services (not depicted).
These validated messages are filtered for relevance and provided to applications by the
OVERSEE’s ITS manager, the emergency vehicle application subscribes to.

8
D5.2: Proof of Concept Use Case Specifications

In addition, the receiving part of the emergency vehicle warning application also subscribes
for vehicle’s dynamics and positioning data described in 2.2.3.2 on the Secure Vehicle Access
Service.
Within the main loop, the application determines the siren and light bar status of the
emergency vehicle. In the case of active siren and light bars, the distance and course to the
emergency vehicle are calculated. When a potential concourse with the emergency vehicle
occurs within the next fifteen seconds, a function call as described in 2.2.3.4 is executed.

2.2.7 Notable Changes and Justification

All necessary information like distance, heading and time to concourse of the emergency
vehicle are calculated by the application running on top of the OVERSEE platform but the
warning message itself is not generated by this kind of head unit. This warning message is
generated within the instrument cluster that cares about all safety-relevant warnings and
message priorities.

2.3 Sending an Emergency Call

2.3.1 Introduction

The use case “Emergency Call” describes an application running in one of the OEM partitions
of the OVERSEE platform responsible for highly reliable and highly available functions. This
V2X-application generates an automated emergency call in case of a trigger event (e.g.
accident). All relevant data according to eCall’s minimum set of data (MSD) are transmitted
via SMS and represented on the OVERSEE’s HMI.

2.3.2 Initial State

The “Emergency Vehicle Warning” application is running on top of the OVERSEE platform and
at least the ignition of the proof of concept vehicle is turned on. The application subscribes
on the SVAS (Secure Vehicle Access Service) to receive all relevant data according to eCall’s
minimum set of data and to the NPS (Network Provisioning Service) to be prepared to send
out the eCall SMS.

2.3.3 Involved Data

2.3.3.1 Vehicle Parameters, Positioning and Driver Information

To gather all necessary data for an eCall, the application subscribes on the SVAS to read the
following data objects:
 VehicleIdentificationsNumber
 GeoPosition
 Course
9
D5.2: Proof of Concept Use Case Specifications

 LocalTime
 TankLevel
 SeatBeltLock
o Remark: To determine the number of passengers

2.3.3.2 Short Message Service

All pre-processed data are sent via SMS to a figurative emergency operations centre, both as
plaintext and PER-coded. To perform the SMS, the application sends a function call to the
NPS (network provisioning service) including the recipient number and the content.

2.3.3.3 HMI

To trigger the prototypic eCall, a dedicated button of the OVERSEE’s HMI sends a function call
to the eCall application. The return value of this function call includes all data in plaintext
that is sent to the emergency operations centre, visualized on the OVERSEE’s HMI.

2.3.4 Used Modules and Services

Module or Service Tasks

NPS Sending the SMS containing the eCall data

SVAS Provides the following Information:

 VehicleIdentificationsNumber
 Course
 LocalTime
 TankLevel
 SeatBeltLock
HMI Initiates the eCall
Visualizes the eCall data

10
D5.2: Proof of Concept Use Case Specifications

2.3.5 Sequence Diagrams

Figure 5: Trigger and send an eCall sequence diagram

2.3.6 Description

Figure 5 shows how an eCall message gets prepared and sent. The eCall application
subscribes for different vehicle’s parameters and positioning data as described in 2.3.3.1 on
the Secure Vehicle Access Service.
Within the main loop, the eCall application pre-processes the necessary data according to
eCall’s minimum set of data, including PER-coding and ASN.1-structuring.
The HMI triggers the eCall application to send out the eCall data, visualized to the driver.

2.3.7 Notable Changes and Justification

The feature eCall in the meaning of a series product is very complex. It is not possible to
fulfill all requirements within the OVERSEE project. A realistic implementation of eCall is out
of focus; thereby this prototypic implementation of an eCall application does not include

11
D5.2: Proof of Concept Use Case Specifications

either the transmission of data via in-band modem nor handover a voice channel to the
vehicle’s passengers.

2.4 Update Partition or OVERSEE Component

2.4.1 Introduction

The OVERSEE Software Update Service provides a central place to manage updates of
complete partitions who do not implement update mechanisms for themselves. In addition
to that it serves as an example for update mechanisms implemented in more complex multi-
application partitions.
The Update Service can update 3 different parts of the OVERSEE system:
 The XEF file, i.e. the whole application in case of a single-application partition, the
kernel in case of a Linux partition
 The file system image in case of a Linux partition
 A file archive for updating the Secure I/O partition itself

2.4.2 Initial State

Consider an XtratuM partition with an application. This partition consists of a kernel

embedded into XtratuM as a XEF file, and a disk image with a file system. Now the software
vendor has created an updated kernel, disk image, or file archive, which he wants to
distribute. He has already packaged it, and, he has noticed the OEM of the update. The OEM
has entered the update into the Update Notification List.
Before updating, the application is still running from an older version of the file system
image.

2.4.3 Involved Data

2.4.3.1 Key Infrastructure

The OEM owns a signing key with a valid certificate enabling him to sign the update
notification lists. The certificate is issued and signed by the OEM’s CA and the chain of trust
traces to a root certificate that is considered trusted by the OVERSEE platform.

2.4.3.2 Update Notification List

The Update Notification List is a list of all current update announcements.

An update announcement consists at least of
 An ID identifying the partition to be updated
 A version number which is machine readable

12
D5.2: Proof of Concept Use Case Specifications

 A short description targeted at the vehicle owner

 Information, on which updates this update depends
 A cryptographic hash value of the update package
 The location of the update package
In addition to that, a digital signature over the whole list is attached, including all certificates
necessary to verify that signature.
For every distinct model of an OVERSEE instantiation a separate update list will be available,
but it is expected that these lists are subsets of a global update package pool, so that most
packages can be reused between different OVERSEE instantiations.

2.4.3.3 Update Package

The Update Package is a binary package consisting of two basic components:

 Meta data and machine-readable install instructions
o Version Number
o Target Partition ID
o Information about included update
 Type, one of
 XEF
 Whole file system
 File archive
 Specific data, e.g., file system ID if there are multiple file systems per
partition
o Optional: Install Scripts, Uninstall Scripts
 Compressed update data, one of:
o File system Image
o XEF file
o File Archive

2.4.3.4 Package Status Database

The package status database should contain information about every update packet that is
installed currently.
 Partition ID
 File system ID
 Version of file system.

13
D5.2: Proof of Concept Use Case Specifications

2.4.4 Used Modules and Services

Module or Service Tasks

Communication Module Receiving update notifications

Downloading update package
Security Service Secure transmission
User authentication
Update list and package authentication
HMI Service Ask for user confirmation
Display progress
XtratuM Service Control partition status (start/stop)
I/O-Service Exchange raw file systems
SVAS Engine status

14
D5.2: Proof of Concept Use Case Specifications

2.4.5 Sequence Diagrams

Figure 6: Software update sequence diagram

15
D5.2: Proof of Concept Use Case Specifications

Figure 7: Permission request sequence diagram

Figure 8: Verify software update list sequence diagram

16
D5.2: Proof of Concept Use Case Specifications

Figure 9: Execute software update sequence diagram

2.4.6 Description

The Update Manager is periodically polling a dedicated server (e.g. update announcement
server), where all available updates are collected in form of a list.
After download, the list is verified against the root certificate by the security service to make
sure that the list is approved by the owner of a valid certificate that allows software upgrades
to be issued.

17
D5.2: Proof of Concept Use Case Specifications

All update announcements are checked if they apply to the current system. If yes, the update
manager waits for a suitable moment to ask the owner for approval. This should be the next
time the vehicle engine is not running.
When the owner approves the update and authenticates himself, the download of the
update package is started.
Upon completion, the update manager lets the Security Service verify the package’s hash,
that means, the Security Service calculates a hash value over the package contents, and
compares to the corresponding hash value previously downloaded list of announced
updates.
If all checks have been successful, the package is installed, that means:
 The update manager stops the respective partition.
 The update manager replaces the old content with the content of the update package
in such a way, that the old content can be restored.
 The update manager starts the partition.
 If any serious error occurs during this procedure, the procedure has to be aborted
and the partition must be restored to its state before the update.

2.4.7 Notable Changes and Justification

It is vital that the update process is very reliable, so a proven existing solution will be
adopted to provide the backbone of this use-case. It is possible that the configuration
capabilities of these solutions do not base on xml as stated in Deliverable 2.2 and hence
cannot fulfill the configuration requirements.

2.5 Cooperative Platoon Automation System

2.5.1 Introduction

The use case “Cooperative Platoon Automation System” describes a V2V-application running
on top of the OVERSEE platform. The Platooning Application enables automated velocity and
steering control of a vehicle group (platoon) in order to let the vehicles travel closely one
behind another. Driving inside a platoon promises to enhance traffic safety and to reduce
fuel consumption.

2.5.2 Initial State

The platoon should already be established. It should consist of a leading vehicle and at least
one following vehicle. The structure of the platoon and the role of each vehicle is appointed
and known to all participants. Messages of participating vehicles inside a platoon are
recognized by a vehicle id, which should be contained equally in all messages. Pseudonym-
change should be locked during the lifetime of the platoon to avoid changes of the vehicle id.

18
D5.2: Proof of Concept Use Case Specifications

Alternatively, the optional update process described in section Update Procedure (optional)
may be used.
The initial state may be set by configuration or alternatively reached through the optional
join procedure described in section Join Procedure (optional).

2.5.3 Involved Data

2.5.3.1 V2X Message Types for Vehicle Coordination

Besides sensor values, a number of different V2X message types is used for coordination of
vehicles inside a platoon. In particular, vehicles are coordinated through regularly
broadcasted messages like CAMs, DENMs, and optionally additional application specific
messages, as described below.
Cooperative Awareness Messages
Most information required for coordination is already contained in regularly broadcasted
CAMs. Relevant fields for the Platooning application are:
 Position
 Speed
 Heading
 Acceleration
 Confidence of the values above
Decentralized Environmental Notification Message
Several environmental notification messages indicate critical situations that are essential for
coordination. Especially, the following DENM subjects might be of special interest:
 Dangerous Driving – Hard brake vehicle
Platoon Coordination Message (optional)
Additional information, which is not part of the previously described message types, might
be exchanged regularly through application specific messages. Platoon Coordination
Messages contain optional data that complements CAMs and DENMs but does not replace
them, e.g.
 Lane specific information
 More precise location information, in terms of spatial and/or time-wise accuracy
This message type is most probably not necessary for a proof-of-concept implementation.

2.5.3.2 V2X Message Types for Platoon Management

Platoon management comprises all tasks to organize a platoon including join, update, leave,
and dissolve procedures, as well as distributing the platoon structure to participants and
announce platoon information to surrounding vehicles. In contrast to vehicle coordination,

19
D5.2: Proof of Concept Use Case Specifications

platoon management cannot be mapped on standardized message formats, but must be

implemented with application specific message types.
Platoon Announcement Message
A Platoon Announcement Message describes the current platoon structure and consists of
the information below.
 Ordered platoon participant list, including the following data for each participant
o Position in platoon
 The leader on first position
 Following vehicles on positions 2, 3, etc.
o Vehicle ID
 Unique Node ID that is mapped to the vehicles signer certificate
 This ID appears also in CAMs and DENMs in order to assign messages
to specific vehicles.
Platoon Request Message (optional)
A Platoon Request Message allows platoon followers to ask or notify the leader on changes
of their platoon participation. It consists of the following fields:
 Request type, with one of the values
o JOIN (to indicate the wish to join a platoon as follower)
o UPDATE (to inform the leader on important changes, e.g., id change)
o LEAVE (cancel platoon participation and leave platoon)
 Optional data, e.g., the new vehicle id
Platoon Advertisement Message (optional)
Platoon Advertisement Messages inform surrounding vehicles about the platoon, in
particular about its
 Destination
This message type is most probably not necessary for a proof-of-concept implementation.

2.5.4 Used Modules and Services

Module or Service Tasks

ITS Communications Receive CAMs, DENMs, and application specific messages

Send application specific messages
Read vehicle/node id
Lock/unlock change of vehicle/node id
SVAS Read distance sensors and/or radar

20
D5.2: Proof of Concept Use Case Specifications

Read speed, steering-angle and further values

Car Control Service Access all available vehicle controls for automatic driving.
(Non-OVERSEE)

2.5.5 Sequence Diagram

Figure 10: Message sequence chart of the Platooning use case

21
D5.2: Proof of Concept Use Case Specifications

Figure 11: Platooning from the view of a follower vehicle

2.5.6 Description

The operation of the Platoon application is separated into two mostly independent
components: the “real-time” coordination of the vehicle’s routes and the management of the
platoon structure.

2.5.6.1 Vehicle Coordination

Vehicle coordination ensures that vehicles inside a platoon coordinate their velocity and
lateral position to stay in a line one after another. Besides (distance) sensor values, mainly
V2V messages are used for that. As described in section 2.5.3.1 several message types are
involved including conventional CAMs and DENMs. These messages are generally
unencrypted but should be signed to avoid possible attacks. Except of DENM, which are sent
only in special situations, all messages are sent periodically with preferably high frequency
(at least 1 message per second). Figure 10 visualizes the process.

22
D5.2: Proof of Concept Use Case Specifications

Coordination messages are always broadcasted. Hence, each vehicle must know the
structure of the platoon to filter incoming messages and regard only that ones from vehicles
inside the platoon, which are driving ahead. Consequently, participants of a platoon must
maintain a platoon map that consists of an ordered list of all platoon participants. The next
section describes the process to keep the list up to date. Figure 11 shows an overview to the
Platooning application from the view of a follower vehicle.

2.5.6.2 Platoon Management

Platoon management comprises the whole organization of the platoon including join, leave,
and update procedures.
The platoon leader sends Platoon Announcement Messages (PAM) on changes of the platoon
to inform participants about the current platoon structure. Addressees are only the following
vehicles inside the platoon, so that instead of broadcasting PAMs, encrypted multi-cast
communication (respectively encrypted single-cast to each participant, if multi-cast is not
available) may be used in order to increase privacy of the platoon participants.
Each of the following procedures, results in sending an updated announcement message (at
least if it was successful). The announcement is also a confirmation for the according
requests.
Join Procedure (optional)
Vehicles who want to join a platoon execute the following procedure:
 The vehicle sends a join request (Platoon Request Message of type JOIN) to the
platoon leader.
 If the leader accepts the vehicle to be a member of the platoon, he sends an updated
Platoon Announcement Message to the platoon participants including the newly
joined vehicle.
 The vehicle takes its position in the platoon and switches to automatic driving
following the vehicles ahead.
Leave Procedure (optional)
A following vehicle may leave the platoon with the following procedure:
 The vehicle sends a leave request to the platoon leader.
 The platoon leader sends an updated Platoon Announcement Message to the platoon
participants, which does not contain the leaving vehicle any longer.
 The vehicle leaves the platoon.
Update Procedure (optional)
An update request is needed in particular on changes of the vehicle id of a platoon
participant. Since other vehicles are not able to map messages with a changed id to a
platoon member, the id-change has to be published to the platoon leader who updates the
platoon announcement. In detail the procedure is:

23
D5.2: Proof of Concept Use Case Specifications

 A vehicle recognizes a pending id-change. Before the id-change takes place, the
vehicle sends an update request (Platoon Request Message of type UPDATE)
containing the new id to the platoon leader. This request is still signed with the old id.
 The id-change is performed. Afterwards, the vehicle confirms the id-change by
resending the update request to the platoon leader. This time it is signed with the
new id.
 The platoon leader sends an updated Platoon Announcement Message to the platoon
participants, which contains the new vehicle id.
Dissolve Procedure (optional)
The platoon leader may dissolve the platoon at any time, at the latest when arriving at its
destination. To avoid safety critical situation the platoon should be stopped before dissolving.
The following process dissolves the platoon:
 The platoon leader sends an empty Platoon Announcement Message.
A more sophisticated approach would allow dissolving a moving platoon by warning drivers
through HMIs and ensuring that each driver takes the control over his vehicle back.
Nevertheless, this proof-of-concept implementation/specification is suited for model cars
without drivers and HMIs and does not regard this issue.

2.5.7 Notable Changes and Justification

This use case was not part of the initial use case list, which was defined in D1.1. The reason
behind that fact is that D1.1 concentrated on near-term use cases and excluded safety critical
use cases. Within work package 5, the need of long-term use cases was recognized and as a
result D5.1 introduced the Platooning use case. Since then the use case remained
unchanged; even the optional parts were maintained. However, these optional parts
(including join, leave, and update procedures) will most probably not be implemented for the
demonstrator, because the focus is more on the main part that is required for the validation
use cases.
In order to implement autonomous driving manoeuvres, this use case makes use of an
automatic driving component, which is not part of the OVERSEE platform. This component is
pre-existing knowledge as part of the model car platform and will not be delivered together
with the use case implementation.

2.6 Active Brake

2.6.1 Introduction

The use case Active Brake is an application running on top of the OVERSEE system. The use
case demonstrates how V2X-messages may lead the vehicle to a safety reaction. Therefore,
Decentralized Environmental Notification Messages (DENM) are broadcasted to surrounding
(in particular following) vehicles, which indicate a road hazard (e.g., an hard braking vehicle).
Based on these notifications and/or sensor values (e.g., distance sensors or radar), drivers in

24
D5.2: Proof of Concept Use Case Specifications

the relevance area are warned and in case of emergency their cars are actively braked to
avoid a crash.

2.6.2 Initial State

The Active Brake Application subscribes on the ITS Communications Service for incoming
“hard brake vehicle” events. Additionally, it registers on SVAS to observe the brakes for an
emergency braking.

2.6.3 Involved Data

2.6.3.1 Decentralized Environmental Notification Message

The DENM is broadcasted via V2X and delivered internally (in a more abstract form) to the
Active Brake Application. Based on the ETSI specification [1], it contains at least the following
values:
 Situation information, including
o Cause code and sub cause code, e.g.
 101 (Dangerous Driving)
 1 (Hard brake vehicle)
 102 (Intersection violation)
 1 (Stop sign violation)
 2 (Traffic lights violation)
o Severity level, with
 1 for relatively low safety impact
 4 for high safety critically events
 Location information, including
o Exact geographic event position
o Relevance area
 Management information, including
o Generation time
o Expiry time

2.6.3.2 HMI Warning Message

The warning message should be displayed visually or acoustically on an HMI device. The
message contains the following data values:
 Reason, e.g., “Hard brake vehicle” or “Stop sign violation”

25
D5.2: Proof of Concept Use Case Specifications

 Distance in meters to the hazardous location

2.6.4 Used Modules and Services

Module or Service Tasks

ITS Communications Receive Decentralized Environmental Notification Messages

Send Decentralized Environmental Notification Messages
HMI Display visual or acoustic warning message

SVAS Read distance sensors and/or radar

Read brake status
Car Control Service Trigger emergency brake
(Non-OVERSEE)

2.6.5 Sequence Diagram

Figure 12: Detection and broadcasting of warning events

26
D5.2: Proof of Concept Use Case Specifications

Figure 13: Incoming V2X messages lead to safety reaction

2.6.6 Description

Various events, such as a hard breaking of a vehicle, may cause a road hazard warning. These
warnings are encoded as and broadcasted via the V2X network. Events regarded for the
Active Brake use case are “Emergency electronic brake lights” and for the alternative variant
“Signal violation warning”. Receiving vehicles analyse these event notifications for relevance
according to their actual position, driving direction, and speed. If the vehicle is located in the
relevance area, a warning message is delivered to the driver. After falling below certain
distance to the event, the Active Brake Application triggers an automatic emergency brake
and broadcasts an additional emergency brake notification to following vehicles.

2.6.7 Notable Changes and Justification

The first description of this use case in D1.1 was not meant to be a long-term use case.
Hence, all safety relevant parts were excluded. However, work package 5 decided to include
also the long-term aspects such as real active breaking instead of only displaying warning
messages.
In order to implement automatic emergency braking, this use case makes use of an
automatic driving component, which is not part of the OVERSEE platform. This component is
pre-existing knowledge as part of the model car platform and will not be delivered together
with the use case implementation.

27
D5.2: Proof of Concept Use Case Specifications

3 Validation Use Case Specification

3.1 USB Flash Drive Media Access

3.1.1 Introduction

The availability of access to nomadic devices usually causes a high risk of attacks, by using
manipulated files opened by the unaware user of the platform. Indeed, manipulated files
could be provided to the media player of OVERSEE. Nevertheless, due to the isolated runtime
environments and the protected interfaces between the OVERSEE components; the effects
will be limited to the partition executing the media player.

3.1.2 Attacker Model

An external attacker (could be also the user of the platform) is assumed to be able to
manipulate files (e.g., audio files) which will be stored on a nomadic device, which will be
probably connected to the OVERSEE platform in a reasonable amount of time.

3.1.3 Additional Components

 Manipulated files
These files are stored on a nomadic device equipped with an USB interface which will be
probably connected to the OVERSEE platform. Thus, access to the modified files will be
provided to the media player installed in one partition of the OVERSEE platform. The files
are modified by the attacker to harm either other partitions or the platform with its
capabilities, e.g., in terms of in-vehicular communication.

3.1.4 Sequence Diagram

See Figure 1 concerning the connection of nomadic devices via USB, consider the files stored
on the attached device as manipulated.

3.1.5 Description

An attacker modifies media files which will be provided to the medial player, executed in one
partition of the OVERSEE platform, by use of an USB equipped nomadic device. Due to the
isolation properties and the protected interfaces in OVERSEE, the consequences will be
limited to the partition executing the media player. Thus, no serious safety or security
problems will occur.

28
D5.2: Proof of Concept Use Case Specifications

3.2 Emergency Vehicle Warning / E-Call

3.2.1 Introduction

Functions with the requirement of high reliability and availability like Emergency Vehicle
Warning and E-Call have to be executed in isolated domains of OVERSEE.
This is done in order to eliminate influences of other applications with different security and
dependability requirements.
To validate the isolation mechanisms of OVERSEE, an exemplary scenario with a faulty third
party application, which causes a crash of an operating system within the open domain, will
be assumed.
Mechanisms to identify attacks against V2X-Communications or insertion of manipulated
software are shown in other use cases within the model car demonstration and the platform
demonstration.

3.2.2 Attacker Model

Not applicable. It is assumed that the third party application that crashes the operating
system behaves unintentionally faulty.

3.2.3 Additional Components

 Faulty third party application

This application is installed and executed in the partition responsible for third party
applications (open domain).
As an example, this application will provide additional information to the navigation
system in order to find free parking lots in one’s proximity.

3.2.4 Sequence Diagram

The procedures of Figure 4 and Figure 5 remain unchanged. The third party application is
executed in parallel.

3.2.5 Description

The third party application is executed right before the use cases start. The faulty behavior of
the third party application is triggered remotely. Due to the isolation properties of OVERSEE,
the consequences will be limited to the partition executing the faulty application. Assuming
that the isolation capabilities of the OVERSEE platform work correctly, the behavior of EVW
and E-Call remain unchanged.

29
D5.2: Proof of Concept Use Case Specifications

3.3 Update Partition

3.3.1 Introduction

In this misuse case an attacker aims to inject malicious software into an OVERSEE partition
via the update functionality.

3.3.2 Attacker Model

An external attacker is assumed. He has control over the environment of the vehicle (i.e.
wireless communication), but he has no internal access to the vehicle systems or the OEM’s
systems. He may therefore manipulate external communication.

3.3.3 Additional Components

 OEM Impersonation
The attacker has to be able to intercept and fake the necessary communication, for
example by providing a Wi-Fi access point with a fake DNS server and a fake server for
updates and update announcements.
 Malicious update package
The attacker has to build a malicious update package by changing a legitimate
package or by creating one from scratch.
The hashes, cryptographic signatures and certificates can be omitted or faked to a
certain degree:
o Simple omission
o Hash does not fit to package
o Changed update list
o Certificate with different public key
o Different Intermediate certificates
o Different Root certificate

30
D5.2: Proof of Concept Use Case Specifications

3.3.4 Sequence Diagram

Figure 14: Attack on the software update process

3.3.5 Description

The process is very similar to the process described in section 2.4, except that the attacker
impersonates the OEM.
He provides a fake update announcement list and provides fake update packages.
The OVERSEE platform will recognize this at one of the two verify steps, as the attacker
cannot fake full valid cryptographic signatures or hashes.

31
D5.2: Proof of Concept Use Case Specifications

3.4 Platoon

3.4.1 Introduction

In this misuse case, an attack against the V2X communication is assumed.

3.4.2 Attacker Model

The attacker has access to V2X communication, but not to internal components. To bypass
security mechanisms he may use different approaches, which differ in their prospect of
success:
 Usage of a self-signed certificate
 Replay of already signed messages
 Misuse of a valid certificate

3.4.3 Additional Components

 ITS Communication stack

The attacker needs to own a complete OVERSEE ITS Communication stack, including
hardware and software components or a compatible equivalent.
 Certificates
To bypass ITS security mechanisms messages have to be signed. Therefore, valid
certificates are necessary.
 Application logic/messages
Manipulation of an actual application needs understanding of the application logic.
For simple attacks, a manipulated application specific message may be sufficient.

3.4.4 Message Sequence Diagram

Figure 15: Attack trying to hijack a platoon

32
D5.2: Proof of Concept Use Case Specifications

3.4.5 Description

Figure 15 givers an overview how to hijack a platoon. Note that position updates are always
broadcasted, but here only relevant receivers are shown that navigate based on this data.
The attacker tries to impersonate the role of the platoon leader. The approach would be:
1. Send a faked Platoon Announcement message that contains a manipulated list of
platoon participants with the attacker as platoon leader. This step is vital for the
success of the attack; if any receiver figures out that the platoon leader is not the
sender of the announcement message, he will reject it. Possible approaches are:
a. Use a self-signed identity
b. Manipulate a captured message
c. Use a stolen identity
2. The platoon members recognize the changed platoon structure and start following
the attacker.
3. Broadcast manipulated position updates that lead the platoon on the desired route.
Countermeasures: OVERSEE verifies incoming messages, with the result that
a. invalid sender identities are recognized by verifying the certificate,
b. manipulated messages are detected by verifying its signature, and
c. stolen identities are invalidated by revocation.
Hence, the receiver detects and discards manipulated messages and the attack should fail
after step 1.

3.5 Active Break

3.5.1 Introduction

In this misuse case, a replay attack against the V2X communication is assumed.

3.5.2 Attacker Model

The attacker has access to V2X communication, but not to internal components. To bypass
security mechanisms, the attacker captures messages that are already signed by other
communication participants. The attacker may replay a message in order to pretend a
situation, which was specified within the captured message. The attacker is not able to
change the content of the signed message without invalidating it. Hence, the location of the
attack must be the initial location of the event. To prevent the attack from being revealed, a
message should never be sent twice to the same vehicle. Additionally, the attacker has only a
short time window in which the message is regarded as being valid.

33
D5.2: Proof of Concept Use Case Specifications

3.5.3 Additional Components

 Wireless communication module

The attacker needs to own a wireless communication module that is compatible to
OVERSEE ITS communications and allows capturing and replaying specific messages.

3.5.4 Message Sequence Diagram

Figure 16: Replay attack to fake a hard braking vehicle

3.5.5 Description

The attack against the Active Brake use case proceeds as shown in Figure 10:
1. The attacker captures a DENM with the cause “Hard brake vehicle”. This could happen
just by randomly observing vehicles or by provoking an emergency brake, e.g.,
physically or by using this attack.
2. Later the DENM can be replayed to vehicles in the DENM’s relevance area that did not
capture the original message. In this manner, the replay-attack will not be recognised.
3. The attacked vehicle will trigger automatically an emergency brake.
4. If step 3 was successful, the attacked vehicle will broadcast a DENM indicating the
hard-brake event. Using this newly generated DENM, the attack may be repeated
recursively.
Countermeasures: OVERSEE verifies incoming messages, with the result that
a. message hashes are stored to detect replay attacks, and
b. timestamps are checked to discard old messages.
Hence, the receiver detects and discards the replayed messages and the attack should fail
after step 2.

34
D5.2: Proof of Concept Use Case Specifications

References
[1] ETSI: TS 102 637-3 V1.1.1. Intelligent Transport Systems (ITS); Vehicular Communications; Basic
Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic
Service. Sep 2010.
[2] DIN: EN 15722, Intelligent transport systems – eSafety – eCall minimum set of data (MSD);
German version EN 15722:2011. Oct 2011
[3] OVERSEE: D5.1 Proof of Concept Use Cases. 2011
[4] OVERSEE: D2.1 List of interfaces and specifications of information flow. 2011
[5] OVERSEE: D2.4 Specification of Secure Communication. 2011

35