1 Introduction
1.1 Attacks on CCAM connectivity infrastructures
1.1.1 Authenticity/identification attacks
-
Sybil attack: A malicious vehicle pretends to be legitimate by exploiting fake identities. Authenticated nodes consider the malicious messages to be legitimate and cannot detect the attackers. Cryptography schemes can be adopted as a countermeasure [2];
-
Location Service Jamming and Spoofing: Global Navigation Satellite Systems (GNSS), e.g., the GPS, are vulnerable to attacks where legitimate satellite signals are either blocked or counterfeited. An effective solution for detecting the location spoofing attack is introduced in [3] and presented in detail in Sect. 4;
1.1.2 Availability attacks
-
Denial of Service (DoS) attack: Aims at preventing legitimate entities from accessing the network services and resources. Access control with packet filtering is the recommended mitigation technique [4];
-
Timing attack: A transmission is delayed by adding extra timeslots between received messages. Authenticated timing methods are effective against these types of attacks [5];
-
Flooding and Jamming attack: Focuses on disrupting the network communication channels. Channel switching is the adopted countermeasure solution [6].
1.1.3 Confidentiality/privacy attacks
-
Eavesdropping attack: Attempts to steal information (e.g., location) by snooping on the communication channel. Although it is easy to carry out, encrypted communication solutions can be used to prevent this attack [7];
-
Traffic analysis attack: The attacker aims to breach confidentiality by collecting traffic information of the whole network of vehicles, for its own purposes. Privacy-preserving methods can be adopted to mitigate this attack [2].
1.1.4 Data integrity/data trust attacks
-
Replay attack: Previously generated data are maliciously repeated; as a countermeasure, duplicated data can be prevented by making use of the sequence number, time-stamp and secure communication [8];
-
Data alteration/Data injection attack: Intentionally modified data are injected in the network of vehicles. Signature of transmitted packets [9], as well as convex optimization approaches that exploit special structures related to spatio-temporal correlations and sparsity characteristics [10], can be used as a countermeasure.
2 Methods/experimental
2.1 The CARAMEL architecture
2.1.1 The CARAMEL’s PKI
-
the Root Certification Authority (RCA): This entity contains the root certificates for the entire PKI. For security reasons, this is an offline entity which must be managed only by authorized personnel;
-
the Online Certification Authority (OCA): This is an online entity signed by the RCA. Its main responsibility is to sign the different lower authorities in the PKI;
-
the Enrolment Authority (EA): This entity is in charge of providing the necessary credentials at the enrolment phase, which are used afterwards by the car to ask for Authorization Tickets (ATs), also known as pseudonym certificates;
-
the Authorization Authority (AA): This entity provides the ATs, which are issued for ensuring privacy of the car communications within the ITS infrastructure;
-
the Validation Authority (VA): This entity provides a way to ask about the revoked certificates. It maintains the Certificate Revocation List (CRL) including the revoked certificates, along with an online service that returns the state of a specific certificate in real-time.
2.1.2 The multi-RAT V2X communication infrastructure with MEC functionalities
-
One Vanetza entity for each RSU.
-
One single Vanetza entity for all LTE-Uu only OBUs, which attends the endpoints of the tunnels created by them.
-
One vEPC that, altogether with the small cells, constitute an LTE system. This module is connected to the Internet through the Internet interface of the MEC, and provides Internet connectivity to all OBUs.
-
The V2X forwarding module that receives all V2X incoming messages, analyzes them, and decides if they need to be forwarded to other vehicles depending on their radio technology, area of interest, age of the messages, content of the message, etc. It also enables to inject V2X messages from external servers to the system of fixed radio stations to be received by vehicles. This module is connected to the Internet through the Internet interface of the MEC.
-
One module called Register to provide LTE broadcast transmissions. Although the LTE standard defines the evolved Multimedia Broadcast Multicast Services (eMBMS), it is not widely deployed. Therefore, to cope with this issue, CARAMEL deploys the Register module that registers all LTE-Uu only OBUs in the system, and each time that one V2X message needs to be broadcasted, it transmits one unicast copy to each one of them. The registration process of a new LTE-Uu only OBU is automatically done whenever it receives a V2X message from a vehicle that enters the region of operation for the first time. The unregistration process is performed when the Register stops receiving V2X messages from a vehicle for some specified amount of time. This process is extremely costly in terms of bandwidth but, if the eMBMS or the LTE-PC5 are not operational, converting one LTE broadcast transmission in multiple LTE unicast transmissions is the only solution to reach all the intended receivers.
-
Applications to remotely connect to RSUs and to small cells in order to manage them. It can be as simple as an ssh.
-
Other processes, e.g., ML algorithms used to improve the overall security of autonomous and connected vehicles.
-
One VLAN to connect each pair formed by one RSU with the virtual container that hosts its associated Vanetza. Both ends of the VLAN are configured as layer 2 interfaces.
-
One VLAN that connects all small cells (eNBs) and the vEPC of the LTE system. All interfaces of this VLAN are configured as IP interfaces forming an IP network. This network constitutes the interface S1-U of the LTE system and small cells can be reached through this network to control them.
-
One VLAN that connects all RSUs with the MEC to be able to access and control them. All interfaces of this VLAN are configured as IP interfaces forming an IP network.
2.1.3 The vehicle’s on-board unit
-
A Hardware Security Module (HSM): One of the possible attack vectors to V2X infrastructure is to steal sensitive data or cryptographic keys from a vehicle’s OBU. To counter this attack, trustworthy, unforgeable, and non-copyable identities must be established. This is achieved by integrating an HSM into the OBU that serves as a secure storage for private key data, security certificates, and even generic sensitive data. The HSM is responsible for enabling secure communication of V2X applications by protecting the integrity of exchanged safety messages and managing authentication of V2X participants. The HSM, among others, also manages private key generation, derivation, and deletion in case of attack.
-
Security applications: This element contains all software functions to interact with the PKI and manage the registration and authorization procedures, as well as to obtain the pseudonymous ATs and store them into the HSM according to [12]. Additionally, this element also controls in real-time the CRL, so as to account for unreliable message reception.
-
ITS Applications: This element represents any ITS application running on the vehicle. The CARAMEL testbed foresees applications for sending and receiving CAMs and DENMs.
-
A V2X Communication Protocol Architecture: This element contains the software package that enables the OBU (and the MEC) to generate Facilities layer messages encapsulated on the BTP and the GN protocol. CARAMEL will use the open source framework Vanetza [11], properly extended to perform all security and privacy related functionalities.
-
Network Radio interfaces (IEEE 802.11p and LTE-Uu): Radio interfaces are used in CARAMEL for three purposes: (1) for connecting OBUs to the PKI servers to obtain the pseudonymous ATs before being able to transmit ITS messages and for real-time management of certificates (for this purpose, LTE-Uu is used); (2) to notify the management center or the MEC when the anti-hacking device detects that the vehicle is under attack (also for this purpose, LTE-Uu is used); (3) for data transmission between vehicles. To reduce latency during ITS message transmission, these communications preferably use direct V2V connections through the 802.11p interface. Nevertheless, as previously mentioned, in the first stages of ITS adoption, not all vehicles will be equipped with this technology. Some cars will only have the LTE-Uu interface and forwarding/message broadcasting will be performed with the assistance of the MEC.
-
In-Vehicle Network (IVN) Interfaces: The OBU is equipped with several communication interfaces that enable networking capabilities within the vehicle. This is part of the IVN interface and includes: a 1000Base-T1 Ethernet interface, which defines Gigabit Ethernet over a single twisted pair for automotive and industrial applications; a WiFi interface, compliant with IEEE802.11a/b/g/n/ac, 5G MIMO and Real Simultaneous Dual Band (RSDB); a Controller Area Network (CAN) bus interface.
-
Hardware Secure Elements: These elements are included to protect the OBU from tamper attacks, through box opening detection, active hardware protection of susceptible signals, and environmental sensors to prevent fault injection attacks. When the Hardware Secure Elements detect an attack, there is a tamper response and the system is enabled to protect sensible data. Logical methods are also used to prevent firmware manipulation. In order to comply with these security functional requirements, several tamper protection layers have been applied on the different OBU interfaces (Fig. 4) based on hardware actuations. More insight about this is given in Sect. 3.2.3.
-
An Anti-hacking Device: This is a physical controller that is integrated into the car and acts as an attack detection device extending the security capabilities of the OBU. The device passively listens to the internal buses (e.g., CAN or Automotive Ethernet) and extracts the raw sensor data, which is used by pre-trained ML algorithms to detect anomalies that might point out malicious attacks. The device receives ITS messages sent by the OBU and performs the functions for, e.g., countering potential location spoofing attacks or renewing used ATs to minimize the possibility of being tracked by attackers. For further details see Sect. 2.1.4 below.
2.1.4 The anti-hacking device
-
HW Interfaces: The anti-hacking device is connected to the in-car systems via appropriate interfaces used in the automotive industry, including the CAN bus, Automotive Ethernet connections, and also Wireless connectivity (Wi-Fi and Bluetooth). For integration into development and simulation frameworks standard Ethernet is also supported.
-
ML hardware: Since the anti-hacking device is based on the Coral Dev Board, the Tensorflow Lite Processing Unit (TPU) is the hardware element utilized to support ML. The integrated Edge TPU processor performs 4 trillion operations (tera-operations) per second (TOPS), using 0.5 watts for each TOPS. For a development and simulation configuration the Coral USB Accelerator is also supported.
-
HSM: Similarly to the OBU, to provide security-related functions, the anti-hacking device hardware also integrates an HSM. Indeed, a Telekom Card Operating System (TCOS) embedded smartcard module is integrated in the anti-hacking device, supporting secure storage of private keys and different cryptographic operations, e.g., authentication of the anti-hacking device for remote provisioning and updates or for central event reporting and alerting.
-
NXP Freescale i.MX8 processor: The adopted processor supports security functions such as High-Assurance Boot (HAB) and Cryptographic Accelerator and Assurance Module.
-
Yocto-based firmware layer (a Linux embedded meta distribution): The firmware for the i.MX8 SOC is created using the Yocto environment which is an industry-standard toolkit to create custom embedded firmware images in a reproducible manner. The anti-hacking device build process supports signed bootloaders and a Linux kernel in order to prevent tampering with the anti-hacking device software and configuration.
-
Docker-based application-specific containers: Out-of-the box, crypto containers supporting the security functions of the anti-hacking device are present. ML workloads are implemented as containers that have access to the underlying ML hardware as well as to the crypto functions exported by the crypto containers.
-
The anti-hacking device could also act as a secure run-time environment for other functions as needed by the different use cases.
3 Overview of CARAMEL connectivity attacks
3.1 Scenario 1: Attack on the V2X message transmission
3.2 Scenario 2: Tamper attack to a vehicle’s OBU
3.2.1 OBU interfaces
-
ITS interface: The application processor sends messages through the V2X transceiver to establish communication with other ITS stations and the ITS infrastructure.
-
HSM interface: Communication channel with HSM for cryptographic and key management functions.
-
IVN interface: Communication over In-Vehicle Network towards the vehicle through the Printed Circuit Board (PCB) connector.
-
GNSS interface: Positioning data communication interface to the main processor.
3.2.2 Threats for tamper attack of the vehicle’s OBU
-
Tamper attack on the ITS interface: The attacker uses tampered V2X messages to cause safety hazardous situations.
-
Software tamper attack on the ITS interface: The attacker uses malicious software on the V2X front end to track ITS stations or to send rogue messages on the ITS network.
-
Clock fault injection attack on the ITS interface: The attacker manipulates the front end’s clock to generate malfunctions or break security in the ITS interface.
-
Software tamper attack on the main processor: The attacker uses malicious software on the main processor to cause safety hazardous situations.
-
Clock fault injection attack on the main processor: The attacker manipulates the main processor’s clock to generate malfunctions or break security.
-
Voltage fault injection: The attacker manipulates the power supply to generate malfunctions or break security.
-
Temperature fault injection: The attacker manipulates the environmental temperature to generate malfunctions or break security.
-
Eavesdropping main processor data signals: The attacker eavesdrops on the communication of the main processor memory to obtain confidential information (encryption keys, secure certificates, etc).
-
Tamper attack on the HSM interface: The attacker uses tampered HSM messages to cause safety hazardous situations and to get privileges.
-
Tamper attack on the GNSS interface: The attacker injects malicious geolocation data to cause safety hazardous situations.
-
Software tamper attack on the GNSS interface: The attacker uses malicious software on the GNSS to cause safety hazardous situations.
3.2.3 Anti-tamper hardware techniques implemented on OBU
-
Environmental sensors: Voltage, temperature and clock sensors added to protect against fault injection attacks.
-
Opening enclosure detection: Protects against the physical access to the OBU internal environment.
-
Coating sensible circuits: Encapsulation of some circuitry with ruggerized epoxy compounds to avoid physical access. If the attacker tries to remove the encapsulation, some components will be broken and an alarm is triggered.
-
Mutual authentication: protects against lifting of critical OBU internal devices and using them in an unintended environment by requiring mutual authentication at start-up.
-
Data encryption: Ensures integrity and confidentiality of exchanged messages between devices in the OBU.
-
Secure boot: Uses a combination of hardware and software together with a public key to protect the system from executing unauthorized programs.
-
Trusted execution environment: Is a secure area on the main processor. Software running in this environment is protected against attacks from potentially compromised platform software.
Countermeasure layers | Threats | |||||||
---|---|---|---|---|---|---|---|---|
Enclosure manipulation | ITS interface tamper attacks | V2X HSM interface tamper attacks | GNSS interface tamper attacks | Eavesdropping data signals | Clock fault injection | Temperature fault injection | Voltage fault injection | |
Environmental sensors | \(\bullet\) | \(\bullet\) | \(\bullet\) | |||||
Opening enclosure detection | \(\bullet\) | \(\bullet\) | \(\bullet\) | \(\bullet\) | \(\bullet\) | |||
Coating covering sensible circuits, with self-destructive components to avoid coating removal | \(\bullet\) | |||||||
Active wire-mesh protection for critical elements and signals | \(\bullet\) | \(\bullet\) | \(\bullet\) | \(\bullet\) | ||||
Mutual authentication | \(\bullet\) | \(\bullet\) | ||||||
Data encryption | \(\bullet\) | \(\bullet\) | ||||||
Secure boot | \(\bullet\) | \(\bullet\) | ||||||
Application processor trusted execution environment | \(\bullet\) | \(\bullet\) |
3.3 Scenario 3: GPS spoofing attack
4 Results and discussion: the CARAMEL system in action
4.1 The GPS spoofing attack detection
4.1.1 In-vehicle GPS location integrity check
4.1.2 Collaborative GPS location integrity check
4.2 Certificate management: a candidate countermeasure
-
The OBU detects a misbehavior in the GPS receiver, i.e., it detects a GPS spoofing attack by means of the proposed in-vehicle detection solution. An alarm is then sent to the MEC, which takes the decision to revoke its authorization certificate.
-
A process running in the MEC that implements the proposed collaborative detection solutions identifies a GPS location spoofing and takes the decision to revoke the authorization certificate of the vehicle under attack.