Security Highlight: Building a Multi-CAN Bus Logger for Automotive
The in-vehicular network in a modern car is complex and composed of multiple electronic control units (ECUs) that communicate with each other using different protocols. Most ECUs found in the car of today communicate using the Controller Area Network (CAN) vehicle bus standard. All ECUs placed on a CAN bus can read all the messages by all the ECUs on that bus. If the in-vehicular network consisted of a single bus, it would result in an inefficient and insecure in-vehicular network. Secure systems prevent complex ECUs with a remote attack surface (e.g., infotainment) from sending messages directly to the vehicle’s power train or brakes, for example. Therefore, it is standard practice in modern cars to implement a gateway, which is responsible for connecting different separate CAN buses and applying message filtering. The network is typically accessed through the Data Link Connector (DLC) which is standardized (i.e., on-board diagnostics generation 2, or OBD-II) on most vehicles. At Keysight we are analyzing the security of a modern car for which a simplified representation of the in-vehicular network is shown below.
This blog post is part of Keysight’s ongoing automotive security research. The results of this research are implemented in Keysight’s tools, services, and training for the automotive market. Check out our latest offers: Automotive Security Penetration Test and Risk Analysis Evaluation services and Automotive Security Training.
To better understand the vehicle under evaluation, we like to understand what messages to send to the different ECUs in order to initiate specific actions. In principle, the gateway has access to all the messages sent on all CAN buses. Therefore, we set out to create a proprietary cable that is capable of sniffing all the messages sent through the gateway. We have two major requirements:
- Sniffing: The multi-CAN bus logger (MCBL) must be able to sniff all the CAN buses at the same time. Timestamps must be added in order to create a coherent log that can be used to track messages sent from ECU A to ECU B and vice versa.
- Sending: The MCBL must be able to send CAN bus messages on arbitrary CAN buses.
There is commercial tooling available to support sniffing and sending on multiple CAN buses at the same time, and this tooling is used extensively by the automotive industry. We did not take this approach for two reasons: It is expensive, and low-level control is most likely limited. However, there are advantages to using professional tooling: There is typically mature software delivered with the hardware, and you can get support. We wanted low-level control of our sniffer in order to implement other functionality in the future (e.g., man-in-the-middle attacks).
We considered two approaches: create our own board designed around a microcontroller (MCU) or repurpose a current solution. We decided to repurpose a commercial solution offered by comma.ai, which also focuses on reverse engineering vehicles in order to retrofit their co-pilot solution. The Panda OBD-II Interface dongles support up to three CAN buses and are easily available. The Panda dongles are designed around a STM32F413 MCU. Their firmware is open source and published on Github. Therefore, we have full control over the firmware and the manufacturer’s blessing to make modifications.
We need to be able to plug the Panda dongles into the gateway’s connection in order to sniff them. We created a cable that we can place between the gateway and the connector going into the gateway. This allows us to connect the CAN buses of the Panda dongles to the CAN buses of the gateway without affecting the original connection. With this cable in place, we can still drive
Our lab personnel implemented our design with high quality connectors and pins. Their craftsmanship resulted in a professional looking cable that is robust enough to drive around with without feeling unsafe. It’s good to be aware when you’ve placed your own hardware and software at a critical location in the in-vehicular network. We do not want to jeopardize our own safety too much. The cable is shown below.
Figure 1. Cable design
Figure 2. Closeup of the Panda dongles connected to the cable
The cable allows us to sniff and send on six CAN buses at the same time. The Panda dongles support a connection via USB, Bluetooth, and Wi-Fi. We prefer to use a physical connection, as it is faster and more robust. We created a flexible Python tool that logs all communication observed by the Panda dongles, including time stamps, using multiple standard formats. In addition, we can interpret and visualize the logged communication data using open source tools like Busmaster and SavvyCAN. We show an example output using these tools below.
Figure 3. Example output
Now we have a physical cable and software to visualize the CAN bus communication observed in the vehicle under evaluation. To give you an idea of the amount of data, we log roughly 20K messages per second on the modern car we are analyzing. Our next challenge is to make sense of this significant amount of communication data.
For any automotive inquiries, contact us at [email protected].