Le résultat forensique dépend de l’état réel de l’appareil et des clés, pas simplement du nom d’une base de données ou d’un algorithme.
Le chiffrement de bout en bout et la protection des données locales sont deux questions liées mais différentes. Un message protégé pendant son transport sur le réseau doit devenir lisible pour être affiché sur un appareil. Le résultat d’une analyse forensique dépend de l’état de l’appareil, du type d’accès, des versions du système et de l’application, ainsi que de l’emplacement des clés ; aucun nom d’algorithme ne détermine à lui seul ce résultat.
L’affirmation « un accès physique permet de tout lire immédiatement » comme la promesse « aucune extraction n’est jamais possible » appellent donc à la prudence.
Examinez séparément quatre couches de protection
| Couche | Fonction principale | Limite importante |
|---|---|---|
| E2EE des messages | Protéger le contenu entre les appareils des participants | Ne garantit ni l’intégrité de l’appareil ni la protection des copies locales |
| Isolation des applications | Limiter l’accès des applications ordinaires aux données des autres | Un accès privilégié ou une vulnérabilité peut modifier le modèle |
| Chiffrement des fichiers ou du disque | Protéger les données stockées dans des conditions précises | Le verrouillage et la disponibilité des clés comptent |
| Chiffrement de la base dans l’application | Ajouter une frontière de protection au fichier de base de données | Le stockage et l’utilisation de la clé sont déterminants |
La documentation FBE d’Android distingue le stockage dépendant des identifiants de l’utilisateur de celui disponible pendant Direct Boot. « Le téléphone est verrouillé » ne suffit pas à connaître l’état de toutes les clés ; le fait que le premier déverrouillage après démarrage ait eu lieu ou non peut aussi compter.
Que prouve un fichier SQLite ?
SQLite est un format et un moteur de stockage, pas une étiquette indiquant à elle seule la présence ou l’absence de toutes les protections. Le fichier peut se trouver dans un espace chiffré par le système d’exploitation ou être protégé par une solution distincte.
Supprimer une ligne n’efface pas non plus nécessairement toutes ses traces dans tous les fichiers. La documentation SQLite explique les paramètres de suppression sécurisée et les limites des tables virtuelles. Les fichiers annexes et sauvegardes doivent aussi être pris en compte dans l’examen du cycle de vie des données. Cela ne garantit pas la récupération de tout message supprimé sur n’importe quel téléphone.
N’exécutez pas de commandes de maintenance de base de données sur des données réelles sans connaître l’application ; modifier directement ses fichiers peut corrompre les données ou altérer les preuves.
SQLCipher et Keystore sont des solutions, pas des certificats d’immunité
SQLCipher est conçu pour le chiffrement transparent des bases de données, mais ses spécifications doivent être lues en fonction de la version. La page de conception de SQLCipher décrit une structure AES-CBC avec authentification ; la présentation de la version 5 bêta en septembre 2026 décrit le passage à AES-GCM. Attribuer un même mode de chiffrement à toutes les versions est donc inexact.
Android Keystore peut également protéger les clés et contrôler leur utilisation, mais il faut établir quelles fonctions et quel niveau matériel l’application emploie réellement. Mentionner StrongBox dans un article ne prouve pas son utilisation par le produit. Voir le guide Keystore.
Même une clé non extractible peut, dans certaines conditions, être utilisée via des opérations autorisées. « La clé ne peut pas être copiée » n’équivaut pas à « un attaquant ne peut déchiffrer aucune donnée ».
Quels rôles jouent la RAM et le ratchet ?
Limiter la durée de vie des clés et du texte sensible réduit les occasions d’exposition. Mais effacer un tampon ne prouve pas qu’aucune autre copie ne subsiste dans une bibliothèque, un aperçu ou le processus d’affichage.
La portée du ratchet varie aussi selon le type de clé compromis et la persistance de l’accès de l’attaquant. « Une clé distincte par message » n’implique pas qu’une capture mémoire expose au maximum un message. Le stockage d’un historique lisible sur l’appareil est une question distincte des clés de transport.
Qu’est-ce qui n’a pas été vérifié à propos de Livara ?
Le modèle de menace de Livara ne garantit pas la protection d’un appareil infecté ou déverrouillé. Cet article ne vérifie pas indépendamment qu’une version précise de Livara utilise SQLCipher ou StrongBox, efface entièrement la RAM ou ne conserve aucune donnée locale d’appel. Ces propriétés ne doivent pas être attribuées au produit sans rapports de tests et preuves d’implémentation.
Le paquet de récupération d’identité décrit dans la documentation de sécurité n’est pas non plus une sauvegarde de l’historique. Vérifier le hash d’un APK dans Proof Lab peut montrer que le fichier correspond à un hash de confiance ; ce résultat n’est ni un audit du stockage ni un test anti-forensique.
Quelles informations une affirmation forensique crédible doit-elle fournir ?
Demandez le modèle de l’appareil, les versions du système et de l’application, l’état du verrouillage, la méthode et le niveau d’accès, le type de données obtenues et les limites du test. L’échec d’un outil dans une expérience ne prouve pas l’impossibilité de toutes les méthodes ; un succès limité ne permet pas non plus de généraliser à tous les utilisateurs.
Pour un utilisateur ordinaire, les priorités sont les mises à jour, un verrouillage robuste, la réduction des copies supplémentaires de médias et la protection des moyens de récupération. Lors d’un incident grave, faites appel à un spécialiste autorisé avant toute action modifiant les données ou les preuves.
