Multi-Manager networks and the security model in plain English

We've come back round to where we started: keys. But this time we'll look at how the cryptography actually shows up in everyday lighting work, because most of Sig-Net's security model is invisible until you start using it for the things it was designed for.

The two scenarios you'll meet most

Main desk and backup desk. You want both consoles to have full powers — either one of them should be able to repatch the rig, change a fixture's IP, push an RDM SET — so that if one fails mid-show, the other takes over without operator intervention. In Sig-Net terms, both are Equal Managers. They share the same K0, they can independently derive every per-device management key in the system, and they're indistinguishable to the rig.

House rig with a touring console visiting. The venue's house engineer doesn't want the touring console accidentally renaming fixtures, changing IPs, or executing RDM SETs against the house rig. But they do want the touring console to be able to see the patch and stream DMX. This is exactly what Guest Manager is for: the house engineer exports a small JSON file containing only the global keys (Km_global, Ks, Kc) onto the touring console. The touring console can poll, can see everything, can stream levels — and any attempt to send a configuration command bounces off every fixture's HMAC check. The cryptography enforces the boundary, not the software.

When the tour leaves, the venue can rotate K0 if it wants to (good practice), and the previously exported guest keys become useless on the new K0. No "did you delete the guest credentials?" anxiety.

The threat model, threat by threat

Sig-Net lays out exactly what it does and doesn't protect against. It's worth knowing the difference.

Tampering with packets in transit (man-in-the-middle): blocked, because every packet has an HMAC signature and tampering breaks it.

Pretending to be the console (spoofing): blocked, because forging packets needs the key.

Replaying recorded packets (replay attack — the classic "force a blackout from yesterday's recording"): blocked, because every packet has a session ID and a sequence number that can only ever go up. Old packets fail the freshness check.

A rogue laptop on the network: blocked. No K0, no valid signatures, every packet is silently dropped.

Eavesdropping on the wire: explicitly not blocked. Anyone with network access can read the DMX values, just like with sACN. If you genuinely care — shared infrastructure venues, multi-tenant buildings — you VLAN-segment the lighting network. Encrypting every level packet would burn too much CPU on a small gateway, this is always a interesting discussion of is the data really confidential.

A physically stolen fixture (someone walks off with a moving light and dumps its memory): the damage is contained. Each Node only knows its own per-device key plus two global keys. The attacker cannot use it to forge configuration commands to other fixtures, because Km_local is bound to each Node's TUID by mathematics.

A physically stolen console: this is the bad one. A Manager permanently retains K0, and from K0 every key on the network can be derived. Treat consoles like a key safe — the spec requires the highest available secure-storage hardware, and recommends a dedicated secure element for any product calling itself a Manager. If a console is stolen or suspected compromised, rotate K0 across the whole rig.

What you can rotate, and how

K0 cannot safely be rotated over the standard Sig-Net network — the data plane is plaintext. So a Root Key change happens out-of-band: a new passphrase typed at each device, a USB stick walked round the rig, an NFC tap, or via a dedicated authenticated tunnel (DTLS or TLS) on devices that support OTW onboarding. Annoying once, but safer than the alternative.

Next up we go in to some more detail on TIDs: the vocabulary of Sig-Net.

This series is based on v0.20 of the Sig-Net spec - visit Sig-Net.net for any updates.