D5.2: Proof of Concept Use Case Specifications · Web viewGSM Global System for Mobile...

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: 08 May 2023

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


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.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.6 Description....................................................................................................6

iii



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.6 Description....................................................................................................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.6 Description....................................................................................................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.6 Description....................................................................................................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.5 Description....................................................................................................6

3.2 Emergency Vehicle Warning / E-Call.....................................................................6

3.2.1 Introduction..................................................................................................6

iv


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



3.2.5 Description....................................................................................................6

3.3 Update Partition...................................................................................................6

3.3.1 Introduction..................................................................................................6

3.3.2 Attacker Model..............................................................................................6



3.3.5 Description....................................................................................................6

3.4 Platoon................................................................................................................. 6

3.4.1 Introduction..................................................................................................6

3.4.2 Attacker Model..............................................................................................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.4 Message Sequence Diagram.........................................................................6

3.5.5 Description....................................................................................................6

References................................................................................................................................ 6

v


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


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


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


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


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


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


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


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:

IntroductionThe 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


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

USB ManagerWill be informed about the new USB device

Assign the memory of the USB device to the selected partition

Security Service User authentication and authorization

Virtual storage device driver in the selected partition

Provide access to the memory of the USB device as a legacy mass storage device to the applications

3


Media PlayerShow the available media files and playback options to the user

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


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


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



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


2.2.5 Sequence Diagrams

Figure 3: Emergency vehicle sends CAMs sequence diagram

7


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


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


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.



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



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.


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


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


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 Numbero Target Partition IDo 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 Imageo XEF fileo 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




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



sd Software Update

Oversee Platform

Update Manager OEMSecurity Service XtratuM IOManager

loop

opt

[engineOff]

ref

verifyList

ref

askPermission

ref

executeUpdate

mayUpdate=askPernission() :bool

updateList= pollForUpdates()

verifyList(updateList)

updatesToBeInstalled=determineUpdates()

updatePackage= downloadUpdate(updateID)

verifyPackageHash(Package)

Figure 6: Software update sequence diagram

15


sd askPermission

HMI ManagerOwner

Security Service

opt

[not Authenticated]

askForAuthentication()

askForPermission()

Figure 7: Permission request sequence diagram

sd v erifyList

Security Service


listHash=calculateHash(updateList)

verifyCertificate(certificate)

verifyCertificate(rootCA)

verifyCertificate(intermediateCAs)

verifySignature(listHash,signature, certificate)

Figure 8: Verify software update list sequence diagram

16


sd executeUpdate

XtratuMUpdate ManagerIO Manager

alt

[type == XEF]

alt

[type == Partition]

alt

[type ==Files]

replaceXEF(partitionID, XEFFile)

newXtratumObject=linkTogether(XEFFiles)

reboot(newXtratumObject)

stopPartition(partitionID)

replaceFileSystem(fileSystemID)

startPartition(partitionID)

stopPartition(partitionID)

mountFileSystem(fileSystemID)

unpackFilesTo(updatePackage,fi leSystemID) startPartition(partitionID)

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


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.


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

18


id. 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


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.



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


Read speed, steering-angle and further values

Car Control Service

(Non-OVERSEE)

Access all available vehicle controls for automatic driving.


Figure 10: Message sequence chart of the Platooning use case

21


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


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:

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)

23


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.


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 the relevance area are warned and in case of emergency their cars are actively braked to avoid a crash.

24


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”

Distance in meters to the hazardous location

25




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

(Non-OVERSEE)

Trigger emergency brake


Figure 12: Detection and broadcasting of warning events

26


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.


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


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.


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


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.


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


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.


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


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.


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.


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



sd Software Update Misuse

Must Fail

Oversee Platform

Update Manager OEMSecurity Service XtratuM IOManager

Attacker

loop

opt

[engineOff]

ref

v erifyList

ref

askPermission

ref

executeUpdate

mayUpdate=askPernission() :bool

updateList= pollForUpdates()


updatesToBeInstalled=determineUpdates()

updatePackage= downloadUpdate(updateID)

verifyPackageHash(Package)

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


3.4 Platoon

3.4.1 Introduction

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


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


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


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.


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



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


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

D5.2: Proof of Concept Use Case Specifications · Web viewGSM Global System for Mobile...

Documents

Transcript of D5.2: Proof of Concept Use Case Specifications · Web viewGSM Global System for Mobile...