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 user credentials — 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 — end-to-end encryption means 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
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 (NCC Group audited 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 tamper-evident and available to compliance officers.