5 ms·

> Or am I missing something important? We absolutely want to remotely control cars at some point, how else will you send a self-driving taxi to a customers or

by belval 5y ago

> Or am I missing something important? We absolutely want to remotely control cars at some point, how else will you send a self-driving taxi to a customers or "ask" a car to comeback to the garage for a recall on the underlying hardware or for general maintenance?

danuker 5y ago
That can be implemented by the vehicle initiating a connection and asking "where should I go now?". But any connection poses vulnerability - for example, security certificates to be sure you're talking to the right person become obsolete over time as processing power gets cheaper, and an update can fail and brick the car.
- nobody9999 5y ago
  >But any connection poses vulnerability - for example, security certificates to be sure you're talking to the right person become obsolete over time as processing power gets cheaper, and an update can fail and brick the car. Exactly. Which is why vehicles (like most other IOT devices) shouldn't connect to the Internet at all. Please define a scenario where internet access would be required (i.e., not replaceable with other, less vulnerable communications mechanisms) for a self-driving vehicle. I can't think of any.
jedberg 5y ago
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
nobody9999 5y ago
>We absolutely want to remotely control cars at some point, how else will you send a self-driving taxi to a customers or "ask" a car to comeback to the garage for a recall on the underlying hardware or for general maintenance? Who is this "we"? You might, but I don't. That's a disaster waiting to happen. What's more, under the circumstances you describe, there's no reason such vehicles need to be internet accessible. Or have we forgotten that communication doesn't require the internet?
- Dylan16807 5y ago
  > > remotely control cars > What's more, under the circumstances you describe, there's no reason such vehicles need to be internet accessible. Or have we forgotten that communication doesn't require the internet? What kind of remote communication these days doesn't require the internet? Text messages? Special short range base stations with 56k modems? Satellite phone?
  - nobody9999 5y ago
    >What kind of remote communication these days doesn't require the internet? Pretty much any low power radio application (CB/HAM radio, key fobs, walkie talkies, POTS lines and dozens more), or higher power (although those require FCC licenses) don't require the internet. Besides, I'm referring to the software that makes the vehicle operate. That software/system should never be exposed to remote sources. Otherwise, you're pretty much begging to be locked in your car and taken on a joyride which ends with you rolling off a cliff.
    - Dylan16807 5y ago
      Your car is not going to have a Ham license, and I already mentioned POTS; do you really think having your car sit close to a special phone-based communication station is the answer? Key fobs and walkie talkies and LoRaWAN do not have enough range to fully enable this kind of use. > Otherwise, you're pretty much begging to be locked in your car and taken on a joyride which ends with you rolling off a cliff. If hacks while driving are your concern, you could have the car isolate from the internet when the key is inside it and/or someone hits a stop button. If hacks before driving are your concern, I don't think any of your suggested radio applications are safe either. And I don't really see why half of them are better than an internet connection in the first place.

by belval 5y ago

danuker 5y ago

That can be implemented by the vehicle initiating a connection and asking "where should I go now?". But any connection poses vulnerability - for example, security certificates to be sure you're talking to the right person become obsolete over time as processing power gets cheaper, and an update can fail and brick the car.

nobody9999 5y ago
>But any connection poses vulnerability - for example, security certificates to be sure you're talking to the right person become obsolete over time as processing power gets cheaper, and an update can fail and brick the car. Exactly. Which is why vehicles (like most other IOT devices) shouldn't connect to the Internet at all. Please define a scenario where internet access would be required (i.e., not replaceable with other, less vulnerable communications mechanisms) for a self-driving vehicle. I can't think of any.

jedberg 5y ago

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

nobody9999 5y ago

>We absolutely want to remotely control cars at some point, how else will you send a self-driving taxi to a customers or "ask" a car to comeback to the garage for a recall on the underlying hardware or for general maintenance? Who is this "we"? You might, but I don't. That's a disaster waiting to happen. What's more, under the circumstances you describe, there's no reason such vehicles need to be internet accessible. Or have we forgotten that communication doesn't require the internet?

Dylan16807 5y ago
> > remotely control cars > What's more, under the circumstances you describe, there's no reason such vehicles need to be internet accessible. Or have we forgotten that communication doesn't require the internet? What kind of remote communication these days doesn't require the internet? Text messages? Special short range base stations with 56k modems? Satellite phone?
- nobody9999 5y ago
  >What kind of remote communication these days doesn't require the internet? Pretty much any low power radio application (CB/HAM radio, key fobs, walkie talkies, POTS lines and dozens more), or higher power (although those require FCC licenses) don't require the internet. Besides, I'm referring to the software that makes the vehicle operate. That software/system should never be exposed to remote sources. Otherwise, you're pretty much begging to be locked in your car and taken on a joyride which ends with you rolling off a cliff.
  - Dylan16807 5y ago
    Your car is not going to have a Ham license, and I already mentioned POTS; do you really think having your car sit close to a special phone-based communication station is the answer? Key fobs and walkie talkies and LoRaWAN do not have enough range to fully enable this kind of use. > Otherwise, you're pretty much begging to be locked in your car and taken on a joyride which ends with you rolling off a cliff. If hacks while driving are your concern, you could have the car isolate from the internet when the key is inside it and/or someone hits a stop button. If hacks before driving are your concern, I don't think any of your suggested radio applications are safe either. And I don't really see why half of them are better than an internet connection in the first place.