To help connect security researchers to heavy trucks, a remotely accessible test bed is prototyped by researchers at the University of Tulsa, Colorado State University and Synercon Technologies. The test bed relies on embedded Linux-based node controllers that can simulate the sensor inputs to heavy-vehicle electronic control units (ECUs). The node controller also monitors and affects the flow of network information between the ECUs and the vehicle communications backbone.

Heavy vehicles have differences from automobiles that create a distinctive threat environment. The first difference is that heavy vehicles deploy an SAE J1939 specified communication network, with open documentation for packet definition and transmission. Passenger vehicles use distinct, higher-level communication protocols that may be proprietary, and thus less open to the creation of attack vectors. The second difference is that J1939 introduces a newer set of protocols that must be run above the CAN (physical layer). Because the J1939 layers are modeled on the network OSI (Open Systems Interconnection) stack, many of these protocols resemble communication protocols used in computer networks. Thus, the attacks common on computer networks may be adapted to vehicular networks following J1939.

While the J1939 network is founded on the same base CAN protocol that passenger vehicles use, heavy trucks follow a more horizontal integration to allow for customization, which requires a more homogeneous network architecture than that seen in passenger vehicles. The third difference is regarding the universal usage of telematics and third-party devices. Fleet managers often install third-party telematics units to connect the truck and driver to a back office server and logistics management system. Thus, it is possible for a heavy vehicle to be subverted through a third-party system.

The design of the test bed includes access to heavy-vehicle electronic parts to minimize cost and maximize utility. The test bed must be able to interact with both the cyber and physical aspects of heavy vehicle systems; therefore, sensor simulation is needed to provide the modules in the test bed with simulated physical environments.

The test bed is designed to enable a researcher to log into a node and observe or affect network traffic on two ends of the controller. As shown in Figure 1, the common backbone connects different ECU nodes. Each node has at least one node controller and one ECU. Some nodes have a sensor simulator to mimic physical sensor values.

The test bed design starts with a communications backbone consisting of an SAE J1939-13 nine-pin connector and its signals. Within the test bed, every engine control module (ECM) has its own remotely accessible node controller. The node controller is a Beagle Bone Black connected to a communications circuit board. This hardware is connected to the backbone and the ECM that it is controlling.

Each node controller is physically connected to an Ethernet switch, which is connected to the remote user management system. Through this network connection, remote users can log in and affect or observe network traffic to and from the backbone and the ECM in the node. They can also issue commands to affect the sensor simulation system.

Requirements for design of the test bed were that it have full J1939 implementation. In addition, it had to allow researchers to fully interact with the ECUs, input experimental or historic data to determine ECU responses, view the results in real time via live-updating charts and tables, inject their own J1939 messages onto the CAN network to simulate attacks, and record any traffic generated by an experiment for analysis.

The test bed architecture shown in Figure 2 consists of five layers: Web Interface, Experiment Processing framework, Experiment Logic framework, CAN Data Processor, and Database. The sequence diagram, shown in Figure 3, depicts the flow of functionality of the remote interface. To demonstrate the utility of the test bed, sample experiments were conducted for seed/key exchange, as well as intrusion detection.

Future study is planned to determine whether real-time constraints can be satisfied by the intrusion detection system (IDS) mechanism. Additional work will investigate the usefulness of the sampling techniques for real-time IDS. Researchers also plan to evaluate the IDS against the standard metrics proposed for IP networks. The eventual goal is to provide a repository of IDSs for J1939 traffic and provide a database of types of attacks detected, requirements needed to deploy the specific IDS, and performance under the given metrics.

This article is based on SAE technical paper 2016-01-8142 authored by Jeremy Daily, Rose Gamble, Stephen Moffitt, Conner Raines, Paul Harris, and Jannah Miran of University of Tulsa; Indrakshi Ray, Subhojeet Mukherjee, and Hossein Shirazi of Colorado State University; and James Johnson of Synercon Technologies. The paper will be presented at the SAE 2016 Commercial Vehicle Engineering Congress.