Sécurité
La garantie de sécurité de Canium est architecturale, pas contractuelle. Le système est conçu pour que même les ingénieurs de Canium n'aient aucune capacité technique d'accéder au contenu des messages, aux clés de chiffrement ou aux informations d'identification des utilisateurs — en aucune circonstance.
Modèle de menace — Ce contre quoi Canium protège
L'architecture de chiffrement de Canium protège les utilisateurs contre :
- Canium lui-même — les opérateurs du serveur ne peuvent pas accéder au contenu des messages ni aux clés
- Violation de base de données — les blobs chiffrés et les enregistrements OPAQUE sont cryptographiquement inutiles pour un attaquant sans les informations d'identification des utilisateurs
- Interception au niveau réseau — le chiffrement de bout en bout signifie que le serveur ne détient jamais de texte en clair
- Les futurs ordinateurs quantiques — tout l'établissement de clés de messages et les enveloppes de récupération DRA utilisent un KEM hybride post-quantique (X-Wing : X25519 + ML-KEM-768). Le texte chiffré enregistré aujourd'hui ne pourra pas être déchiffré rétroactivement par un futur ordinateur quantique — « récolter maintenant, déchiffrer plus tard » est fermé. Les primitives classiques ne subsistent que dans l'authentification (connexion et signatures), où une future rupture quantique constituerait un risque de falsification à ce moment-là, jamais un risque de déchiffrement rétroactif du trafic enregistré.
- Divulgation forcée à Canium — Canium ne peut pas produire ce qu'il ne possède pas
Ce contre quoi Canium ne protège pas
Canium ne protège pas contre :
- La compromission de l'appareil propre de l'utilisateur (la sécurité des points de terminaison est de la responsabilité de l'utilisateur)
- La divulgation DRA où l'agent de conformité de l'organisation agit légalement
- L'ingénierie sociale visant l'utilisateur
Standards et conformité
| Standard / Cadre | Statut |
|---|---|
| LPRPDE | Architecture conçue pour la conformité |
| Résidence des données de communications | Canada — messagerie, clés de chiffrement et contenu des canaux |
| Résidence des données de facturation | Selon le processeur de paiement — actuellement basé aux États-Unis ; migration vers un processeur canadien prévue pour les clients d'entreprise et gouvernementaux nécessitant une résidence complète des données de facturation |
| IETF RFC 9420 (MLS) | Implémenté via OpenMLS |
| IETF RFC 9807 (OPAQUE) | Implémenté via opaque-ke (bibliothèque auditée par NCC Group) |
| NIST ML-KEM-768 (FIPS 203) | KEM hybride post-quantique (combinateur X-Wing avec X25519) pour tout l'établissement de clés de messages MLS et les enveloppes de récupération DRA |
| AES-256-GCM | Chiffrement des messages |
| CCCS / Gouvernement du Canada | Marché cible ; préparation à l'approvisionnement en cours |
Piste d'audit
Chaque opération de changement d'état cryptographique émet un événement d'audit structuré. Ceux-ci comprennent les événements d'authentification (succès/échec de connexion, changement de mot de passe, réinitialisation), les événements de matériel de clé (consommation de package de clé, utilisation de clé de secours), et toute opération de divulgation DRA. Les journaux d'audit sont infalsifiables et disponibles pour les agents de conformité.