Fleet Security Audit
How 8 critical security gaps in an IoT device fleet were mapped to SDK capabilities. From shared secrets to cryptographic device identity.
Context
An IoT device fleet manages physical access to secured spaces. Devices are commissioned via QR code scan and communicate over MQTT. A security audit identified 8 critical gaps in the existing architecture. This case study maps each finding to an SDK-based mitigation.
Gap 1: Shared Secrets in Source Code
A single API key hardcoded in firmware, shared across all units. Extractable via firmware dump. One compromised device exposes the key for the entire fleet.
Ed25519 keypair generated per device at commissioning. Private key never leaves the device. No shared secrets exist in source code or firmware.
Agent.create() — per-device DIDGap 2: One Device = All Devices
Flat permission model. Every device has the same API key and the same access level. Compromising Device 104 grants access to Devices 1–500.
Per-device DID mapped to scoped permissions in trust registry. zone.DEVICE-104.* — blast radius is one unit.
TrustRegistry — per-DID scope graphGap 3: MQTT Message Forgery
MQTT messages authenticated with symmetric HMAC. Any device with the shared key can forge messages appearing to come from any other device.
Messages signed with Ed25519. Signature is bound to the sender’s DID. Impossible to forge without the private key, which never leaves the device.
agent.send() — Ed25519 signed envelopesGap 4: Replay Attacks
No nonce, no timestamp window. A captured “unlock door” MQTT message can be replayed indefinitely.
128-bit cryptographic nonce + 30-second timestamp window. Server-side NonceStore rejects duplicates. Even legitimate captured messages cannot be reused.
NonceStore — Redis-backed, single-useGap 5: Admin Insider Threat
Admins with database access can modify audit logs, delete entries, or alter timestamps. No cryptographic proof of message origin.
Every message carries an Ed25519 signature. Audit logs include the signature. Rewriting the database doesn’t invalidate signatures — they can be verified against the device’s public key.
Gap 6: Revocation Latency
Revoking a compromised device requires pushing new secrets to every other device in the fleet. Latency: hours to days. During that window, the compromised device retains access.
Remove the device’s DID from the trust registry. Effect is immediate — next message from that DID is rejected. No fleet-wide update needed.
TrustRegistry.revoke() — instantGap 7: Commissioning QR Tampering
QR codes contain the shared API key in plaintext. Intercepted QR = full fleet access. No binding between QR and specific device.
QR contains only the device’s public DID. Even if intercepted, the DID alone cannot forge messages (no private key). The DID is registered in the trust registry at commission time with unit-specific scopes.
Gap 8: Recovery Envelope Interception
Recovery envelopes sent in plaintext over email. Intercepted recovery envelope grants full device access.
Recovery envelopes encrypted with AES-256-GCM via ephemeral X25519 key agreement. Only the intended recipient (identified by DID) can decrypt.
agent.send() with encryption — encrypt-then-sign envelopeFindings Closure Table
| Finding | Before | With PRIVATE.ME SDK |
|---|---|---|
| Shared secrets in source | OPEN Hardcoded API key | CLOSED Per-device Ed25519 |
| Flat permissions | OPEN All-or-nothing access | CLOSED Scoped DID permissions |
| MQTT forgery | OPEN Symmetric HMAC | CLOSED Ed25519 signatures |
| Replay attacks | OPEN No nonce protection | CLOSED NonceStore + timestamp |
| Admin insider threat | OPEN Mutable audit logs | CLOSED Signed audit entries |
| Revocation latency | OPEN Fleet re-key (hours) | CLOSED DID revoke (instant) |
| QR tampering | OPEN Plaintext API key | CLOSED Public DID only |
| Recovery interception | OPEN Plaintext email | CLOSED Encrypted envelope |
What It Doesn’t Fix
- Physical device theft (hardware tamper protection is out of scope)
- Compromised admin email accounts (email provider security is external)
- Biometric spoofing at the entry point (biometric systems are separate hardware)
- WiFi/network-level attacks (transport security is orthogonal)
- Firmware supply chain attacks (code signing is a separate concern)
The SDK secures the messaging and identity layer. Physical security, network security, and firmware integrity require additional controls.
Net Posture Change
The fleet moves from operational security (policy-dependent, human-error-prone, revocation-latent) to cryptographic security (mathematically verifiable, per-device scoped, instantly revocable). 8 of 8 findings addressed. Attack surface reduced from fleet-wide to single-device. Revocation time reduced from hours to seconds.