L’étendue de l’exposition dépend du type de clé et de la durée d’accès de l’attaquant ; un ratchet ne garantit pas qu’un seul message soit menacé.
Un chiffrement solide exige aussi une exécution correcte sur l’appareil. Une vulnérabilité du système d’exploitation, de l’implémentation cryptographique ou du matériel peut ouvrir un accès aux données sensibles ; toutefois, les recherches sur les attaques contre les processeurs ne permettent pas de conclure que tous les téléphones ou services de messagerie sont vulnérables de la même manière.
Les questions utiles sont les suivantes : de quel accès l’attaquant dispose-t-il, quelle clé ou quel texte en clair peut-il voir, et son accès est-il temporaire ou persistant ? Les réponses comptent davantage que le nom de l’algorithme.
Quelle différence entre canal auxiliaire et extraction de mémoire ?
Lors d’une extraction directe de mémoire, l’attaquant peut éventuellement lire certaines parties de la mémoire d’un processus ou de l’appareil. Une attaque par canal auxiliaire utilise des indices tels que le temps d’exécution des opérations ou le comportement du cache pour déduire des informations. Ces deux approches n’ont pas nécessairement les mêmes prérequis ni les mêmes résultats.
Les travaux originaux sur FLUSH+RELOAD ont étudié le comportement du cache et les pages mémoire partagées dans un environnement expérimental précis, et montré l’extraction d’une clé depuis une version de GnuPG. Ce résultat n’est ni un test de sécurité de Livara ni une preuve de vulnérabilité de tous les processeurs de téléphones.
| Type d’accès | Question nécessaire à l’évaluation |
|---|---|
| Exécution d’une application ordinaire sur le même appareil | L’isolation des processus et les prérequis de l’attaque permettent-ils l’observation ? |
| Accès privilégié au système d’exploitation | Quelles données ou opérations sur les clés deviennent accessibles à l’attaquant ? |
| Accès physique ou en laboratoire | Quels sont l’état de verrouillage, le modèle matériel et les protections des clés ? |
| Accès persistant à l’application | L’attaquant peut-il à nouveau recueillir des textes en clair ou des clés récents ? |
Sans ces précisions, l’expression générale « piratage de la RAM » ne constitue pas une explication technique suffisante.
En quoi Keystore et le matériel sécurisé sont-ils utiles ?
Android Keystore peut restreindre l’utilisation des clés et, sur les appareils adaptés, effectuer des opérations avec un support matériel. Dans cette conception, une clé non extractible n’est pas pour autant inutilisable par un attaquant : dans certaines circonstances, une application compromise peut abuser des opérations autorisées avec la clé, même sans en extraire les octets. Guide Android Keystore.
Toutes les clés et tous les algorithmes ne sont pas non plus automatiquement placés dans du matériel sécurisé. Il faut préciser le type de clé, la prise en charge par l’appareil et l’usage qu’en fait l’application. Dire que « la clé est sur l’appareil » ne prouve à soi seul ni son emplacement ni son niveau de protection.
Une clé exposée ne révèle-t-elle qu’un seul message ?
L’exposition d’une clé de message indépendante a parfois une portée limitée. Mais si l’attaquant obtient une clé de chaîne, l’état de session, une clé d’identité, un historique lisible ou plusieurs tampons, le résultat diffère. Sans identifier les données exposées, on ne peut donc pas affirmer qu’« au maximum un message » est menacé.
Changer de clé pour chaque message ne coupe pas nécessairement l’accès de l’attaquant. Si les clés suivantes dérivent d’un état qu’il possède, ou s’il reste présent sur l’appareil, il peut aussi accéder aux messages ultérieurs. La protection du passé et le rétablissement de la sécurité future sont deux propriétés distinctes, assorties d’hypothèses précises.
Quelles sont les limites des ratchets et du nettoyage de la mémoire ?
Un ratchet peut faire évoluer les clés au fil d’une conversation. Le rétablissement après une exposition nécessite des informations nouvelles auxquelles l’attaquant n’a pas accès ; le simple envoi d’un message ne démontre pas que cette condition est remplie. La spécification Double Ratchet explique le rétablissement ainsi que les risques liés à un accès persistant et à la récupération de données supprimées.
Raccourcir la durée de vie des données sensibles et nettoyer les tampons est utile, mais cela ne permet pas d’affirmer de manière générale que toutes les copies en RAM ont été effacées. Les bibliothèques, le langage de programmation et les chemins d’affichage doivent être examinés.
Que peut-on dire de Livara ?
La page de sécurité de Livara décrit la construction hybride et l’évolution des clés dans LVR1. Cet article n’est ni un test de canal auxiliaire, ni un audit de mémoire, ni une confirmation que toutes les clés utilisent Keystore. En particulier, la documentation publique du modèle de menace ne garantit pas la protection d’un appareil compromis.
Il ne faut donc pas attribuer au produit des promesses telles que « le message suivant neutralise une compromission matérielle » ou « au maximum un message est exposé », sans éléments précis pour la version et le scénario concernés.
Les décisions pratiques pour l’utilisateur
Maintenez le système d’exploitation et l’application à jour, choisissez un appareil bénéficiant d’un suivi de sécurité actif, évitez les installations non fiables et les autorisations inutiles, et utilisez un verrouillage approprié. Si une compromission grave est suspectée, changer de messagerie ou envoyer un nouveau message ne remplace pas l’examen et l’assainissement de l’appareil.
Face à une affirmation de sécurité, demandez quatre éléments : la version testée, l’accès de l’attaquant, les données exposées et les limites du résultat. Le nom d’un processeur ou d’une norme de chiffrement ne répond pas à lui seul à ces quatre questions.
