5 ms·

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 mo

by moftz 8y ago

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.

jcranmer 8y ago
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.
- fastball 8y ago
  You can't fake cryptographic signatures.
  - NotHereNotThere 8y ago
    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 ?
    - fastball 8y ago
      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.
  - jcranmer 8y ago
    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?
    - dcbadacd 8y ago
      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.
    - moftz 8y ago
      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.
- dmurray 8y ago
  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.

by moftz 8y ago

jcranmer 8y ago

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.

fastball 8y ago
You can't fake cryptographic signatures.
- NotHereNotThere 8y ago
  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 ?
  - fastball 8y ago
    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.
- jcranmer 8y ago
  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?
  - dcbadacd 8y ago
    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.
  - moftz 8y ago
    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.
dmurray 8y ago
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.