Le FBI a récupéré des messages Signal supprimés via les données de notification de l’iPhone

• Un cas où le FBI a récupéré des messages Signal supprimés en utilisant la base de données interne des notifications de l’iPhone a été révélé par un témoignage au tribunal
• Sur l’iPhone de l’accusée, le contenu des notifications Signal reçues était resté dans le stockage interne même après la suppression de l’application, alors que l’aperçu des notifications était désactivé
• En raison de l’état de sécurité de l’iPhone (AFU, BFU) et de la structure du cache local, certaines données peuvent subsister à l’intérieur du système
• Même après la suppression de l’application, le jeton de notification push n’est pas invalidé immédiatement, ce qui soulève la possibilité que le serveur ait continué à envoyer des notifications et que l’iPhone les ait reçues
• Cette affaire montre que la structure de conservation des données des applications de messagerie chiffrée et du système de notifications d’iOS devient un enjeu central de la sécurité de la vie privée

---

Cas du FBI ayant récupéré des messages Signal supprimés à partir des données de notification de l’iPhone

• Un cas où le FBI a récupéré des messages Signal supprimés via la base de données interne des notifications de l’iPhone a été rendu public
  • Selon 404 Media, cela a été révélé par un témoignage lors du procès d’une accusée impliquée dans une affaire de feux d’artifice et de dégradations au centre de détention ICE Prairieland à Alvarado, au Texas
  • L’agent du FBI Clark Wiethorn a expliqué au tribunal le processus de collecte des preuves

• Messages récupérés depuis les données de notification

  • Sur l’iPhone de l’accusée Lynette Sharp, le contenu des messages reçus était resté dans le stockage interne des notifications même après la suppression de l’application Signal
  • D’après le résumé des pièces versées au dossier (Exhibit 158), « Signal avait été supprimé, mais les notifications reçues avaient été conservées en mémoire interne via le stockage interne des notifications d’Apple, et seuls les messages reçus ont pu être récupérés »
  • Signal propose un réglage permettant de masquer le contenu des messages dans l’aperçu des notifications, mais il apparaît que l’accusée l’avait désactivé
  • Ni Signal ni Apple n’ont pris officiellement position sur la manière dont les données de notification sont stockées ou traitées

• Structure de stockage interne et contexte technique

  • Faute d’informations techniques précises sur l’état de l’iPhone de l’accusée, la méthode exacte utilisée par le FBI pour récupérer les données n’est pas claire
  • L’iPhone dispose de plusieurs états de sécurité, comme BFU (Before First Unlock) et AFU (After First Unlock), et les droits d’accès aux données varient selon l’état
  • Lorsque l’appareil est déverrouillé, le système part du principe que l’utilisateur l’utilise directement, ce qui élargit l’accès aux données protégées
  • iOS gère divers états de sécurité sur une base de confiance et, pour des raisons de confort d’usage, stocke localement beaucoup de données sous forme de cache

• Jeton de notification push et possibilité de persistance des données

  • Même si l’application est supprimée, le jeton utilisé pour l’envoi des notifications push n’est pas invalidé immédiatement

    • Le serveur ne peut pas savoir si l’application a été supprimée ; il peut donc continuer à envoyer des notifications après la dernière alerte, et l’iPhone peut les recevoir et les traiter en interne
    • Apple a récemment modifié la méthode de validation des jetons de notification push dans iOS 26.4 ; aucun lien direct avec cette affaire n’a été confirmé, mais la chronologie attire l’attention

• Possibilités d’extraction des données et outils d’enquête

  • Selon la description de l’Exhibit 158, le FBI a récupéré les données via le stockage interne des notifications d’Apple, ce qui pourrait être des informations extraites d’une sauvegarde de l’appareil
  • Les forces de l’ordre disposent de nombreux outils forensiques commerciaux capables d’extraire des données en exploitant des vulnérabilités iOS, et le FBI a pu y avoir recours
  • 404 Media a également publié séparément le rapport original sur cette affaire

• Signification de l’affaire

  • Ce cas attire l’attention comme un exemple montrant que ni la suppression d’une application de messagerie ni le chiffrement ne garantissent une suppression complète des données
  • La structure de conservation des données du système de notifications d’iOS et sa gestion de la sécurité pourraient devenir un enjeu central des futurs débats sur la vie privée

[GN⁺]

Réactions sur Hacker News

• Du point de vue de l’utilisateur, je pensais que Signal, grâce à la forward secrecy, faisait disparaître les messages une fois reçus.
  Mais si l’on n’active pas les disappearing messages, des outils de forensic comme Cellebrite peuvent les restaurer. Par défaut, l’option est désactivée.
  Même si elle est activée, le message peut être inclus dans une notification et donc stocké par l’OS. Apple l’a effectivement fait, et il existe une option pour l’empêcher, mais elle est elle aussi désactivée par défaut.
  Même si l’app est supprimée, les messages restent dans l’OS. Au final, quand l’équilibre entre sécurité et ergonomie s’effondre, ce n’est pas la faute de l’utilisateur mais un problème de conception du système, selon moi.
  J’ai réuni des cas liés à cela dans mon article.

  • Tant que les sauvegardes ne sont pas chiffrées, le chiffrement de bout en bout (E2EE) me semble être une illusion. Si votre correspondant n’utilise pas ADP, iMessage ou WhatsApp n’appliquent qu’un chiffrement du stockage.
    WhatsApp sur Android recommande aussi par défaut des sauvegardes non chiffrées sur Google Drive.
    Je me demande si Google, Apple et Meta n’ont pas mis en place, comme une sorte d’accord succédant à PRISM, une logique de « laisser l’E2EE exister, mais avec des réglages par défaut qui restent accessibles ».
    La plupart des utilisateurs gardent les réglages par défaut, donc au final la sécurité est neutralisée.
  • Même si Signal est très sûr, l’OS et l’écosystème sur lesquels il repose sont bien trop complexes pour être certain que l’on communique réellement de façon sécurisée.
    Les métadonnées (qui communique avec qui et à quel moment) restent elles aussi exposées.
  • Comme la plupart des utilisateurs ne changent pas les réglages par défaut, le niveau de sécurité réel d’une app est celui de ses valeurs par défaut.
  • Le fait que Signal mette le message en clair dans les notifications est encore plus grave.
    Comme l’explique cet article, les données sensibles ne devraient pas être incluses dans les notifications, ou alors il faudrait utiliser une payload chiffrée.
  • Si vous voulez vraiment une messagerie sûre, je recommande SimpleX. Whonix la recommande, et Snowden soutient aussi Whonix.
    Page de recommandation Whonix Chat

• Dans les réglages de Signal,
  Settings > Notifications > Notification Content > Show: en le passant à “Name Only” ou “No Name or Content”,
  les messages sensibles ne s’affichent pas quand on montre l’écran. À la lumière de cette affaire, ce réglage apporte aussi un avantage de sécurité supplémentaire.

  • Ce n’est pas un réglage de l’OS, mais un réglage interne à l’app Signal. Modifier seulement les réglages de notification du système bloque l’affichage à l’écran, mais le stockage interne continue.
  • Sur Android, cela se trouve dans Settings > Notifications > Messages > Show.
  • Le réglage par défaut devrait être le moins intrusif possible. Pour une app de sécurité, des valeurs par défaut sûres sont indispensables.
  • Il vaut aussi mieux désactiver les résumés d’Apple Intelligence pour les notifications d’apps sensibles.
  • Activer le mode Lockdown peut bloquer plusieurs vulnérabilités de ce type d’un coup.

• Si le réglage d’aperçu des notifications de Signal n’est pas désactivé, le système stocke le contenu du message dans une base de données.
  Sur macOS, on peut consulter cet historique des notifications dans ~/Library/Group Containers/group.com.apple.usernoted/db2/db.
  Avec l’app Crank, on peut l’extraire via des requêtes SQL.

  • Sur Android, on peut consulter l’historique des notifications avec des apps comme NotiStar.
    Mais une infrastructure centralisée de notifications comme FCM (APNs) peut aussi stocker les données au passage.
  • Sur Pixel, on peut voir une partie de l’historique dans Settings > Notifications > Manage > Notification History.
  • Sur iPhone, si l’affichage des aperçus est activé sur l’écran verrouillé, le contenu des notifications est stocké en clair.
    Le réglage par défaut est « aperçu au déverrouillage », mais même dans ce cas, on ne sait pas clairement si le stockage interne est chiffré.
    En fin de compte, il s’agit d’un problème d’OPSEC dû à une erreur de réglage utilisateur, et on peut considérer que les réglages par défaut de Signal étaient appropriés.
  • Sur Android, il existait autrefois une page d’adresse de protocole qui montrait toutes les notifications. C’était utile, mais ce n’est plus vraiment utilisé aujourd’hui.

• Je me suis demandé pourquoi Signal continuait à me demander chaque mois d’activer les notifications.
  Même après avoir refusé, la demande revenait sans cesse.

  • D’après les développeurs de Signal, c’est parce qu’ils reçoivent beaucoup de signalements liés à la fiabilité des notifications, et ils veulent éviter que des utilisateurs les aient désactivées par erreur. Cela dit, la fréquence semble excessive.
  • Mais la plupart des logiciels font passer les intérêts des développeurs ou des entreprises avant la volonté de l’utilisateur.
    Continuer à pousser quelque chose dont l’utilisateur ne veut pas est désormais un motif UX très courant.
  • Une plateforme de messagerie a plus de succès quand les utilisateurs répondent immédiatement ; les inciter à activer les notifications est donc une stratégie naturelle.
  • iOS lui-même est aussi conçu pour redemander périodiquement de vérifier quand les notifications sont désactivées.
  • Les demandes périodiques, comme le PIN 2FA de WhatsApp, relèvent d’une logique similaire.

• Je pense que les témoignages en justice sont le vrai moyen de vérifier l’état réel de la sécurité.
  Plus que les débats théoriques, ce qui compte, c’est de voir quelles données sont effectivement restaurées dans des affaires réelles.

  • Cela dit, il arrive aussi que les autorités abandonnent les poursuites pour éviter de révéler leurs moyens cyber, donc tout n’est pas rendu public.
  • Le tribunal reste l’un des rares lieux où de vrais détails techniques sont parfois dévoilés.
  • L’affaire récente Trivy / LiteLLM concernait aussi un sujet de sécurité, mais d’une autre nature.
  • Dans des États corrompus, toutefois, les décisions de justice peuvent ne pas refléter la réalité. La parallel construction existe.

• La phrase « l’accusé n’avait pas activé le réglage, donc le système a stocké les messages » signifie en réalité que le vrai problème, ce sont les réglages par défaut d’Apple.
  La plupart des utilisateurs ne changent pas les réglages, et Apple le sait.

  • Le pire, c’est que des réglages de sécurité modifiés avec difficulté sont réinitialisés à chaque mise à jour. Les réglages de confidentialité de Firefox reviennent eux aussi souvent en arrière de cette façon.
    Même si ce n’est pas intentionnel, nous devons agir comme si ça l’était.
  • Si l’on se soucie de sécurité, il faut impérativement désactiver les aperçus sur écran verrouillé. Un écran verrouillé peut être vu par n’importe qui, donc il n’est pas privé par défaut.
  • Si les médias avaient écrit non pas « l’accusé n’a pas changé le réglage », mais « le système Apple stockait les données par défaut », la perception aurait été différente.
    Au final, la responsabilité est transférée à l’utilisateur, tandis que l’entreprise qui a conçu le système se cache derrière l’anonymat du « système ».
  • J’ai d’ailleurs cherché des données statistiques sur la capacité des utilisateurs à modifier des réglages, et le niveau de formation informatique est très faible. Il ne s’agit pas seulement d’apprendre à taper au clavier, mais de développer une culture numérique.

• Article original : FBI Extracts Suspect’s Deleted Signal Messages Saved in iPhone Notification Database

  • Mais l’article est réservé aux abonnés, donc les détails restent limités.

• Je me demande pourquoi Apple n’efface pas les enregistrements restés dans la base de données des notifications même après la suppression de l’app.
  Conserver indéfiniment le contenu d’anciennes notifications, c’est préparer un futur incident de sécurité.

  • Quand ce genre de problème est révélé, on se demande presque « pourquoi seulement maintenant ? » tant cela paraît évident. Il est probable que l’architecture évolue à l’avenir.
  • Sur Android, supprimer une app efface l’historique de ses notifications, et désactiver puis réactiver la fonction d’historique réinitialise aussi les anciennes données.
    D’après la documentation officielle Android, elles ne sont conservées que pendant une certaine durée.
  • Mais si les données ont réellement été écrites en mémoire flash, il est possible que les blocs subsistent même après suppression.
    À cause du wear leveling, des données peuvent rester pendant des années.
  • Dans la plupart des bases de données (sqlite, etc.), supprimer une ligne n’efface pas immédiatement les données réelles sur le disque.
    Des phénomènes similaires se produisent aussi au niveau du système de fichiers et du SSD.

• Au final, cela montre bien que l’une des extrémités de l’E2E n’est pas l’app, mais le téléphone lui-même.
  Comme avec WhatsApp, où lire un message depuis la notification ne le marque pas comme lu, l’OS joue en quelque sorte le rôle d’homme du milieu (MITM).

  • Mais comme Signal génère lui-même la notification, on ne peut pas forcément considérer que le simple fait d’afficher une notification, comme echo "my_private_data" | notify-send, soit en soi dangereux.

• En réalité, ce problème de stockage des données de notification est connu depuis longtemps.
  Il était déjà évoqué dans RealityNet iOS Forensics References ou
  un article de The Forensics Scooter.