4 ms·

Have it poll once a minute and ask for instructions with a display in the car that says "instructed to go to X, accept?" and then have it auto accept after anot

Have it poll once a minute and ask for instructions with a display in the car that says "instructed to go to X, accept?" and then have it auto accept after another minute. Sure that means maybe waiting two minutes for the car to move, but that's not a huge deal, especially if you know that happens and request it two minutes in advance, but it gives anyone in the car the chance to cancel the request if it's invalid.

iamthirsty 5y ago
What if you're asleep and the car is in the drive-way? How would you be able to accept/decline in 60 seconds?
- jedberg 5y ago
  Make it beep loudly for 60 seconds? Add a function that puts the car into auto-deny mode that you can turn on when you sleep (or whenever you're in the car). There are many ways to solve this problem. The point is that the car won't just take remote instructions but will gather them and allow the occupants the chance to override them.
shadowgovt 5y ago
Replacing accept-incoming-connections with polling just changes the threat story from "An outside attacker can compromise the machine" to "An outside attacker can compromise the machine every sixty seconds."
- jedberg 5y ago
  Not really, because the server where the request is pulled from would have to be compromised, and it's a lot easier to secure a single remote server than every individual car. It's also a lot easier to monitor a single server for intrusions. Sure, that single server becomes a juicy target, but that's where the defense in depth comes in, where the car still doesn't execute the command until the user accepts it.
  - TillE 5y ago
    This is a weird, awkward solution to a problem which is far better solved cryptographically (eg, by paired SSL certs).
    - nobody9999 5y ago
      >This is a weird, awkward solution to a problem which is far better solved cryptographically (eg, by paired SSL certs). Sure, client/server certificates are great. But as soon as there's a BGP hiccup/attack, a fire at the relevant data center, a moron with a backhoe, among other eventualities, you're screwed. Autonomous vehicles (as well as those with drivers) need to be, as the name says, autonomous. Not dependent on some online resource. I'll say it again: Vehicles should not be dependent/accessible/updateable over the Internet. Full stop.
      - shadowgovt 5y ago
        Then how will they know about changes to road conditions? They could know about it the way humans do: get stuck in traffic or stuck at a road closure and just burn time waiting for the issue to correct itself. But wireless radio communications allows us to do so much better.
Communitivity 5y ago
Something controls the software that would ask for instructions, and that could be hacked. I'd also suggest a default of auto-reject after a minute, not auto-accept. When people think about attack surfaces in devices they often think about the things making repeated connections out. The thing is, every piece of reachable mutable code in the device is an attack surface, not just the software making connections. You may have heard of ATM car collectors that attach to real ATMs, or people that have hacked an ATM to collect cards. Your smart car connects to a number of systems throughout its life: your dealer's diagnostics, every time you charge, every time you play music through the bluetooth connection on your phone. Each one of these is a potential attack vector. Let's say one of these things is using JAVA, and somehow does not have an updated log4j [1]. Now that thing can be used to compromise other subsystems of your car. And these attack vectors do not have the antivirus and other protections your desktop computer or laptop do. As bizarre and backward as it sounds, I think the best bet is burned immutable firmware on a physical module that can be easily swapped out by an authorized dealer (or with a key of some sort to allow people to service their own cars). This would reduce the vulnerability quite a bit, though not eliminate it. It also would eliminate over the air firmware updates, which are insane in my opinion. It's kind of how if you want a more secure computer you burn a live CD with a minimal hardened distro of linux, rip out the hard drive, make sure you have a fast CD, and have the computer boot to CD. This is part of what I used to do for a DMZ PC. There's always a risk your firmware will be hacked, but that is harder, and can be checked on startup depending on what you have on the system [2]. [1] https://www.trendmicro.com/en_us/research/21/l/examining-log4j-vulnerabilities-in-connected-cars.html https://www.trendmicro.com/en_us/research/21/l/examining-log... [2] https://crypto.stackexchange.com/questions/59965/tpm-and-remote-attestation https://crypto.stackexchange.com/questions/59965/tpm-and-rem...
- Dylan16807 5y ago
  > I'd also suggest a default of auto-reject after a minute, not auto-accept. You're suggesting that if a self-driving car has a feature to remotely summon it, such a feature should need a passenger inside to click "accept"?
  - salawat 5y ago

iamthirsty 5y ago

What if you're asleep and the car is in the drive-way? How would you be able to accept/decline in 60 seconds?

jedberg 5y ago
Make it beep loudly for 60 seconds? Add a function that puts the car into auto-deny mode that you can turn on when you sleep (or whenever you're in the car). There are many ways to solve this problem. The point is that the car won't just take remote instructions but will gather them and allow the occupants the chance to override them.

shadowgovt 5y ago

Replacing accept-incoming-connections with polling just changes the threat story from "An outside attacker can compromise the machine" to "An outside attacker can compromise the machine every sixty seconds."

jedberg 5y ago
Not really, because the server where the request is pulled from would have to be compromised, and it's a lot easier to secure a single remote server than every individual car. It's also a lot easier to monitor a single server for intrusions. Sure, that single server becomes a juicy target, but that's where the defense in depth comes in, where the car still doesn't execute the command until the user accepts it.
- TillE 5y ago
  This is a weird, awkward solution to a problem which is far better solved cryptographically (eg, by paired SSL certs).
  - nobody9999 5y ago
    >This is a weird, awkward solution to a problem which is far better solved cryptographically (eg, by paired SSL certs). Sure, client/server certificates are great. But as soon as there's a BGP hiccup/attack, a fire at the relevant data center, a moron with a backhoe, among other eventualities, you're screwed. Autonomous vehicles (as well as those with drivers) need to be, as the name says, autonomous. Not dependent on some online resource. I'll say it again: Vehicles should not be dependent/accessible/updateable over the Internet. Full stop.
    - shadowgovt 5y ago
      Then how will they know about changes to road conditions? They could know about it the way humans do: get stuck in traffic or stuck at a road closure and just burn time waiting for the issue to correct itself. But wireless radio communications allows us to do so much better.

Communitivity 5y ago

Something controls the software that would ask for instructions, and that could be hacked. I'd also suggest a default of auto-reject after a minute, not auto-accept. When people think about attack surfaces in devices they often think about the things making repeated connections out. The thing is, every piece of reachable mutable code in the device is an attack surface, not just the software making connections. You may have heard of ATM car collectors that attach to real ATMs, or people that have hacked an ATM to collect cards. Your smart car connects to a number of systems throughout its life: your dealer's diagnostics, every time you charge, every time you play music through the bluetooth connection on your phone. Each one of these is a potential attack vector. Let's say one of these things is using JAVA, and somehow does not have an updated log4j [1]. Now that thing can be used to compromise other subsystems of your car. And these attack vectors do not have the antivirus and other protections your desktop computer or laptop do. As bizarre and backward as it sounds, I think the best bet is burned immutable firmware on a physical module that can be easily swapped out by an authorized dealer (or with a key of some sort to allow people to service their own cars). This would reduce the vulnerability quite a bit, though not eliminate it. It also would eliminate over the air firmware updates, which are insane in my opinion. It's kind of how if you want a more secure computer you burn a live CD with a minimal hardened distro of linux, rip out the hard drive, make sure you have a fast CD, and have the computer boot to CD. This is part of what I used to do for a DMZ PC. There's always a risk your firmware will be hacked, but that is harder, and can be checked on startup depending on what you have on the system [2]. [1] https://www.trendmicro.com/en_us/research/21/l/examining-log4j-vulnerabilities-in-connected-cars.html https://www.trendmicro.com/en_us/research/21/l/examining-log... [2] https://crypto.stackexchange.com/questions/59965/tpm-and-remote-attestation https://crypto.stackexchange.com/questions/59965/tpm-and-rem...

Dylan16807 5y ago
> I'd also suggest a default of auto-reject after a minute, not auto-accept. You're suggesting that if a self-driving car has a feature to remotely summon it, such a feature should need a passenger inside to click "accept"?
- salawat 5y ago