Keys, K0, and how a device joins the show

Every Sig-Net network has exactly one secret at its core: a 256-bit value called the Root Key, written K0. Every other key on the network — the per-device management key, the Sender Key, the Citizen Key — is mathematically derived from K0 and a known formula. Lose K0 and you lose everything. Protect K0 and you protect the show.

How K0 gets onto a device

The spec is fanatical about preventing typos, because a Node with the wrong K0 can't talk to anyone — it'll silently drop every poll and every command, and you'll spend an hour debugging it. So Sig-Net only allows three ways to load K0:

The Manager generates one. This is the recommended path. The console rolls a high-entropy random key (or a strong random passphrase) using its built-in cryptographic random number generator. It's checked for entropy automatically — the spec rejects anything too predictable.

You type a passphrase. Minimum 10 characters, maximum 64. Must mix at least three of: uppercase, lowercase, digits, symbols. No more than two consecutive identical characters ("aaa" is rejected) and no more than three consecutive sequential characters ("abcd" or "1234" rejected). The device runs this through PBKDF2 with 100,000 iterations to derive K0.

Out-of-band electronic transfer. A USB stick, an NFC tag, or a dedicated TLS/DTLS tunnel can carry K0 as a 64-character hex string in a small JSON file. Wipe the medium afterwards.

What the spec explicitly forbids is letting anyone manually type the 64-character hex key. That mistake is too easy to make and too painful to debug.

Beacon Mode: the offboarded device

A device with no K0 — factory-fresh, freshly wiped, or just unprovisioned — is "offboarded". It has no working keys, can't generate or verify any signatures, and silently drops every authenticated packet that comes its way. But it isn't completely silent.

Every five seconds or so, an offboarded device chirps a small unauthenticated beacon to a special multicast address that says "I'm here, here's my TUID, here's my model, please add me to a network". A Manager listening on that address can pop up a "new device wants to onboard — accept?" prompt. If the operator says yes, the Manager hands over K0 (via passphrase, USB, or whatever mechanism the device supports), the device derives its working keys, immediately erases K0 from RAM, and joins the show.

That last bit is important. Once a Node has its working keys, it doesn't need K0 any more — and keeping it around would just be a security liability. So it's destroyed. Only Managers permanently retain K0 (or the passphrase that derives it), because they need to onboard new devices later.

Open Mode: when you don't want any of this

For trade shows, classrooms, conformance test rigs and other low-stakes environments, a device can be put into Open Mode by hand. It bypasses all the cryptography entirely. The spec is clear about three things: devices cannot ship in Open Mode by default, Open Mode can only be enabled via a deliberate physical action on the device itself, and the device must visibly indicate Open Mode on its display so nobody is confused about whether they're running secured.

Next post: how Sig-Net solves sACN's universe-scaling problem with something called Multicast Folding.

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