Hacking Traffic Lights: The City's Invisible State Machine#

What comes to mind under "smart city" is an interconnected "state machine." Traffic lights are the part of that system that looks simple but is actually complex. In reality they are network nodes that continuously exchange data between sensors, regulating controllers, and central management systems. In this post I go over intersection architecture, the protocols, the known weaknesses, and the defense side with a lab-oriented view.

Ethics and lab note: Everything below is for education and awareness, on an isolated lab environment and simulation. Unauthorized access to or tampering with real traffic systems is strictly forbidden and a serious crime.

Looking at the field: it is not just a light#

At an intersection all you notice is green-yellow-red; but behind it there is a chain:

• Vehicle detection sensors: inductive loops, radar, and cameras.
• Local controller: the unit that manages light phases and timings on site (ATC or 2070-class devices).
• Communication layer: the network that connects controllers and the central Traffic Management Center (TMC) to each other.

The beauty of the local controller is this: even if the network drops, it keeps managing the signal on site. So the intersection is not an extension entirely dependent on the center; it is a node with its own decision-making ability.

NTCIP: the city's common language#

NTCIP is a family of communications standards for intelligent transportation systems, not a single protocol implemented identically everywhere. One published traffic-signal-controller profile is NTCIP 1202, Object Definitions for Actuated Traffic Signal Controller (ASC) Units; the official standards catalog lists revisions, including v03b. Check the agency-adopted edition and the actual controller's conformance before assuming which objects or operations can be read or changed.

Control networks are often designed separately from enterprise IT, but that is a design intent, not proof of isolation. Verify routes, maintenance access, remote gateways, and vendor connections instead of assuming a closed network.

Attack surface: the invisible door#

It helps to think about the attack surface in three layers.

1. Network and protocol layer#

SNMP can be one management path. A misconfigured agent may retain well-known community strings such as public or private; these are examples, not a universal controller default. SNMPv1/v2c use community-based message handling and do not provide cryptographic privacy, so exposed traffic can reveal the community and management data. RFC 1157 and RFC 1901 describe the v1 and community-based v2c frameworks; deployment behavior still depends on device and configuration.

The studies must be kept distinct. Ghena et al.'s "Green Lights Forever" examined a deployed traffic-signal network in coordination with authorities. Cerrudo's 2015 IOActive white paper discusses smart-city attack surfaces more broadly; it is not evidence for the specific Ghena findings or for a particular current controller. Neither establishes that the same flaw persists in every city today.

2. Controller layer#

Physical access can bypass network-only controls, but the available interfaces and safeguards vary by controller. Protect cabinets, maintenance ports, debug interfaces, and firmware update paths according to the installed equipment and agency policy.

3. Sensor layer#

If the sensitivity of the inductive loop or the camera/radar perception is manipulated, the controller thinks "there is a vehicle on the road" or "there is not." The result is not direct code execution; it is denial of service and traffic congestion. Here we clearly see that OT threats are availability-oriented, not only confidentiality-oriented.

The hard part in the real world: the safety chain#

A well-designed intersection does not depend on a single point. There are safety mechanisms that hold the system together:

• Conflict monitor: prevents conflicting greens at the same time.
• Flash mode: the flash pattern in a fault state depends on the cabinet configuration and local traffic-engineering rules; a yellow flash on every approach is not assumed.
• Timing gates: limit phases that are too short or too long.

These mechanisms may prevent some unsafe states, but they do not guarantee availability, correct timing, pedestrian service, or safe operation under every fault. They are not a substitute for controlling network, identity, maintenance, and physical access.

The safety controller is not an authorization system that verifies that an authorized user chose the correct timing plan. Even without a conflicting green, an inappropriately long cycle, pedestrian wait time, or loss of coordination can cause harm. That is why "there is a conflict monitor" is not a justification to leave network management access open. And if SNMPv3 is used, you look not just at the version name but at the effective security level: you need authPriv for authentication and privacy; noAuthNoPriv does not provide the same protection.

The SNMPv3 USM specification (RFC 3414) separates message identity, integrity, timeliness, and optional privacy; the protocol version alone is not access authority. Which management objects a user may write to must additionally be restricted. The algorithms to be used in a modern deployment are also chosen according to the device's current support; do not copy the algorithm list from the historical RFC as today's cryptography recommendation.

Defense checklist#

• Do not keep the default: change default SNMP community names and device passwords; move to SNMPv3 (authentication + encryption) where possible, and disable SNMP entirely if it is not needed.
• Isolate: separate the control network from the IT network; do not expose devices directly to the internet, reach them through VPN/TLS tunnels.
• Monitor: monitor not just network traffic but device state and abnormal commands; set up OT-specific anomaly detection.
• Physical hardening: cabinet locks, a service-port policy, signed firmware/secure boot.
• Identity discipline: role-based access, individually defined for every controller at the center, instead of shared accounts.

Legal dimension#

Unauthorized testing or manipulation may violate criminal and critical-infrastructure laws; the exact rules depend on jurisdiction. Test only under written authorization and in an isolated lab, never on live traffic systems.

Lab approach#

SUMO is for modeling phase logic; it is not for validating NTCIP controller firmware or a cabinet safety circuit. The SUMO Traffic Lights documentation defines the tlLogic program, phase durations, and the state string. Each character is a traffic-light link index; assuming each character is a lane, or erasing the g (permissive green) versus G (priority green) distinction, produces a wrong conflict interpretation.

In a safe exercise, first build a single intersection in netedit and display the light-link indices. Copy the default program to produce a second programID; keep traffic demand and randomness fixed and change only one green phase duration. Compare phase transitions, queue buildup, and pedestrian wait. Do not delete yellow/all-red transitions. SUMO's default program may not include an all-red phase, so its behavior is not evidence of real cabinet approval. The experiment asks whether an authorized but inappropriate timing change can disrupt service without triggering the simulated safety checks. If modeling SNMP, use a separate simulator or vendor lab disconnected from field networks; do not send control writes to live equipment.

Conclusion#

Traffic signals combine networked control with physical effects. For an installed system, verify actual network paths, controller-specific access controls, maintenance interfaces, and safe failure behavior; a SUMO model does not validate field hardware. Testing live equipment requires written authorization and coordination with the responsible agency and vendor.

Sources#

• NTCIP published standards catalog: controller-profile revisions, including NTCIP 1202 v03b.
• RFC 1157 and RFC 1901: SNMPv1 and community-based SNMPv2 framework.
• Ghena et al., Green Lights Forever, WOOT 2014: original research on the controller network.
• Cesar Cerrudo, IOActive (2015): broader smart-city threat context, separate from the Ghena traffic-network study.
• SUMO traffic light modeling documentation: phase state, link indices, and simulation limits.

Related Research & Internal References#

• EV charging station security — another physical-world OT/IoT system with a similar identity-and-network attack surface.
• Cybersecurity risk model — how to score availability-oriented OT risks against business impact.