3 ms·
The V2V stuff is interesting, but from what I've seen, it is definitely a 1st gen design, especially with regards to security. Not that I know how I'd fix it.
by ansible 11y ago
The V2V stuff is interesting, but from what I've seen, it is definitely a 1st gen design, especially with regards to security. Not that I know how I'd fix it.
What I'm talking about is this. Suppose I've got this nice 802.11p transceiver system in my car. My car uses it to talk to the infrastructure and other vehicles to get warnings and such. The HUD in my car can then give me a pop-up when there's an accident ahead, and all the usual stuff being talked about.
Now, for completely unrelated reasons, I wrecked my car (texting while driving, sheesh, when will I ever learn?). The car is sold to a junkyard. The 802.11p module survived the crash with no damage, though.
Evil hacker then goes to the junkyard and buys the module, and maybe the ECU as well if necessary. He can then do fun stuff like continuously broadcasting things like my car has had an accident, or has engaged emergency braking, which will cause warnings to pop up for other drivers, or with autonomous vehicles, they may act directly on that information.
Its still a valid BRAND NAME manufacturer's 802.11p unit. But without a way to revoke the "security certificate" for my specific vehicle, the rest of the network will still trust it. As far as I know, the trust is on a per-manufacturer or per-model level, and not per-device.
But of course, doing per-device drastically increases memory requirements, which will cost a lot of money, and make the system slower too.
Like I said, I don't know how I'd fix it...
- zeveb 11y agoThis is a problem with antimatter CRLs (so called because the CRL is like antimatter: it wanders around, annihilating a cert only if it encounters it). Rather than sending out revocation lists, agents should be forced to renew their certificates regularly. Store a small trusted base in-memory (perhaps one trust root per nation-state), and then use certificate chains to authenticate. Fortunately, there's already a precedent for a credential one needs to renew from the government in order to operate a vehicle: a license plate. Heck, one could avoid the whole problem by doing what the government could have one do with one's license plates in case of accident: turn 'em in.
- ansible 11y agoThe architecture you propose sounds better that what's currently being implemented. Now the problem is going to be educating the public that they are directly responsible for their "license transponder" too, and that they need to be really careful with it in the case of an accident or at other times when the car is out of their possession.
- zeveb 11y ago> The architecture you propose sounds better that what's currently being implemented. Thanks. It's not actually my idea—it dates back to the mid-1990s, and the work done on RFCs 2692 & 2693. Our industry's failure to seriously adopt their framework is one of the more damning indictments of our maturity which I can think of right now.
- lfowles 11y agoOne idea: On crash, the module could lock down to broadcasting a timestamped accident warning (no replay attacks) and would need someone with authorized access to reset it. Doesn't really solve a hacker getting a non-crashed-but-otherwise-junked vehicle though :) Edit: There's no reason to assume a hacker won't get access to the kit to reset a module as well. Guess we need to put a UseYourBestJudgement module in line with it for your driverless car ;D