AutoSar IDS Architecture

Here,

  • Doc Name refer to docs that AutoSar published.
  • Section as item to its parent.
  • Definition The definition to important concept.

AutoSar IDS Reference Documents

Domain Documents Description
IdsM AUTOSAR_RS_IntrusionDetectionSystem.pdf This document specifies requirements for the AUTOSAR Intrusion Detection System (IDS) .
IDS Protocol Layer AUTOSAR_PRS_IntrusionDetectionSystem.pdf This Protocol Requirements Specification defines the format, message sequences and semantics of the AUTOSAR Protocol IDS
IdsM specification AUTOSAR_SWS_IntrusionDetectionSystemManager.pdf This specification describes the functionality, API, and the configuration for the AUTOSAR Basic Software module Intrusion Detection System Manager ( IdsM).

General Architecture of a distributed onboard IDS

An onboard IDS according to the AUTOSAR standard consists of the following elements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
graph BT;
subgraph In-Vehicle
subgraph ECUA
A(Host Sensor)-->C(IdsM)
B(Ethernet Sensor)-->C(IdsM)
I(Sem)---C
end
subgraph ECUB
E(Host Sensor)-->G(IdsM)
F(Ethernet Sensor)-->G(IdsM)
J(Sem)---G
end

C-->D(IdsR)
G-->D
end

subgraph TSP
H
end

D-->H(SOC)

style D stroke:#333,stroke-width:2px,stroke-dasharray: 5 5;

As listed, we got the following elements that constitute AutoSar IDS standard:

  • Secure Sensor
  • Intrusion Detection System Manager(IDSM)
  • Security Event Memory(Sem)
  • Intrusion Detection System Repoter(IDSR)

The Intrusion Detection System Manager (IdsM) is a Basic Software module (for the AUTOSAR Classic Platform) or a Platform Service (for the AUTOSAR Adaptive Platform) that collects and centrally aggregates security incidents that possibly result from malicious attacks on the vehicle’s software, communications or electronics system. In each of the security relevant ECUs or machines within the vehicle, an instance of the IdSM module or service collects and filters security events (optionally including additional data) in order to store them in a local Security Event Memory (Sem) and/or to forward them over the vehicle network to a central Intrusion Detection System Reporter (IdsR). This IdsR might be, for example, located within a telematics unit enabling it to send security reports and associated data via a cellular network to an OEM’s Security Operations Center (SOC). This information is then analyzed by the Security Incident and Event Management (SIEM) and, if necessary, used to develop and decide on appropriate defense or mitigation actions to counter the attack.

Security Sensors and Security Events

AUTOSAR BSW modules, CDD and SWC can act as Security Sensors. Security sensors report Security Events (SEv) to the IdsM, and the module IdsM itself can also be used as a Security Event sensor.

IDSR

IdsR is the bridge between Car and Backend, which is NOT SPECIFIED by AutoSar actually. The IdsR should typically further enrich the received data e.g. geo-position based on OEM requirement for the needs of SIEM.

IDS protocol

This Protocol Requirements Specification AUTOSAR_PRS_IntrusionDetectionSystem defines the format, message sequences and semantics of the AUTOSAR Protocol IDS.

The main use case for the IDS protocol is the propagation of Qualified Security Events QSEv to the IdsR in a way that is independent from the kind of ECU or the used communication mechanism.

Protocol specification

Overview

Event Frame Timestamp(optional) Context Data(optional) Signature(optional)

Protocol Detail

FieldName Length Purpose Description
Protocol Version 4 Bit The version of the IdsM protocol
Protocol Header 4 Bit IdsM protocol header information: Bit 0: 0 - No Context Data included, 1 - Context Data included
Bit 1: 0 - No Timestamp included, 1 - Timestamp included
Bit 2: 0 - No Signature included, 1 - Signature included
Bit 3: reserved
IdsM Instance ID 10 Bit Unique identifier of the sending, IdsM - Instance 0 - 1023
Sensor Instance ID 6 Bit Identifier to differ between multiple instances of sensors
Event Definition ID 16 Bit Unique identifier of a Security Event Range of AUTOSAR internal IDs: 0…0x7FFF
Range of Customer specific IDs: 0x8000…0xFFFE
Count 16 Bit Number of IdsM calls which result in the current event after processing the configured filter, e.g. EventAggregation 1.. 65535 .
Reserved 8 Bit Reserved for future use
Timestamp 64 Bit Timestamp/Timestamp when event was detected: (optional) Byte0 - Bit7: 0 - AUTOSAR Standard, 1 - Auxiliary/ OEM specific
Byte0 - Bit 6: reserved
Resolution in ms. Maybe not necessary for every event type (optional).
Context Data 2..(2^31 + len) Bytes Binary blob attached by the sensor. (optional) Most Significant Bit of first byte signals if ContextData Length is encoded in
7 Bit (1 Byte) or 63 Bit (4 Bytes):
Context Data [0]: MSB = 0 - 7 Bit Length Information encoded in Context Data [0]: 1..127
Context Data [0]: MSB = 1 - 63 Bit Length Information encoded in Context Data [0..3]: 1..2^31
len = 1 or 4
Signature 3…65537 Bytes Signature for encryption of security event. (optional) Signature calculated with Event Frame + optional Timestamp + optional Context Data
Signature[0..1]: Signature Length 1..65535

Byte Order The IDS protocol uses big endianess as byte order also known as Motorola format

Event Frame

Event Frame consists of Protocol Version, Protocol Header, IdsM Instance ID, Sensor Instance ID, Event Definition ID, Count and Reserved part.

Timestamp
Source Reserved Nanoseconds Seconds

Bit 7: Souerce

  • 0: AUTOSAR Standard CP: StbM - AP: ara::tsync
  • 1: Auxiliary/ OEM Specific timestamp

If Bit 7 = 0, then:

  • Reserve:Bit 6
  • Nanoseconds:Byte 0(0::5)::3
  • Seconds: Byte 4::7
Context Data

The IDS protocol provides an optional feature to enrich the standard security event transfered in the Event Frame with more detailed information. Therefore context data can be added. It is a binary blob attached by the sensor. These data includes specific detailed information about the security event which can be used by the SOC for improved analysis of the security incident, e.g. a malformed message detected by a communication sensor.

IdsM has no knowledge of the content or structure of these data. Only the issuing sensor and the Backend or SOC knows it

Signature

The IDS protocol provides an optional feature to make the transmission of QSEv more secure. A digital signature can be added to the IDS message. It can be used to ensure authenticity as well as to prove integrity of signed messages from the IdsM via all communication systems until reaching the Backend or SOC (End2End-Security).

IDSM

The Intrusion Detection System Manager handles security events reported by security sensors.

  • IDSM privides a standardized interface for receiving SEvs. SEv can be reported with optional context data.
  • IDSM has the capability of qualifying SEvs, filters and transforms reported SEVs into QSEvs
  • QSEvs can be stroed locally on Security Event Memory(Sem) or forwarded towards configured sinks, or both.
  • Sinks could be Diagnostic Event Manager(Dem) and IDSR. Both may pass QSEv data to SOC.

The IdsM shall provide interfaces for reporting SEv. The interfaces shall allow to report the following SEv properties:

  • Security event type: Uniquely identifies the security event type
  • Context data: Optional data which can be used to analyze the security event in the SOC.
  • Timestamp: Optional timestamp provided by the sensor.
  • Count: Optional count provided by the sensor.

IdsM shall provide mechanisms to add timestamps to SEvs.

Timestamp Sources: IdsM shall provide mechanisms to let application or sensor software provide timestamps.

IdsM shall allow to transmit the QSEv and context data by using an IDS protocol, which is independent from the underlying bus technology

The IdsM shall be able to locally persist QSEvs via a user defined diagnostic memory. The user defined diagnostic memory shall be separate from the main diagnostic memory to allow separate access control and protection of the NVM block which is used to store the QSEv records. Persisted QSEvs can be accessed at a later point in time for analysis without relying on, e.g., network connectivity.

IdsM shall support limiting the rate of QSEvs transmitted to the IdsR and the bandwidth consumed by these transmissions.

AUTOSAR_TPS_SecurityExtractTemplate

The Security Extract Template (SECXT) is part of the Intrusion Detection System (IDS). In the context of ECU development projects, the SECXT serves multiple use cases. The SECXT specifies the security events and their properties for a vehicle on system level. The Security Extract as a specific, “standalone” file for security event definitions is in particular useful in view of the reasonable expectation that new approaches or kinds of attacks are identified after SOP of a vehicle. The resulting new or changed security events lead to an updated SECXT file that can subsequently be deployed onto the affected ECUs or machines of a vehicle together with a software update. Additionally, the SECXT file can potentially be used by the SIEM and SOC to interpret incoming reports of the IdsR instances of the vehicles in field.

To summarize, the Security Extract Template defines a standardized AUTOSAR exchange format for defining security events and their properties. The Security Extract (SECXT) is formalized as an ARXML file and applicable for both the AUTOSAR Adaptive and AUTOSAR Classic Platforms in a way similar to a Diagnostic Extract file.

Conceptual Background

Main Development Phases for an IDS

Typically, an Intrusion Detection System (IDS) is based on the system parts IdsM, IdsR and the Security Operation Center (SOC) as exemplarily depicted in General Architecture of a distributed onboard IDS

The development of such an IDS can be divided into the following main phases:

  1. Security Analysis phase
  2. IDS Design phase
  3. IDS Deployment phase
  4. IDS Operational phase

The Security Extract Template supports all these four phases and can both be used for specification and exchange of IDS related definitions by and between OEMs and their suppliers. Therefore, a Security Extract file has potentially a high number of release cycles starting with security analysis and ending with “end of support” for a specific vehicle.

Security Analysis Phase

In the Security Analysis phase, the vehicle’s electronics and software system is examined and analyzed by security experts to identify and evaluate potential approaches of attacks on the components of the system that could lead to a security breach. In a second step, based on these potential attack approaches, detectable events that deviate from the normal behavior of the system are identified and defined as Security Events.

IDS Design Phase

The IDS Design phase distributes, customizes and adapts the generic IDS components towards a concrete vehicle electronics and software system taking into consideration the security events identified in the previous phase

In this phase, the Security Extract Template is enriched with the design decisions such as definition of IdsM instances, the mapping of security events onto them and the configuration of filters

IDS Deployment Phase

The IDS Deployment phase comprises the realization of the IDS Design from the previous step towards the real system in hardware and software.

This phase is supported by the Security Extract Template through definition of IdsM instance deployment onto specific ECU-HW and the possibility to derive ECU configuration parameters for the IdsM modules on the Classic Platform

IDS Operational Phase

The IDS Operational phase refers to the running IDS in the field when the vehicle is used by the end customer.

This phase is still regarded as part of the development process because it typically involves an IDS update process to keep the IDS up to date with new versions of application and platform software as well as with newly identified attack approaches and thus new security events.

During the IDS update process, Security Extract files can be used to reconfigure the IdsM instances of the IDS and also to make these reconfigurations known to the IdsR.

This is a notable difference to other AUTOSAR (M2 level) exchange files (e.g. System Description) which usually do not evolve further after the final configuration of the ECU-HW devices of the vehicle has been specified for SOP. On the other hand, the Security Extract file is expected to be maintained and further extended even after SOP of the vehicle it relates to due to its involvement in the IDS update process.

Abbreviations

Abbr Description
API Application Programming Interface
BSW Basic Software
BswM Basic Software Mode Manager
CDD Complex Device Driver
Csm Crypto Service Manager
Dcm Diagnostic Communication Manager
Dem Diagnostic Event Manager module
DET Default Error Tracer
ECU Electronic Control Unit
ECUC ECU configuration
ID Identifier
IDS Intrusion Detection System
IdsM Intrusion Detection System Manager
IdsR Intrusion Detection System Reporter
IF Interface
MCU Microcontroller Unit
NvM Non-volatile memory
NVRAM Non-volatile random access memory
OEM Original Equipment Manufacturer
PDU Protocol Data Unit
PDU ID PDU Identifier
PduR PDU Router
QSEv Qualified Security Event
RTE Runtime Environment
SecXT Security Extract
Sem Security Event Memory
SEv On-board Security Event
SIEM Security Incident and Event Management
StbM Synchronized Time-Base Manager
SW-C Software Component
SOC Security Operation Center
TP Transport Protocol
BSW Basic Software
CDD Complex Device Driver
SWC Software Component
SWS Software Specification
SOC Security Operation Center