Highlights
In the recent years, vehicles have begun to provide more and more advanced features and in turn have led to a massive rise in computing power and software complexity required to keep all the four wheels spinning and firmly on the ground. This in turn has led to vehicles
becoming susceptible to cyberattacks and countries requiring stricter compliance from vehicle manufacturers to cybersecurity design principles and standards. The EU has made it compulsory for all vehicles manufactured after July 2024 to comply with UNECE WP.29
regulations [1].
A vehicle compromised on the field can have severe to fatal consequences ranging from financial losses to user due to theft or to the OEM due to theft of intellectual property to severe injuries due to failure of critical vehicle systems. This has led the OEMs to adopt security baselines across platforms ensuring not only the more robust zonal ECUs but also the peripheral controllers to achieve a certain level of security. The available resources on these peripheral controllers or the system constraints of these controllers often restrict the implementation of standard security measures derived from pre-existing global cybersecurity standards.
Problem Statement
A customer faced several challenges in securing their Electronic Control Unit (ECU) co-controller. They required a signed and
encrypted flash image for the co-controller, transmitted via the Controller Area Network (CAN) to comply with European security
standards. However, two limitations hindered this process:
Limited Memory on the Main Controller: The main controller, responsible for verifying the image signature, lacked sufficient RAM
to handle the entire image for verification.
Missing Cryptographic Libraries on Co-Controller: The co-controller, where the image needed to be flashed, completely lacked
any cryptographic libraries, rendering it unable to handle the signed and encrypted format itself.
Solution
- To address the customer’s CU co-controller security challenges, we took a two-pronged approach that focused on achieving
the essential security goals while working within the limitations of the system.
First, we conducted a thorough analysis to identify the core security objectives behind the requirement for a signed and
encrypted flash image. This analysis revealed two critical aspects: - Authenticity of Header and Firmware: Ensuring that the header information and the firmware itself had not been tampered
with during transmission. - Integrity of Header and Firmware: Verifying that the header and the entire firmware image remained unaltered during transit.
Considering these objectives and the constraints of limited memory on the main controller and the absence of cryptographic
libraries on the co-controller, we proposed an optimized solution: signing only the header. This approach had two key
advantages: - Accommodating Limited Memory: By signing just the header, the verification process could be performed on the main
controller within its available memory capacity. - Ensuring Integrity without Encryption: The header would include a CRC (Cyclic Redundancy Check) value calculated by the
OEM over the entire firmware image. This CRC value acts as a fingerprint, allowing the main controller to verify if the firmware
data has been tampered with during transmission. The signature on the header, using the OEM’s private key, guarantees that the
header itself was generated by a trusted source (the OEM).
In essence, this solution leverages the CRC for data integrity verification while relying on the signed header to confirm its
authenticity – both crucial aspects for securing the ECU co-controller firmware update process.
Our proposed solution, while effective, did come with some identified cybersecurity risks: - Bricked Co-Controller on Failed Flash: If the flash process failed, the co-controller would be left without any firmware,
potentially disabling critical functions of the ECU. This risk was deemed acceptable since the ECU was not designed for Over-
The-Air (OTA) updates. Reflashing, in case of such a failure, would only be possible at a service center or supplier facility. - Higher Collision Probability of CRC32: Compared to more robust cryptographic checksums like hash or CMAC, CRC32 has a
higher chance of two different data inputs generating the same checksum value (collision). However, this risk was also
considered tolerable given the infrequent nature of co-controller flashing. Additionally, the encryption of the firmware image
itself further limited the potential for exploitation even if a collision occurred.
Results
Our approach yielded positive results:
Security Controls and Feasibility Assessment: Through a thorough analysis of the
system requirements, we were able to identify the necessary security controls and
assess their feasibility within the existing system constraints. Early Vulnerability
Detection and Solution: We effectively pinpointed a potential vulnerability at the system
architecture level during the design phase itself. This allowed for a proactive solution to
be implemented early on, mitigating the risk later in development. Constrained Solution
Meets OEM Needs: We successfully designed a solution that adhered to the system
limitations while still achieving all the security goals outlined by the OEM.
References:
[1) Automotive Cybersecurity: New Regulations in the Auto Industry
(securityintelligence.com
[2] Explanation of Security Overview (autosar.org)
