Security concerns have been raised about Wi-Fi updates to car software following Ford Motors' announcement on Tuesday this week that it will use Microsoft to provide cloud-based network services for remote wireless software updates to its cars, including display screen graphics and voice-recognition software.
Ford owners will be asked to give permission for their car to continually monitor the Microsoft Azure cloud service where any software updates will be hosted on Microsoft's global network of data centres. When the vehicle is connected to a Wi-Fi network, any new software would install itself automatically, and notify the driver the next time they start their car – avoiding the need for recall cars for patching or updating.
Ford's cloud connectivity starts its roll-out this year with its Sync3 multimedia system, while electric-car maker Tesla Motors Inc's Model S has already embedded wireless connection to perform updates, and General Motors Co intends to launch 30 plus vehicles with built-in LTE 4G broadband connections.
Talking to SCMagazineUK.com, Tony Dyhouse, director at the government-led Trustworthy Software Initiative (TSI) commented: “These developments make the car a network node and browser with internet connectivity so we are transferring all the existing online threats to the owners of a smart vehicle.”
The TSI was set up to address the wider problem of software often not being initially designed with security in mind, thus incurring the additional vulnerabilities, update and patching costs and effort entailed in retro-fitting. But this problem is exacerbated with the Internet of Things (IoT) where systems and devices not originally intended to be connected, nor seen as under threat, are now just that – with vehicles in particular having their security and safety potentially undermined.
For cars, the priority was always safety, not security, and while that may have begun to change following the hacking and theft of BMW's keyless vehicles, the prioritising of innovation and speed to market means that testing time for security is being overlooked says Dyhouse. And cars are especially vulnerable because the Control Access Networks (CAN) used means all nodes talk to one-another in a ‘peer-to-peer' way – all connected with little isolation of say brakes from entertainment. CarShark demos have already shown how the dashboard can be shut down and all doors locked causing a moving vehicle to crash.
Remote updates offer huge savings on cost and reputation compared to recalls, so manufacturers are pushing ahead. However, a remote means of changing the software on a car presents an opportunity for a hacker says Dyhouse, adding that it could also encourage sloppy behaviour in software coding as it reduces the cost of carrying out an update.
Another emerging issue is people changing the management chip that came with the car. The chips achieve a balance of horsepower, emissions, and safety factors, whereas a new chip may just focus on power – even to the extent that it now exceeds the capacity of the braking system – and it's not known who has written it for what purpose. And other apps from unknown entities are also being made available globally from app stores, again with the potential to do harm.
Such unauthorised chips and apps would invalidate any warranty from the manufacturer. Though here the law is already starting to lag behind change on the ground in terms of responsibilities of the driver versus those of the manufacturer/coder. And that's before fleets of driverless cars take to the road, run from a control centre whose GPS connection could be blocked, or whose software may have to choose the lesser of two evils in unexpected scenarios – eg whether to prioritise a single passenger or multiple pedestrians.
While conceding that even the best software will not be 100 percent secure, Dyhouse adds that the security industry does already have solutions, knowledge and best practice that the auto industry ought to learn from. BMW's response to a Man in the Middle attack (MiTM) was to embed HTTPS encryption – but this highlighted the fact that such best practice had not been considered earlier.
“What's needed is intrusion detection and monitoring capabilities,” says Dyhouse, suggesting that unbroken authentication is a start – not passwords, but perhaps use of Checksum, whereby any changes will register and an alert be given to the driver. Similarly, an intrusion detection system (IDS) on the network is seen as straightforward given the closed nature of the CAN, again flashing a warning. However, it is not clear what action should be taken when such warnings flash up. And of course, developers should be given appropriate testing time rather than using the public as beta testers. HTTPS needs to be implemented. Work needs to be done with MISRA (the Motor Industry Software Reliability Association) and the PAS754 framework implemented, along with the TSI focus on safety, reliability, availability, resilience and security for all software.
There is also the issue of data ownership, which has barely begun in this realm, from the location of the vehicle, to the likely tiredness or hunger of its occupant, to the derived data sets of similar drivers – and who has the right to own and sell this data.