Today with the advent of the fully connected car these activities have reached the next level, as not only can a single vehicle be stolen, but ultimately an entire fleet of vehicles could be targeted by a sophisticated attacker.
The following lists the various personas, and their motivation for attacking a connected vehicle
- Car tuner: their business is to remotely unlock specific features or improve performance
- Black hat hacker: perform publicly visible hack to gain community recognition
- Competition: use industrial espionage to gain competitive advantage (or close technical gap)
- Terrorist: use individual cars or a fleet for targeted terrorist attack.
To understand how potential adversaries could attack a connected vehicle it is critical to understand to whom or what such a vehicle is connected.
Of course, there are the obvious connections, like those to the driver or passengers via their mobile devices using Bluetooth or Wi-Fi, to GPS/GNSS/Galileo satellites, to the cloud using 3G, 4G or in the future 5G networks or to other instances as part of the C2X/V2X activities.
However, there are other ways a car can be connected to the environment. All vehicle sensors – radar, lidar, camera – provide information that will be used to perform specific actions. The decision-making process behind those actions can be influenced by modifying the sensor data.
Above; Consolidation of ECUs is one of the means to tackle the complexity of automotive EE architectures
There are further connections which are only used periodically during the car’s lifecycle, but still provide potentially dangerous attack surfaces, e.g. the connection to a tester whenever the car is brought in for maintenance or even the production equipment at the OEM plant where ECUs receive their final configuration.
When talking about all these potential attack surfaces it is worth taking a second to explain the fundamental difference between security and (functional) safety in this context as they are both closely related but yet completely different.
Safety’s goal is to make sure that any system at any time will behave according to its requirements, which generally defines potential safety threats and how they are handled. To achieve the highest levels of safety, tools and methodologies like requirements tracing, design/code reviews, testing and verification and system redundancy are used.
Security on the other hand is going a step further: besides the goals of safety, security also wants to make sure that at any time the system does not do anything it is not supposed to do. In addition to all the activities to guarantee safety, measures like security policy definition/enforcement, penetration testing or covert channel analysis need to be performed.
So, how to maintain security?
To maintain security in a system a few basic principles need to be followed:
- Authentication: information can only be exchanged with trusted partners.
- Encryption: information to be stored and transferred between trusted partners needs to be encrypted
- Device Lifecycle Management: This ensures that the keys used to secure both the ECU and back office processes can be revoked and replaced in the case of compromise.
- Separation: to minimise the number of devices or functions that need to be secured, secure separation should be utilized to separate secure and non-secure components
This list contains the basic principles to be applied for developing a secure system. However, it is important to mention that the concepts of security need to be applied from the start of the design phase and at every level in the system to ensure a robust device that can withstand an attack or recover quickly if it is overcome. This is known as ‘security in depth’.
Software separation
Growing interdependencies between signals and functions inside a vehicle, as well as growing system complexity, are driving the need to consolidate multiple functions or features on a single ECU (See above). Ensuring that secure and safety critical functions remain free from interference by non-critical/non-secure functions is one of the key aspects of embedded security.
Real-time operating systems like INTEGRITY enable this by providing safe and secure separation in time and space as part of its underlying microkernel architecture.
Communication channels between different address spaces only exist if defined and configured up-front, stopping an attacker forcing a connection from a vulnerable function to a critical one or sensitive data which is a common threat vector in other operating systems.
Besides this advantage for securing the software architecture, INTEGRITY’s type-2 hypervisor approach brings other benefits: as the separation kernel is already secure, providing full hypervisor functionality in a secure partition means less complexity and code than a typical type-1 hypervisor solution.
This means less context-switching and higher performance, less latency and better predictability. Also, potential harm in this software architecture is limited to the specific software partition it is running in.
Secure OS – why so important?
Looking at various attack vectors of recent attempts to penetrate systems they all end up at the operating system - often the last line of defence preventing an attacker taking control of or accessing secure information in the system.
The OS, while it should be able to defend against attacks coming in from various applications, not only controls the hardware resources of the system and the interfaces between software partitions, i.e. user spaces, it may also add – depending on the specific type or version of the OS – a significant number of vulnerabilities.
So, it is highly recommended to evaluate all the operating systems of choice not only regarding functionality but take a close look at security related certifications, like the common criteria security evaluation. For high-value assets suffering from significant risks, e.g. cars that pose a very high potential threat, it is recommended to use an OS with a rating of at least EAL6 (Evaluation Assurance Level).
Of course, making the right choice regarding a secure OS is only one aspect of security and does not solve all the security issues in a system – more effort and caution needs to be applied on all levels of a project. Neglecting the need for using a secure OS equals the building of a skyscraper without a proper concrete foundation.
It’s not the question if, but when security would be breached.
In-Vehicle Intrusion Detection and Prevention System (IDPS) on CAN
The CAN bus is the main data carrier in vehicles today. Each device can send or receive a message on the bus. There is no designated bus master and each device may initiate transmission, which is subject to arbitration. Since the number of ECUs in vehicles has grown significantly and the criticality of the different devices has widely diverged, vehicle network architectures separate the different ECUs on different CAN buses which in many cases are connected via a gateway.
For hackers the CAN bus provides an attack surface that enables them to completely take control over a vehicle. After getting access to the gateway, malicious messages can be injected on practically any CAN bus segment – even to critical ECUs like engine controllers, brake controllers, etc.
To prevent a security violation through a malicious message the Israeli cybersecurity provider, Arilou (part of the NNG group) has developed an in-vehicle intrusion detection and prevention system (IDPS). It enables any ECU to distinguish between legitimate and malicious frames by providing a security agent. The agent compares messages with a model of the OEM-specified CAN traffic on a given CAN bus segment and filters out unwanted messages on the lowest layers of ECU software before they can be processed in the targeted ECU. With such a solution, CAN bus security is moved to the lowest layers of the ECU software. In addition, the agent can provide security audits of other components in the vehicle, which can then be used to remove the vulnerability and update the ECU. This can be done via an OTA service (over-the-air update), where the software of any ECU, from which the malicious messages originate, is updated by the OEM to patch the security issue
Author details: Nikola Velinov is Senior Business Development Engineer and Stephan Janouch, Senior Manager Business Development, at Green Hills Software
