Calterah Cybersecurity White Paper III: Calterah Firmware Solutions for Radar Chips
As we steer towards the future of software-defined vehicles (SDVs), automotive software technology has become a crucial driving force in transforming automobiles into intelligent mobile terminals. As intelligent driving technologies evolve, SDV systems have become more complex, facing greater cybersecurity challenges. This white paper, Calterah Firmware Solutions for Radar Chips, introduces the cybersecurity firmware support, as one part of the Calterah Vehicle Security Subsystem (VSS) solution for Radar, covering the full security scenarios and functionalities of all Calterah chip series. It integrates advanced cybersecurity designs to help car OEMs ensure vehicle safety and improve user experience.
Calterah's secure firmware solutions, developed based on radar SoC products, offer users various security features and covers a diverse range of user scenarios:
- Cryptographic Engine Drivers
- Secure Boot
- Secure Storage
- Secure Debugging
- Secure Communication
- Secure Upgrade
1. Cryptographic Engine Drivers
Calterah’s software development kits (SDKs) for radar chips provide Crypto Drivers that comply with the AUTOSAR CP1 standard. Located in the Microcontroller Abstraction Layer (MCAL), the Crypto Drivers are responsible for interactions between the cryptographic hardware abstraction layer and the cryptographic service manager. Calterah’s SDKs support the seamless integration of EB Tresos configurations and the Crypto Interface of AUTOSAR CP. The SDKs also provide different software implementation schemes for non-independent security islands (e.g. SHE2 and HSM3 Light) and independent security islands (e.g. HSM Medium and HSM High) in hardware based on the security design characteristics of different radar SoCs.
1AUTOSAR CP: AUTomotive Open System Architecture（AUTOSAR）Classic Platform（CP）
2SHE：Security Hardware Extension
3HSM：Hardware Security Module
Figure 1 Non-Independent Security Island Design
Figure 2 Independent Security Island Design
Calterah radar chips are equipped with a comprehensive set of engines for Crypto algorithm acceleration. Based on this hardware capability, the Crypto Drivers of SDKs provide processing interfaces for the following Crypto algorithms or primitives, as well as both synchronous and asynchronous processing interfaces.
4PKCS: Public Key Cryptography Standards
5SHA: Secure Hash Algorithm
In addition to the algorithms mentioned above, Calterah SoC products also support the following algorithms to meet the requirements of cryptographic products in China:
- ShangMi2 (SM2): Elliptic Curve cryptographic Algorithm
- ShangMi3 (SM3) Hash Algorithm
- ShangMi4 (SM4) Block Cipher Algorithm
- ShangMi9 (SM9) Identity-Based Encryption Algorithms
*Support for these algorithms varies across different SoC products. For specific information of cybersecurity support, please refer to the SoC reference manuals.
Calterah's radar chip products offer a complete solution for Secure Boot. It establishes the root of trust and chain of trust for boot through the Boot ROM and the Root Key and achieves a complete Secure Boot solution via step-by-step software verification during the boot process.
2.1 Root of Trust Creation
- Root Key Generation: Automotive OEMs and Tier-1 suppliers can generate multiple sets of asymmetric root keys using various algorithms as needed, with key digests stored in a One-Time-Programmable (OTP) area.
- Root Key Programming: Using the OTP programming solution and demo tool provided by Calterah, users can burn the root key digests securely into the protected OTP area, and develop further based on manufacturing requirements.
- Root Key Usage: Boot ROM, as the foundation of the root of trust, uses the root key stored in the OTP to verify the signature of payload in the next stage of flash.
2.2 Establishment Process for Chain of Trust
- Secure Boot Flow
Figure 3 Secure Boot Flow
- Secure Boot Process: The Boot ROM verifies the Bootloader signature based on the Root Public Key (PUK). After successful verification, the Bootloader starts to execute.
- The Bootloader verifies the application software signature based on the user PUK. Upon successful verification, the application software starts to execute.
2.3 Firmware Encryption
When Calterah’s firmware products operate in the XIP (eXecute-In-Place) mode with XIP decryption enabled, the XIP supports real-time loading and execution of AES-encrypted firmware. When the CPU executes code in the XIP space, it triggers the XIP to read instructions from flash and uses the built-in AES engine to decrypt the encrypted code in real-time and send the decrypted data to the CPU for execution.
The aim of Secure Storage is to ensure the confidentiality of keys or sensitive user data. To meet confidentiality needs, Calterah products provide root key storage and encryption storage of firmware and sensitive data.
3.1 Root Key Storage
Calterah products are built with OTP for root key storage, supporting both asymmetric key digest storage for secure boot and secure storage of symmetric keys such as:
- XIP AES Key: When accessing flash via XIP, the XIP AES key can be used for automatic decryption of encrypted data on flash.
- Root AES key: User data that needs to be stored in flash during radar operation can be encrypted and decrypted dynamically using the Root AES key. This key is only visible to the radar AES engine and supports one-machine-one-key to reduce risks from key loss.
3.2 Encryption Storage for Firmware and Sensitive Data
For firmware encryption, users can encrypt the firmware image using the XIP AES key in the following circumstances:
- The firmware image itself requires confidentiality
- The firmware image contains sensitive data that requires confidentiality
For user encryption of dynamic data, users can choose to use the Root AES key for encryption or decryption in the following circumstances:
- User keys generated during radar operation that need to be stored in Non-Volatile Random Access Memory (NVRAM)
- Sensitive data generated during radar operation that need to be stored in NVRAM
Calterah radar chip products provide different control strategies for debugging interfaces, offering three modes for debugging interface control: open, restricted, and disabled.
- Open: The debugging interface is open by default. This mode can be used during product development and debugging phases. The access mode can be upgraded from open to restricted or disabled via OTP.
- Restricted: In this mode, the debugging interface is disabled by default. Users can authenticate through challenge-response authentication. Upon successful authentication, the interface for debugging can be opened through related configuration switches. Without authentication or with failed authentication, access to the debugging interface is denied.
- Disabled: In this mode, the debugging interface is permanently disabled.
As automobiles become more intelligent and connected, in the absence of any security measures, attackers can easily acquire vehicle information from the vehicle network communication, spoof messages, and control the vehicle, posing a threat to the property and even life safety of drivers and passengers. Based on existing information security risks, AUTOSAR has added a series of measures, in addition to Crypto Drivers, to ensure the security of information communication.
- Secure Onboard Communication
Secure Onboard Communication (SecOC) is an information security component added in the AUTOSAR software package, focusing on communication authentication without involving message encryption. It primarily achieves data authenticity and integrity verification through MAC-based authentication and anti-replay based on freshness. If protection to avoid message eavesdropping by an attacker is needed, message payloads also require additional encryption.
- Transport Layer Security
Transport Layer Security (TLS) belongs to the transport layer protocol of the OSI (Open System Interconnection) model, positioned between underlying protocols and the upper-layer application protocols of the transport layer and used for protecting application data transmitted over Transmission Control Protocol (TCP). It can support the upper-layer protocols like SOME/IP (Scalable service-Oriented MiddlewarE over IP), MQTT (Message Queuing Telemetry Transport), and HTTP (Hypertext Transfer Protocol). The TLS can be used for V2X secure communication and secure communication between nodes in vehicles. For data transmitted over the User Datagram Protocol (UDP), the Datagram TLS (DTLS) protocol can be employed.
- Internet Protocol Security
Internet Protocol Security (IPsec) is a suite of internet security protocols operating at the network layer of the OSI model. The AUTOSAR CP R19-11 standard has integrated IPsec-related functions into the TCP/IP module with conditional constraints on functional implementations. IPsec provides security services such as data source authentication, data confidentiality, data integrity, anti-replay, etc. above the network layer.
- Media Access Control Security
Media Access Control Security (MACsec) is a point-to-point secure communication method in the Local Area Networks (LANs) based on IEEE 802.1AE and IEEE 802.1X protocols. Operating at the data link layer in the OSI model, MACsec ensures Ethernet data frame security through functions such as authentication, data encryption, integrity checks, and replay protection, preventing devices from processing security-threatening messages.
In the SDKs for Calterah radar chips, Crypto Drivers compliant with the AUTOSAR standard is provided. It also extends compatibility with interfaces of Chinese cryptographic standards through the Complex Design Driver (CDD) interface, meeting the development needs of secure communication via SecOC, TLS, and IPsec for vehicle networks. As automotive requirements for security of point-to-point Ethernet communication increase, MACsec support will also be integrated into Calterah SoCs to meet comprehensive security communication requirements for radar chip products in vehicles.
To ensure the secure upgrade of radar software, Calterah radar chip products offer the following Secure Upgrade measures:
- Upgrade File Signatures: Calterah products support software upgrades with signatures of RSA root key, effectively preventing tampered software from being upgraded into radar devices.
- Firmware Encryption: Calterah products also support an encryption mechanism based on the XIP AES key to ensure confidentiality of firmware and sensitive data during information transmission.
- Upgrade Process Assurance:
Figure 4 Secure Upgrade Flow
1) An OEM generates a software upgrade file and then packages and signs the file. It can encrypt the file as needed.
2) The software, after signing (or signing and encrypting), enters manufacturing or the OTA (Over-the-Air) phase through secure transmission.
3) The software file is downloaded to radar devices via upgrading tools or OTA.
4) The radar device verifies the software signature (or decrypts and then verifies the signature).
5) If the verification is successful, burn the file to flash and then perform verification. And if verification fails, the upgrade is terminated.
- Backup Partition Mechanism:
Calterah radar chip products support an A/B partition mechanism, with radar software stored in both the A and B partitions on flash. The A/B partition mechanism supports product boot robustness. Meanwhile, during software upgrades, upgrading one partition at a time can effectively prevent boot failure caused by software availability issues.
