Why is encryption alone insufficient for protecting traffic light control systems or car remote keys?
Because an attacker can capture and replay an encrypted command without knowing its content — you need authentication, not just secrecy.
This is the classic replay attack problem:
Traffic light example:
- Even if the control signal is encrypted, an attacker can record the encrypted "switch to green" command
- They can replay it later without ever decrypting it
- Encryption provides no protection here — you need authentication to verify the command is fresh and from a legitimate source
Car keyless entry example:
- Keyless systems send low-frequency signals that can be intercepted
- A relay attack extends the signal range — one thief stands near the car, another near the key owner
- Simply encrypting the signal doesn't help; you need mutual authentication (challenge-response) before the car executes any command
The decisive questions for any control signal (traffic lights, remote pacemaker settings, railway signal radio control):
- Does the command come from a party that is authorised to give it? (user authentication of the sender)
- Is the receiver sure the command is meant for it?
- Is the command unaltered? (data integrity)
- Is it timely, i.e. not an old, replayed or delayed command? (freshness)
Only when the signal content itself must stay secret (e.g. a combat drone's commands) does encryption join the list, and even then it is the last mechanism added, not the first.
The lesson: Always analyze which security property you actually need. Encryption (confidentiality) protects content. User and data authenticity protect against impersonation, tampering and replay, and for control systems they are what matters. Many systems mistakenly use only encryption when they really need authentication — or both.
Go deeper:
Replay attack - why encryption alone fails: valid ciphertext can be recorded and re-sent; countermeasures are nonces/timestamps/MACs.