Security
Canium's security guarantee is architectural, not contractual. The system is designed so that even Canium's own engineers have zero technical ability to access message content, encryption keys, or your password — under any circumstance.
Threat Model — What Canium Protects Against
Canium's encryption architecture protects users from:
- Canium itself — server operators cannot access message content or keys
- Database breach — encrypted blobs and OPAQUE records are cryptographically useless to an attacker without user credentials
- Network-level interception — every call and every message is encrypted end to end; the server never holds plaintext
- Future quantum computers — all message key establishment and DRA recovery envelopes use a hybrid post-quantum KEM (X-Wing: X25519 + ML-KEM-768). Ciphertext recorded today cannot be retroactively decrypted by a future quantum computer — "harvest now, decrypt later" is closed. Classical primitives remain only in authentication (login and signatures), where a future quantum break would be a forgery risk at that time, never a retro-decryption risk to recorded traffic.
- Compelled disclosure to Canium — Canium cannot produce what it does not have
What Canium Does Not Protect Against
Canium does not protect against:
- Compromise of the user's own device (endpoint security is the user's responsibility)
- DRA disclosure where the organization's compliance officer acts lawfully
- Social engineering of the user
Always On
Encryption applies to every call and every message — audio, video, and text — automatically, from the first session. There is no mode to enable, no feature that requires turning it off, and no path that bypasses it. If encryption cannot be established, no content is sent. Canium fails closed.
Standards and Compliance
| Standard / Framework | Status |
|---|---|
| PIPEDA | Architecture designed for compliance |
| Communications data residency | Canada — messaging, encryption keys, and channel content |
| Billing data residency | Per payment processor — currently US-based; Canadian processor migration planned for enterprise/government clients requiring full billing-data residency |
| IETF RFC 9420 (MLS) | Implemented via OpenMLS |
| IETF RFC 9807 (OPAQUE) | Implemented via opaque-ke, an independently reviewed open source library. |
| NIST ML-KEM-768 (FIPS 203) | Hybrid post-quantum KEM (X-Wing combiner with X25519) for all MLS message key establishment and DRA recovery envelopes |
| AES-256-GCM | Message encryption |
| CCCS / Government of Canada | Target market; procurement readiness in progress |
Audit Trail
Every cryptographic state-change operation emits a structured audit event. These include authentication events (login success/failure, password change, reset), key material events (key package consumption, fallback key use), and any DRA disclosure operations. Audit logs are available to your compliance officers.
Canadian sovereignty, lawful access, and the DRA architecture.
MLS, OPAQUE, and post-quantum key establishment, end to end.