Threat Model

PQ Cloud is a verification and policy layer. Customer systems retain their private keys, existing classical controls and final allow/deny authority. The integration is designed to fail closed when verification cannot be trusted or completed.

Security boundary

• Customer: private-key custody, signing, classical authorization, business rules and final decision.
• PQ Cloud: canonical payload verification, ML-DSA-65 evidence verification, registered public-key checks and HybridRequired policy evaluation.
• Result: Valid or Rejected. A Valid result is an input to the customer's decision.

API downtime or timeout

Threat: the verifier is unreachable, slow or returns an incomplete response. Required behavior: timeout, transport error or malformed response must never be promoted to Valid.

Current evidence: TypeScript and Go integration guidance requires an explicit successful verification response before continuing.

Transport integrity

Threat: an attacker attempts to alter or impersonate the verification service response. Required behavior: authenticate the HTTPS service endpoint, reject malformed responses and consume explicit verification semantics.

Current design: service authentication uses HTTPS/TLS to pq.rannta.com with explicit JSON verification results.

Key rotation

Threat: stale or rolled-back public keys remain accepted after a rotation. Required behavior: key versions are monotonic, policy defines the minimum accepted version, and retired keys are not treated as current authorization keys.

Current evidence: the crypto/policy suite passed key registration, rotation, stale-version rejection, future-version rejection and rollback-negative behavior. Public-key records are persisted in the service database.

Replay

Threat: previously valid evidence is submitted again. Required behavior: a unique nonce is part of the signed canonical payload and a previously accepted payload hash must not be accepted again.

Current evidence: production replay rejection PASS. Replay state is persisted per project in the production database with a uniqueness constraint on project and payload hash.

Canonicalization mismatch

Threat: signer and verifier construct different bytes from apparently equivalent application data. Required behavior: both sides use the V1 canonical byte format. Any changed signed byte invalidates the existing signature.

Current evidence: TypeScript customer-side verification and the Rust-backed production verifier both rejected the recorded one-byte mutation. See canonical payload specification.

Fail-closed behavior

Threat: missing PQ evidence, policy mismatch, unregistered key, invalid signature, replay or failed classical authorization is accidentally treated as authorization. Under HybridRequired these states must not produce Valid.

Customer final authorization

PQ Cloud verifies the post-quantum evidence and policy state. The customer backend combines that result with its own authentication, authorization, risk and business controls before allowing an action.