Re:Pwn2Own Vancouver 2019: Tesla, VMWare, Microsoft, and more
by moftz on Thursday January 17, 2019 @02:58PM
(#18934022)
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.
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?