Skip navigation
blackboxPROMO.jpg

Protect Automotive Black Box Data with Secure Memory

Privacy of data generated by an automotive event data recorder is a major concern, especially in terms of unauthorized access. Implementation of F-RAM could help achieve the level of security needed.

An event data recorder (EDR), also known as a “black box,” continuously stores a vehicle’s dynamic data in a circular buffer prior to and during a crash (Fig. 1). The function is analogous to an airplane’s black box.

Fig1.jpg

1. Shown is an event data recorder (EDR).

Technically, an EDR is not a black box, with the primary difference being that the EDR stores data only for a few seconds before and after a crash, whereas an airplane’s black box stores data continuously for the entire time of operation. EDR data in the buffer is saved when the vehicle accelerometer crosses a certain threshold or when an airbag deployment occurs. Specific information gathered varies by auto manufacturer. Some of the recorded data includes vehicle speed, forward and lateral acceleration, braking, steering wheel angle, engine rpm, and restraint deployment.

Automobile manufacturers began installing EDRs as part of the airbag control unit. The airbag control unit detects a crash event and, if necessary, deploys the airbag. EDRs were added to collect crash data that could be used to design safer generations of vehicles. EDR data includes information on the severity of the crash, airbag operation, and what deployment decisions were used during the crash event. This information can help determine if the vehicle was operating properly at the time of the crash, and if not, to help detect the undesirable vehicle operation.

EDR data is very useful to manufacturers. According to the Insurance Institute for Highway Safety (IIHS), 100% of new cars have some form of EDR voluntarily added by the manufacturer. The trend toward autonomous vehicles will demand an ever-increasing number of sensors, with the resulting data being collected by the automobiles and using it to provide driver assistance. This will require future vehicles to log even more data to provide safety of the vehicle operation and accountability in case of system failures. As an example, in newer advanced driver-assistance systems (ADAS), EDRs are used to store camera images immediately before a crash.

Data Retrieval

Crash data is retrieved through the car’s diagnostic link connector (DLC) or by downloading directly from the EDR. Bosch Corp.'s Crash Data Retrieval (CDR) system is a commercially available tool that can be used for downloading EDR data. Manufacturers may have their own tools as well. The CDR acts as an interface allowing a PC to be connected to the DLC or directly to the EDR.

The EDR can have more than eight pages of data downloaded in code, which the CDR software converts into a format that can easily be read. Figure 2 shows the blue CDR tool used to directly connect the EDR and the PC for data retrieval. It’s conceivable that this data will also be accessed over the air as cars get connected to the network.

Fig2.jpg

2. A CDR tool (blue box), used to retrieve EDR data, connects to a PC.

Stored EDR data, though originally intended for research and development by manufacturers, is being used in accident reconstruction by law enforcement, crash investigators, and insurance companies. According to the National Highway Traffic Safety Administration (NHTSA), these data have been used in about 100 court cases as evidence. Some states collect data under their existing state laws governing crash investigations, and courts can subpoena EDR data. In addition, some insurance policies may have contract terms related to data collection from EDRs.

There are no federal laws governing access to EDR data. Many states have different laws regarding who can access EDR data, but most have none. There’s an ongoing debate about who owns the data. Initially, auto companies claimed that they owned it. Now there’s an increasing consensus that the data is owned by the owners and lessees of the vehicle. Typically, access is allowed by court order, for safety, for repairs, or with the automobile owner’s permission.

Currently, EDR data can be accessed by anyone with a CDR tool by connecting it to the DLC port below the steering wheel. For example, an insurance company might access the data without the owner’s knowledge to understand the owner’s driving habits, to establish fault, and to set rates. To prevent access to EDR data, several vendors provide tools, and YouTube instructional videos are available to help erase crash data. There are also tools (e.g. AIRPRO), services (e.g. karmanauto.com), and software available from sources such as eBay for EDR data modification.

For automobile owners, privacy of EDR data is a significant concern. They don’t want unauthorized access to the black box data. Owners want to either turn off their black box or at least restrict access by locking the DLC port using products such as AutoCYB and OBD Lock. Figure 3 shows one such device. These devices aren’t sufficiently effective as the data can still be accessed by directly connecting to the wires behind the DLC port.

Fig3.jpg

3. The OBDII Port Lock prevents unauthorized access.

Since EDR data isn’t secure in today’s systems and may be easily modified, it’s conceivable that after an accident, the party at fault may erase the EDR data before law enforcement or insurance agents can get access using the methods previously described. Without securing the EDR data, its authenticity is questionable and can’t be relied on to provide accurate post-accident data forensics.

The NHTSA doesn’t mandate the installation of EDRs in vehicles since manufacturers voluntarily install them. The NHTSA has indicated that it will consider mandating EDR installations if the trend reverses. It’s standardized the format of the data recorded to enhance its usefulness across manufacturers. If a vehicle has an EDR, it must conform to the standard format.

The NHTSA specifies 15 essential data elements and 30 additional optional data elements for recording. There isn’t a limit to the maximum number of data elements that can be collected, but if the EDR is capable of logging additional data elements, the NHTSA defines the minimum frequency and time interval requirements for those additional data elements.

As per NHTSA regulations, EDRs must capture specified data elements for up to two events; for example, a collision followed by the vehicle hitting a tree. It also specifies that memory must be locked to prevent any future overwriting of the data. Automakers must make commercially available tools for retrieving the black box data. The rules also mandate that the car’s owner’s manual contain a brief statement indicating that the vehicle includes an EDR and explain what it does. See Rule 563 for more details.

EDR System Design

As shown in Figure 4, an EDR system takes inputs from various sensors in the automobile and stores them in a non-volatile memory using an MCU. The EDR detects a crash event, at which time the MCU locks the contents of the memory so that it can’t be overwritten. A crash event is likely followed by power loss to the system. This requires that the EDR consume very low power after the crash to successfully log the data.

Fig4.png

4. Design of an EDR system.

Thus, a fast, non-volatile memory is required so that it can instantaneously log the last few milliseconds of data. An F-RAM is the ideal memory for such applications. F-RAM is fast, reliable, and provides instant non-volatility while using very low power. MCUs used for EDRs fall into two categories: secure and non-secure. A secure MCU implements cryptographic functions and is able to provide security to the system.

Secure F-RAM, such as the Excelon Secure F-RAM from Cypress, integrates security functionality so that it can operate with either secure or non-secure MCUs and still help protect sensitive data. Check out this video:

Secure F-RAM uses the same host processor interfaces and timing as memories such as serial SRAM, EEPROM, and serial flash. However, it takes advantage of fast write speed to eliminate write delays due to “soak time” or page/sector buffering required of other technologies. Instant writes eliminate “data at risk” resulting from unexpected power loss and secures it using cryptographic functions.

To protect data, the non-volatile memory has a configurable secure memory region. All sensitive data can be stored in this secure region. It implements an authentication engine that performs mutual authentication using SHA-256-based HMAC (hash-based message authentication code). To be able to access the sensitive data, the F-RAM requires successful authentication. It also implements a monotonic counter to prevent replay attacks during authentication. In addition, secure F-RAM implements access control mechanisms that include a lock capability, which prevents overwriting the data after a crash.

When a secure MCU is present, a secure F-RAM can seamlessly protect logged data. At system power up, a mutual authentication with the secure MCU is required to allow access to the F-RAM and start logging data (Fig. 5). If the system encounters a power loss, the F-RAM can’t be accessed again without mutual authentication with a secure local or remote host. The data is locked automatically at power down, which protects the logged data from attacks.

Fig5.png

5. Secure F-RAM connected to a Secure MCU.

The table in Figure 6 details the system operation. At power up, the F-RAM is locked, with read and write accesses blocked. During system initialization the Secure MCU performs authentication using a shared secret key, which has been provisioned at the factory. The Host requests and receives a “Nonce” value that, along with the secret key, is used to generate an HMAC. The host then sends the HMAC to the F-RAM, which generates its own HMAC and compares it to the received one. If both match, the F-RAM allows access to the data. In case of a crash and power loss, the F-RAM gets locked. It requires an authentication at system power up to read the data.

Fig6.png

6. Secure F-RAM data access control with Secure MCU.

Secure F-RAM has been designed to provide security even when the host MCU doesn’t support cryptographic functions (Fig. 7). In this case, the F-RAM allows read/write accesses at power up. Data logging can continue as usual. Once there’s a crash, the MCU sends a lock command to the Secure F-RAM. At this point, the F-RAM gets permanently locked and subsequently can only be accessed by a forensic host. The Forensic key is a shared secret key, programmed in the F-RAM at the factory.

Fig7.png

7. Secure F-RAM data access control with Non-Secure MCU.

Almost all new vehicles have some form of EDR that must comply with NHTSA regulations to log crash data in a standardized format. This data is valuable—to the vehicle owner, law enforcement, and insurance companies. It’s increasingly used in criminal and civil cases. Since the logs are a target of attack, this data must be locked and secured to ensure its authenticity and thwart misuse by unauthorized agents. With advances in driver-assist features and autonomous driving, more data is getting logged that must be secured.

Avi Avanindra is Director of Systems Engineering for the Memory Products Division at Cypress Semiconductor Corp.

SourceESB banner with caps

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish