L’agilité cryptographique est la capacité de faire passer un protocole d’une suite cryptographique à une autre sans perdre un cadre clair de garanties de sécurité. En messagerie, cela implique davantage que l’ajout d’un nouveau nom d’algorithme. Les anciens clients, les destinataires hors ligne, les messages stockés et les appareils associés doivent tous se comporter de façon prévisible pendant la transition.
La RFC 7696 de l’IETF décrit l’agilité algorithmique comme un problème de migration impliquant des identifiants, des implémentations et des changements opérationnels. Un numéro de version aide à identifier ce qui est utilisé ; il ne rend pas la migration sûre à lui seul.
Trois versions faciles à confondre
Une messagerie peut avoir une version de l’application, une version du protocole de communication et un identifiant de suite cryptographique. Ils répondent à des questions différentes :
| Identifiant | Ce qu’il indique à une personne chargée de l’examen | Ce qu’il ne démontre pas |
|---|---|---|
| Version de l’application | Quelle compilation du logiciel est installée | Que chaque conversation utilise le protocole le plus récent |
| Version du protocole | Quel format de message et quelles règles d’état s’appliquent | Que l’implémentation respecte correctement ces règles |
| Identifiant d’algorithme ou de suite | Quels composants cryptographiques sont sélectionnés | Que la négociation ne peut pas être rétrogradée vers une option plus faible |
Les notes de version devraient expliciter cette relation. « Nouveau chiffrement livré » est ambigu si seules les nouvelles conversations l’utilisent, ou si un ancien client associé provoque un retour à un mode antérieur.
Ce qu’une migration sûre doit préciser
Partons d’un scénario concret : Alice effectue la mise à jour aujourd’hui ; Bob reste hors ligne avec un ancien téléphone. Alice envoie un message, puis ajoute un second appareil. Que doit accepter, stocker et afficher chaque appareil ?
Une conception susceptible d’être examinée répond au moins aux questions suivantes :
- Comment chaque partie découvre-t-elle les versions prises en charge par l’autre ?
- La version sélectionnée est-elle authentifiée dans le cadre de la session ?
- Que se passe-t-il lorsqu’aucune version acceptable n’est commune aux deux parties ?
- Un relais malveillant peut-il supprimer une capacité et provoquer le recours à un mode plus faible ?
- Les anciens messages restent-ils lisibles, et quelles anciennes clés restent nécessaires ?
- La restauration d’une sauvegarde réactive-t-elle un état de protocole obsolète ?
- Quand les algorithmes dépréciés seront-ils désactivés, plutôt que simplement déconseillés ?
Un échec visible est souvent plus sûr qu’une transition silencieuse vers un mode non voulu par l’utilisateur. Mais le comportement exact en cas d’échec et lors de la récupération devrait être documenté afin que les personnes ne le contournent pas en passant à un canal non protégé.
Une matrice pratique de tests de mise à niveau
Une mise à niveau de sécurité exige davantage qu’une conversation réussie entre deux installations neuves. Testez ces cas avec des données non sensibles :
| Test | Éléments à consigner |
|---|---|
| Nouveau client vers ancien client | Protocole sélectionné ou résultat d’incompatibilité explicite |
| Destinataire hors ligne pendant la mise à niveau | Comportement de livraison et de déchiffrement après reconnexion |
| Retour d’un ancien appareil associé | S’il peut lire, envoyer ou imposer un mode inattendu |
| Ajout d’un membre incompatible à un groupe | Politique explicite du groupe et état visible par l’utilisateur |
| Sauvegarde restaurée après abandon d’anciens mécanismes | Si l’état non pris en charge est rejeté ou migré |
| Métadonnées de version altérées | Échec d’authentification plutôt qu’une rétrogradation inaperçue |
Il s’agit de critères d’évaluation, et non d’affirmations selon lesquelles un produit nommé aurait réussi ces tests. Conservez les identifiants de compilation et les résultats observés pour pouvoir distinguer une régression ultérieure d’une modification de la documentation.
Comment interpréter les noms de protocoles de Livara
Dans sa documentation de sécurité, Livara utilise le nom LVR1 pour les conversations directes et LGS1 pour les groupes privés. Ces noms distinguent les responsabilités ; ils ne doivent pas être interprétés comme la preuve d’une normalisation ou d’un audit indépendant. La page traite aussi du comportement des clients ou groupes qui ne peuvent pas satisfaire aux prérequis du mode chiffré.
Les prochains éléments utiles seraient une spécification versionnée, des vecteurs de test, des règles de compatibilité et des résultats d’examen rattachés à une version précise. Le Proof Lab indique explicitement la portée plus restreinte de sa démonstration. Exécuter des primitives dans un navigateur ne revient pas à tester tous les chemins de migration dans l’application.
Que faire pendant une mise à niveau du chiffrement ?
Gardez les clients pris en charge à jour, lisez les avis de sécurité concernant la compatibilité des appareils et soyez attentif aux changements des indicateurs d’identité ou d’état du chiffrement. Ne supposez pas qu’une nouvelle icône d’application signifie que tous les anciens groupes et toutes les sauvegardes bénéficient d’une nouvelle protection. Si le produit ne peut pas expliquer quelles données ont changé de protection, posez la question avant de partager des informations sensibles.
Une bonne agilité cryptographique rend le changement vérifiable. Elle indique ce qui a changé, comment les correspondants s’accordent sur ce changement, ce qui peut mal se passer et quand l’ancien mécanisme cesse d’être accepté.
