Introduction
With the rapid development of connected vehicles, owners gain convenience while facing new security risks. Convenient features include keyless entry, remote start, OTA (over-the-air) updates, and remote diagnostics. Risks include leakage of sensitive personal data and remote compromise of vehicles. Such incidents are real: for example, the 2022 Yandex Taxi hacker attack, when attackers used the Russian ride-hailing app to summon available vehicles to Moscow, causing local traffic congestion.
Personal information that, if leaked or misused, could lead to discrimination or serious threats to personal or property safety includes vehicle location and trajectory, audio, video, images, and biometric data.
Improving vehicle information security is urgent. The EU and other Western jurisdictions have issued standards and regulations such as ISO 21434 and WP.29. In China, the "Automotive Vehicle Information Security Technical Requirements" is currently under review. This article starts with the information-security term "public key" and discusses:
- What a public key is
- When and where a public key is written and stored
1. What is a public key
A public key is the public half of an asymmetric key pair, used to verify signatures produced by the corresponding private key. The public key can be shared with third parties; the private key must be kept by the node itself or a trusted center and must not be exposed to third parties.
In engineering practice, public keys are often categorized as Development Public Key and Product Public Key.
Development Public Key: the public key used during software development.
Product Public Key: the public key written into the device before production-line flashing of application software (EOL, end-of-line). The product public key is written once and should not be modified. In some architectures, it is treated as the root of trust or a trust anchor.
Development and Product public keys are fundamentally the same and can be distributed; they differ only in when they are used—during development versus at product release.
Because the public key is primarily used for signature verification, signing algorithms must be considered. In practice, SHA-256 combined with RSA-2048 is commonly used for signing operations.
(a) Roles of SHA-256 and RSA-2048
RSA-2048: an asymmetric encryption algorithm where sender and receiver each have a public/private key pair. Asymmetric algorithms involve exponentiation operations and are far slower than symmetric algorithms such as AES-256, so they are used for small amounts of data (for example, encrypting a public key or producing a signature).
SHA-256: a secure hash algorithm used mainly for data integrity verification. Its function is similar to a CRC but provides stronger integrity guarantees than CRC.
Therefore, RSA-2048 is used for small-data operations such as digital signatures and public key operations, while SHA-256 is used for data integrity checks.
2. When to write and where to store the public key
A public key can be written into an ECU using the $2E (Write Data By Identifier) service. Since the primary role of the public key is to verify software parts, the public key is generally written before flashing application software or calibration data, so that the device can verify software validity.
Because the public key is the basis for verifying other information, it must reside in a protected area, for example an HSM NVM. To prevent modification after write, engineering practice often requires the product public key to be written into an OTP (one-time-programmable) region, meaning it can only be programmed once. This implies the controller has the product public key written once on the production line; that public key remains with the product for its lifetime and will be used for subsequent application upgrades.
VBT (Verification Block Table) stores hash values of other software blocks. When verification occurs, the device first verifies the VBT's hash value, also called the root hash. If the root hash is valid, the hash values stored in the VBT are trusted, and the device then computes the hash of each software block (for example using SHA-256) to perform integrity checks. See related discussion on software authentication.
Supplementary information: the VBT's hash (root hash value) is signed using the private key to generate a digital signature that is sent to the ECU. The ECU uses the public key to verify the digital signature and recover Root Hash Value #1. The ECU also computes Root Hash Value #2 by hashing the VBT at its stored address and length. If Root Hash Value #1 equals Root Hash Value #2, the root hash verification passes.
Digital signatures are a technique to verify data origin and integrity: the private key signs the target data to create a signature, and the public key is used to verify that signature.
3. Additional considerations
Because the public key forms the basis of software authentication, its legitimacy must be confirmed. How can one be sure the public key written into a chip has not been tampered with?
Answer: by performing a handshake between the written public key and a server. The server holds the private key and has the corresponding public key. If the handshake succeeds, the public key is validated. On the production line, the public key is written via the $2E service (first write) while the vehicle is offline, so the chance of tampering at that stage is minimal. For OTA updates where the vehicle is online, the vehicle should perform a handshake between the onboard public key and the server to validate the public key. In production-line, OTA, and after-sales update scenarios, software integrity and compatibility checks are part of the update process; if public key validation fails, the system should report the public key as invalid.
