QSE ASTRUM
PROTOTYPE / REFERENCE · CSfC-track

Operator sign-in

Authenticate to your Astrum account. Your permissions come from the account, not from this form.

Your access role (operator / admin / evaluator) is assigned to your account by an administrator and resolved server-side. It is not selected here, and asking for a wider role would not grant one.

What signing in does — and does not — do

This is an account, not a cryptographic identitySign-on authenticates an ACCOUNT, not a cryptographic identity. It does not prove possession of any node's ML-DSA-87 private key, and this build holds no private key for a provisioned nodes.mldsa_pubkey. A signed-in session and a node identity are separate namespaces; users.node_id, when set, is an advisory link and is not verified by anything at sign-in.
  • Password only. No MFA, no FIDO2/hardware token, no TOTP, no e-mail or SMS second factor is implemented. Anyone holding the password holds the account.
  • The session is NOT bound to a device, an IP address, or a TLS channel. A stolen session token is usable from anywhere until it expires or is revoked.
  • Sign-on is NOT bound to the message-path cryptography. Signing out revokes the session; it does not destroy ratchet state, re-key a conversation, or make already-relayed ciphertext unreadable.
  • Transport confidentiality is whatever TLS the deployment terminates at its edge proxy. The application does not terminate TLS.
  • FIPS 140-3 is NOT validated. Password hashing is scrypt (RFC 7914); session tokens are HMAC-SHA256. Neither is a CMVP-validated module.
  • There is no password-reset or account-recovery flow. A forgotten password requires an administrator to set a new one.
  • The session token is held in this app’s own storage and is reachable by any script running in it. Treat an XSS on this surface as a full session compromise.

Node identity (read-only)

Astrum server console · tenant 1 · node 1UNVERIFIED
ML-DSA-87 public-key fingerprintnot fetched — no node key is read before sign-in
Identity algorithmML-DSA-87 (FIPS 204)
KEM algorithmML-KEM-768 + X25519 hybrid
Payload cipherAES-256-GCM
CertificationUNVERIFIED
Displayed for reference onlyThis node identity is not what your password authenticates, and signing in does not check any key shown here.
TOFU-only identityTOFU does not scale and does not protect first contact against MITM. Enroll a CSfC certificate or enterprise CA before operational use.

How a message session is secured

The cryptographic path — separate from sign-on, and unaffected by it.

  1. 1 · ML-KEM-768 + X25519 hybrid KEMEphemeral exchange produces the shared session secret. Hybrid classical + PQC gives harvest-now-decrypt-later resistance for in-transit ciphertext.
  2. 2 · ML-DSA-87 (FIPS 204) identity bindingML-DSA-87 identity binding is mandatory — this step cannot be skipped. Each node signs its KEM public key; an unauthenticated KEM session is open to active interception.
  3. 3 · Double Ratchet / MLS startPairwise: Double-Ratchet forward secrecy. Group: MLS TreeKEM (RFC 9420) epoch. Forward secrecy / PCS and MLS epoch rotation are always on — locked by policy.

K_comsec ⊥ K_transec — HKDF domain-separated · never the same keystream

FIPS 140-3: not validated — prototype use onlyEAR 5A002/5D002 — export controlled