01 Information Security Requirements
01
Information security requirements
This section presents information security requirements from four perspectives: hardware security, system security, communication security, and data security, with emphasis on hardware and system security.
1.1 Hardware Security
Hardware security mainly focuses on confidentiality measures for the PCB and encryption capabilities of critical chips.
1.1.1 Interface Security
During mass production, debug interfaces (such as JTAG, SWD) should not be directly exposed on the PCB. If unavoidable, consider dispersing the test pins.
In mass production, debug interfaces must require secure authentication. Authentication passwords should be at least 8 characters and must include digits and both upper- and lower-case letters.
For headlamp modules, pay attention to the main MCU debug interface; other peripheral chips typically do not expose code readout.
1.1.2 Mainboard Security
In mass production, silkscreen markings that identify critical chips on the mainboard (such as the main controller, hardware encryption chips, transceivers, ports, and pin functions) should be removed.
Communication traces carrying sensitive data between chips should be hidden where possible to resist eavesdropping and spoofing attacks on internal controller data transfers.
Critical chips on the mainboard should use reliable soldered packages (such as BGA or CSP) to prevent removal and direct access to chip internals.
1.1.3 Chip Security
To protect vehicle network security, hardware-level encryption is recommended. Choose MCUs that integrate an HSM module with FULL EVITA level when possible. If the MCU lacks a built-in encryption module, an external automotive-grade secure element (SE) can be used. The SE should provide at least the following interfaces:
- AES-128 algorithm interface
- Symmetric key storage interface
- SHA-256 algorithm interface
- RSA-2048 algorithm interface
- Asymmetric key storage interface
- True random number generation interface
Major chips and encryption chips should provide anti-attack protections, including:
- Security measures against single fault injection attacks targeting voltage and clock of the chip;
- Security measures against single fault injection attacks using electromagnetic or laser methods;
- Protections against side-channel simple power analysis (SPA) attacks targeting the encryption chip;
- Protections against first-order differential power analysis (DPA) attacks targeting the encryption chip;
- Protections against correlation power analysis (CPA) attacks targeting the encryption chip.
EVITA (E-safety Vehicle Instruction Protected Applications) defines specifications for HSM modules applicable to automotive network security. It classifies HSMs into Full, Medium, and Light levels. The EVITA classification table is available from referenced sources.
1.3 System Security
System security focuses on software authenticity and integrity across the system and measures to prevent software leakage.
1.3.1 Code Security
During development, perform security scanning or analysis of code and provide scan reports. Apply code obfuscation and hardening to core functional code to prevent reverse engineering.
MCUs used in headlamp modules typically use M0 or M4 cores and have less complex code compared with BCMs or gateways, so extensive security scanning may not be necessary. For high-end vehicles that include advanced driver functions, those algorithms can be complex and code obfuscation and hardening are recommended.
1.3.2 Read Protection
Implement external read protection for code storage regions to protect firmware from theft.
1.3.3 Secure Boot
Ensure a secure root of trust; verify the authenticity and integrity of the bootloader and application code to prevent malicious tampering.
1.3.4 Secure Update
Verify the source legitimacy and integrity of application-level programs before updating; verify the authenticity and integrity of flash drivers.
1.3.5 Secure Diagnostics
Support adaptation to new secure access algorithms for diagnostics and flashing; prohibit undefined diagnostic services.
1.4 Communication Security
Communication security ensures reliable delivery of critical messages between ECUs.
Critical data should be transmitted encrypted and messages should be authenticated to ensure origin authenticity and integrity.
Message authentication should comply with vehicle manufacturers' SecOC (Security Onboard Communication) specifications.
For ECUs using high-rate CAN FD communication, automakers may require symmetric encryption of certain critical data prior to transmission. Headlamp modules are increasingly adopting CAN FD, but communication security is not yet universally mandated by automakers.
1.5 Data Security
Data security addresses secure storage of critical information.
Important data and personal sensitive information should be securely stored and isolated to prevent unauthorized access, modification, deletion, or retrieval.
Ensure secure transmission of important and personal sensitive information to maintain confidentiality, integrity, and availability.
Headlamp modules mainly need to store keys used to encrypt critical data. MCUs with HSM modules or external SE chips support this function.
02 Secure Boot Flow
As automotive MCUs include richer cryptographic modules, implementing secure boot becomes easier.
After MCU power-on, the trusted boot program runs first. It verifies whether the bootloader region has been tampered with by checking the bootloader's authenticity and integrity. If the bootloader verification succeeds, control transfers to the bootloader, which then verifies the application's authenticity and integrity. If the application verification succeeds, control transfers to the application, completing the secure boot process.
For MCUs with hardware cryptographic modules, the trusted boot program typically enables the cryptographic module and configures the bootloader size to be verified. For example, S32K144 secure boot is enabled via the CSEc module, while S32K3 secure boot is handled by the HSE module.
S32K3 highlights - secure boot function
The secure boot approaches corresponding to the flow include three options described below: signature-based, symmetric MAC-based, and CMAC-based.
2.1 Signature-Based Secure Boot
Production stage:
Before shipment, the MCU vendor computes a hash (commonly SHA-256) of the bootloader and application binaries to obtain integrity measurements. Each measurement is signed using a private key and RSA-2048. The binary files, signed measurements, and the public key are programmed into the MCU.
The private key used in secure boot at production is generated, stored, and managed by the parts supplier; the automaker does not participate in private key operations.
Boot stage:
After power-on, the trusted boot program computes the hash of the bootloader region to obtain measurement 1. It verifies the signed measurement using the stored public key and RSA-2048 to obtain measurement 2. If measurement 1 matches measurement 2, the MCU transfers control to the bootloader; otherwise, the MCU remains in reset or another automaker-specified state.
The bootloader then repeats the same operation for the application using stored address information, public key, and signed measurement to verify application authenticity and integrity.
2.2 Symmetric MAC-Based Secure Boot
Production stage:
Before shipment, hash values (commonly SHA-256) of bootloader and application binaries are computed. Using a symmetric key and a symmetric algorithm (at least AES-128), the hashes are converted into MAC values. The binaries, MAC values, and the symmetric key are programmed into the MCU.
MAC: Message Authentication Code.
Boot stage:
After power-on, the trusted boot program computes the bootloader hash to obtain measurement 1. It uses the stored symmetric key to decrypt the stored MAC value using the agreed symmetric algorithm to obtain measurement 2. If measurement 1 matches measurement 2, the MCU transfers control to the bootloader; otherwise, the MCU remains in reset or another automaker-specified state.
The bootloader then repeats the same procedure for the application using stored address information, the symmetric key, and the MAC value.
2.3 CMAC-Based Secure Boot
Production stage:
Before shipment, compute CMAC values for the bootloader and application binaries using a key and CMAC algorithm (at least AES-128). Program the binaries, CMAC values, and the key into the MCU.
CMAC: Cipher Block Chaining-Message Authentication Code, a message authentication code based on symmetric block cipher algorithms, also referred to as CBC-MAC.
Boot stage:
After power-on, the trusted boot program computes CMAC value 1 over the bootloader BIN using the stored key. It compares CMAC value 1 with the stored CMAC value. If they match, the MCU transfers control to the bootloader; otherwise, the MCU remains in reset or another automaker-specified state.
The bootloader performs the same verification for the application using stored address information, key, and CMAC value.
03 Secure Update Process
Secure updates differ from traditional updates mainly by providing more robust verification of application authenticity and integrity. One of the methods below can be used. The following describes the signature-based secure update; the other two methods are similar in principle.
3.1 Signature-Based Secure Update
Production stage:
The parts supplier programs the automaker-provided public key and the BIN files into the MCU.
The private key generation, storage, and signing are handled by the vehicle manufacturer.
Update stage:
After the parts supplier uploads the updated application BIN to the automaker's designated portal and the automaker approves it, the signed BIN is distributed from the cloud to the vehicle body gateway. The BIN includes the corresponding signed measurement.
The body gateway transmits the BIN and signed measurement to the target ECU over CAN/LIN. The ECU's MCU computes the hash of the received BIN and verifies the signature. It compares the locally computed measurement with the transmitted signed measurement. If they match, the MCU upgrades the received application; otherwise, it discards the update and deletes the transferred BIN.
