Security Experts Warn Government Over Driverless Car Plans

The UK government reaffirmed its commitment to developing driverless and electric vehicles in the Queen’s Speech yesterday, but security experts cautioned that protections must be engineered into systems to ensure privacy and deflect hacking attempts.

In a brief allusion to the government’s current projects, the Queen had the following:

“My ministers will ensure the United Kingdom is at the forefront of technology for new forms of transport, including autonomous and electric vehicles.”

In fact, the Tories have already trailed such developments over recent months.

In February they announced £20m of funding for eight new projects in the sector which will see driverless cars trialed on the streets of Bristol, Coventry and Milton Keynes, and Greenwich and on designated tracks at Heathrow airport.

These include the The UK Connected Intelligent Transport Environment (UKCITE) project which involves Jaguar Land Rover, Siemens, Vodafone Group and others. Driverless pods will also be trialed in Greenwich and Milton Keynes.

“Our cars of the future will be equipped with the technologies that will make getting from A to B safer, faster, and cleaner,” business secretary, Sajid Javid said at the time. “They will alert drivers of accidents ahead and be able to receive information from their surroundings about hazards, increasing the safety of drivers, passengers and pedestrians.”

However, there remain concerns over security and privacy – particulary in terms of the amount of data potentially collected by such vehicles.

“An extraordinary amount of digital infrastructure is needed to store the data generated by the vehicles. Indeed, Tesla’s fleet of cars records 1.5 million miles worth of data every single day,” argued Nimble Storage director, Paul Scarrott.

“With this already mammoth amount of data set to increase rapidly as driverless cars become more popular, it’s important that greater consideration is given to how and where this data will be stored and shared, especially with the GDPR and Privacy Shield on the horizon.”

Others warned that autonomous or even connected cars could theoretically be hacked and remotely controlled, as was demonstrated in a well-publicized Black Hat presentation last year from Miller and Valasek.

The pair showed how attackers could move laterally inside the embedded computing systems of a 2014 Jeep Cherokee until they get to the CAN bus which controls the major steering, braking and other functions of the vehicle.

By reverse engineering firmware code, they could then modify, reflash and reboot it to execute arbitrary code – effectively giving the car instructions to override the driver.

Gordon Morrison, director of government relations at Intel Security, alluded to the research.

“It is crucial that in its pursuit of innovation, the government doesn’t neglect the security essentials which will guarantee not only the success of these new technologies, but also the safety of its users,” he argued.

“The government must ensure that, as part of its innovative work with the automotive industry, cybersecurity remains a top priority.”

Paul Farrington, senior solution architect at Veracode, warned that the security of driverless cars will come down to code.

“Findings from a recent IDC report indicated that there could be a lag of up to three years before car security systems are protected from hackers,” he claimed. “With over 200 million lines of code in today’s connected car, not to mention smartphone apps linked to the car, we must ensure they are developed with security at the heart of the strategy, rather than as an afterthought.”

One organization which is working towards improving the security of embedded computing systems such as those in connected cars is the non-profit prpl Foundation.

It recently released a guidance document for the industry in which it proposed a solution to the problems highlighted by Miller and Valasek, involving SoC virtualization to achieve security-by-separation at a chip level, and a “root of trust” anchored in the silicon, ensuring firmware can’t be overwritten by a third party.

from http://ift.tt/1TpdhO6