As vehicles become more connected and intelligent, they are increasingly integrated into the internet and thus exposed to network attack vectors. Automotive cybersecurity has become a foundational element of vehicle safety. AUTOSAR, a widely adopted automotive embedded software architecture, includes security-related modules that support requirements such as protecting in-vehicle communications and safeguarding confidential data. Because Classic Platform (CP) AUTOSAR and Adaptive Platform (AP) AUTOSAR have different architectures, implementations of these security modules differ between platforms.
1. SecOC
The CAN bus remains a common in-vehicle communication bus. Most CAN messages are broadcast in plaintext without authentication, which provides low cost and high performance. However, as connected and smart features increase, data security is becoming more important. Traditional protections such as rolling counters and checksums offer limited security and are susceptible to reverse engineering and message forgery, which can enable attackers to control vehicle functions.
SecOC is a security component introduced into the AUTOSAR software stack to add cryptographic operations, key management, freshness value management and distribution, and related requirements. Its primary purpose is to provide authentication for data transmitted on the bus, allowing effective detection of replay, spoofing, and tampering.
Figure 4.1-1 Message authentication and freshness verification flow
In the SecOC specification, AUTOSAR uses MAC-based authentication plus freshness features to achieve data authenticity and integrity. The MAC (Message Authentication Code) is a cryptographic method used for integrity and authentication. For symmetric encryption, CMAC (cipher-based MAC) is commonly used; OEMs may provision keys statically at vehicle production or distribute keys dynamically via a cloud server. A MAC does not prevent disclosure of payload data; it prevents tampering and authenticates the message source. If confidentiality is required, payload data must be encrypted in addition to authentication.
To reduce replay risk, SecOC embeds a freshness value in Secured I-PDUs. A freshness value is a continuously updated value according to a defined logic. Typical freshness mechanisms in AUTOSAR are counter-based or time-based freshness values.
On CP AUTOSAR, the SecOC module depends on PduR APIs and functionality, providing the upper and lower layer APIs required by the PDU Router. Cryptographic algorithms used by SecOC are provided by the Crypto Service Manager (CSM). SecOC requires APIs to generate and verify cryptographic signatures or message authentication codes, and it exposes management APIs to RTE for service invocation.
SecOC features are also applicable to AP AUTOSAR. The main goal on AP is interoperation with CP SecOC, particularly for message scenarios using UDP multicast (SecOC is currently the only supported protocol) and for signal-based secure network bindings between CP and AP.
Figure 4.1-2 SecOC in AP AUTOSAR communication management
To interoperate with CP, SecOC is also applied within Adaptive Communication Management. Authentication information includes an authenticator (for example, a message authentication code) and an optional freshness value. AP AUTOSAR relies on a pluggable freshness management library that provides APIs mirroring the CP freshness management client and server interfaces.
SecOC focuses on communication authentication and does not encrypt message payloads. While message forgery becomes harder, plaintext transmission still carries privacy risks. Authentication data length affects message payload size; adding authentication increases bus load (traditional CAN payloads are only 8-64 bytes), which may degrade timing and real-time behavior. Designers must balance security strength against communication real-time requirements. MAC-based schemes require robust symmetric key management and secure storage; many MCUs lack secure elements, and keys stored in plaintext in memory or system storage are vulnerable. Key provisioning and distribution in plaintext is insecure. Implementing security mechanisms consumes CPU and memory resources on resource-constrained MCUs; system stability and the ability to run both application and security functions must be considered. Key provisioning, update, maintenance and post-replacement key consistency also require planning.
2. TLS
TLS (Transport Layer Security) is the transport-layer foundation for protocols such as SOME/IP, MQTT and HTTP. TLS can be used for V2X secure communication and for secure communication between in-vehicle IP nodes. Nodes that communicate outside the vehicle, such as T-Box units, typically require a full TLS deployment for stronger security and flexibility. For in-vehicle communication where IP addresses, ports and service interfaces are fixed and security demands are lower, TLS pre-shared key suites (TLS_PSK) can provide an efficient and stable solution.
TLS sits between transport-layer primitives and application protocols. The main transport-layer protocols for in-vehicle Ethernet are TCP and UDP. Each corresponds to a different transport security protocol: TLS is used over TCP, and DTLS (Datagram TLS) is used over UDP. DTLS is the datagram-oriented variant of TLS. Common protocol versions are 1.2 and 1.3; AUTOSAR supports both, preferring 1.3 where available.
AUTOSAR defines Ethernet-based solutions and supports ISO DoIP (Diagnostic Over IP). DoIP handles diagnostics over IP and in ISO 13400-2 defines secure DoIP sessions using TLS for diagnostic communication. A DoIP server stack will decide whether to use TCP or TLS based on client requests. TLS enables authenticated and encrypted channels between DoIP client and server; client authentication can be implemented at the diagnostic application layer, for example via an ISO 14229 service.
TLS also has constraints. Most vehicle controllers use MCUs with limited CPU and memory. Implementing cryptographic algorithms and certificate handling incurs resource costs; solutions must not impact normal controller functions. TLS requires provisioning of certificates; replacement of controllers requires maintaining certificate consistency so that the new unit can be authenticated. Many controllers lack secure storage (SE or HSM), so protecting certificates and private keys requires careful design. TLS-based protection also affects communication latency and throughput; the impact on real-time behavior must be evaluated. Security level selection should balance regulatory requirements and controller resource availability to ensure both secure and reliable operation.
As vehicle networking and in-vehicle Ethernet proliferate, TLS and DTLS appear more frequently in automotive architectures. AUTOSAR has incorporated TLS/DTLS in both CP and AP. CP AUTOSAR from version 4.4 specifies support for TLS 1.2 and 1.3, preferring 1.3. AP AUTOSAR R21-11 specifies TLS 1.2, and future AP releases are expected to add 1.3.
3. IPsec
IPsec (Internet Protocol Security) is a network-layer security suite operating at the IP layer. It is widely used in VPNs to provide confidentiality, integrity, authentication and anti-replay for IP packets by adding security fields to the IP payload and headers.
Figure 4.1-3 IPsec protocols and component functions
IPsec supports two primary mechanisms: authentication and encryption. Authentication allows a receiver to verify the sender identity and to detect tampering. Encryption protects confidentiality by encrypting payloads. IPsec components include the Authentication Header (AH, IP protocol number 51), Encapsulating Security Payload (ESP, IP protocol number 50), and Security Association (SA). AH provides source authentication, integrity and anti-replay using hash algorithms such as MD5 and SHA1. ESP encrypts and optionally authenticates payload data using algorithms such as DES, 3DES and AES. SA contains the protocol, algorithms and keys needed to provide security for a traffic flow. IPsec operates in tunnel mode and transport mode; combined with AH and ESP this yields various protection configurations.
CP AUTOSAR R19-11 introduces IPsec support in the TCP/IP module with constraints: currently only IPsec transport mode is supported; tunnel mode, IPv6 and multicast are not supported yet. The specification defines required interactions with other modules: KeyM can provide certificate handling for IPsec submodules, and CSM may perform cryptographic operations and key handling used by IPsec.
In AP AUTOSAR, the IPsec implementation aims to provide secure channels in vehicle IP networks. AP deployment of IPsec can offer confidentiality, integrity or both between network nodes, and supports multi-vendor stack interoperability. Because the Adaptive Platform does not mandate a specific operating system, it is an appropriate environment for IPsec deployments.
4. Crypto Stack
A unified cryptographic interface for automotive software is provided by AUTOSAR Crypto Stack, introduced in AUTOSAR 4.3. The Crypto Stack handles data encryption, key management and exposes standardized cryptographic services to applications and system services. It supports hash computation, asymmetric signature verification, symmetric encryption, and typical use cases such as ECU communication protection, SecurityAccess flow protection, and key management.
The Crypto Service Manager (CSM) sits at the top service layer and schedules cryptographic services. CSM relies on cryptographic driver implementations provided by software libraries or hardware modules, optionally mixing multiple crypto drivers. CSM accesses drivers via the Crypto Interface (CryIf).
Figure 4.1-4 CSM and adjacent module relationships
CSM provides APIs to SW-Cs and BSW for cryptographic operations. CSM schedules and orchestrates services, calling CryIf which dispatches requests to crypto drivers and driver objects statically assigned to services. CSM uses configured primitives (CsmPrimitives) describing algorithm instances. These primitives are assigned to jobs (configured CsmJob), which encapsulate keys, primitives and channel references. Keys are stored in the crypto driver; CSM holds only references.
Separating keys from primitives allows the cryptographic operation API to be independent of key management. Applications request operations such as MAC calculation and verification while a key manager supplies keys during configuration.
CSM APIs are roughly two types: direct APIs (primarily for key management) and job-based APIs (primarily for cryptographic operations). Direct APIs map directly to functions in CryIf and the Crypto Driver and are synchronous. Job-based APIs use a Crypto_JobType structure containing static and dynamic parameters and references; CSM packs the parameters and passes them to CryIf and the configured crypto driver.
Figure 4.1-5 CSM, CryIf and Crypto Job and direct API call tree
Jobs may run synchronously or asynchronously based on static configuration. The concrete cryptographic algorithms executed are determined by the configured service information, algorithm family and mode parameters.
CryIf (Crypto Interface) is the BSW abstraction layer that provides a single interface for heterogeneous hardware and software cryptographic implementations such as HSM, SHE, or software-based CDDs.
Figure 4.1-6 AUTOSAR layered view with Crypto-Interface
Crypto driver implementations include:
- Crypto (HW based): Drivers for hardware crypto modules controlling HSM or SHE, chip-specific.
- Crypto (SW based): Software-based CDD implementations of algorithms such as AES-128.
By providing a single CryIf-based interface, CSM can use multiple underlying crypto HW and SW solutions and handle concurrent access to cryptographic services to support multiple simultaneous jobs.
Unlike CP, AP AUTOSAR supports runtime APIs for general cryptographic operations and key management. These APIs support dynamic key generation and cryptographic jobs at runtime and can reference a central crypto service manager to implement platform-level tasks such as consistent access control and certificate storage. The implementation can coordinate offloading to crypto drivers, for example to an HSM. To support secure remote key management if applications are compromised, the Crypto Stack integrates a key management architecture where keys and related data are managed with end-to-end protection. Keys can be injected based on a provisioning key in a trusted way or introduced via local key generation in an untrusted manner.
5. IAM (Identity and Access Management)
In-vehicle infotainment applications often connect to external networks and are at higher risk of compromise. These applications must not be allowed to access body-control services. For example, an infected infotainment system must be unable to invoke braking services. Growing security needs drive Identity and Access Management (IAM) to establish robust, well-defined trust relationships between adaptive platform applications and platform services. IAM enforces privilege separation, protects against privilege escalation under attack, and allows integrators to validate requested resource access during deployment. IAM provides an access control framework for adaptive application requests to service interfaces, platform base function clusters and related modeled resources.
The IAM framework enables modeling application intent, making access control decisions based on requests, and enforcing access control. IAM focuses on limiting adaptive applications' access to explicit platform interfaces and resources (for example key slots). IAM does not mandate enforced quotas for system resources such as CPU or RAM.
At runtime, IAM is transparent to adaptive applications unless a request is denied and notification is issued. Remote requests for adaptive platform services are subject to IAM; incoming request PDPs must be implemented by adaptive applications.
The framework assumes adaptive applications are authenticated at startup and that a protected runtime environment ensures isolation and prevents privilege escalation (for example bypassing access control).
A typical representation of access rights is an access matrix showing subjects and objects and the allowed actions between them.
Figure 4.1-7 Access rights matrix
Access manifests are deployed as manifest files. There are two manifest forms: (1) for each subject, list intended accesses to other services or applications (objects); or (2) for each object, list which subjects are allowed to access it. Subject manifests are typically stable; object manifests may be updated when new applications are deployed.
6. KeyM
Keys and certificates play a central role in cryptographic functions. Keys are parameters for encrypting or decrypting data and many algorithms require keys. The Key Management (KeyM) module manages keys, primarily focusing on key update and key generation. Certificates protect integrity and authenticity in networked interactions; KeyM supports certificate chain configuration, storage and verification.
AUTOSAR KeyM consists of two submodules: a key submodule and a certificate submodule. The key submodule initializes, updates and maintains key material. The certificate submodule defines and configures certificates for production storage and later use.
Figure 4.1-8 AUTOSAR layered view with KEYM
The key submodule provides APIs and configuration items to introduce or update predefined key material. It acts as a key client, interpreting data from a key server and creating key material that is provided to the crypto service manager. Once keys are installed, applications can perform cryptographic operations.
The certificate submodule provides APIs and configuration for certificate operations. It allows configuration of certificate chains and the mapping of certificate storage locations (NVM, CSM or RAM) according to configuration and HSM parsing. It enables BSW modules and SW-Cs to perform certificate operations more efficiently, such as verifying a full certificate chain or extracting elements from runtime-provided certificates. Required cryptographic operations, such as verifying certificate signatures, are performed by the crypto jobs defined in the crypto service manager.
On AP AUTOSAR, services such as update and configuration, communication, persistence and diagnostics may require cryptographic services as part of their functionality. Because AP leaves many application-specific and variant functions to application layer implementations, applications can define required key slots, crypto providers and certificates. Key material provisioning is typically performed by an adaptive application (for example an OEM key manager) that configures the platform key slots. A dedicated adaptive key manager application can manage key material consistently across applications.
7. IdsM (Intrusion Detection System Manager)
Many advanced vehicle functions depend on in-vehicle and backend services and must address the challenge of protecting vehicles from network attacks. Security mechanisms are being configured across vehicle E/E architectures, including authenticated updates, secure boot and secure in-vehicle communication. Intrusion detection systems (IDS) are receiving growing attention from OEMs and suppliers as an additional layer of defense.
The Intrusion Detection System Manager (IdsM) is a basic software module (for Classic AUTOSAR) or a platform service (for Adaptive AUTOSAR) that collects and aggregates security events potentially caused by malicious attacks on vehicle software, communications or electronics. IdsM provides a standardized interface to receive on-board security event notifications (SEv). SEv can be reported by security sensors implemented in BSW modules, CDDs or SW-Cs. Optional contextual data, such as event type and suspicious payload, can be included and are useful for backend forensic analysis.
IdsM can filter SEv based on configurable rules. Filtered events are converted to qualified on-board security events (QSEv) and further processed for storage or forwarding. Depending on the security concept, QSEv can be persisted locally in a Security Event Memory (Sem), forwarded to configured receivers, or both. Available receivers include the Diagnostic Event Manager (Dem) and an IDS reporter (IdsR), which can forward QSEv data to a backend Security Operations Center (SOC).
Each safety-relevant or monitored ECU instance runs an IdsM that collects and filters security events (optionally with additional data) to store them locally in Sem and/or forward them via the vehicle network to a central IDS reporter. The IdsR may be located in a telematics unit that sends security reports and related data to an OEM SOC via cellular networks. SIEM systems analyze this information and determine appropriate defensive or mitigation actions.
AUTOSAR specifies that BSW modules, CDDs and SW-Cs can act as security sensors that report SEv to IdsM. The AUTOSAR specification standardizes a subset of security event types reportable by BSW modules; each BSW lists its own security event types. Application components may report vendor-specific, nonstandard event types. Security event types reported by a given ECU can be specified using the Security Extension (SecXT). The AUTOSAR IdsM is generic and highly configurable. It is independent of the underlying communication system and can be applied across automotive domains within the stated assumptions and constraints.
