Récupérer un compte, une identité et un historique de conversations sont des opérations différentes ; vérifiez laquelle le produit prend réellement en charge.
La récupération d’identité cryptographique restaure le matériel de clé associé à votre identité de messagerie. Elle ne revient pas automatiquement à se reconnecter à un compte, à restaurer toutes les conversations ou à prouver qu’un appareil de remplacement est sûr.
Une sauvegarde chiffrée de clés peut permettre à un serveur de stocker un paquet récupérable sans détenir le secret nécessaire pour l’ouvrir. La protection offerte à l’utilisateur dépend de la génération des clés, de l’authentification, de la conservation du secret de récupération et de la manière dont le client traite l’identité récupérée.
Trois choses que l’on appelle « récupération »
| Objectif de récupération | Ce qui doit être restauré ou autorisé |
|---|---|
| Accès au compte | Autorisation de se connecter et d’utiliser le service |
| Identité cryptographique | Les clés privées appropriées ou une nouvelle identité authentifiée |
| Historique des discussions | Les données des messages et les clés ou l’état nécessaires pour les lire |
Une connexion réussie ne prouve aucun des deux autres résultats. De même, une clé d’identité ne recrée pas nécessairement d’anciennes clés de messages volontairement effacées ni un fichier d’historique qui n’existe plus.
Notez quel objectif la fonction de récupération d’un produit promet réellement avant de vous y fier.
Comment une sauvegarde d’identité chiffrée peut fonctionner
Une conception courante génère le matériel d’identité sur un appareil de confiance, chiffre une sauvegarde à l’aide d’un secret de récupération distinct et ne stocke auprès du service que le paquet protégé. Un appareil de remplacement récupère le paquet et utilise localement le secret de récupération.
Le serveur peut toujours contrôler l’accès au paquet, observer les requêtes, retenir des données ou renvoyer une ancienne version. Le chiffrement authentifié et la liaison à la version et à l’identité aident à traiter certains risques de manipulation ; la disponibilité et la gestion des retours à une ancienne version nécessitent leur propre conception. « Chiffré sur le serveur » ne constitue pas une réponse complète à tous les scénarios de compromission du serveur.
Une clé de récupération aléatoire à forte entropie et un mot de passe choisi par une personne sont également des entrées différentes. Ne présentez pas HKDF comme une méthode transformant toute phrase de passe faible en secret robuste. La RFC 5869 explique le rôle de HKDF et le distingue de l’étirement des mots de passe.
Ce que dit la documentation v7 de Livara
La page de sécurité de Livara indique que ses clés P-256 d’accord de clés et de signature ainsi que sa graine ML-KEM sont chiffrées sur l’appareil, sous une clé de récupération aléatoire de 256 bits, avant leur envoi. Le format v7 authentifie notamment la suite, l’époque d’identité et la génération.
Cette même page est explicite : il restaure l’identité, pas l’historique des discussions. Elle précise aussi qu’un mot de passe de connexion correct ne suffit pas, à lui seul, à ouvrir la sauvegarde chiffrée de clés ; la clé de récupération représentée par la phrase de récupération est nécessaire.
Il s’agit d’affirmations publiées sur le produit, et non d’un nouvel audit du format de sauvegarde ou de toutes les voies de récupération. Le modèle de menace, plus général, doit être lu conjointement à cette description plus ciblée de la récupération.
Où intervient SRP
Le modèle d’authentification SRP concerne la connexion par mot de passe. Il peut éviter de transmettre le mot de passe lui-même dans l’échange prévu par le protocole, mais ne définit ni le contenu d’une sauvegarde de clés ni la dérivation automatique de chaque clé de récupération.
Son vérificateur côté serveur doit toujours être protégé. La RFC 5054, section 3.3 décrit le risque de deviner les mots de passe après le vol d’un vérificateur. Ne transformez pas « le serveur ne reçoit pas le mot de passe dans cet échange » en « une intrusion sur le serveur ne peut révéler aucune information utile ».
Les sessions de compte, les paquets de récupération, les métadonnées opérationnelles et le logiciel client constituent des actifs distincts, avec des modes de défaillance distincts.
Liste de préparation à une récupération sûre
- Confirmez précisément quelles données la fonction restaure et lesquelles elle ne restaure pas.
- Conservez le secret de récupération à un endroit où perdre le téléphone ne signifie pas perdre aussi l’unique copie.
- Évitez de placer le secret dans un message, un ticket d’assistance ou une capture d’écran publique.
- Protégez l’endroit où le secret est conservé ; quiconque l’obtient peut acquérir des capacités importantes s’il obtient aussi la sauvegarde correspondante et l’accès nécessaire.
- Consultez les instructions officielles de récupération avant d’effacer ou de remplacer le seul appareil fonctionnel.
- Ne testez qu’avec les procédures prises en charge, sans détruire l’unique copie de données importantes.
Après la récupération, examinez séparément les appareils liés et les sessions. Le matériel d’identité récupéré ne révoque pas automatiquement un ancien appareil. Si l’identité cryptographique change, les contacts échangeant des informations sensibles doivent vérifier la nouvelle clé par une voie de confiance indépendante.
Si la phrase de récupération est perdue
Ne supposez pas que l’assistance peut recréer un secret que le système a été conçu pour ne pas conserver. Ne supposez pas non plus que tout oubli d’un mot de passe de compte signifie que tous les messages locaux ont déjà disparu. Le résultat dépend des appareils restants, des sauvegardes disponibles et des règles documentées du produit.
La question utile est précise : « Quel secret ou quelle copie manque, et quel objectif de récupération reste possible ? » Elle apporte une réponse plus sûre qu’une promesse générale selon laquelle la récupération serait soit sans effort, soit impossible.
