Many cities have installed systems that let emergency vehicles control traffic lights via infrared remote controls, thereby getting to the scene of an emergency more quickly. This is good.
Yesterday’s Detroit News, in a story by Jodi Upton, reports on the availability of remote controls that allow ordinary citizens to control the same traffic lights. Now traffic engineers worry that selfish people will use the remotes to disrupt the flow of traffic.
As Eric Rescorla notes, this could have been avoided by using cryptography in the design of the original system. Instead, we’re likely to see a crackdown on the distribution of the remote controls, and the predictable black market in the banned devices.
This seems like a classic example of the harm caused by deploying a technology without considering how it might be abused. It would be interesting to know why this happened. Did the vendor not stop to think about the potential for abuse? Did they think that nobody would ever figure out how to abuse the system? Did they fail to realize that anti-abuse technologies were available? I wish I knew.
Poor Traffic Light Engineering Practices
The Detroit News has a story on special infrared transmitters that can can broadcast a signal to receivers on traffic lights, turning the light from red to green (Gadget may wreak traffic havoc). The purpose of the devices is to…
DOes Anyone know where I can get a remote that will change the lights?
Or perhaps the manufacturer of the ‘official’ traffic light changer also manufactures the ‘unofficial’ version.
It wouldn’t be the first time in recorded history that such a problem/solution pair has occurred. Examples include selling hangover cures and ‘get sober fast’ supplies in bars as well as the US selling arms to both sides during the Iraq/Iran (and most probably every other) war.
I don’t think this is a straightforward system to secure at all; just saying “crypto” isn’t the answer. To be secure against replay attacks, I think you really need either a timestamp or a three-way handshake (or preferably both.) The latter requires a transmitter in the light controls: extra expense, decreased reliability, etc. Timestamping might actually be feasible since presumably traffic lights have clocks anyway, but it’s not at all obvious that the benefits of securing the system actually outweigh the costs here.
The dual problem to unauthorized access is denial-of-service— potentially far more life-threatening. So there is a case for restricting the use of devices which broadcast on the relevant frequencies anyway (pace spread-spectrum advocates). Crypto can’t protect against jamming the airwaves.
I’d rather have a system which is not-really-secure against unauthorized use and has low incidence of misuse (due to restricted availability and social norms) than one which is pretty secure but fails more often (due to added complexity.) Maybe I can’t get either, but I value getting to the hospital quickly much more than I value hitting all the traffic lights green. 🙂
Certainly the designers should take non-authorized use into account and make sure the system cannot be manipulated over extended periods of time. The system has to recognize that defaulting to the old behavior is better than obeying an endless stream of commands, authorized or not. That’s a layer of robustness which seems necessary whether the actual signals are authenticated or not.
The Opticom system (which is, AFAIK, what the vast majority of cities with emergency-vehicle overrides use) has been around for something like 25 years (and spoofing devices have been around for at least 15), so I don’t think it’s reasonable to expect them to have incorporated PKC from the beginning. More recent versions seem to have the ability to send some data from the vehicle to the light controller, including some simple authentication. But remember that this kind of hardware has a replacement cycle of several decades, so don’t expect every city to have spiffy PKC-based traffic light synchronization any time soon.
Emergency response folks are understandably a bit conservative, and I’d guess that the higher risk of failure from a complex encoded authentication protocol outweighs the minor effects of a handful of yahoos with spoofing devices. If the number of yahoos increases, that could change. But it would be easy enough for a city to pass a law making it illegal for unauthorized persons to trigger the opticom receivers, and I expect that that’s what would happen.
You can find a lot of information about these by googling for “opticom”, various traffic control keywords, “chrome box” (the phreaker name for a box which spoofs opticom transmissions), etc. Many cities or their fire/emergency departments have web pages up describing what this Opticom thing is that they spent a bunch of money on, or why their vehicles have strobe lights on ’em, or a FAQ page explaining what the white confirmation beacon means, etc., etc.
One thing that I think is interesting is that although this technology was originally designed for emergency-vehicle response it’s been expanded a bit to include things like giving transit vehicles priority to pull out of bus stops and so forth.
Exactly. One way to make such a system more resistant hacking is to have the transmissions be coded (i.e. you have a specified pulse code, lmike your garage door opener). That would qualify as “programmable”, but of course such systems are very vulnerable to replay attack. Like Ed, I’d be a lot happier to hear that they were using crypto and knew how to get it right.
Older receivers are still vulnerable, and it’s “unclear how vulnerable” the newer receivers are. Calling the new devices “programmable” doesn’t inspire as much confidence as, for instance, saying that they use crypto.
Read further down the article, beware journo-hype:
Troy traffic engineer John Abraham said newer receivers are
programmable, making it unclear how vulnerable the city is to MIRTs.
“We had a scare a few years ago when we realized there was a
potential for the technology to get out, so we upgraded,” Abraham said.