Embedded technology at the heart of the Secure-CAV project: Part 2

In the first part of the Siemens technology overview of the Secure-CAV project, we introduced the Siemens FPGA platform with Tessent Embedded Analytics (EA) and enabling software including the Tessent Embedded SDK.

In this second blog, we will look at how this analytics platform is utilized with the hacking scenarios researched and proposed by Copper Horse, how the hardware provides a line of defense, and how the on-chip Embedded Analytics are used to mitigate hacking threats within the automotive electronics system.

Using the technology described in the first blog, we created an emulation of a car’s electronics system and an application implementing hacking scenarios, together with a display screen so we can demonstrate and visualize successful hack defense on a dashboard. We have implemented four threat scenarios, based on the priorities of our Secure CAV industry panel of automotive experts:

  • Mileage (odometer) tampering
  • OBD-II attack
  • Infotainment attack
  • Unauthorized door unlock

Each of these hacks has associated threat scenario descriptions, which can be mapped to low-level events occurring in the SoC, or in our case an FPGA emulating multiple chips. The task of doing this is spread over five CPUs:

  • ARM0 is running an application which provides services to load and start other CPUs, access the storage disk, and allow TCP/IP communication to the FPGA
  • ARM1 is running a visualizer which processes requests from the analytics applications to build the dashboard display
  • ARM2 is running the ‘car app’, an application which emulates the car’s infotainment system
  • RISC-V ACPU (analytics CPU) is running analytics software, observing CAN bus frames and Tessent Embedded Analytics messages to detect anomalies which may indicate one of the four hacking scenarios. (It also sends visualization request to the visualizer.)
  • RISC-V SCPU (system CPU) is running CAN frame trace replay to generate traffic on the CAN bus. (This can be switched off when we want to injected CAN frames directly into the system)

We can then ‘hack’ the system using specially defined scripts which inject realistic malicious frames on the CAN bus, for example:

  • Inject OBD-II frames that don’t normally occur on the CAN bus
  • Request the ‘car app’ to do something suspicious (for example, write to the CAN controller)

On-chip analytics on the ACPU can then detect anomalies in a range of different ways:

  • Observing CAN frames or using EA monitors to observe AXI buses, looking for unusual features
  • Using  a rule-based algorithm to find inconsistencies, for example between speed and distance measurements inside CAN frames to detect odometer tampering. (Odometer tampering leads to a mismatch between the odometer update data and the value of speed x time, all which can be extracted from CAN data and corrected by the ACPU.)
  • Monitoring suspicious access attempts using EA Bus Monitors and raising a warning/alarm if one is seen

The dashboard display using embedded graphics libraries to visualize system data is shown in the figure below.

The Embedded Analytics hacking visualization dashboard, showing various data from the emulated car electronics system. The hacking alert panel in the top right is indicating that a hack has been detected and mitigated (an unauthorized door unlock).
You May Also Like