Before you get too complacent riding hands-free in your fancy new self-driving car you may want to check out these videos.
The first one shows folks that took apart a Tesla Model S and installed ways to get access to the low-level firmware of the system. What they found out has already been reported and fixed by Tesla but it shows some lax security practices:
The presenters in that one openly admit their hack required physical access to the vehicle.
This next video doesn’t require that:
Not concerned enough?
Here’s one where researchers show how to mess with the camera, lidar, and radar sensors you see installed on every self-driving car:
The US Department of Transportation just released a set of new guidelines for manufacture of self-driving cars.
The rules include a list of 15-point Safety Assessment objectives for Highly Automated Vehicles (HAVs) which are broad voluntary guidelines for vehicle makers to follow. These include:
Operational Design Domain: How and where the HAV is supposed to function and operate;
Object and Event Detection and Response: Perception and response functionality of the HAV system;
Fall Back (Minimal Risk Condition): Response and robustness of the HAV upon system failure;
Validation Methods: Testing, validation, and verification of an HAV system;
Registration and Certification: Registration and certification to NHTSA of an HAV system;
Data Recording and Sharing: HAV system data recording for information sharing, knowledge building and for crash reconstruction purposes;
Post-Crash Behavior: Process for how an HAV should perform after a crash and how automation functions can be restored;
Privacy: Privacy considerations and protections for users;
System Safety: Engineering safety practices to support reasonable system safety;
Vehicle Cybersecurity: Approaches to guard against vehicle hacking risks;
Human Machine Interface: Approaches for communicating information to the driver, occupant and other road users;
Crashworthiness: Protection of occupants in crash situations;
Consumer Education and Training: Education and training requirements for users of HAVs;
Ethical Considerations: How vehicles are programmed to address conflict dilemmas on the road; and
Federal, State and Local Laws: How vehicles are programmed to comply with all applicable traffic laws.
These are pretty well-considered especially given that in the race to full-automation you don’t see many of the non-technical issues that have high societal cost discussed so much. Things like Ethical Considerations which I think will be a major topic of discussion once these vehicles move out of labs and onto the streets.
A couple of issues not explicitly addressed in this list which will need further thinking has to do with the question of liability when things don’t work as anticipated, of how insurance will work (related to liability and who is at fault), and what happens to all those people whose livelihood depends on the current architecture of vehicles and transportation.
Another important part of the document is the DoT asking for authority to regulate the Post-sale Regulation of Software Changes. This means DoT wants to have a say in managing the process of Over-The-Air (OTA) firmware updates. This is a gray area which will need clarity as time goes on.
The FDA which has authority over medical equipment currently doesn’t have much by way of guidelines for OTA firmware updates to medical devices. The two agencies might want to coordinate and come up with a common set of rules because the problems are similar where consumer safety is concerned.
The document also hints at new technology that needs to be developed in the future:
Variable Test Procedures
Additional Recordkeeping and Reporting
Enhanced Data Collection
If you’re looking for product ideas in the brave new world of self-driving you might want to consider these as domains where the government will be requiring automakers to track and provide data.
Start putting those thinking caps on!
Update: we now have the actual detailed report directly from the DoT. The above link was to the summary press-release describing the report.
Wireless key remotes are turning into open vectors when it comes to automotive security.
A year ago Samy Kamkar showed how a Software Defined Radio (like the HackRF One) can be used to observe, record, and replay a radio signal to help unlock a car. Similar methods have been shown to work against a variety of remotes (including garage door openers).
It sounds like it’s now VW’s turn to be targeted by researchers who not only unlocked the doors but also bypassed the RFID immobilizer transponders to allow them to turn cars on. What made the story newsworthy was not only that VW went to court to prevent the researchers from releasing their report, but that the researchers have come back with even more vulnerabilities to present:
One of the attacks would allow resourceful thieves to wirelessly unlock practically every vehicle the Volkswagen group has sold for the last two decades, including makes like Audi and Škoda. The second attack affects millions more vehicles, including Alfa Romeo, Citroen, Fiat, Ford, Mitsubishi, Nissan, Opel, and Peugeot.
The problem is that a lot of remotes are based on decade-old technology and the cost of replacing what’s already out there at this point is prohibitive.
The whole Uber/self-driving movement is a bit of a head-scratcher Their primary business model is to match riders with drivers and collect a transaction fee for doing so. It’s not clear where human drivers will fit into the equation if Uber starts transitioning toward self-driving cars.
Arm Holdings, having dominated the mobile world, has bought embedded vision company Apical to make sure it stays relevant in the connected device space. This purchase will allow it to go deeper into Automated/Augmented Driving applications.
However, competitors like NXP have already moved on to Radar Technology targeted at similar use-cases.