Driverless car security in a safety-critical world
- 作者：Ella Cai
- 发布时间：：2017-05-31
Operating self-driving cars in a single software environment exposes all software to any cyber attack surface. A more sensible solution is to use a hypervisor to host multiple virtual machines on one processor, writes Chris Barlow.
The security of automotive systems goes hand-in-hand with functional safety gas defined in ISO 26262. But cybersecurity presents a different challenge.
New cyber vulnerabilities are being discovered so machines exposed to wireless internet networks must be considered ‘untrusted’.
Lynx figure 1In connected autonomous cars, we need to accommodate wireless signals from other cars and even street furniture in the case of vehicle-to-infrastructure communications.
A malicious wireless signal might be ‘valid’ (traffic lights ahead are green), but might be hazardous in a certain context (lights are actually red). To protect such a system, we need to isolate the safety-critical software from untrusted environments, and control all communications such that functional safety cases can be designed around the detection of ‘valid but unauthorised’ signals.
Locking down communications
Traditional automotive systems comprise of separate ‘boxes’ that communicate using serial communications, typically Controller Area Network (CAN).
CAN was designed to use a bus topology where all broadcast messages are visible to every node on a network. It is then up to the nodes to decide if they need a given message. This has a fundamental vulnerability which was demonstrated by Miller and Valasek’s remote vehicle hack in 2015.
Anyone can read or transmit messages on a CAN bus and, critically, it is very difficult for the receiving nodes to know where the messages came from. A topology where each node has a private point-to-point connection with those it needs to ‘talk’ to would be more secure, however the increase in weight and complexity of the wiring harness would be prohibitive to production.
With a hypervisor, any topology can be implemented between virtualised nodes with minimal impact on the car’s cost. Private channels can be set up through shared memory regions and read/write, read-only or write-only permissions can be enforced.
Communication speeds are no longer limited by the electrical properties of a wiring harness, but can be as fast as a memory access. Authentication and intrusion detection methodologies can be implemented to ensure signals are coming from their intended sources.
The automotive industry does not like to reinvent the wheel every time a new car is built. Software written for one car must be portable to new vehicles so that code does not have to be re-written. The AUTOSAR standard was developed to address this, allowing software modules to be written by different suppliers against a common standard.
The latest addition to the AUTOSAR ecosystem is the AUTOSAR Adaptive Platform (AP). Unlike the AUTOSAR Classic Platform (CP), AP implements a POSIX environment designed to allow new applications to be added to a vehicle on the fly. AUTOSAR AP is also written to accommodate the concept of virtual machines.
However, AUTOSAR AP isn’t designed as a replacement to CP, so it is important that a domain controller is capable of hosting both Adaptive and Classic platforms. This will allow code already written for Classic Platform microcontrollers to run with no modifications and minimal changes to timing behaviour.
Hypervisor choice
There are several ‘embedded hypervisors’ on the market that all claim to do similar things. Many, however, have been developed by stripping down an existing operating system. Device drivers are kept in this trusted codebase and assigned to guests by a hypervisor service. The additional processing overheads associated with running a Real-Time Operating System on top of another OS could potentially increase the variation in system response time, known as ‘jitter’. This would pose challenges when trying to run safety- or timing-critical AUTOSAR software.
The domain controller paradigm closely maps to the Separation Kernel described by John Rushby in 1981. A Separation Kernel “recreates, within a single shared machine, an environment which supports the various components of a system, and provides the communications channels between them, in such a way that individual components of a system cannot distinguish this shared environment from a physically distributed one”.
A Separation Kernel Hypervisor is therefore very well suited for deployment in these Domain Controllers. It implements a very thin trusted codebase which contains no device drivers and instead simply controls device assignment and CPU time given to the VMs allowing them to run almost as if they are on ‘bare metal’.
There is no getting around the fact that timing behaviour will be impacted to some extent, particularly when running multiple VMs on one processor core, but with deterministic CPU scheduling, developers can accurately model what the guests are doing at any given time, even when VMs are sharing a core.
The security of automotive systems goes hand-in-hand with functional safety gas defined in ISO 26262. But cybersecurity presents a different challenge.
New cyber vulnerabilities are being discovered so machines exposed to wireless internet networks must be considered ‘untrusted’.
Lynx figure 1In connected autonomous cars, we need to accommodate wireless signals from other cars and even street furniture in the case of vehicle-to-infrastructure communications.
A malicious wireless signal might be ‘valid’ (traffic lights ahead are green), but might be hazardous in a certain context (lights are actually red). To protect such a system, we need to isolate the safety-critical software from untrusted environments, and control all communications such that functional safety cases can be designed around the detection of ‘valid but unauthorised’ signals.
Locking down communications
Traditional automotive systems comprise of separate ‘boxes’ that communicate using serial communications, typically Controller Area Network (CAN).
CAN was designed to use a bus topology where all broadcast messages are visible to every node on a network. It is then up to the nodes to decide if they need a given message. This has a fundamental vulnerability which was demonstrated by Miller and Valasek’s remote vehicle hack in 2015.
Anyone can read or transmit messages on a CAN bus and, critically, it is very difficult for the receiving nodes to know where the messages came from. A topology where each node has a private point-to-point connection with those it needs to ‘talk’ to would be more secure, however the increase in weight and complexity of the wiring harness would be prohibitive to production.
With a hypervisor, any topology can be implemented between virtualised nodes with minimal impact on the car’s cost. Private channels can be set up through shared memory regions and read/write, read-only or write-only permissions can be enforced.
Communication speeds are no longer limited by the electrical properties of a wiring harness, but can be as fast as a memory access. Authentication and intrusion detection methodologies can be implemented to ensure signals are coming from their intended sources.
The automotive industry does not like to reinvent the wheel every time a new car is built. Software written for one car must be portable to new vehicles so that code does not have to be re-written. The AUTOSAR standard was developed to address this, allowing software modules to be written by different suppliers against a common standard.
The latest addition to the AUTOSAR ecosystem is the AUTOSAR Adaptive Platform (AP). Unlike the AUTOSAR Classic Platform (CP), AP implements a POSIX environment designed to allow new applications to be added to a vehicle on the fly. AUTOSAR AP is also written to accommodate the concept of virtual machines.
However, AUTOSAR AP isn’t designed as a replacement to CP, so it is important that a domain controller is capable of hosting both Adaptive and Classic platforms. This will allow code already written for Classic Platform microcontrollers to run with no modifications and minimal changes to timing behaviour.
Hypervisor choice
There are several ‘embedded hypervisors’ on the market that all claim to do similar things. Many, however, have been developed by stripping down an existing operating system. Device drivers are kept in this trusted codebase and assigned to guests by a hypervisor service. The additional processing overheads associated with running a Real-Time Operating System on top of another OS could potentially increase the variation in system response time, known as ‘jitter’. This would pose challenges when trying to run safety- or timing-critical AUTOSAR software.
The domain controller paradigm closely maps to the Separation Kernel described by John Rushby in 1981. A Separation Kernel “recreates, within a single shared machine, an environment which supports the various components of a system, and provides the communications channels between them, in such a way that individual components of a system cannot distinguish this shared environment from a physically distributed one”.
A Separation Kernel Hypervisor is therefore very well suited for deployment in these Domain Controllers. It implements a very thin trusted codebase which contains no device drivers and instead simply controls device assignment and CPU time given to the VMs allowing them to run almost as if they are on ‘bare metal’.
There is no getting around the fact that timing behaviour will be impacted to some extent, particularly when running multiple VMs on one processor core, but with deterministic CPU scheduling, developers can accurately model what the guests are doing at any given time, even when VMs are sharing a core.
