CYBERSECURITY IN AUTOMOTIVE
Secure Onboard Communication (SecOC) in AUTOSAR: Architecture and Practical Implementation
This article is part of a series dedicated to the topic of cybersecurity in the automotive industry, prepared by Krzysztof Labuda.
Frame formation with SecOC in AUTOSAR ETH stack
In this section, I will introduce the reader to the AUTOSAR architectural approach to the Secure Onboard Communication Protocol (SecOC).
SecOC, which I referred to in the fourth part of the series “What lies behind the term cybersecurity in automotive,” is one of the main protocols enabling authentication and consistency checking of vehicle communication.
The dependence on other protocol layers and SecOC, with the lower communication stack layer, will depend on the platform architecture (AP – Authentic PDU or CP – Cryptographic PDU), and in the case of CP implementation, it will also depend on the type of transmission (here we can distinguish direct transmission, triggered transmission, or transport protocol). These project-specific dependencies are not part of the protocol specification and depend on other dedicated standards or norms. I mean, among others, FIPS-180-4 (which standardizes hashing functions) or NIST publications.
The SecOC protocol is not dependent on the typical automotive application layer. However, it relies on the existence of a software component that provides information about freshness values. In addition, there may be specialized applications that trigger changes in SecOC behavior.
The image below compares SecOC implementations based on the CAN bus and the standard ETH network stack. It also includes cryptographic modules described in the 2nd part of the series (CSM, CRYIF, Cry for CRYPTO). The general method of frame formation is based on a network stack implemented on the ETH protocol (you can see the encapsulation of freshness and MAC with data).
Illustration showing the structure of a frame secured by SecOC:
Source: https://autosec.se/wp-content/uploads/2019/03/6.-Holisec_SecOC_2019-03-26_Kaushik_final.pdf
Illustration showing the reception and verification of a frame:
Source: https://www.linkedin.com/pulse/cyber-security-solution-autosar-classic-platform-quoc-bao-nguyen/
Communication Architecture: CAN vs Ethernet in SecOC
As a curiosity, one can consider the implementation based on the CAN bus. I discussed the methods of securing this protocol and related issues in a separate series – Cybersecurity in automotive: network solutions.
Notably, the implementation based on CAN cannot be carried out within a single frame. It requires implementation through a Cryptographic Message and a complementary Authentic Message.
Illustration showing CAN-based implementation:
Source: https://www.linkedin.com/pulse/cyber-security-solution-autosar-classic-platform-quoc-bao-nguyen/
SecOC as a solution introduces key functionality necessary for verifying the authenticity of PDU-based communication between ECUs within the vehicle architecture/network. This approach requires that both the sending ECU and the receiving ECU implement the SecOC module. To ensure message authenticity, the SecOC module on the sending and receiving side obtains so-called freshness values from an external manager of this value for each uniquely secured communication link.
On the sender’s side, the SecOC module creates a Secured I-PDU by adding authentication information to the outgoing Authentic I-PDU. The authentication information consists of an element that performs the authentication role, e.g., a message authentication code, and optionally freshness values. Regardless of whether the freshness value is included in the Secure I-PDU payload, the freshness values are taken into account during generation by the authenticating entity. In the case of using a freshness counter instead of timestamps, the freshness counter should be incremented by the Freshness Manager before delivering the authentication information to the recipient.
On the receiver’s side, the SecOC module checks the authenticity (and freshness) of the I-PDU by verifying the authentication information that was added by the sender’s SecOC module. To verify the authenticity of the Authentic I-PDU, the Secured I-PDU delivered to the receiver’s SecOC must be the same Secured I-PDU.
Components of Secured I-PDU:
Source: https://www.autosar.org/fileadmin/standards/R20-11/FO/AUTOSAR_PRS_SecOcProtocol.pdf
Diagram showing an example of the contents of a secured data unit (Secured I-PDU) with truncated freshness value and authenticator:
Source: https://www.autosar.org/fileadmin/standards/R20-11/FO/AUTOSAR_PRS_SecOcProtocol.pdf
SOC and SIEM – Off-vehicle threat analysis
AUTOSAR distinguishes 3 SecOC profiles, depending on the selected parameters – MAC algorithm (message auth code), how the freshness value and MAC value are handled:
SecOC Profile 1 (or 24Bit-CMAC (Cipher-based Message Authentication Code)-8Bit-FV)
- Algorithm: CMAC/AES-128
- Truncated freshness value: 8 bits
- Truncated MAC value: 24 bits
SecOC Profile 2 (or 24Bit-CMAC-No-FV)
- Algorithm: CMAC/AES-128
- Truncated freshness value: 0 bits => this profile operates without freshness value – it simply does not use it
- Truncated MAC value: 24 bits
SecOC Profile 3 (known as JASPAR)
- Algorithm: CMAC/AES-128
- Freshness value length: 64 bits
- Truncated freshness value: 4 bits
- Truncated MAC value: 28 bits
Challenges and limitations of SecOC implementation in practice
I would like to draw the reader’s attention to the fact that the protocol as proposed does have some “pain points.” The main ones are:
• Each OEM defines its own dedicated method of implementing SecOC. Therefore, adaptation of the implementation is needed. To solve this problem, one can use a known Python library called Scapy.
• When the freshness value is used, it must be meticulously tracked. I also mean the fact that providing reliable mechanisms for handling freshness fields and their synchronization is problematic.
• Typically, SecOC-protected frames are mixed with frames that are not protected.
• Inconsistent MAC generation. Under certain conditions, this can result in at least unpredictable behavior of the security system. This occurs when there is ambiguity about the fields in the frames covered by MAC authentication (such as PDU-ID or frame length).
• Cryptographic material management issues. Variability in key derivation, storage, updates, and mapping of PDU-ID to keys affects the implementation of secure key handling, threatening communication integrity, which is an easy recipe for trouble.
AUTOSAR provides support, guidelines, and mechanisms for secure data storage and protection of confidential information in vehicle ECUs and their transparent management to address the mentioned pain points. This includes encryption of stored data, access control, and secure data deletion to prevent unauthorized access (a potential attacker could aim to destroy or disrupt systems such as IPS/IDS that record malicious activity) or data leakage.
Author: Krzysztof Labuda,
Security Testing Consultant
A participant in the Certified Ethical Hacker CEH v11 program, which teaches the latest commercial-grade hacking tools, techniques, and methodologies used by hackers and information security professionals.
