SENTRA Licensing Authority
Datasheet for the root of trust that issues every SENTRA licence and signs every release (version 1.2).
Version: 1.2 · Layer: Trust & supply · Address: https://licensing.sentra-ai.com
The root of trust for every SENTRA system. It holds the SENTRA root signing key, designs and issues every licence, certifies VIEWs and GUARDs as signing authorities with limits, keeps a record of every key ever issued, and approves and signs software releases. It is operated by SENTRA.
Key capabilities#
| Area | Capabilities |
|---|---|
| Design & issue | A wizard that designs the hierarchy for a customer (stand-alone ATS, stand-alone NTS, GUARD with boxes, VIEW fleet), then what each level needs: products, modules, term or perpetual, seats and limits |
| Approvals | Requests and approvals with per-user limits; the Super Admin's approval is final; optional four eyes |
| Registry | Deployments, every licence (reveal key with 2FA, revoke, CSV export), customers (archive or delete), signing authorities, systems seen online |
| Signing authorities | Enrolment codes; authority certificates with products, limits and latest expiry; ledger upload for offline authorities |
| Import | Bring existing licence files into the register |
| Releases | Candidates from the release builder with tests and what's new; Approve & publish with a fresh 2FA code; Withdraw |
| Security | Root signing keys, users and access, policy and vault, audit trail with one-click verification |
Security design#
| Control | Implementation |
|---|---|
| Vault | Every record and audit entry encrypted with AES-256-GCM; master key wrapped with a key derived from the vault passphrase (scrypt, N = 2^17, 128 MiB); sub-keys by HKDF-SHA256; blind indexes so nothing — not even a customer name — is stored in the clear |
| Sealing | Sealed after every restart until the passphrase is entered; no way to recover a lost passphrase |
| Sign-in | scrypt password hashes; TOTP two-factor forced at first sign-in, with recovery codes; codes work once; lockout and rate limits |
| Sessions | In memory only; __Host- cookie (Secure, HttpOnly, SameSite=Strict); idle and absolute timeouts; CSRF token on every change |
| Step-up | Revealing keys, bundles, approvals, signing keys, users and policy need a fresh 2FA code |
| Roles | Super Admin, Administrator, Approver, Issuer, Auditor, Viewer, plus per-user limits (levels, longest term, perpetual, most boxes) |
| Audit | Encrypted entries chained with SHA-256 and sealed with an HMAC; verifiable in one click |
| Web hardening | Strict CSP, HSTS, frame deny, COOP/COEP/CORP, no-store, noindex, optional IP allow list, body size limits; locked-down systemd service behind SENTRA AI Threat Shield |
Release signing#
SENTRA root key (in the vault)
└─ certifies the release key (OTGRK1)
└─ signs each product's release list (index.json + index.sig)
└─ pins the checksum of each package and of every file
The release builder runs as a separate service user, tests each product and prepares candidates — it never signs. The release server (updates.sentra-ai.com) serves only public, signed files, so a second server for 1+1 availability needs only a copy of the published folder.
Interfaces used by SENTRA systems#
| Endpoint | Purpose |
|---|---|
POST /api/v1/licence/check |
Check-in from ATS and NTS: status of each key, revocations and renewals |
POST /api/v1/authority/enrol |
A VIEW or GUARD enrols as a signing authority |
POST /api/v1/authority/sync |
An authority reports the keys it issued (signed with its own key) |
GET /api/v1/health |
Health check |
Deployment#
Runs on SENTRA's server on 127.0.0.1:8640 (release server 127.0.0.1:8641), published through SENTRA AI Threat Shield, which terminates TLS and inspects every request.