Tesla's are designed to receive software updates on a regular basis using a cellular connection, whereas with every other car brand you'll need to bring the car to a certified dealership to have a mechanic (!= computer engineer) install the new firmware.

So: a nasty bug in a 'regular' car means the manufacturer must consider a recall of all affected cars, where Tesla will simply push an update to all cars in the field. This also means that Tesla can run the update before the vuln is disclosed.

Musk said he regards Tesla as a software company, their software just so happens to have a car attached to it. I highly doubt other car manufacturers see it that way, they probably see the software development as an expense.

Maybe, but that sounds optimistic. What if the hack turns that off? What if the hack bricks a piece of hardware? Should remote updates be trusted if the car's been infected with malware?

> Musk said he regards Tesla as a software company, their software just so happens to have a car attached to it. I highly doubt other car manufacturers see it that way, they probably see the software development as an expense.

Software companies write most of the software bugs, so that doesn't make me feel any better...

Your statement is untrue about OTA updates. Tesla might have been the first to do it in 2012 but most companies are doing it already or plan to.

GM and Ford plan it for 2020 and Mercedes and BMW have announced it in the past year. The Japanese makers are usually more reluctant to adopt new tech.

There are much cheaper APs than a Unifi AC Pro.

Which tells me you probably could've saved money in some other ways as well.

This is not true. Some FiatChrysler vehicles have OTA updates. And if FCA is doing it, others are, too.

when a system is breached with methods that don't leave a signature a clean reinstall from scratch is the only option. once one to all your system are potentially breached by remote exploits it's recall time.

local exploit that require access to the car innards could potentially be patched over the air if the method allows the owner to know if the car was breached into. then it'd be update for safe car and recall for breached cars.

[1]https://autoweek.com/article/car-news/your-jeep-cherokee-vul...

You can maybe come up with a version of this that uses a HSM, or simply some part of the firmware that is read-only.

In the threat model I describe, the attacker who controls the car's system can lie to the server about what is on its system. It also has access to anything that's distributed to the car itself (such as a per-car private key!), and presumably it has oracle knowledge in the form of what the server expects the correct hash to be. A compromised car can freely lie about the hashes of anything on its own system as necessary; it can freely sign any attestation with a per-car private key; it can parrot the expected hashes of files distributed to other cars. Even if you sent watermarked files to cars, the compromised car could remember the hashes of those watermarks to parrot them back later.

So, pray tell, where do you imagine the cryptographic signature actually adds value? As in, how can you pick the owner of the private key and the owner of the hashing process such that a near-omnipotent compromised car cannot fool the server?

What prevents an attacker from overriding some validateFile("path","hash") call to always return 0 ?

You also never store the hash, so once a user has gained access to the car it's impossible to get the right hash (as you would've had to modify the firmware/filesystem/etc in some way to gain entry).

You would also need to include a timestamp/car serial in the hash so that you couldn't reuse an old hash from before your entry (that you had MITM'd) or use a hash from a different car that still had its integrity.