Difference between revisions of "Projects:2020s1-1290 Car Hacking"

From Projects
Jump to: navigation, search
(Conclusion)
 
(145 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Student Researchers:<br>
+
== Abstract ==
 +
Numerous systems that utilise a shared bus architecture have not been designed with security in mind. Consequently, security is either an afterthought or the system has minimal security features implemented. Three examples of shared bus protocols that were created with minimal security considerations are CAN, FlexRay, and USB. The CAN bus and the FlexRay bus are both vehicle bus standards that enable ECUs (Electronic Control Units) to communicate with each other. Meanwhile, USB is a standard that allows connection, communication, and power supply between computers, peripherals, and other computers. The security of systems that implement these protocols can be critical for the protection of sensitive data, property, and the safety of individuals.
 +
 
 +
== Introduction ==
 +
The aim of this project is to investigate shared bus protocols and their vulnerabilities to nondestructive attacks. In order to achieve this, the project focuses on aspects of three different protocols:
 +
# How the security of CAN-based communication in vehicles could be improved (Adam Watts),
 +
# Investigating the interoperability and mapping of the CAN and FlexRay protocols (Alexis Jennings),
 +
 
 +
It has been shown in several previous studies that CAN-based communication is vulnerable to numerous attacks, thus improving the security of CAN-based communication is vital to improving the security of the vehicle. Similarly, a FlexRay-CAN gateway will be developed to allow an investigation into the vulnerabilities of connecting several bus systems that follow different protocols together. Although none of these protocols prioritise security, severe consequences could occur if attacked by an adversary.
 +
 
 +
== Background and Relevant Work==
 +
 
 +
=== CAN ===
 +
[[File:CAN_Transmission.gif|0.4px|frame|right| Simplified CAN bus transmission]]
 +
CAN (Controller Area Network) is the most widely used communication protocol in vehicles. The protocol allows the ECUs in vehicles to communicate. ECUs control many of the functions of the vehicle including the engine, transmission, and traction control. An ECU can send messages to another ECU over the CAN bus. The data sent over the CAN bus is broadcast to all other ECUs in the network, and the ECU can determine whether it would like to process the message or ignore it. Benefits of the CAN protocol include it is robust, efficient, fully centralised, simple and low cost.
 +
 
 +
Security vulnerabilities have been found on CAN systems. The CAN protocol has been found to have a lack of authentication [1], [2]. Therefore, the CAN protocol cannot distinguish between a malicious ECU and a legitimate ECU. Furthermore, as all nodes in the CAN network listen to the bus for messages intended for them, an unauthorised node can join the network and send and receive messages. This makes it possible to perform replay attacks and transmit spoofed messages.
 +
 
 +
Another vulnerability of the CAN protocol is that ECUs communicate using unencrypted messages [1], [2]. Encrypting CAN messages would result in overhead for a communication protocol that was designed to be light and fast. Furthermore, ECUs have limited computational power to implement robust cryptographic algorithms. This, therefore, makes it possible to sniff the messages sent over the bus by attaching hardware to the bus.
 +
 
 +
The CAN protocol has also been found to be vulnerable to denial of service attacks [1], [2]. The CAN protocol uses message arbitration when more than one CAN node wants to send data. This means transmitting nodes will monitor the bus. If a higher priority message is being transmitted on the bus, the CAN node will stop transmitting and will listen to the bus. Thus, a denial of service attack can be performed by continuously sending high priority messages over the CAN bus. This prevents other nodes from sending messages.
 +
 
 +
=== FlexRay ===
 +
 
 +
To continue to improve safety, increase performance, reduce environmental impact and increase the comfort of the vehicle, the reliability and volume of data must increase between the vehicle’s ECUs. The FlexRay protocol can meet these requirements. FlexRay can also meet the error tolerance and time-determinism requirements for X-by-wire systems. X-by-wire refers to the replacement of mechanical systems with electronic ones. These replaced systems can include braking and steering.
 +
 
 +
FlexRay provides some protection for data availability and data integrity, although this was intended for safety rather than security [3]. The FlexRay protocol does not provide assurance of confidentiality, authentication or freshness of data. It was found that reading and spoofing can be performed on any ECU in the FlexRay network.
 +
 
 +
It has also been found that a full denial of service is possible in the dynamic segment, while a partial denial of service can be performed in the static segment. Spoofing could not be performed in the static segment as message collision could cause an unpredictable bus state. However, spoofing can be used in the dynamic segment, although message collisions could still occur. 
 +
 
 +
There has also been an attack on a FlexRay network using a CAN network. This attack involved creating a gateway that would convert CAN packets to FlexRay. This attack then sent CAN messages to override specific bits on a FlexRay bus to control the EPS (Electric Power Steering) [4].
 +
 
 +
== Project Aims and Method ==
 +
 
 +
===Aim 1===
 +
[[File:Flex-board.png|0.4px|frame|right| A FlexRay Evaluation Board]]
 +
One stream of the project aims to investigate the interoperability and mapping of the CAN and FlexRay protocols. This includes studying the use of FlexRay-CAN gateways in vehicles. Gateways allow FlexRay messages to be converted to CAN messages before being sent across a CAN network and vice versa. This research will allow the vulnerabilities of FlexRay-CAN gateways to be investigated.
 +
<br><br>
 +
'''Approach:''' Initially, a simulation was designed to investigate the timings of a FlexRay network connected to a CAN network. A FlexRay Evaluation Board that is capable of acting as a FlexRay-CAN gateway was also studied.
 +
<br><br><br><br>
 +
 
 +
===Aim 2===
 +
Improving the security of CAN-based communication in existing vehicles. Extensive research into the vulnerabilities of CAN bus has shown that not only is it possible to inject attacks, but there are multiple attack vectors. This past research has indicated a need for defensive tools and techniques that could be used to mitigate these attacks and improve the security of the inherently insecure communication method.
 +
 
 +
'''Approach:'''  Identify CAN bus shortcomings, consider flow control, TDMA, and “allowed paths” to design and implement a retrofittable solution to critical CAN systems.
 +
 
 +
<br>
 +
 
 +
== Outcomes ==
 +
===Interoperability and mapping of the CAN and FlexRay protocol===
 +
 
 +
From the simulation and investigation of a FlexRay-CAN gateway, it was found that the vulnerabilities of one network can be used to exploit the other. Gateways are designed to be fast and lightweight, with messages sent across the gateway with minimal latency. Furthermore, the simulation can be used for planning future network designs and the gateway design can be used to further investigate CAN and FlexRay vulnerabilities and vulnerabilities that result from connecting CAN and FlexRay networks.
 +
 
 +
{| class="wikitable"
 +
|-
 +
| [[File:CAN-FlexRay.gif |thumb| center| 500px| A simulation demonstrating CAN packets being converted to FlexRay packets and sent over a FlexRay network]]  || [[File:FlexRay-CAN.gif|thumb| center| 500px | A simulation demonstrating FlexRay packets being converted to CAN packets and sent over a CAN network]]
 +
|}
 +
 
 +
===CANflex===
 +
[[File: TRANSITION.gif |thumb| right| 500px|Transforming a CAN network to CANflex]]
 +
“CANflex” is a tunnelling type protocol that sits on top of existing CAN bus hardware. Inspired by elements of FlexRay that improved network security, it has the ability to tunnel CAN messages onto a scheduled timing format. The significance of this is that it improves transmission speed, reduces the effectiveness of DOS attacks, and allows for packet control that does not exist in CAN.
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
[[File:CANflex Transmission.gif|thumb| left| 800px|Simplified transmission of frames on CANflex]]
 +
When implemented, a CANflex gateway is attached to every ECU on the CAN network. Functionally,  CAN frames from an ECU are converted to CANflex frames, buffered and transmitted according to a TDMA schedule, converted back to CAN for the receiving ECU(s). Flow control ensures only “allowed” paths are permitted to traverse past the CANflex gateways.
 +
 
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
 
 +
CANflex takes transmission strategies from both CAN and FlexRay and enforces flow control of "allowed paths" to improve CAN bus throughput and resilience to attacks while still utilising the existing CAN bus wiring loops. The end result is that previous successful CAN bus attacks do not hold up once CANflex tunnelling protocol is applied (depicted in the animations below).
 +
{| class="wikitable"
 +
|-
 +
! MOTS attack on CAN 'vs' CANflex networks
 +
! MOTS attack on CAN 'vs' CANflex networks
 +
|-
 +
| [[File:CAN_MOTS.gif |thumb| center| 500px| MOTS attack on CAN bus network]]
 +
| [[File:CAN_MITM.gif |thumb| center| 500px| MITM attack on CAN bus network]]
 +
|-
 +
| [[File:CANflex_MOTS.gif|thumb| center| 500px| MOTS attack with CANflex tunnelling]]
 +
| [[File:CANflex_MITM.gif|thumb| center| 500px| MITM attack with CANflex tunnelling]]
 +
|}
 +
The end result is that the attacks are not allowed to transmit outside of a valid time slot or to paths that are restricted and will simply be blocked at the gateway. Thus, in the past where a bad actor may have been able to gain control of  car, now, at best can cause transmission losses through packet collisions on the network.
 +
<br>
 +
 
 +
== Conclusion and Future Work==
 +
 
 +
=== Conclusion ===
 +
 
 +
FlexRay is often used to communicate between safety-critical aspects of vehicles including steering and brakes. With the increasing number of autonomous systems and the interconnectivity of networks in vehicles increasing, the security of FlexRay becomes even more important.
 +
 
 +
With widespread reliance on CAN, rolling out effective vulnerability countermeasures to all existing instances is infeasible. However, vulnerabilities and practices explored in our research are worth taking into consideration in the design of critical systems that may need to depend on these technologies.
 +
 
 +
=== Future Work ===
 +
'''FlexRay-CAN Gateways'''<br>
 +
The work on FlexRay-CAN gateways aims to be used to further investigate the vulnerabilities of these networks and the implications of connecting them together.
 +
<br>
 +
<br>
 +
'''CANflex'''<br>
 +
A possible extension to the CANflex tunnelling that has been developed is to improve its learning ability. In real-world applications vehicles are consistently modified or undergo maintenance. This causes a problem for any intrusion detection system that is unaware of this change and could cause the CANflex controller to deliberately block friendly CAN frames. Development of a "''learning mode''" where the car is in a trusted environment would allow the CANflex controller to learn through observing packet flow. In its development, careful attention should be paid to ensure that this does not expose CANflex to additional vulnerabilities.
 +
<br>
 +
<br>
 +
 
 +
== References ==
 +
 
 +
[1]    Robert Buttigieg, Mario Farrugia, and Clyde Meli. “Security Issues in ControllerArea Networks in Automobiles”. In: (Nov. 2017).
 +
 
 +
[2]    Omid Avatefipour and Hafiz Malik.State-of-the-Art Survey on In-Vehicle NetworkCommunication (CAN-Bus) Security and Vulnerabilities. 2018. arXiv:1802.01725[cs.CR].
 +
 
 +
[3]    Dennis Oka et al. “A First Simulation of Attacks in the Automotive Network CommunicationsProtocol FlexRay”. In: Jan. 2008, pp. 84–91.doi:10.1007/978-3-540-88181-0_11.
 +
 
 +
[4]    Melching W. Hogan G. Derks R.Hacking an Audi: performing a man-in-the-middleattack on FlexRay. Available:https://medium.com/@comma_ai/hacking-an - audi - performing - a - man - in - the - middle - attack - on - flexray -2710b1d29f3f. 2020. [Online] [Accessed: Feb. 27, 2020].
 +
 
 +
== Project Team ==
 +
 
 +
===== Student Researchers =====
 +
 
 
Alexis Jennings<br>
 
Alexis Jennings<br>
 
Robert Dumitru<br>
 
Robert Dumitru<br>
 
Adam Watts<br>
 
Adam Watts<br>
  
Supervisors:<br>
+
===== Supervisors =====
 +
 
 
Dr. Matthew Sorell<br>
 
Dr. Matthew Sorell<br>
 +
Dr. Richard Matthews<br>
 
Yuval Yarom <br>
 
Yuval Yarom <br>
 
Aaron Frishling (DSTG)<br>
 
Aaron Frishling (DSTG)<br>
 
Bradley Cooney (DSTG)<br>
 
Bradley Cooney (DSTG)<br>
 
Daniel Coscia (DSTG)
 
Daniel Coscia (DSTG)

Latest revision as of 15:37, 19 March 2021

Abstract

Numerous systems that utilise a shared bus architecture have not been designed with security in mind. Consequently, security is either an afterthought or the system has minimal security features implemented. Three examples of shared bus protocols that were created with minimal security considerations are CAN, FlexRay, and USB. The CAN bus and the FlexRay bus are both vehicle bus standards that enable ECUs (Electronic Control Units) to communicate with each other. Meanwhile, USB is a standard that allows connection, communication, and power supply between computers, peripherals, and other computers. The security of systems that implement these protocols can be critical for the protection of sensitive data, property, and the safety of individuals.

Introduction

The aim of this project is to investigate shared bus protocols and their vulnerabilities to nondestructive attacks. In order to achieve this, the project focuses on aspects of three different protocols:

  1. How the security of CAN-based communication in vehicles could be improved (Adam Watts),
  2. Investigating the interoperability and mapping of the CAN and FlexRay protocols (Alexis Jennings),

It has been shown in several previous studies that CAN-based communication is vulnerable to numerous attacks, thus improving the security of CAN-based communication is vital to improving the security of the vehicle. Similarly, a FlexRay-CAN gateway will be developed to allow an investigation into the vulnerabilities of connecting several bus systems that follow different protocols together. Although none of these protocols prioritise security, severe consequences could occur if attacked by an adversary.

Background and Relevant Work

CAN

Simplified CAN bus transmission

CAN (Controller Area Network) is the most widely used communication protocol in vehicles. The protocol allows the ECUs in vehicles to communicate. ECUs control many of the functions of the vehicle including the engine, transmission, and traction control. An ECU can send messages to another ECU over the CAN bus. The data sent over the CAN bus is broadcast to all other ECUs in the network, and the ECU can determine whether it would like to process the message or ignore it. Benefits of the CAN protocol include it is robust, efficient, fully centralised, simple and low cost.

Security vulnerabilities have been found on CAN systems. The CAN protocol has been found to have a lack of authentication [1], [2]. Therefore, the CAN protocol cannot distinguish between a malicious ECU and a legitimate ECU. Furthermore, as all nodes in the CAN network listen to the bus for messages intended for them, an unauthorised node can join the network and send and receive messages. This makes it possible to perform replay attacks and transmit spoofed messages.

Another vulnerability of the CAN protocol is that ECUs communicate using unencrypted messages [1], [2]. Encrypting CAN messages would result in overhead for a communication protocol that was designed to be light and fast. Furthermore, ECUs have limited computational power to implement robust cryptographic algorithms. This, therefore, makes it possible to sniff the messages sent over the bus by attaching hardware to the bus.

The CAN protocol has also been found to be vulnerable to denial of service attacks [1], [2]. The CAN protocol uses message arbitration when more than one CAN node wants to send data. This means transmitting nodes will monitor the bus. If a higher priority message is being transmitted on the bus, the CAN node will stop transmitting and will listen to the bus. Thus, a denial of service attack can be performed by continuously sending high priority messages over the CAN bus. This prevents other nodes from sending messages.

FlexRay

To continue to improve safety, increase performance, reduce environmental impact and increase the comfort of the vehicle, the reliability and volume of data must increase between the vehicle’s ECUs. The FlexRay protocol can meet these requirements. FlexRay can also meet the error tolerance and time-determinism requirements for X-by-wire systems. X-by-wire refers to the replacement of mechanical systems with electronic ones. These replaced systems can include braking and steering.

FlexRay provides some protection for data availability and data integrity, although this was intended for safety rather than security [3]. The FlexRay protocol does not provide assurance of confidentiality, authentication or freshness of data. It was found that reading and spoofing can be performed on any ECU in the FlexRay network.

It has also been found that a full denial of service is possible in the dynamic segment, while a partial denial of service can be performed in the static segment. Spoofing could not be performed in the static segment as message collision could cause an unpredictable bus state. However, spoofing can be used in the dynamic segment, although message collisions could still occur.

There has also been an attack on a FlexRay network using a CAN network. This attack involved creating a gateway that would convert CAN packets to FlexRay. This attack then sent CAN messages to override specific bits on a FlexRay bus to control the EPS (Electric Power Steering) [4].

Project Aims and Method

Aim 1

A FlexRay Evaluation Board

One stream of the project aims to investigate the interoperability and mapping of the CAN and FlexRay protocols. This includes studying the use of FlexRay-CAN gateways in vehicles. Gateways allow FlexRay messages to be converted to CAN messages before being sent across a CAN network and vice versa. This research will allow the vulnerabilities of FlexRay-CAN gateways to be investigated.

Approach: Initially, a simulation was designed to investigate the timings of a FlexRay network connected to a CAN network. A FlexRay Evaluation Board that is capable of acting as a FlexRay-CAN gateway was also studied.



Aim 2

Improving the security of CAN-based communication in existing vehicles. Extensive research into the vulnerabilities of CAN bus has shown that not only is it possible to inject attacks, but there are multiple attack vectors. This past research has indicated a need for defensive tools and techniques that could be used to mitigate these attacks and improve the security of the inherently insecure communication method.

Approach: Identify CAN bus shortcomings, consider flow control, TDMA, and “allowed paths” to design and implement a retrofittable solution to critical CAN systems.


Outcomes

Interoperability and mapping of the CAN and FlexRay protocol

From the simulation and investigation of a FlexRay-CAN gateway, it was found that the vulnerabilities of one network can be used to exploit the other. Gateways are designed to be fast and lightweight, with messages sent across the gateway with minimal latency. Furthermore, the simulation can be used for planning future network designs and the gateway design can be used to further investigate CAN and FlexRay vulnerabilities and vulnerabilities that result from connecting CAN and FlexRay networks.

A simulation demonstrating CAN packets being converted to FlexRay packets and sent over a FlexRay network
A simulation demonstrating FlexRay packets being converted to CAN packets and sent over a CAN network

CANflex

Transforming a CAN network to CANflex

“CANflex” is a tunnelling type protocol that sits on top of existing CAN bus hardware. Inspired by elements of FlexRay that improved network security, it has the ability to tunnel CAN messages onto a scheduled timing format. The significance of this is that it improves transmission speed, reduces the effectiveness of DOS attacks, and allows for packet control that does not exist in CAN.







Simplified transmission of frames on CANflex

When implemented, a CANflex gateway is attached to every ECU on the CAN network. Functionally, CAN frames from an ECU are converted to CANflex frames, buffered and transmitted according to a TDMA schedule, converted back to CAN for the receiving ECU(s). Flow control ensures only “allowed” paths are permitted to traverse past the CANflex gateways.








CANflex takes transmission strategies from both CAN and FlexRay and enforces flow control of "allowed paths" to improve CAN bus throughput and resilience to attacks while still utilising the existing CAN bus wiring loops. The end result is that previous successful CAN bus attacks do not hold up once CANflex tunnelling protocol is applied (depicted in the animations below).

MOTS attack on CAN 'vs' CANflex networks MOTS attack on CAN 'vs' CANflex networks
MOTS attack on CAN bus network
MITM attack on CAN bus network
MOTS attack with CANflex tunnelling
MITM attack with CANflex tunnelling

The end result is that the attacks are not allowed to transmit outside of a valid time slot or to paths that are restricted and will simply be blocked at the gateway. Thus, in the past where a bad actor may have been able to gain control of car, now, at best can cause transmission losses through packet collisions on the network.

Conclusion and Future Work

Conclusion

FlexRay is often used to communicate between safety-critical aspects of vehicles including steering and brakes. With the increasing number of autonomous systems and the interconnectivity of networks in vehicles increasing, the security of FlexRay becomes even more important.

With widespread reliance on CAN, rolling out effective vulnerability countermeasures to all existing instances is infeasible. However, vulnerabilities and practices explored in our research are worth taking into consideration in the design of critical systems that may need to depend on these technologies.

Future Work

FlexRay-CAN Gateways
The work on FlexRay-CAN gateways aims to be used to further investigate the vulnerabilities of these networks and the implications of connecting them together.

CANflex
A possible extension to the CANflex tunnelling that has been developed is to improve its learning ability. In real-world applications vehicles are consistently modified or undergo maintenance. This causes a problem for any intrusion detection system that is unaware of this change and could cause the CANflex controller to deliberately block friendly CAN frames. Development of a "learning mode" where the car is in a trusted environment would allow the CANflex controller to learn through observing packet flow. In its development, careful attention should be paid to ensure that this does not expose CANflex to additional vulnerabilities.

References

[1] Robert Buttigieg, Mario Farrugia, and Clyde Meli. “Security Issues in ControllerArea Networks in Automobiles”. In: (Nov. 2017).

[2] Omid Avatefipour and Hafiz Malik.State-of-the-Art Survey on In-Vehicle NetworkCommunication (CAN-Bus) Security and Vulnerabilities. 2018. arXiv:1802.01725[cs.CR].

[3] Dennis Oka et al. “A First Simulation of Attacks in the Automotive Network CommunicationsProtocol FlexRay”. In: Jan. 2008, pp. 84–91.doi:10.1007/978-3-540-88181-0_11.

[4] Melching W. Hogan G. Derks R.Hacking an Audi: performing a man-in-the-middleattack on FlexRay. Available:https://medium.com/@comma_ai/hacking-an - audi - performing - a - man - in - the - middle - attack - on - flexray -2710b1d29f3f. 2020. [Online] [Accessed: Feb. 27, 2020].

Project Team

Student Researchers

Alexis Jennings
Robert Dumitru
Adam Watts

Supervisors

Dr. Matthew Sorell
Dr. Richard Matthews
Yuval Yarom
Aaron Frishling (DSTG)
Bradley Cooney (DSTG)
Daniel Coscia (DSTG)