Cold-Chain Gateways with a Shared Key
A cold-chain operator tracks 5,000 reefer containers. Each container carries a cellular gateway with a temperature probe and a door switch; it sends a CoAP POST every 5 minutes to a public cloud endpoint over UDP. All devices ship with the same 128-bit pre-shared key hard-coded in firmware and use DTLS 1.2 in PSK mode; the replay window is not configured and timestamps are not checked. Firmware is downloaded over HTTP and applied without signature verification. A university team bought a decommissioned gateway on the secondary market, extracted the key, and demonstrated injecting fake 8 degrees Celsius readings while real containers held vaccines at -70 degrees Celsius. Auditors also found 300 devices still using the default admin password on the local web interface.
1. Rank the remediation actions by urgency and justify the order.
Read the worked answer
Rank by exploitability times blast radius:
- Default admin password on 300 devices: trivially exploitable, no tooling needed, and it gives local control. Disable the local UI or force a unique password immediately, and scan the fleet for other exposed interfaces.
- Shared PSK: one extracted key authenticates every device, so the entire fleet can be impersonated. Plan key rotation, but a like-for-like rotation to another shared key only resets the clock. Prioritise the highest-risk containers for migration to per-device credentials.
- Firmware over HTTP without signatures: an attacker on the path can push arbitrary code. Move to HTTPS or signed packages and enable secure boot where hardware supports it.
- Replay and timestamp checks: enable the DTLS anti-replay window and require time synchronisation or a monotonic sequence number so old readings cannot be replayed.
- Inventory and decommissioning: a gateway sold second-hand still trusted by the cloud is a process failure. Revoke on retirement and maintain a device register with credential status.
Order is driven by what an attacker can do today, not by what is cleanest to fix.
2. The traffic is encrypted with DTLS, so why is the shared PSK still unacceptable? Explain what it does and does not provide.
Read the worked answer
DTLS with a PSK provides confidentiality and integrity for the link, provided the key is secret. It does not survive a key compromise, and a single key for 5,000 devices guarantees compromise:
- One device, one firmware dump, one decommissioned unit, and the attacker can impersonate any container ID and read or inject traffic for the whole fleet.
- There is no per-device identity, so the platform cannot attribute a reading to a specific device cryptographically and cannot revoke one device without breaking all of them.
- Rotation becomes a fleet-wide event with a hard cutover, which in practice means it is never done.
- PSK mode also gives no device lifecycle: provisioning, renewal and revocation are manual and error-prone.
What is needed: per-device credentials anchored in hardware, such as a secure element holding a unique key or an X.509 certificate, with mutual authentication to the platform, a documented rotation and revocation process, and server-side anomaly checks on the data itself, because a valid device can still send false readings if its sensor is spoofed.
3. Design the target security architecture for the fleet and the migration path from today's state.
Read the worked answer
Target architecture, by layer:
- Device: hardware root of trust (secure element or TPM), secure boot, signed firmware with rollback protection, unique credentials, disabled or authenticated local interfaces, and a tamper-evident enclosure for the probe.
- Transport: CoAP over DTLS 1.2 with mutual authentication, or OSCORE if end-to-end protection through a proxy is needed; TLS for any HTTP path.
- Platform: per-device identity and authorisation, revocation list, anomaly detection on temperature rate-of-change, door events and geofence, plus immutable audit logs with 90-day retention for pharmaceutical compliance.
- Operations: device register with owner and lifecycle state, secure decommissioning that wipes keys, and a key ceremony that does not put one secret on a factory image.
Migration in waves: first freeze new builds, then ship a firmware update that removes the hard-coded key and enables signature checks; migrate 200 pilot containers to certificate-based credentials; run both authentication paths during the transition with a per-device flag; retire the PSK path container by container; and revoke the old key only after the last device has moved and the data shows no PSK clients.