Hacker News Reader

Comment by joezydeco | Hacker News Reader

Seems like Tesla could fix security holes remotely. Chrysler could not.

assuming it's a remote exploit then you can't trust the update code that's on board, because that could be compromised and just pretending to run the update.

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.

My car, the Grand Cherokee, can get OTA updates. Not sure if the 2014 Cherokee is able to get them. According to autoweek Cherokee owners could download the update themselves and install from a USB stick.[1] Chrysler issued the TSB to try and force people to come in and get an update who couldn’t or wouldn’t do it themselves.

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

The ability to remotely patch a car seems like a double edged sword. Hasn't Tesla already had at least one example of introducing a bug through OTA updates?

I consider that an issue with the software quality, not with the update mechanism. The bug would still have been introduced even if it required a trip to the dealer to plug in a programming cable.

At least, when it's updated by a dealer and a cable, you know when to expect changed behavior. With OTA, the vehicle's driving behavior could (and has) quite literally change overnight.

I'm pretty sure you still need manual confirmation in the car, and it shows you patch notes when you next get in, so you should have reason to expect changed behavior.

The only problem I can see with the OTA updates is that they remove the need for physical access to the car. This is very convenient and allows for fast updates but it does slightly decrease the security and lowers the bar for successfully hacking the car remotely.

That same bug could have been introduced whether or not the update was OTA. At least they could fix it OTA as well...!

Assuming the attacker doesn't devise some malware that silently blocks subsequent OTA updates.

All it would take would be for Tesla to send out a verification check to get software signatures from all running that have phoned home anytime in the last 6 months. If something doesn't match, Tesla calls you up and tells you your car is fucked and to come get it serviced. If your car doesn't phone home yet still is pulling data from the internet, Tesla would know and suspect it's compromised.

And what prevents the compromised Tesla system from lying about its software signatures? When you have a compromised system, literally everything that system tells you or is capable of telling you is suspect.

You can't fake cryptographic signatures.

How so? Telsa would most likely communicate with an API on the car and not directly running file hashes remotely.

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

Because you could ask for a checksum of the firmware and if it doesn't return the right hash you know something isn't right.

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.

Cryptography is not a magic bullet. The assertion of a signature is that "Private Key Bar says Hash(plaintext) = Foo." But who is the private key; who is actually computing the hash of the plaintext? Note that practically every cryptographic system in existence has been broken at one time or another, and most of those breaks are not in the mathematical primitives of cryptography but in the wider ecosystem of the procedures of how these primitives are combined into a full system.

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?

It's super hard to ensure something with 100% confidence, but it doesn't mean there shouldn't be at least some basic integrity checks.

The private key would need to be stored in some read only media like a smartcard or a PROM chip. A boot environment that can only be externally programmed would need to be the first thing to start up and check the integrity of the filesystem. It would hash it, timestamp it, and send it to an HSM to sign it with a secured private key, then transmit the signed hash out and hand off the rest of the startup to the main OS. Tesla gets the hash, verifies the signature so they can check whether or not the OS is compromised. Because the bootloader chip sits outside the control of the main OS, you can ensure that as long as someone doesn't rip out the ECU, the filesystem check is legit. Another step would be to allow the HSM to cycle in new keys using a KEK. The HSM would have a master private key that is only used for KEK updates and a lesser private key that it uses for signing hashes.

Well, you could fill all of the unused storage space on the system with random noise specified by you, then ask the system to regurgitate that noise to you (or more practically, tell you a function calculated from some set of bytes you specify). That would require that an attacker physically alter the hardware to defeat your verification process.

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.

Not at all a Tech/software/hardware guy, but based on my experience with OTA firmware updates with my Netgear router, I'd be cautious.

Teslas get regular OTA updates. They sometimes fail, but they've been remotely patching their vehicles for years.

Reply on news.ycombinator.com