Security Model

NORTHSTARSHOW SYSTEMS

Security Model

Licensing, device binding, OTA authentication, and threat surfaces

Document NumberRevisionDatePlatform Version
NSSS-DOC-0013A2026-05-201.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

ChannelEncryptionNotes
HelmOS HTTPNoneLAN-trusted; CORS open for tool access
HelmOS WebSocketNoneSame trust model as HTTP
Polaris UDPNoneShow traffic; format intentionally simple
ArduinoOTA pushMD5 password challengeProject-derived password gates pushes
Wi-FiWPA2/WPA3AP-managed; primary security boundary
  • NSSS-DOC-0012TrueNorth Network Design
  • NSSS-DOC-0061Firmware OTA Update Guide

Revision History

RevisionDateDescription
A2026-05-20Initial publication