Abstract

Cars of today have proliferating electronic endpoints that are generally connected to an electronic control unit (ECU) that controls the endpoint. Counterfeit endpoints or malicious data introduced into the car could at best degrade the performance and at worst become a safety hazard for mission critical components. AEC-Q100 DeepCover™ Authenticator solutions from Analog Devices help solve these automotive security concerns.

Adding Secure Hardware: Host vs. Endpoints

Cars of today have proliferating electronic endpoints generally connected to an electronic control unit (ECU) that controls the endpoint, receives information back, or a combination of the two. As shown in Figure 1, a few examples include advanced driver assistance systems (ADAS) optical cameras and sensors, driver monitoring systems (DMS), occupancy sensors, electric vehicle battery (EVB) systems, front light modules, steering wheels, and many others.

This ecosystem of interconnected sensors, actuators, and ECUs presents the need for the system to prove all endpoints and their data are genuine. Counterfeit parts or malicious data introduced into the car can at best degrade the performance and at worst become a safety hazard for mission critical components. In the connection between two points, the host ECU generally provides the ‘’brains’’ that collects information or controls the endpoint. In cases such as sensors, where the endpoint returns data, it is important for the host ECU to trust the connected sensor. In cases of actuators, where the endpoint takes some action, it is important for the endpoint to trust the ECU sending it commands. Some endpoints both send and receive data, and can benefit from two-way authentication with the ECU to ensure trust.

For one entity to trust another, the second entity must do something to prove it is authentic and trustworthy. This is accomplished with a challenge from the first entity followed by a correct response from the second. In old war movies, one may hear a guard challenge an intruder with the terse message “halt, who goes there?”. The intruder must quickly respond with the correct answer, sometimes even a passphrase. Likewise, ECUs and endpoints can use a digital challenge and response to prove their credentials to each other; for two-way authentication, the process goes both ways as the two entities prove to each other they are trusted. The host and endpoint are considered paired with each other after they prove to each other they are trusted. Often, encryption comes to mind for cybersecurity topics, but it is important to note that in many scenarios, the confidentiality of data is not required, only the authenticity is needed. In these cases, digital authentication algorithms may be used in place of more complex encryption algorithms.

DeepCover™ Authentication solutions from Analog Devices use industry developed and recognized algorithms such as SHA-256 and ECDSA. SHA-256 is a symmetric algorithm, which means the same secret is known (or computed) by both the host and endpoint. Elliptic curve digital signature algorithm (ECDSA), on the other hand, is an asymmetric algorithm that uses a public key on the host side and private key on the endpoint side. A second key pair can be used with the private key on host side and public key used by endpoint for two-way authentication.

Coprocessors and Authenticators

Some host ECUs already have a secure microcontroller fully capable of doing all host computations. However, in hosts with a non-secure micro or a heavily loaded secure processor with limited computing resources, customers can use the DS2478 coprocessor to offload the authentication operations on the host side.

One may ask, what is the difference between a coprocessor and an authenticator, aside from where in the system they are implemented? The good news is that a secure coprocessor and authenticator often use a relatively similar command set, which makes using the coprocessor very straightforward once the authenticator is put in place. The first difference is the DS2478’s user-selectable flag. This flag governs how the authentication is used. The flag can be set to one of four settings: unprotected, SHA-2 write authorization, ECDSA write authorization, or an ECDSA certificate.

Another difference between a coprocessor and an authenticator is how they are set up to perform their security function within the system. Authenticators are bound to secrets installed, whereas a coprocessor can be set up to be more generic in several ways. First, the coprocessor needs to be set up in a way that enables pairing with the endpoint an infinite number of times. Infinite pairing is a necessity where any valid authenticator can be verified with a public key and a valid certificate to ensure this authenticator is signed by the authorized system key. A practical example is an endpoint that can be replaced numerous times during the lifetime of the car. With infinite pairing, anyone can replace the part, and the host recognizes valid parts without any specific pairing steps. On the other hand, original equipment manufacturers (OEMs) can choose a different pairing option, where only the factory and authorized service centers have the hardware and keys required to do a fixed pairing between the host and endpoint.

Authentication in Pairing Applications

Authenticators can be used in applications where it is necessary to pair a peripheral device with the vehicle. Pairing is a strong theft deterrent because it prevents reuse or repurposing of components. Pairing can also be vital in cases where the technology is so advanced that it becomes a liability if got into the hands of a malicious third party. In these cases, the authenticator embedded within the endpoint blocks the unauthorized host by preventing the module from operating without first doing a secure handshake, which can only be done by an authorized host.

The host can prove it is authorized to access the endpoint’s capabilities by providing a valid certificate to prove it is an authorized part of the system, and additionally can provide a signature to further prove it is authorized to pair with the device.

Alternatively, a coprocessor and authenticator can have 1-to-1 pairing. A host and peripheral can also be paired together with a symmetric key pair unique to those devices. In a 1-to-1 pairing application, one page from both the coprocessor and authenticator is written to store the unique binding data to pair these individual devices together. This can cause limitations because the one-time programmable (OTP) memory, as the name implies, can only be programmed once. This means that once the pairing is done, that memory cannot be reprogrammed for a new device. Additionally, a given coprocessor is limited to the number of authenticator devices it can be paired with because it only has six pages of memory.

Next, let us do a deeper dive into several potential examples of how authenticators can be used in automotive applications. This list is in no way exhaustive but gives some detail on a few specific cases.

Authentication of Camera or Sensor Modules

Cameras and sensors play a key role in keeping drivers safe on the road. Each component is specifically designed and tuned to comply with a system that relies on carefully calibrated devices to send the proper data to make every decision. If one of these sensors or cameras are replaced with a lower-grade counterfeit, the entire system can be jeopardized. Adding authentication gives confidence the proper camera is installed and paired with the ECU host. Several technologies, including gigabit multimedia serial link (GMSL) from Analog Devices, provide data path connection between the ECU and camera, as shown in Figure 2. The GMSL technology receives video from the camera and provides a back channel from the ECU upstream to control camera features. The ECU host can drive the authentication functions to the camera and verify correct responses through this control channel. For more information, refer to the application note: Authenticating Remote Automotive Peripherals Using GMSL Tunneling.

Authenticating Front Light Modules

Front light modules provide visibility to the driver in dark or unclear conditions. It is critical that these lights are not dimmer than required, and do not compromise the driver and system’s ability to judge their surroundings. In addition to the operation of the light, a counterfeit light module can be hazardous if it is not up to specifications, and can potentially pose a threat of fire or electrical damage to the system.

In addition to the hazards mentioned above, it is important to also bring up the application of theft prevention for front light modules. Front light modules are often a target of theft, and by embedding an authenticator, counterfeits and unauthorized repurposing can be stopped. If stolen headlamps do not work in other vehicles, it disincentivizes thieves from stealing light modules in the first place (Figure 3).

Many newer vehicles use digital matrix LED lighting in their headlamps. These are high-resolution modules with a matrix of lamps that can focus the beams to adjust to surroundings without mechanical movement of the lights. The lamps have high enough resolution, making it tempting for aftermarket manufacturers and tinkerers to attempt customization of images on the head lamps. Deviating from the headlamp’s intended use like this can also present dangers to people in the vehicle as well as other surrounding people and vehicles. Like optical cameras discussed earlier, headlamps with digital matrix lighting can use the GMSL technology from Analog Devices to send information from the ECU to the headlamps. The authentication functions can be seamlessly performed through the control channel. As shown in Figure 4., a DS2478 implemented in the host ECU can optionally be used to offload the authentication operations from the system-on-chip (SoC) or microcontroller in the ECU. In this case, the headlamps authenticate the host to ensure only valid control of the matrix lighting occurs. When combined with the theft prevention technique discussed earlier, this is an example of two-way authentication between the host and endpoint.

Authentication of LiDAR Modules

Light detection and ranging (LiDAR) systems are emerging as a key component in safety-critical ADAS systems. LiDAR complements optical cameras by gathering object proximity information in relation to the vehicle. The proximity information is in turn used by ADAS processors to make driving decisions for the vehicle. Following the common theme with optical cameras and front light modules, the authenticator can be added inside the LiDAR module to enable the host ECU to verify it is genuine equipment paired with the host. Lower quality or unauthorized equipment can lead the vehicle to make erroneous and dangerous driving decisions. In Figure 5, an FPGA is shown connecting to the authenticator. Some implementations can instead use a microcontroller or SoC.

Authentication of Battery Management Systems

Electric Vehicles (EV) continue to grow in market share every year, and with this growth comes a unique set of challenges. Each EV relies on its BMS to regulate the health of its power source, and monitor a multitude of parameters including its state of charge, state of power, and temperature. The BMS oversight plays a critical role in ensuring the battery does not operate outside of its safe operating range. In Figure 6, an optional bridge device is shown if communication protocol conversion is required for each cell management controller (CMC) to communicate with its corresponding module authenticator. This authenticator, shown in the figure as the DS28x40, is embedded in each module among the cells. The x notation represents the flexibility to choose to communicate through 1-Wire^® (DS28E40) or I²C (DS28C40) between the CMC’s microcontroller and the module’s authenticator. Analog Device’s 1-Wire protocol gives the benefit of combining power and half-duplex communication onto a single pin, while I²C enables use of a common industry-recognized interface. If the CMC and authenticator use the same communication protocol, then no bridge device is required, and the CMC and its authenticator can interface and pass data to one-another directly. All CMCs and their cell modules constitute a battery pack. Each CMC monitors the temperature and voltage of each cell within the module, which is why it is critical that each CMC and its module of cells are authentic components capable of giving correct status updates back to the central battery pack control module (BPCM). If any of these components is not authentic and giving accurate status reports of its various measurements, the safety of the entire system is in doubt.

In this application, the authentication generally takes place during vehicle start-up, which does not interfere with the performance of the continuous looping of battery performance checks that occur during normal operation. This way, the authenticator can detect if a counterfeit battery module is introduced into the system, as it is infeasible to replace battery modules while the vehicle is driving.

In the daisy-chain implementation of BMS, each module is equipped with an authenticator to communicate with its respective CMC counterpart. A hard-wired connection is used to communicate between the BPCM and the modules in the battery pack. Additionally, the daisy-chain implementation features the DS2478 companion coprocessor on the ECU side embedded in the BPCM. This companion coprocessor offloads the cryptographic computations and key storage required on the host side if the microcontroller unit (MCU) does not have the resources available. The DS2478 can authenticate each module to ensure only authorized battery modules are inserted into the larger battery pack assembly.

In summary, numerous endpoints in vehicles can benefit from the addition of an authenticator. Host ECUs can offload the authentication operations from their microcontroller by adding a coprocessor. Having genuine, OEM-approved components ensures the safety of mission-critical automotive components. AEC-Q100 DeepCover Authenticator solutions from Analog Devices solve these security needs.