Comment Zerotistic a fait fonctionner « Localiser » d’Apple sur Linux sans casser le chiffrement

Un chercheur en sécurité connu sous le pseudonyme Zerotistic a démontré qu’une machine Linux pouvait être acceptée par les services privés d’Apple et recevoir des données de Localiser – Personnes, malgré la restriction officielle de cette fonction aux appareils Apple. Pour y parvenir, il n’a pas cassé le chiffrement : il a reproduit suffisamment de protocoles d’authentification, d’enrôlement, de messagerie et de synchronisation pour que les serveurs d’Apple considèrent Linux comme un appareil autorisé.

La nuance est essentielle. Le client ne pouvait lire qu’un partage de position que le compte Apple avait déjà le droit de recevoir. Il ne permettait pas de contourner le choix d’un contact, de localiser arbitrairement des utilisateurs Apple ou d’accéder aux données de n’importe quel compte.

La vraie découverte : la frontière matérielle n’était pas absolue

Dans ce parcours précis, l’exclusivité des appareils Apple s’est révélée être une limite de produit et d’implémentation, plutôt qu’une exigence cryptographique incontournable. Une fois fournies les informations attendues — identifiants du compte, identité de l’appareil, certificats, capacités déclarées et comportement réseau — les serveurs d’Apple ont traité le client Linux comme un récepteur de confiance supplémentaire.

Cela ne signifie pas qu’un ordinateur Linux anonyme peut interroger librement « Localiser ». Le chercheur a montré qu’un système non Apple pouvait reproduire le comportement du client officiel après avoir franchi les étapes d’authentification et d’enrôlement du compte.

Comment Linux a reproduit le fonctionnement de « Localiser »

Le projet a relié plusieurs briques habituellement invisibles pour l’utilisateur :

1. Authentification du compte. Zerotistic a utilisé GrandSlam, le protocole de connexion d’Apple. Le parcours comprenait un échange Secure Remote Password (SRP), puis l’authentification à deux facteurs. Il produisait notamment des identifiants de compte et un jeton temporaire équivalent à un mot de passe.

2. Enrôlement de l’appareil. Le client générait une demande de signature de certificat (CSR) au format PKCS#10, avec une clé RSA de 2 048 bits et une signature SHA-1. Cette demande était envoyée à l’ancien point d’accès d’enrôlement authenticateDS, qui renvoyait un certificat d’Apple Identity Services.

3. Inscription auprès d’IDS. Grâce à ce certificat et aux éléments d’identité associés, Linux pouvait se déclarer comme un appareil compatible avec Identity Services (IDS), annoncer ses types de chiffrement, s’abonner aux sous-services de messagerie requis et obtenir les identifiants de livraison d’Apple Push Notification Service (APNs).

4. Synchronisation avec « Localiser ». Le client reproduisait la séquence native de Localiser – Personnes : initialisation, opérations d’actualisation, puis requête SubscribeAndFetch avec

   intent: distributeKeys

   et

   mode: proactive

   . Apple demandait alors à l’appareil du contact consentant d’envoyer les éléments de clé nécessaires à la nouvelle identité enrôlée, via IDS et APNs.

5. Déchiffrement local. Le paquet IDS chiffré contenait des informations sur la relation de partage ainsi que du matériel de clé SearchParty. La bibliothèque open source pypush prenait en charge la couche push et IDS, tandis que FindMy.py interrogeait puis déchiffrait les rapports de Localiser pour en extraire les coordonnées, les horodatages et la précision.

Il s’agissait donc d’une émulation de protocole, pas d’un faux certificat Apple. Les identifiants étaient délivrés par Apple après l’authentification du compte et la procédure d’enrôlement.

Ce que le paquet IDS révèle sur la distribution des clés

Le comportement de SubscribeAndFetch suggère qu’Apple peut transmettre les clés de position actuelles à un appareil nouvellement autorisé lorsqu’une relation de partage existe déjà. Cette possibilité est nécessaire pour synchroniser un compte ou remplacer un appareil : sinon, l’utilisateur devrait demander à chaque contact de désactiver puis de réactiver le partage à chaque ajout d’un nouveau terminal.

Le paquet observé contenait notamment un identifiant de relation, un index de clé, une clé d’annonce hachée de 32 octets et une représentation de clé privée de 85 octets. Ces éléments indiquent que le déchiffrement des rapports de position de Localiser repose sur du matériel lié à la relation de partage et à la version de clé concernée, redistribuable par l’intermédiaire d’IDS.

La publication technique montre les mécanismes de synchronisation et de renouvellement des clés, mais ne permet pas d’établir un intervalle universel de rotation. Autrement dit, elle décrit la livraison de l’état actuel des clés, pas l’intégralité du calendrier de gestion des clés d’Apple.

Ce que le client pouvait — et ne pouvait pas — faire

Le client testé était volontairement limité. Il pouvait lire un partage de position déjà accepté sur le compte Apple du chercheur, puis traiter les données localement. La logique de géorepérage — par exemple déclencher une alerte à l’arrivée dans une zone — s’exécutait également sur la machine Linux, et non sur les serveurs d’Apple.

D’après la publication, il ne permettait pas :

• d’envoyer de nouvelles invitations de partage de position ;
• de modifier les autorisations existantes ;
• d’ajouter des membres à un groupe familial ;
• de créer des zones géographiques hébergées par Apple ;
• d’envoyer des commandes à des appareils.

Il faut donc voir cette affaire comme une découverte sur l’interopérabilité et la frontière de confiance, pas comme une faille permettant de suivre à distance n’importe quelle personne. Le risque de sécurité le plus plausible concernerait plutôt la compromission d’un compte Apple ou d’un appareil de confiance : un attaquant qui en prendrait le contrôle pourrait potentiellement exposer les partages déjà accessibles à ce compte.

Une recherche très différente de nRootTag

La démonstration de Zerotistic et les travaux de nRootTag, publiés en 2025, touchent des parties différentes de l’écosystème « Localiser » et ne présentent pas le même modèle de menace.

Zerotistic s’est intéressé à Localiser – Personnes. Son client reproduisait le rôle du récepteur dans une relation de partage existante et autorisée. Le compte et l’appareil devaient être acceptés par Apple, et la personne concernée devait avoir partagé sa position avec ce compte.

nRootTag ciblait le réseau Localiser et la recherche hors ligne. Les chercheurs ont indiqué que le service d’Apple acceptait des types d’adresses Bluetooth qui n’étaient pas ceux attendus. Cette faiblesse pouvait permettre à un ordinateur compatible Bluetooth de se comporter comme une balise comparable à un AirTag et d’utiliser les appareils Apple voisins pour relayer sa position, sans que le propriétaire de l’appareil suivi en ait connaissance.

En résumé, Zerotistic a reçu des données qu’un compte était déjà autorisé à consulter ; nRootTag cherchait à créer un mécanisme de suivi sans autorisation. Les confondre donnerait à la démonstration Linux une portée que les éléments disponibles ne justifient pas.

L’objectif initial : automatiser des alertes Discord

Le projet partait d’un objectif présenté comme consenti : un ami qui partageait déjà sa position avait accepté qu’un système Linux maintienne des zones géographiques locales et envoie des notifications sur Discord lors de son arrivée ou de son départ de certains lieux.

Zerotistic pensait d’abord qu’il suffirait d’effectuer une requête web authentifiée et estimait le travail à environ une soirée. Le rétro-ingénierie s’est toutefois considérablement développée. Les sources disponibles ne donnent pas de durée totale précise pour le projet achevé ; toute estimation plus exacte serait donc spéculative.

Quelle a été la réponse d’Apple ?

Les sources citées confirment la démonstration, mais ne rapportent pas de déclaration publique vérifiée d’Apple répondant spécifiquement à cette implémentation Linux de Localiser – Personnes. Elles ne permettent pas non plus de confirmer un correctif ou l’issue d’un éventuel programme de récompense pour les chercheurs.

La leçon principale reste néanmoins claire : réserver une fonction aux appareils Apple ne signifie pas forcément que le matériel constitue, à lui seul, la frontière de sécurité. Si la confiance côté serveur dépend surtout des identifiants, des certificats, des capacités et du comportement protocolaire, un client suffisamment compatible sur un autre système d’exploitation peut franchir la frontière du produit — tout en restant limité par les autorisations du compte et les clés cryptographiques qu’il obtient légitimement.