Secure CAN Bus Logging & Telematics - A Simple Intro

Most CAN bus data loggers record unencrypted CAN data. To understand this, it is important to address two misconceptions:

Binary data is not encrypted: Log files are typically recorded either in plain text (CSV, TXT, ASC, ...) or binary form (MDF4, BLF, ...). The binary data is sometimes referred to as 'encrypted' - but this is not the case at all. Using suitable software tools, the binary formats can be easily displayed in plain text form.

Raw CAN data is not encrypted: CAN data is recorded in raw 'bus logging' form. This means that you will be recording CAN IDs and data bytes, which need to be scaled to 'physical values' (speed, temperature, ...). This scaling process requires that you have a CAN database of conversion rules (often a DBC file) to interpret the data. Because of this, a common misconception is that raw CAN data is encrypted by default. This is, however, not the case. First, many assets use standardized protocols like J1939 or OBD2. For these protocols, a large share of the data can be directly decoded using standard J1939 DBC or OBD2 DBC files. Further, even if the CAN data is 100% proprietary, the data can be reverse engineered with limited effort.

In other words, logging unencrypted CAN data to an SD card should be seen as equivalent to making the contents of the data accessible to anyone with physical access to the SD card.

Further, for many use cases it is not enough to know that your data is "confidential". It is often equally important that your data is "authentic" - i.e. that you know whether it has been modified.

Recorded CAN data is often uploaded via WiFi/3G/4G/5G to a server as part of a telematics system. In many cases, this transfer of data is unencrypted meaning that the data is exposed to remote attacks. Examples of unsecure transfer protocols include FTP or HTTP in contrast to SFTP and HTTPS.

CAN bus telematics also exposes the asset itself to attacks due to two features supported by many CAN loggers:

1. The ability to transmit data into the CAN bus (e.g. to request OBD2 data or control the asset via CAN commands)
2. The ability to receive firmware updates, sometimes over-the-air

The ability to transmit CAN data can be used to e.g. remotely control the asset (turning a steering wheel or disabling the brakes). Further, it can be used to send high priority CAN IDs at high frequency, causing a denial of service for lower priority CAN IDs.

The above is typically prevented through built-in restrictions on e.g. the frequency of transmission as part of the CAN logger firmware. However, if an attacker is able to add a custom firmware to the device, such restrictions can be removed. Further, if this can be done over-the-air, it opens up for remote control and hostile takeovers of e.g. vehicles. As such, cyber security in automotives is an important topic, which is also addressed via standards like SAE J3061 (Cybersecurity Guidebook for Cyber-Physical Vehicle Systems). Here, car cyber security and general vehicle cyber security are also key motivations for rolling out the second generation of CAN bus, CAN FD, which will aid in improving the connected car security.

Often, CAN devices are manufactured at 3rd party PCB assembly houses. However, the firmware and end-of-line (EOL) test step should be controlled by the original device manufacturer. This is critical for two reasons:

1. To ensure that the firmware is not stolen and e.g. modified for use in a cyber attack
2. To ensure that the specific devices (and firmware on it) have not been modified

At CSS Electronics, PCBs are manufactured by our trusted US partner (ISO 9001, 5+ years of collaboration). PCBs are shipped to Denmark where 100% of units go through an extensive in-house EOL test procedure in which the firmware is added.

Various companies specialize in reverse engineering firmware code from embedded devices. This means that an attacker can in principle extract the firmware code, which would provide the basis for creating a custom firmware that may be used in an attack.

The CANedge uses microcontroller based code encryption, meaning that it is not possible to read out firmware code from the device. This serves as basic protection, though it is not bullet-proof. This is why digital signing is critical as outlined below.

If an attacker is able to deploy a modified firmware to a CAN based device, it opens up a vast array of possible attacks, incl. safety-critical ones like e.g. disabling vehicle brakes during driving. This is particularly dangerous for IoT CAN loggers with over-the-air capability, where attacks can be performed without physical access to the device.

To prevent such attacks, the CANedge only accepts digitally signed firmware files from CSS Electronics. This means that even if an attacker was able to decode, modify and build a custom firmware, it would not be accepted by the device.

In order to ensure the security of the device going forward, the CANedge supports firmware updates via the SD card. For the CANedge2, it is also possible to update the firmware securely over-the-air.

A secure CAN bus data logger will require user-specific passwords for both CAN bus data encryption, SIM PIN code or WiFi access point(s) and the server endpoint. These passwords are stored on the device and should therefore be encryptable in a secure way.

The CANedge solves this through the use of an Elliptic Curve Cryptography (ECC) scheme. The implementation uses NIST approved methodologies (National Institute of Standards and Technology). In general, it is recommended to use NIST approved schemes for cryptographic and security-related implementations. For details on the ECC scheme deployed, see the CANedge2 Docs.

The CANedge2/CANedge3 also optionally supports over-the-air configuration updates, which means that passwords can be rotated over time.

As explained above, SD card data encryption is important for various reasons.

First, the roll-out of GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act) means that data breaches can result in massive fines to the data processor. CAN data is often in scope of this, meaning that exposing unencrypted CAN data on e.g. an SD card can lead to a breach simply by somebody having access to the device. However, if breached data is encrypted such fines may be waived.

Second, the data recorded is often business-sensitive - meaning that confidentiality is critical. This is particularly important if advanced filtering is applied, since strategic use cases may be deduced based on the filtering.

Third, unencrypted data can be easily modified. For example, a plain-text CSV/TXT/ASC file can be opened from the SD card in a text editor and directly edited. This makes it possible to e.g. insert false information - e.g. by copying chunks of data from one time period into another.

When could falsification be an issue? Many OEMs use CAN loggers as 'black boxes' in vehicles to monitor usage in the field by their customers. This is particularly powerful during warranty disputes where CAN data may help prove misuse by a customer. However, if the customer modifies the data, the usefulness is eliminated. Obviously, this can also be turned around: If the data can be modified by the OEM, the customer may claim that the data is invalid.

The CANedge encrypts data using a NIST approved AES-GCM scheme. Importantly, data is streamed through the encryption scheme prior to persistence on the SD card. Further, the CANedge remains 100% power safe while encryption is enabled. This means that if power is cut in the middle of a recording, the device will properly shut down the logging and encryption process without any data corruption - and without leaving the log file unencrypted. The AES-GCM scheme also includes an integrity check to ensure the authenticity of the log file data, preventing untraceable modification of the contents.

Data encryption of thousands of CAN frames per second is computationally intensive, hence the CANedge uses a dedicated encryption module to enable this.

Secure data transfer is important as it ensures the privacy and security of data during movement - e.g. from local storage on an SD card to remote storage on a server. This concept is similar to how you can access websites via HTTP (unsecure) or HTTPS (secure).

The CANedge2/CANedge3 supports secure data upload via the NIST approved TLS 1.2 protocol. This facilitates encryption of data transmissions and server authentication via certificates. In turn, this enables the secure upload of log file data, as well as secure over-the-air updates of firmware and configuration.

As a rule of thumb, server access should be monitored, limited and controlled. This ensures that a potential access breach is contained and does not affect the entire server.

The CANedge2/CANedge3 uploads data via the S3 interface. This means that you can setup e.g. a free MinIO S3 server on your PC or corporate server - or upload data to a cloud server like AWS, Google Cloud or Azure. In all cases, you can monitor server access logs and manage user access via customizable policies.

For example, an OEM can use this to set up multiple buckets (folders) on a single server - with each bucket being restricted to a specific customer for telematics use cases. Further, each bucket could have multiple user access levels: Some may provide full read/write/delete access to all files, while others may only enable the user to view and download log files.

When deploying several units in the field, it is important that the security critical data is separate to each device. This ensures that if a single device is compromised, it does not compromise the security of other devices. Similarly, if an attacker is able to decode e.g. the WiFi password, this should not expose other passwords like the server or data encryption passwords.

For the CANedge, this is ensured via globally unique device-specific keys used in e.g. the password encryption process. Further, the encryption scheme ensures that each password (e.g. WiFi, server, data encryption) is encrypted independently.

End users can also decide to e.g. use device specific data encryption passwords, meaning that even if a data encryption password was compromised for one device, it would not enable decryption of data from other devices.

To ensure the security of your server, it is recommended to rotate the server certificates periodically. This means that devices connected in the field must be updated with the new certificates prior to the rotation.

The CANedge solves this via support for 10+ certificates and over-the-air certificate updates. With this, you can e.g. pre-install e.g. the 'current' and 'upcoming' certificate before the device is deployed in the field. After the first certificate rotation is completed, the device will use the second pre-installed certificate. Before a second rotation is performed, an over-the-air update can be used to add the next upcoming certificate to the device.

Note: OTA server certificates is pending a short-term firmware update.