Given that it seems like a foregone conclusion that these things are going to end up with some WAN interface [0], pure ROM is out of the question. The best we could probably do would be to assert that the flash could only be updated through a local debug port, with protections against eg full RCE allowing remote re-flashing.
Given physical access, it's trivially easy to sabotage a car - the new problem here is having it done remotely. More important would be some kind of auditing so that a local debug device could be assured of reading out the exact code image, knowing how many times it had been flashed and ideally checksums, and being sure that a reflash reset the system completely.
(btw, loved "shit early, shit often")
[0] I mean, I'd personally rather they not. But it seems like a foregone conclusion of trends/marketing/sloppy design/implementation shortcuts/can't stop the signal.
In my case, for example, I have a 2014 and a 2015 car which are both more than a year overdue for a software updates. One is related to the braking system; the other to a problem where if you stomp on the gas in an emergency (like to avoid a crash), the car stalls.
The problem is that the dealers in my area don't have the capacity or the will to do software updates. One dealership only has maintenance hours between 9am and 4pm Monday through Thursday, and the ONE guy who is allowed to do software updates is only in on Saturdays from 9-noon occasionally.
The other dealership doesn't take appointments at all. It's first-come, first-served, 8am-5pm Monday through Saturday. I stopped going there because even at 7am, there's a huge line of people waiting for service. The final straw was when I sat there from 7am until 3pm for a very simple non-engine part swap that was covered under warranty.
The next nearest dealer is 138 miles away.
tl;dr version: OTA updates are good because there are places where you can't get a software update done at the dealer in a reasonable time.
Unfortunately there’s no quick fix about the current cars having the “guided” self driving principle.
(randomly, as in "where do you want to go today? meh, nevermind.")
I'm not sure I'd go that far. OTA "automatic update" probably not a good idea. Downloadable/flashable at the dealer OK, no need to go as far as swapping out ROM modules.
Following avionics software engineering standards should be absolutely required. Entertainment/nav systems that require network access should be 100% air-gapped from the vehicle control systems.
ehhh, cars shouldn't be communicating with cars they can't see. but i'd like to them to communicate over free space optical, aimed at the level of other vehicles. brake lights could be modulated to contain current braking force, and reason for braking. turn signals could contain the destination lane. head/tail lights the current speed, and target speed.
Seriously, "let's have everyone jump on the bandwagon all at once, and we shall be redeemed by $TECHNOLOGY_DU_JOUR" is a very brave proposal.
How cars were designed 30 years ago is completely irrelevant, because that's not how all or most new self-driving cars will be designed. They will be designed so that the software can be changed on the go.
You seem to be out of touch what happens today. Car2Car or Car2Infrastructure is about as aircraft to aircraft communication is used in TCAS. It is about what car (object) is at which position, so that collision may be detected as early as possible to prevent them.
Also next generation cars will have their maintenance modes locked down as far as possible. OBDII will be closed down as far as possible. All those dongles, which are hip right now, will be rendered useless. But of course the tuning scene has still a lot of incentives like in the past to thwart all this and to reverse engineer. It will be a cat-and-rat game like it always was.
http://www.templetons.com/brad/robocars/v2vdata.html
Pithily, "It can never be that useful because if it's being really useful, something is very wrong."
As for surveillance related to V2V communications, I fail to see how it meaningfully adds any surveillance over just monitoring the other electronic emissions from the car like those that emanate from the media centre or even the phones of those within the car.
This doesn’t follow.
> including improvements related to security.
This should not, under any circumstances, be a reasonable justification. Cars should not have any external attack surface, period. The ECU and any other critical electronics should not be networked at all. Unfortunately, that ship has long since sailed.
It should be possible for cars to be updated, but it should require physical access, and any mandatory update (e.g. due to a safety failure) should result in the manufacturer incurring heavy costs, e.g. you have to give every owner $1000. We have to internalize the externalities of shitty software, especially in stupendously dangerous machines like cars.
> This should not, under any circumstances, be a reasonable justification.
That presupposes that humans cannot make mistakes, which they do. Whether it is hackable software defined radio, or just plain oversights.
The levels of abstraction that programmers deal with do not allow for the necessary security you propose.
> Cars should not have any external attack surface, period.
What you advocate for is a car with no ports, no radios, and a perfectly secure component manufacturing chain. It isn't doable. There is a reason the ship sailed.
They're expensive, annoying, etc. But they're safe (or safer, at least), and if you screw up badly enough that a safety-critical system needs an update, they're necessary.
I don't think anyone is arguing that the infotainment system should be disconnected from the world, but the core driving systems (steering, brakes, transmission, etc) should be air-gapped and inaccessible without physical access to the interior of the car. Also, that access could (and maybe should) be disabled when the car's engine is running, preventing an attacker from plugging in a wireless device and then subverting the system with the car in motion.
In any case, I agree that it's unlikely unless there's a severe disaster related to OTA updates, but it's still the best solution from a security and safety perspective.
I don't think so, just that the radio and other non-critical components mustn't be connected to the critical components. Essentially the radio becomes like any other portable device, that just happens to be physically installed in the dashboard.
If it is discovered that any model of car is vulnerable to this, it needs to be recalled and scrapped.
> The levels of abstraction that programmers deal with do not allow for the necessary security you propose
This is true of the kind of shit pumped out by low-quality commodity hardware and consumer-focused software companies. Anything controlling millions of multi-ton missiles should ideally be formally verified top to bottom. Exceeding NASA vehicle code standards are the sort of thing that would be appropriate here. However, just the plain old standards we apply to the embedded code in ECUs plus full hardware isolation (i.e. no “start from your phone” bullshit) would be sufficient.
> What you advocate for is a car with no ports, no radios,
No radio attached in any way to the critical hardware is sufficient. The goal here is to defend against bulk remote attacks (the kind that are actually dangerous in a noticeable economic sense) and bugs, not evil maids.
For example, cars being able to broadcast their immediate path and do some dynamic route mapping based on which lanes and areas will be in use by the time it arrives; being able to agree with nearby vehicles about routes that are partially colocated so they could join together bumper to bumper for that leg and realize fuel efficiencies (I have no idea if that would actually be useful but I’m brainstorming possibilities); being able to negotiate a car parking space in advance of arrival...
Is it that there actually aren’t many applications where inter-car communication is useful, or is it more that the benefits of communications like these are outweighed by risks to security, or am I missing important pieces of the puzzle?
Better yet, the software should be uploaded to an intermediate agency, that is responsible for the testing of cars (could be part of the US Department of Transportation for example). Only this agency can (after sufficient testing) upload the software to the actual cars.
The big problem is allowing firmware updates.
Many years ago, I knew some of the people involved with the Ford Electronic Engine Control IV, the "EEC IV", used in 1980s Fords. This used a custom CPU, an Intel 8061, which was an Intel 8051 with some extra timer features. The program was etched onto the CPU silicon. There is no way to change that program without replacing the whole unit. There's an external ROM with some tables, different for each engine model, but it's a true ROM, not something that can be rewritten. If you want to replace it, it takes a wrench.
The level of paranoia and testing that went into that program was very high. Any bug meant bringing back hundreds of thousands of Fords in a recall. That didn't happen, and there are still many EEC IV vehicles running today, 30 years later. That's what it was like in the days of hardcore embedded programming.
I'd argue that safety critical vehicle software should not be downloadable. If a fix is needed, the vehicle has to go back to the dealer for a new memory module. This would discourage "shit early, shit often" software development, and encourage manufacturers to keep the safety critical systems, like ABS, totally disconnected from the entertainment system.
Autonomous vehicles should not communicate with each other. Waymo's cars don't. Most of the schemes for "car to car communication" are motivated by marketing or surveillance, not driving. Aircraft systems don't communicate with the ground much, and when they do, the uploaded data is very simple. (It's common in commercial aircraft to hardware disable maintenance functions unless the "weight on wheels" switch is on, indicating the plane is on the ground and parked.)