Sous le capot
Comment C-Connect chiffre, transporte et protège vos messages : les choix techniques, les algorithmes, et les briques open source sur lesquelles tout repose.
Des briques cryptographiques open source, partout
Tout le chiffrement de C-Connect et de Chiffre AES repose sur quatre bibliothèques écrites en Rust, publiques et auditables, sous double licence MIT ou Apache-2.0. Ce sont les mêmes partout : dans l'application, le serveur, les outils d'administration et Chiffre AES. Pas de cryptographie « maison » cachée, pas de variante par produit.
| Bibliothèque | Rôle | Utilisée par |
|---|---|---|
| chiffre-aes-core | Chiffrement authentifié AES-256-GCM, dérivation de clé Argon2id, format de fichier .enc par blocs (détecte modification, corruption, troncature, réordonnancement) | application, outils, Chiffre AES |
| chiffre-rsa-core | Clés RSA-4096, signatures RSA-PSS (SHA-256), scellement de clé RSA-OAEP (SHA-256), empreintes | application, serveur, outils |
| chiffre-rsa-enveloppe | Enveloppe hybride : une clé de contenu aléatoire chiffre le message (AES-256-GCM), elle-même scellée en RSA-OAEP pour chaque destinataire | application |
| chiffre-rsa-keystore | Documents de clé : identités signées par l'administrateur, clé racine d'une organisation, signatures et vérifications | application, outils |
Le code des applications et du serveur n'est pas publié à ce jour ; leurs dépendances sont listées, avec leurs licences, dans l'écran Informations de chaque programme.
C-Connect, l'application
Un cœur Rust, deux interfaces
Toute la logique (clés, chiffrement, signatures, contacts, conversations, file d'envoi, synchronisation) est dans un cœur unique en Rust, partagé par l'ordinateur et Android : un seul code pour la sécurité. L'interface de bureau (Windows, Linux) est en Slint ; celle d'Android en Kotlin / Jetpack Compose, reliée au cœur par UniFFI. Android n'ajoute que l'affichage, les sélecteurs de fichiers, la biométrie et les notifications.
Chaque message
Le texte est signé par l'expéditeur (RSA-PSS), puis chiffré par une clé de contenu aléatoire (AES-256-GCM, format .enc) ; cette clé est scellée pour chaque destinataire avec sa clé publique (RSA-OAEP). Le serveur reçoit un fichier opaque. À l'arrivée, l'application déchiffre, vérifie la signature et l'identité de l'expéditeur (certifiée par l'administrateur), puis accuse réception.
Vos clés restent chez vous
La clé privée (RSA-4096) est stockée chiffrée par son propre mot de passe (Argon2id + AES-256-GCM), distinct du mot de passe de l'application. Elle n'est jamais envoyée au serveur. Sur Android : stockage privé de l'application, ni sauvegarde dans le cloud ni transfert d'appareil, verrouillage 60 secondes après le passage en arrière-plan, biométrie liée à l’Android Keystore.
La connexion au serveur
HTTPS en TLS 1.3 uniquement (rustls sur ordinateur, OkHttp sur Android), avec épinglage de la clé du serveur. Pas de mot de passe : l'application prouve son identité en signant un défi avec sa clé ; le serveur répond par un jeton de session dont il ne garde que l'empreinte. Le serveur ne connaît l'utilisateur que par un identifiant anonyme.
Le serveur
Une API Rust, minimale
Serveur écrit en Rust (axum, tokio), TLS 1.3 par rustls, base SQLite intégrée. Il authentifie, reçoit, garde le temps de la remise, puis efface après accusé de réception. Il ne déchiffre jamais rien et ne détient aucune clé privée : seulement les clés publiques des membres, dans des certificats anonymes signés par l'administrateur de l'organisation. Quarantaine des messages refusés, journal des actions d'administration, licence signée, limitation de débit, horloge vérifiée.
Hébergement isolé
Sur nos VPS (Debian), chaque organisation a son instance : un conteneur Podman, sous un compte système dédié, avec sa propre base et sa propre clé TLS. Un relais HAProxy aiguille les connexions d'après le nom demandé, sans déchiffrer le flux TLS, qui va de l'application jusqu'à l'instance. Serveur chez vous : il ouvre un tunnel WireGuard sortant vers le relais ; aucun port n'est ouvert chez vous.
Notifications sans contenu
Les notifications Android passent par UnifiedPush et l'application libre ntfy, sans aucun service Google. Elles ne contiennent rien (ni texte, ni expéditeur) : un simple « quelque chose vous attend ». Une passerelle dédiée est le seul service autorisé à publier sur ntfy ; elle reconnaît chaque instance par sa prise locale, ou par son jeton à travers le tunnel.
Atelier et Console
Atelier : l'outil de l'administrateur, sans aucune bibliothèque réseau (vérifié à chaque construction) ; il garde la clé racine de l'organisation et signe membres et opérateurs. Console : l'outil de l'opérateur ; connexion épinglée au port d'administration du serveur, authentification par défi signé, droits délégués et limités dans le temps par l'administrateur.
Chiffre AES
Chiffre AES protège vos fichiers avant de les confier à n'importe quel canal (courriel, clé USB, stockage en ligne). Il utilise directement la bibliothèque open source chiffre-aes-core : la clé de chiffrement est dérivée de votre mot de passe par Argon2id, volontairement coûteux pour décourager les essais en masse ; les données sont chiffrées en AES-256-GCM, bloc par bloc, dans un conteneur .enc versionné qui détecte toute modification, corruption, troncature ou réordonnancement. Interfaces : Slint (Windows, Linux), Kotlin/Compose avec un pont Rust (Android). C'est le même moteur qui protège, dans C-Connect, le contenu des messages et votre clé privée.
L'épinglage TLS : pourquoi, et ses limites
Sur Internet, un site est d'ordinaire reconnu grâce à une autorité de certification : il suffit qu'une seule des centaines d'autorités acceptées par votre appareil délivre un faux certificat pour qu'un imposteur soit cru. C-Connect ne fait confiance à aucune autorité : chaque application connaît l'empreinte exacte de la clé de son serveur (l'« épingle ») et refuse tout le reste.
Ce que l'épinglage empêche
- Un faux certificat, même émis par une autorité reconnue ou installé sur l'appareil.
- Un détournement DNS vers un faux serveur.
- Une interception par un proxy d'entreprise ou un réseau hostile.
L'épingle est remise dans un document signé par la clé de votre organisation, et vérifiée de vive voix entre l'exploitant et votre administrateur : la confiance reste dans votre organisation.
Ses limites, en toute transparence
- Vol de la clé TLS d'un serveur : un attaquant placé sur le réseau pourrait se faire passer pour lui. Il ne lirait aucun message (chiffrement de bout en bout), mais verrait qui se connecte et quand, et pourrait bloquer la remise.
- Pas de révocation à distance : une nouvelle épingle se diffuse par un nouveau document à chaque membre.
- Les notifications ne sont pas épinglées (certificat Let's Encrypt) : elles ne contiennent rien.
Évolution prévue : une épingle de secours (le protocole en accepte jusqu'à quatre), pour changer de clé sans couper personne.