[2022] Hardware-Based SOC Monitoring (Real Time) Solutions to CAVs

To start with the topic of SOC Monitoring and CAVs, we need to know the link between them. Systems-on-a-chip (SoCs) integrate all the computing components that power today's Internet of Things (IoT), including connected cars and self-driving vehicles (CAVs). Their global connectivity and computational resources make them vulnerable to cyber attacks via various vectors, including wired (e.g. CAN, LIN) and wireless (e.g. Bluetooth, Wi-Fi) communications.

As a result, CAVs represent a significant cybersecurity challenge. In this paper, an SoC containing a Field Programmable Gate Array (FPGA) is proposed that deploys a unique silicon intellectual property (IP), including a dedicated analysis CPU (Central Processing Unit), to intelligently monitor not only the SoC itself, but also the internal automotive network in parallel and in real time.

The solution has been tested against 2 automotive-related infringement cases and the results show that the proposed solution can successfully detect and block cyber attacks in the automotive domain.

Cyber Attacks Against Automobiles Increased over the Past Decade

Attacks include intrusions into various safety-critical systems of the vehicle such as brake failure, stopping the engine and turning off the headlights, all of which put human lives at serious risk. Therefore, there is a need to enhance the operational resilience of CAVs to minimize their impact on safety-critical IoT systems. However, existing software monitoring solutions suffer from a number of limitations.

1. First, they typically require hundreds of milliseconds to process the data from sensors. This is too slow for safety-critical applications that may be critical to avoiding accidents.
2. Second, they are very clearly more vulnerable to hacking.
3. Third, their implementation is intrusive and interferes with the normal operation of the CAV. Finally, because of their limited data access, they cannot monitor the entire system.

On the other hand, hardware-based SoC monitoring approaches can provide appropriate solutions to overcome these limitations, as they are non-intrusive and runtime configurable. For instance, Siemens has developed a unique set of silicon IP that could enable hardware-based SoC monitoring. Supported by powerful machine learning models, they support system behavior learning, fast anomaly identification, detection of alarms and troubleshooting tracing of fault causes.

In this paper, hardware-based SoC monitoring is proposed to be applied to the automotive domain to strengthen its cybersecurity standards. This approach will ensure that safety-critical IoT systems, such as CAVs, function as designed to intelligently protect occupants and digital infrastructure systems. In addition, this also provides wire-speed anomaly detection to avoid potentially fatal disasters such as car crashes and major socio-economic disruptions.

The Automotive Software-Based Solution

1. An Attack on a CAN Network Requires the Attacker to Change the Packet Broadcast

Attacks may disrupt packet broadcast rates, for example, by flooding the network with fabricated packets to perform a denial of service (DoS), thereby disabling a vehicle or certain functions. Although immediately destructive, such crude attacks are considered to be relatively easy to detect. Attacks that attempt to take control of certain functions of the vehicle or meaningfully alter the representation of information may be more difficult to detect.

An example would be a misleading payload packet fabricated over the air. Such attacks may force the car into a dangerous situation, systematically alter the performance or efficiency of the car, or manipulate it for financial gain or dissatisfaction. These tricks may require the fabrication of seemingly legitimate packets from an attacking system disguised as a legitimate control unit.

The well-publicized attack on a Jeep Cherokee required the attacker to broadcast fabricated packets containing plausible speed data, thereby tricking the car's system into thinking the car was traveling more slowly-which in turn allowed other functions, such as parking assistance, to be activated. One problem with detecting such attacks is that the manipulated data values are still within the legitimate range, and so may not appear to be obviously malicious.

2. Two Detecting Attacks Method: Signature Method and Anomaly Method

Signature methods compare traffic patterns to a rule-based approach. While these methods may be accurate, it is assumed that they are able to identify, encode and distribute evolving attack models. However, this is problematic for automotive CAN systems because:

i) data derivation is typically kept secret from manufacturers;

ii) cars have different locations, usage patterns, and lifecycles, which makes it difficult to maintain and update signature databases;

iii) attack scenarios are still emerging. Therefore, signature methods for detecting CAN attacks are usually considered less favorable.

The anomaly approach attempts to identify anomalies in network traffic. The assumption is that the anomalies may be caused by an attack. As a result, the main machine learning algorithms that can be applied to the cybersecurity domain are focused on detecting anomalies or outliers. By definition, these data points are scarce in the collected dataset and challenging to even flag as anomalies.

In addition to CAN bus vulnerabilities, which are currently a major concern for automotive security, cyber attacks can also directly or indirectly target automotive SoCs, such as ADAS. automotive SoCs are connected to some non-secure hardware and at least one type of network or service. They store and exchange large amounts of user data, including sensitive information, such as mobile banking details or private information. As the world becomes digital, this cloud of data, including security-related data and private information makes the Internet of Things (IoT) an attractive area for attackers, which raises the need for security. Today, the security of automotive system-on-a-chip (SoC) for IoT is not a simple topic.

In fact, SoCs are becoming increasingly complex and they include many sophisticated applications such as hardware acceleration, making these applications and the entire SoC secure is a huge challenge for the semiconductor industry, especially if their designers want to reduce area cost and power consumption; therefore, reviewing and understanding the development of AXI interconnect vulnerabilities in SoCs is critical.

The Automotive Hardware-Based Solution

Modern automotive systems are becoming increasingly complex. These consist of clusters of ECUs that are typically connected to one or more than one in-vehicle networks. Many individual ECUs are simple in nature, but others are not.

One of the most rapidly evolving areas of systems-on-chip (SoC) is the ADAS subsystems for adaptive cruise control, driver monitoring, lane departure warning, and collision avoidance. These devices employ an array of cameras, LiDAR, radar and ultrasonic sensors. In addition, they themselves contain complex systems that process data from the sensors, as well as systems that control the vehicle's electromechanical actuators to perform automatic steering and braking.

As ECUs continue to evolve in the autonomous vehicle space, there is an urgent need to ensure that ECU performance is under control. silicon chips deployed in ECUs will have a special, non-intrusive monitoring infrastructure that can be used to understand not only how the ECU is working, but also how the entire vehicle is working.

For example, ADAS systems have many functions occurring simultaneously, many of which may be interdependent. Strict time deadlines need to be met or the entire system may break down. Identifying and diagnosing these problems in the lab is very difficult and in some cases impossible. The situation is further complicated by the fact that systems like this are often updated wirelessly: industry standards are evolving rapidly, and so must be the firmware.

Siemens' Embedded Analytics IP introspection monitors (shown in light green) are used to evaluate the operation of ADAS SoCs. These monitors can be configured at runtime and provide a wealth of data that analysis tools can use to gain insight into problems that may be observed. For example, AXI bus monitors are protocol-aware and transaction-aware. They can be configured at runtime to provide information on many items-for example, latency of a transaction; minimum/maximum/average latency of a transaction; bandwidth; duration of a transaction; counting and timing. This data is used by analysis software executing on a dedicated CPU to identify performance, security, and assurance issues.

Real-time Hardware-Based Soc Monitoring Solution [HOT!]

This section provides a demonstratable hardware-based SoC FPGA monitoring platform that is capable of emulating a range of ECUs. figure 1 gives a block diagram of this FPGA, which contains several Siemens monitoring IPs, also referred to as embedded analysis IPs, as well as a number of hardware and software CPUs. the analysis IPs are shown in blue-green. These IP blocks, together with the analysis software, are used to detect and mitigate a number of security threats that have been identified as significant by consortium members and automotive manufacturers.

In brief, the following IP blocks are deployed in the FPGAs.

-An Analytical CPU: which can be used to configure and analyze data from the monitoring infrastructure.

-System CPUs (two RISC-V, four ARM A53, two ARM R5): can be used to perform system functions such as infotainment, central door locking and other ECUs, etc.

-The CAN bus: A CAN transceiver can be used to integrate other CAN nodes. Together with the analytic CPU, it can be used as a prototype for CAN bus sentinels. There are two enhanced CAN-HGTM, bus controllers. The CAN-HGTM handles the high-speed and protected bus. It is used to carry additional information in the CAN frame to overcome limitations and vulnerabilities. They are also fully compatible with standard CAN.

-JPAM (x3): Provides the ability to easily stop/resume/restart code on a RISC-V core.

-Static Instrumentation: Used to implement software-based monitoring.

-Virtual Console: Used to implement communication between code running on the CPU and the debug host.

-Direct Memory Access (DMA): Used to provide access to the entire space.

-Bus Monitor (x8): used to provide observation of all AXI interfaces of interest. In the context of relevant network security, they can also monitor, detect and remove erroneous interconnect transactions.

Most importantly, these modules are connected to the Siemens messaging structure - annotated as message engine. This allows the data collected and generated by the monitoring IP to be transferred across the entire SoC (in this case the FPGA). Data can be obtained off-chip, for example, via a USB 2.0 communicator; providing communication without on-chip software overhead - that is, USB communication is done entirely in hardware.

Further Reading:  AI algorithms in self-driving technology

Cases of Automotive Cybersecurity Infringement

AXI is an interface for accessing the SoC interconnect of multiple systems. Current FPGA systems also support AXI monitoring using Siemens Embedded Analytics IP. infotainment system and door lock unit tampering were chosen as infringement cases in order to verify the effectiveness of the solution. Both cases are implemented by monitoring AXI reads/writes as described in sections IV-B1 and IV-B2.

To implement the attack scenarios and communicate with the FPGA and the simulated ECU, we developed a python host session that first initializes the FPGA CPU and IP, and second injects malicious attacks related to the infringement cases into the FPGA, triggering detection and mitigation during the field tests.

This means that they replicate the cyber-attack scenario. These functions are also highly customizable and can be modified depending on the nature of the attack.

1) Corrupted infotainment system: In this scenario, the attacker corrupts the car infotainment system and the malware runs on the CPU of the infotainment system. It attempts to access system modules (peripherals/memory) that exist on the SoC interconnect and are architecturally accessible to the CPU, but the CPU should not normally access them. Examples of this include.

• -Memory areas that are not normally used by infotainment system software
• -Flash controllers
• -Memory controllers
• -CAN bus controllers

In fact, it can be a peripheral device used by any attacker to maliciously trigger actions or obtain information from it. It is not possible to permanently block access to all potentially sensitive peripherals structurally, as the infotainment system will need to access them with proper authorization. Of course, there are multiple layers of protection against unauthorized use of these resources (e.g. properly set up MMUs or MPUs), but the use of Siemens Embedded Analytics IP provides hardware monitoring independent of the infotainment system software, which can still work even if an attacker manages to reprogram the MMU tables.

In the FPGA, the infotainment system is emulated by an ARM53 CPU which runs an application representing the infotainment software. Note that this application does not actually emulate the full functionality of the actual infotainment system, it is only able to perform accidental accesses on the AXI bus. It performs these accesses based on a request from the host Python session controlling the FPGA. This request represents an attacker's attempt to maliciously access a banned AXI address.

The Analysis IP (APCU, one of the RISC-V CPUs in the system) is responsible for.

-Configuring the AXI bus monitor at boot time and notifying the APCU when accesses to the infotainment CPU are targeted to a range of prohibited AXI addresses.

-Receiving notifications from the bus monitor when it sees prohibited accesses during normal operation.

2) Unauthorized car door lock device tampering: In this case, the attacker gains access to the AXI bus initiator to perform unauthorized car unlocking.

On the FPGA, an AXI bus sentry looks for accesses to the address range of the car door lock controller from a designated AXI bus initiator (a DMA), emulating a compromised initiator.

Similar to the previous case, at boot time, the APCU configures the Siemens Embedded Analytics IP to monitor forbidden accesses from the DMA to the automotive door lock controller. This time, instead of a bus monitor, the IP block used is a bus sentry.

The Bus Sentry, unlike the Bus Monitor, is capable of blocking AXI accesses in addition to monitoring AXI accesses.