Security Model
NORTHSTARSHOW SYSTEMS
Security Model
Licensing, device binding, OTA authentication, and threat surfaces
| Document Number | Revision | Date | Platform Version |
|---|---|---|---|
| NSSS-DOC-0013 | A | 2026-05-20 | 1.0 |
Threat Model
Northstar is sold to venue operators who install on a venue-local Wi-Fi network. The security boundary is the WPA password plus physical access. Inside that boundary, components trust each other.
Threats In Scope
- Software piracy — running a copied Compose or HelmOS install without a license
- License forgery — minting valid tokens without the Northstar private key
- Hostile firmware push — flashing a malicious binary onto Polaris nodes via the venue Wi-Fi
- Replay across venues — using a project file from one venue to attack another
Threats Out of Scope
- Sophisticated network attackers on the venue LAN — there is no transport encryption between HelmOS, Polaris, and Cuemaster
- Physical seizure — administrators with NUC access can copy license tokens and project files
License Tokens
Format: NSSS1.<base64url(payload)>.<base64url(signature)>
Payload is a JSON object containing format version, issuer, product key (compose / helmos / northstar), device fingerprint, customer name, issued and expiry timestamps. Signature is Ed25519 over the base64url payload using the Northstar private key.
Verification
Both Compose and HelmOS perform the same verification chain on every activation:
- Parse and split the three token segments.
- Verify the signature against the embedded public key.
- Check the issuer is NSSS and the product matches the running platform.
- Check the device fingerprint matches the current machine.
- Check the expiry is null or in the future.
Any failure → activation refused. Stored tokens are revalidated on each startup.
Device Fingerprint
Sources:
- Windows: SHA-256 of HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid
- macOS: SHA-256 of IOPlatformUUID
- Linux: SHA-256 of /etc/machine-id
Truncated to 16 hex characters and formatted as XXXX-XXXX-XXXX-XXXX. Stable per-machine and resilient to user account changes.
OTA Authentication
Each Polaris board's ArduinoOTA listener requires a password. The password is derived deterministically from the project name plus the node ID using a hash function — see NSSS-DOC-0061 Firmware OTA Update Guide for details. HelmOS knows the password because it has the project file. An attacker on the same Wi-Fi cannot push firmware without the project.
What Crosses the Wire
| Channel | Encryption | Notes |
|---|---|---|
| HelmOS HTTP | None | LAN-trusted; CORS open for tool access |
| HelmOS WebSocket | None | Same trust model as HTTP |
| Polaris UDP | None | Show traffic; format intentionally simple |
| ArduinoOTA push | MD5 password challenge | Project-derived password gates pushes |
| Wi-Fi | WPA2/WPA3 | AP-managed; primary security boundary |
Related Documents
- NSSS-DOC-0012TrueNorth Network Design
- NSSS-DOC-0061Firmware OTA Update Guide
Revision History
| Revision | Date | Description |
|---|---|---|
| A | 2026-05-20 | Initial publication |