I remember seeing a talk at RSA a couple of years ago about the plausibility of the "Italian Job" type attack, where they make all the lights green and cause everyone to crash.. they said that sort of thing was impossible because there is a mechanical switch that prevents both lights from being green at the same time.
So at least an attacker couldn't cause those sorts of accidents, even if they could totally mess up the system.
This was true back in the mechanical era when a drum was used for control; you physically could not engage multiple directions as green at the same time. I do not believe this is the case now that control is done with software/firmware.
The controllers may be able to order it but the lights are supposed to be wired so it's impossible. E.g. grounding the green lights thorugh the cross direction green lights so you can't illuminate green in all directions at once. Or something along those lines.
Not foresight. It was a limitation of the hardware at the time. It's also a relic of the past and no longer accurate as modern boards don't possess the same limitation.
>Not foresight. It was a limitation of the hardware at the time.
Nonsense. Even mechanically timed lights can be wired to illuminate any arbitrary set of lamp in either direction. The only difference between then and now is that back then you had to physically move wires, whereas now it's software switched.
Well, yeah. I phrased that poorly. I'm just saying there is very little chance the designers foresaw the possibilities of people hacking into the lights when they were transitioned into computer controlled. I imagine it was done because it reduced the chance of a bug in the hardware creating an ambiguous signal.
Wireless!? On traffic lights that presumably have to be connected to a power source anyway? It seems to me that the cost of running an additional network cable to each light (or even just sending the control through powerline networking) would be negligible, and it would prevent much of the attacks described - physical "hacking" would be required, which is more difficult to do and easier to detect. This seems like yet another case of large increases in complexity (and thus attack area) for little to no benefit, as is all too common in systems these days.
Note that it is entirely possible your power source (often a metered source from a utility) may be distinct from your comms source, if you even have comms in that location at all.
Sometimes emergency vehicles need the ability to affect traffic lights.
I'm pretty sure I've seen this happen once (in NL), at an intersection with a very predictable traffic light sequence (some intersections use sensors, others simply follow a set pattern), an ambulance came by, sirens blaring, and the whole pattern pretty much skipped a "turn".
Another method would be to setup a vehicle or box on the side of the road that emulated an emergency vehicle which instructed the light to change to green in the direction that you wanted it (could also be used to change lights to red if put in the perpendicular direction). http://en.wikipedia.org/wiki/Traffic_signal_preemption
I'm not sure which method is most common. The wikipedia article says that IR, acoustic, visible lights, and GPS can be used to change the lights. It would be fun to experiment with different methods of changing them, but would undoubtedly be illegal.
Apparently it's not illegal federally to use these devices to change lights, it might be legal in some states.
More than anything I'd love to use this to actually improve the way the lights are run downtown in my city. It's insane that they actually use them to make people spend longer in the downtown corp. (when one turns green, the next turns red, there is literally no flow to traffic and would be faster going through a number of stop signs.)
Exactly. If you observe carefully, you'll notice that at night, when there's less traffic/pedestrians, most of those lights turn into green waves for anyone driving at or slightly above the speed limit.
Allowing green waves in a high traffic, high pedestrian downtown area would be lunacy.
It's also not THAT MUCH gas. Cars don't use a ton of gasoline while idling. This page (http://greenactioncentre.ca/living-green-living-well/myth-2-...) asserts that cars use 1/10 to 4/10ths of a liter of gas per 10 minutes of idling. Call it an average of .3 liters, which is 0.08 gallons. If you spend 20 minutes a day (a HUGE amount) at red lights, and then your city doubles the length of all red lights, so now you're spending 40 minutes a day (absurd), that means that each day you spend an additional 0.16 gallons.
So at $4 per gallon, that suggests that your cost (not the city's revenue) for this absurd scenario is $0.66 per day. If the city has a completely ridiculous 10% gasoline tax, that suggests that it's getting $0.07 per resident per day. Or $25 per year.
This may not be the most difficult way for a city to raise $25/resident/year of revenue, but it's certainly in contention for it.
$25 per resident per year is significant, $25M a year in a city of 1M. And how is this 'difficult'? It seems like it's a trivial software modification - certainly not $100,000 worth of work.
I agree that it's a bizarre and horrible way to raise revenue, but your calculations actually make it look quite straightforward to implement.
> And how is this 'difficult'? It seems like it's a trivial software
I co-founded a traffic sensing startup circa 2008. At the time, very few cities had centralized control over their lighting systems (LA mostly did for example, most others did not). In fact, most traffic systems we looked into at the time had very little aggregated control at all. You may see situations were a particular busy street had 'linked' control for a series of 5,6 or 7 block in a row, but even that was fairly rare. Most of the time, each intersection has it's own controller, with minimal if any linkage to the outside world. You can usually find the control boxes, they're the randomly placed conspicuous steel boxes somewhat near the intersection. As for a 'software update', in most cases you were talking about an 8bit 8051 MCU switching some relays. A 'software update' involves someone going to each of these boxes physically (thousands in a decent sized city), plugging into some sort of serial port on the controller board, and running a possibly dangerous destructive write on the MCU flash.
Okay, so this whole scenario is absurd, but I'm enjoying the thought experiment. Don't take this post as anything other than fun noodling about -- the fundamental fact is that no city is trying to raise revenue this way.
The simple answer to your objection is that it doesn't matter if you stop at a light for 30 seconds or 60, you still decelerate to a stop and accelerate to your cruising speed again -- the marginal difference is idle time, not decelerate/accelerate time.
"Ah," but you say, "But presumably if the red light is longer, some number of people who would have in the counterfactual world cruised through the green light will instead come to it while it is red, decelerate, stop, and accelerate again."
True enough. But while that light is red, another light is green -- for longer, presumably. So compared to the counterfactual, some cars who would have come down to the stop at the red in the other direction are instead cruising through the intersection.
(I presume, here, that nobody actually just sets the intersection to "all lights red" for extended periods of time. That would indeed increase the gas use of everyone in the city, but it also rather gives the game away.)
Indeed, ignoring the all-lights-red approach, the fact is that presumably however long you set the reds for, the intersection spends 50% of its time red and 50% green (or whatever for more complicated intersections, but the point is, you aren't altering the overall amount of red at the intersection, you're just changing it from many shorter intervals to fewer longer intervals). That being the case, we can reasonably answer whether it's possible to raise revenue at all here. Is every increased stop balanced by a missed stop?
And the answer to that depends on whether it's more or less efficient for overall city traffic to have longer or shorter reds. My intuition fails to provide an answer, and I don't have any formal background in traffic engineering.
But in any case, the difference seems unlikely -- at moderately reasonable red light lengths -- to make drastic changes to the city. At which point the $25/resident/year that I earlier estimated starts to look like a huge overestimate.
TL;DR: There is no conceivable way that cities are cynically lengthening red lights to raise revenue. Not effectively, at least.
> According to the paper, the vendor responsible stated that it "has followed the accepted industry standard and it is that standard which does not include security."
I was under the assumption traffic signalling was so horrible because it was a simple timing based system.
Knowing they are all networked, accessible, and controllable from a central computer infuriates me, not because they are hackable, but because the software currently running them is so, so horrible. It's good ol' 'government' software.
That is, as a driver, one isn't in a position to judge whether traffic lights timing make sense, because they're optimized globally to ensure best traffic throughput in the whole city.
But as a software engineer, I can certainly say that comic is wrong.
After enough short sighted releases, mountains of technical debt, poor coding standards, and general apathy, I do not believe the engineer depicted in the comic is accurate. "Hours of simulation" and "took me a week to work out the timing sequences". No. No government paid software engineer spent a week working out the timing sequences. They hacked out something as quick as they could to meet the ridiculous deadline they were given, and then had a good laugh about fixing the process during the retrospective meeting.
When you're sitting at a red light for several minutes at one in the morning with no cars visible for miles, it doesn't take a traffic engineer to realize that intersection is not working optimally.
As someone who works on traffic control systems in a different country, I can definitely believe a story!
We make security a priority (even with full network access you couldn't control our system) but a lot of third party systems are ridiculously rubbish and a lot of Government agencies only make token efforts at security.
Probably stating the obvious, but messing with traffic signs not a good idea for a fun hacking project. I heard of someone going to prison for removing a stop sign, obviously being held responsible for the accident that ensued.
So at least an attacker couldn't cause those sorts of accidents, even if they could totally mess up the system.