Comprendre ce qui
protège vos échanges.

Protéger le contenu, les clés et leur utilisation.

Une conversation privée ne se résume pas à une icône de cadenas. Elle dépend de plusieurs protections qui doivent fonctionner ensemble : ce qui est chiffré, où résident les secrets, qui peut recevoir les clés et ce qui se passe quand un appareil disparaît.

L’architecture de CryptoMail vise trois objectifs complémentaires. D’abord, chiffrer les données avant leur stockage ou leur transport. Ensuite, cloisonner les contextes cryptographiques pour ne pas faire dépendre tous les échanges d’une unique clé de contenu. Enfin, donner des choix lisibles sur le réseau, la conservation et la récupération.

Le chiffrement du contenu et celui du transport ont des rôles différents. Une connexion HTTPS protège un trajet entre l’application et un service. Le chiffrement de bout en bout vise à réserver le déchiffrement aux appareils autorisés des participants. Une base chiffrée, à elle seule, ne démontre pas que l’opérateur ne possède pas les moyens de lire les données.

Ces distinctions guident la présentation du produit. La partie locale du coffre est écrite; les protections de messagerie sont encore à porter ou à intégrer au mobile. Ce dossier décrit donc des mécanismes de référence et l’architecture cible, avec leur état indiqué en fin de page.

Un profil hybride pour préparer l’ère post-quantique.

Le profil visé combine ML-KEM-768 et X25519 pour établir les secrets de communication. Le principe hybride associe une composante post-quantique et une composante classique. Ce n’est pas une double copie du message : il s’agit de combiner des secrets au sein d’un protocole défini, puis d’utiliser des clés symétriques pour le contenu.

ML-KEM est standardisé dans FIPS 203. C’est un mécanisme d’encapsulation de clés, pas l’algorithme qui chiffre directement chaque photo ou chaque ligne de texte. Le contenu peut ensuite être protégé par un chiffrement authentifié comme AES-256-GCM. Référence : standard ML-KEM du NIST ↗

L’intérêt de préparer cette transition est de ne pas limiter la conception aux seules techniques classiques d’établissement de clés. Le choix d’un algorithme ne suffit toutefois pas : combinaison des secrets, validation des clés reçues, implémentation et protection contre les retours vers un profil plus faible doivent aussi être évaluées.

La base de référence contient un chemin hybride conditionné au support cryptographique de l’environnement. Le client CryptoMail n’a pas encore cette intégration native opérationnelle. Une bibliothèque maintenue, des tests d’interopérabilité et une revue indépendante sont nécessaires avant de présenter le profil comme disponible.

Chaque conversation, son contexte de clés.

Le protocole de référence associe les sessions à une conversation et aux appareils participants. Cela permet de distinguer le contexte d’un échange de celui d’un autre. Les décisions de sécurité ne reposent donc pas seulement sur un mot de passe de compte commun à toute la messagerie.

À l’intérieur d’une session, Double Ratchet fait évoluer les clés de message. Les chaînes d’envoi et de réception avancent au fil des échanges, avec des compteurs et un traitement explicite des messages reçus dans le désordre. Des enveloppes de clés permettent de viser les appareils autorisés.

Cette évolution vise à limiter l’exposition liée à une clé donnée. Elle doit être accompagnée d’une gestion correcte des anciennes clés, des messages en attente, des sauvegardes et des changements d’appareil. Une chaîne de clés ne protège pas un texte déjà affiché ou copié sur un téléphone compromis.

Pour les groupes, les membres et les appareils destinataires doivent être traités explicitement. Retirer une personne peut empêcher l’accès aux clés de futurs messages selon le protocole, mais ne retire pas ce qu’elle a déjà reçu. Le portage mobile devra vérifier ces frontières, au lieu de promettre une suppression rétroactive universelle.

Savoir à quelles clés vous faites confiance.

Un nom de profil, une photo ou une adresse courriel ne suffisent pas à authentifier une clé cryptographique. L’architecture reprend la vérification d’empreintes de clés d’appareil afin de permettre aux participants de contrôler le correspondant et les appareils auxquels ils accordent leur confiance.

Un changement de clé peut être légitime, par exemple après un remplacement de téléphone. Il peut aussi être inattendu. Le produit doit distinguer ces situations, signaler le changement et permettre une nouvelle vérification avant de poursuivre une conversation sensible.

La base comporte également un journal de transparence signé, des vérifications de continuité et des mécanismes de témoins. Leur objectif est de rendre les évolutions de clés vérifiables. Le niveau de garantie dépend de la configuration, de l’ancrage des clés de confiance et du contrôle effectué par le client.

Ces fonctions ne remplacent pas la confirmation d’identité entre personnes. Pour un échange important, comparer une empreinte par un canal déjà fiable reste une étape distincte de la simple connexion au compte. L’interface mobile de CryptoMail doit encore intégrer ce parcours et son comportement en cas d’anomalie.

Le direct P2P : un trajet, pas une formule magique.

L’objectif du mode direct est que les appareils connectés puissent s’échanger les données sans serveur applicatif dans le chemin du contenu. Une conversation peut ainsi utiliser un canal appareil-à-appareil lorsque la connexion réseau est réalisable et que le mode a été choisi.

Cela ne veut pas dire qu’aucun service n’intervient. La mise en relation peut utiliser une signalisation; la découverte du trajet peut s’appuyer sur ICE et STUN. Si le direct échoue et qu’un relais TURN est autorisé, les paquets empruntent alors un relais. Le mode réellement utilisé doit rester visible.

Le P2P protège certains aspects du trajet mais peut exposer l’adresse IP publique d’un participant à son correspondant. Un relais peut éviter ce trajet direct entre eux, tout en voyant ses propres métadonnées de connexion. Le chiffrement du contenu doit rester indépendant de ce choix. Référence : considérations de sécurité WebRTC ↗

La base de référence possède des appels WebRTC et des politiques de transport. L’envoi de texte observé utilise encore une API d’enveloppes chiffrées. La messagerie directe par canal de données reste donc une intégration à terminer pour CryptoMail, pas une capacité déjà validée sur téléphone.

Le coffre et les notes : chiffrer avant de conserver.

Le coffre local de la base CryptoMail chiffre les fichiers par blocs en AES-256-GCM. Les métadonnées, dont les noms, sont protégées elles aussi. Les notes sont enregistrées dans cet espace chiffré; elles peuvent contenir du texte, des listes, des quantités ou des montants.

La clé racine est conservée au moyen du stockage sécurisé du système avec authentification biométrique. Le code abandonne la session au verrouillage, à la mise en arrière-plan et après une période d’inactivité. Les essais sur appareils doivent confirmer le comportement réel du système, des capteurs et des protections de capture d’écran.

Importer un fichier crée une copie chiffrée dans le coffre. Cela ne supprime pas silencieusement l’original dans vos photos ou chez votre fournisseur de documents. De même, exporter une copie déchiffrée vers une autre application la fait sortir de la protection du coffre.

Le chiffrement au repos protège surtout les données lorsqu’elles ne sont pas en cours d’utilisation. Une autre application recevant un export, un appareil déjà compromis ou une capture du contenu affiché représente un autre périmètre. Les contrôles système complètent le coffre sans transformer le téléphone en environnement inviolable.

Choisir la conservation, comprendre l’expiration.

La base de messagerie prévoit des durées de rétention par conversation et des échéances pour les messages. Cette politique permet de définir une conservation limitée plutôt que d’accumuler systématiquement tous les échanges sans fin.

Un message éphémère n’est pourtant pas une garantie d’effacement partout. Un destinataire peut avoir pris une capture, exporté une pièce jointe ou conservé une copie avant l’échéance. Les sauvegardes et les appareils hors ligne doivent aussi avoir des règles explicites.

CryptoMail devra présenter le périmètre exact de l’expiration : ce qui est retiré de l’appareil, du service, des enveloppes de clés et des sauvegardes. Les nouveaux réglages ne doivent pas être annoncés comme une destruction rétroactive de toutes les copies existantes.

Le choix de ne pas télécharger automatiquement certains médias constitue une autre mesure de maîtrise. Il évite de confondre réception d’un message, ouverture d’un fichier et enregistrement durable sur l’appareil. Les parcours mobiles doivent encore être validés ensemble.

La phrase d’urgence et la récupération des clés.

La fonction prévue utilise une phrase distincte du déverrouillage habituel pour déclencher la destruction de clés locales sélectionnées. Lorsqu’il n’existe plus de copie récupérable d’une clé, les données qu’elle protégeait peuvent devenir illisibles. Ce mécanisme est appelé effacement cryptographique.

La référence comporte l’intention d’une phrase d’urgence, mais le flux destructif y est désactivé. CryptoMail doit encore définir précisément quelles clés seraient concernées, comment prévenir un déclenchement accidentel et comment les sauvegardes ou un kit de récupération interagiraient avec cette action.

Ce dispositif n’est pas un effacement à distance garanti des appareils d’autres personnes. Il ne peut pas faire disparaître une capture déjà envoyée, une exportation ou une sauvegarde indépendante. Son efficacité dépend de l’absence de copies utilisables des clés visées et du modèle de stockage réel.

La récupération répond au besoin inverse : retrouver l’accès après la perte d’un appareil. Elle doit rester un choix explicite, avec un secret détenu par l’utilisateur et un périmètre clair. Une sauvegarde conservant une clé récupérable peut contredire un objectif d’effacement définitif. Ces deux parcours doivent être conçus ensemble avant leur activation.

Le courriel et le réseau ont leurs propres frontières.

Un message entre deux utilisateurs compatibles peut suivre un protocole de chiffrement de bout en bout. Un courriel Internet envoyé à une adresse externe n’adopte pas automatiquement ce protocole. TLS protège des liaisons de transport; il ne signifie pas, à lui seul, que seuls les appareils des correspondants peuvent lire le contenu.

Le service doit donc distinguer les échanges internes protégés par un protocole compatible des courriels externes et de leur méthode réelle de protection. Les identités, les destinataires multiples, les pièces jointes et les brouillons doivent être traités avec les mêmes frontières d’accès.

Le projet d’accès Tor/.onion vise une autre couche : le trajet réseau et certaines métadonnées. Il ne remplace pas les clés de contenu et n’efface pas les informations qu’un utilisateur choisit lui-même de communiquer. Aucun service onion CryptoMail n’est annoncé comme actif à ce stade.

Le mode Tor prévu devra évaluer l’ensemble des flux : résolution des noms, connexions au service, notifications et éventuels canaux directs. Ouvrir le site dans Tor ne prouve pas que l’application mobile ou ses connexions P2P utilisent Tor.

Ce qui existe. Ce qui reste à terminer.

La confiance repose aussi sur la visibilité de l’avancement. Une fonction présente dans une base de référence n’est pas automatiquement disponible, testée et auditée dans CryptoMail. Voici le périmètre de cette présentation.

Les tests logiciels locaux ne remplacent ni une recette sur plusieurs appareils et réseaux, ni un audit indépendant du protocole, des bibliothèques et du serveur. CryptoMail ne revendique actuellement aucune certification de sécurité, aucun audit externe terminé ni garantie d’inviolabilité.