Technical overview
Q Phone security architecture
A deeper description of the planned Q Phone security architecture for developers, security reviewers and technically minded readers. Everything described here is a design direction under active development. No implementation claim, audit result or certification is being made.
Quantum threat model
The primary concern is not that a quantum computer exists today. It is that classically encrypted material captured today can be retained and attacked later — the Harvest Now, Decrypt Later model. Long-lived secrets are the highest-risk category: identity keys, signing keys, recovery material and archived conversations.
Q Phone's design therefore prioritizes post-quantum protection for the longest-lived assets first: device and application identity, Splendor signing keys, and supported Q Connect session establishment.
Out of scope: carrier voice and SMS, third-party application cryptography, and any component whose security is defined by an external party.
Cryptographic architecture
The planned architecture targets the NIST post-quantum standards finalized in 2024: ML-KEM for key establishment and ML-DSA for digital signatures. Selection of parameter sets is being made per function, balancing signature size, latency and the sensitivity of the operation.
Where a supported function must interoperate with existing infrastructure, hybrid constructions — classical plus post-quantum in combination — are planned so that a break in either component alone does not reduce the session below current security expectations.
- ML-DSA — authorization of supported transactions and identity actions.
- ML-KEM — establishment of shared secret material for supported Q Connect sessions.
- Hybrid modes — used where interoperability with classical endpoints is required.
- Symmetric primitives — parameterized with post-quantum margins in mind.
Q Vault and key lifecycle
Q Vault is the planned protected key store. The design intent is that supported Splendor signing keys are generated inside protected hardware, are never exported to application memory, and are used only through an explicit signing request that the user approves.
Key lifecycle stages under design: generation inside the protected boundary, attestation of the boundary, usage gated by user presence, rotation of application-scoped keys, and destruction on device reset. Recovery is being designed so that losing a device does not mean losing an identity, without creating a copy of the signing key on general-purpose storage.
- Generation — inside dedicated protected hardware, under evaluation.
- Usage — per-operation approval, no ambient signing authority.
- Rotation — application-scoped keys rotate independently of device identity.
- Recovery — user-controlled recovery flow, design in progress.
Splendor integration
Splendor is planned as a QOS-level verification layer rather than an installed wallet app. The device produces ML-DSA signatures inside Q Vault; Splendor verifies and settles supported transactions, identity assertions and verifiable actions.
The separation is deliberate: the device signs, Splendor verifies. Private key material is not intended to leave the device at any point in the flow, including during recovery.
Q Connect
Q Connect is the planned communication layer. Supported Q-to-Q sessions are intended to use end-to-end encryption with ML-KEM key establishment and periodic rekeying, with identity bound to Q Identity signatures.
The interface is being designed to state plainly when a conversation leaves the Q Connect boundary — for example an SMS fallback or a carrier call — rather than implying protection that does not apply.
Software updates
Update integrity is part of the post-quantum scope. The intent is that QOS update packages are signed with post-quantum signatures and verified before installation, so update delivery does not become the weakest link in an otherwise post-quantum chain.
Threat boundaries
A phone is a system of many parties. The following are explicitly outside the planned Q protection boundary: carrier voice and SMS, third-party application data handling, cloud services chosen by the user, and any peripheral or network operator behaviour.
Physical attacks with unlimited device access, supply-chain compromise prior to first boot, and compromise of a user's own recovery material are also outside the design guarantees.
Audit status
No independent security audit has been completed and no certification is being claimed. Independent cryptographic implementation review and device penetration testing are planned steps on the security roadmap, ahead of production.
Technical references
Q Phone is in development. Everything described on this page is a design direction and is subject to change. No audit, certification or shipping implementation is being claimed.
Join the waitlist