Apple-hardware bleek niet de volledige vertrouwensgrens

De demonstratie wijst erop dat de beperking tot Apple-apparaten in deze route vooral een implementatie- en productgrens was, en geen absolute cryptografische eis voor Apple-hardware. Zodra de Linux-client de verwachte accountgegevens, apparaatidentiteit, certificaten, mogelijkheden en netwerkcommunicatie aanleverde, behandelden Apples servers hem als een nieuwe vertrouwde ontvanger.

Dat betekent niet dat iedereen vanaf een willekeurige Linux-pc zomaar Find My kan ondervragen. De client moest eerst Apples authenticatie- en registratiestappen doorlopen. Het onderzoek laat vooral zien dat een ander besturingssysteem het relevante gedrag van een Apple-client kan reproduceren en zo binnen die bestaande vertrouwensrelatie kan functioneren.

Hoe de Linux-client de Find My-stappen nabouwde

Zerotistic verbond verschillende onderdelen van Apples normaal gesproken verborgen infrastructuur:

1. Accountauthenticatie: de onderzoeker gebruikte Apples GrandSlam-inlogprotocol. De beschreven procedure omvatte een Secure Remote Password-uitwisseling en tweefactorauthenticatie. Dat leverde accountidentificatoren en een tijdelijk token op dat als wachtwoord-equivalent fungeerde.

2. Apparaatregistratie: de client genereerde een PKCS#10-certificaataanvraag met een 2048-bits RSA-sleutel en een SHA-1-handtekening. Die aanvraag werd naar Apples legacy-eindpunt authenticateDS voor profielregistratie gestuurd, waarna een certificaat van Apple Identity Services werd teruggegeven.

3. Registratie bij IDS: met het certificaat en de bijbehorende apparaatgegevens kon Linux zich registreren als apparaat dat Identity Services ondersteunt. De client gaf aan welke versleutelingstypen hij aankon, abonneerde zich op de benodigde berichtensubdiensten en verkreeg aflevergegevens voor Apple Push Notification Service (APNs).

4. Synchronisatie met Find My: vervolgens bootste de client de native aanvraagvolgorde van Find My People na, met initialisatie, vernieuwingsacties en een SubscribeAndFetch-verzoek met intent: distributeKeys en mode: proactive. Apple gaf het apparaat van de instemmende contactpersoon daarna opdracht om het actuele materiaal voor de locatiesleutel via IDS en APNs naar de nieuw geregistreerde identiteit te sturen.

5. Lokale ontsleuteling: het versleutelde IDS-bericht bevatte relatiegegevens en SearchParty-sleutelmateriaal. De opensourcelibrary pypush verzorgde de push- en IDS-laag, terwijl FindMy.py de Find My-rapporten opvroeg en ontsleutelde naar coördinaten, tijdstippen en nauwkeurigheidsgegevens.

Dit was protocolimitatie, geen vervalst Apple-certificaat. De server verstrekte de benodigde inlog- en registratiegegevens pas nadat de authenticatie- en inschrijvingsprocedure was voltooid.

Wat de IDS-berichten laten zien over sleutelverdeling

Het beschreven gedrag van SubscribeAndFetch suggereert dat Apple actuele locatiesleutels kan leveren aan een nieuw geautoriseerd apparaat wanneer er al een bestaande deelrelatie is. Dat is praktisch nodig voor het vervangen van een apparaat of het synchroniseren van een account: gebruikers zouden niet telkens aan ieder contact opnieuw hoeven te vragen om het delen van hun locatie uit en weer aan te zetten wanneer ze een extra apparaat toevoegen.

Volgens de beschrijving bevatte het payload een relatie-ID, een sleutelindex, een 32 bytes lange sleutel voor gehashte advertenties en een representatie van een privésleutel van 85 bytes. Samen wijzen die velden erop dat het ontsleutelen van Find My-locatieberichten afhankelijk is van materiaal dat specifiek is voor een relatie en een bepaalde sleutelversie, en dat dit via IDS opnieuw kan worden verspreid.

De openbare technische beschrijving toont synchronisatie- en rotatiegedrag, maar legt geen universeel interval voor sleutelrotatie vast. Dat onderscheid is belangrijk: het onderzoek laat zien hoe de actuele sleutelstatus wordt afgeleverd, niet hoe het volledige openbare schema voor Apples sleutelbeheer eruitziet.

Wat de client wel en niet kon

De geteste client had bewust een beperkte functie. Hij kon een reeds geaccepteerd locatie delen op het Apple Account van de onderzoeker uitlezen en de gegevens lokaal verwerken. Ook de geofencing — het uitvoeren van acties op basis van het binnenkomen in of verlaten van een bepaald gebied — draaide lokaal, niet als Apple-functie op de server.

Volgens de technische beschrijving kon de client niet:

• nieuwe uitnodigingen voor locatie delen versturen;
• bestaande deelrechten aanpassen;
• gezinsleden toevoegen;
• door Apple gehoste geofences aanmaken; of
• opdrachten naar apparaten sturen.

Daarom gaat het hier om een interoperabiliteits- en vertrouwensgrensbevinding, niet om een exploit waarmee op afstand willekeurige personen kunnen worden gevolgd. Het realistischer beveiligingsrisico ligt bij een overgenomen Apple Account of een ongeautoriseerd apparaat dat aan zo’n account wordt toegevoegd: locatiegegevens die het account al mocht zien, zouden dan mogelijk kunnen uitlekken.

Verschil met het nRootTag-onderzoek uit 2025

De demonstratie van Zerotistic en nRootTag hebben betrekking op verschillende onderdelen van Find My en kennen een ander dreigingsmodel.

Zerotistic richtte zich op Find My People. Het project reconstrueerde de ontvangende kant van een bestaande, geautoriseerde deelrelatie. Het account en het apparaat moesten door Apple worden geaccepteerd, en de andere persoon moest de locatie al met dat account hebben gedeeld.

nRootTag richtte zich op Find My Network en offline zoeken. De onderzoekers meldden dat Apples dienst ook Bluetooth-adrestypen accepteerde die niet werden verwacht. Daardoor zou een aanvaller een computer met Bluetooth kunnen laten functioneren als een soort AirTag-achtige volgzender, waarbij Apple-apparaten in de buurt de locatie doorgeven zonder dat de eigenaar van het gevolgde apparaat daarvan weet.

Kort gezegd: Zerotistic ontving gegevens die een account al mocht bekijken; nRootTag probeerde een ongeautoriseerde trackingmogelijkheid te creëren. Die twee onderzoeken op één hoop gooien maakt de Linux-demonstratie veel krachtiger dan de beschikbare bewijzen rechtvaardigen.

Het oorspronkelijke doel en de tijdsinschatting

De oorspronkelijke motivatie was volgens de beschrijving toestemming-gebaseerde automatisering. Een vriend die zijn locatie al deelde, stemde ermee in dat een Linux-systeem lokale geofences zou bijhouden en Discord-meldingen zou sturen wanneer die persoon op bepaalde plaatsen aankwam of vertrok.

Zerotistic verwachtte aanvankelijk dat het project zou neerkomen op één geauthenticeerd webverzoek en schatte dat het ongeveer een avond werk zou kosten. Het reverse-engineeringwerk bleek uiteindelijk aanzienlijk omvangrijker. De beschikbare berichtgeving geeft geen precies totaal aantal uren of dagen voor het voltooide project, waardoor een exactere tijdsduur speculatief zou zijn.

Wat Apple heeft gezegd

De aangehaalde berichtgeving bevestigt de demonstratie, maar bevat geen geverifieerde openbare reactie van Apple over precies deze Linux-implementatie van Find My People. Ook is er geen bevestigde oplossing of openbaar gemaakte bugbounty-uitkomst in de aangehaalde bronnen.

De centrale les blijft daardoor overeind: een functie beperken tot Apple-hardware maakt die hardware niet automatisch tot de beveiligingsgrens. Als vertrouwen aan de serverkant vooral wordt toegekend op basis van accountgegevens, certificaten, mogelijkheden en protocolgedrag, kan een voldoende compatibele client op een ander besturingssysteem de productgrens passeren — terwijl hij nog steeds wordt beperkt door de accountrechten en cryptografische sleutels die hij rechtmatig verkrijgt.

Apple-hardware bleek niet de volledige vertrouwensgrens

De demonstratie wijst erop dat de beperking tot Apple-apparaten in deze route vooral een implementatie- en productgrens was, en geen absolute cryptografische eis voor Apple-hardware. Zodra de Linux-client de verwachte accountgegevens, apparaatidentiteit, certificaten, mogelijkheden en netwerkcommunicatie aanleverde, behandelden Apples servers hem als een nieuwe vertrouwde ontvanger.

Dat betekent niet dat iedereen vanaf een willekeurige Linux-pc zomaar Find My kan ondervragen. De client moest eerst Apples authenticatie- en registratiestappen doorlopen. Het onderzoek laat vooral zien dat een ander besturingssysteem het relevante gedrag van een Apple-client kan reproduceren en zo binnen die bestaande vertrouwensrelatie kan functioneren.

Hoe de Linux-client de Find My-stappen nabouwde

Zerotistic verbond verschillende onderdelen van Apples normaal gesproken verborgen infrastructuur:

1. Accountauthenticatie: de onderzoeker gebruikte Apples GrandSlam-inlogprotocol. De beschreven procedure omvatte een Secure Remote Password-uitwisseling en tweefactorauthenticatie. Dat leverde accountidentificatoren en een tijdelijk token op dat als wachtwoord-equivalent fungeerde.

2. Apparaatregistratie: de client genereerde een PKCS#10-certificaataanvraag met een 2048-bits RSA-sleutel en een SHA-1-handtekening. Die aanvraag werd naar Apples legacy-eindpunt authenticateDS voor profielregistratie gestuurd, waarna een certificaat van Apple Identity Services werd teruggegeven.

3. Registratie bij IDS: met het certificaat en de bijbehorende apparaatgegevens kon Linux zich registreren als apparaat dat Identity Services ondersteunt. De client gaf aan welke versleutelingstypen hij aankon, abonneerde zich op de benodigde berichtensubdiensten en verkreeg aflevergegevens voor Apple Push Notification Service (APNs).

4. Synchronisatie met Find My: vervolgens bootste de client de native aanvraagvolgorde van Find My People na, met initialisatie, vernieuwingsacties en een SubscribeAndFetch-verzoek met intent: distributeKeys en mode: proactive. Apple gaf het apparaat van de instemmende contactpersoon daarna opdracht om het actuele materiaal voor de locatiesleutel via IDS en APNs naar de nieuw geregistreerde identiteit te sturen.

5. Lokale ontsleuteling: het versleutelde IDS-bericht bevatte relatiegegevens en SearchParty-sleutelmateriaal. De opensourcelibrary pypush verzorgde de push- en IDS-laag, terwijl FindMy.py de Find My-rapporten opvroeg en ontsleutelde naar coördinaten, tijdstippen en nauwkeurigheidsgegevens.

Dit was protocolimitatie, geen vervalst Apple-certificaat. De server verstrekte de benodigde inlog- en registratiegegevens pas nadat de authenticatie- en inschrijvingsprocedure was voltooid.

Wat de IDS-berichten laten zien over sleutelverdeling

Het beschreven gedrag van SubscribeAndFetch suggereert dat Apple actuele locatiesleutels kan leveren aan een nieuw geautoriseerd apparaat wanneer er al een bestaande deelrelatie is. Dat is praktisch nodig voor het vervangen van een apparaat of het synchroniseren van een account: gebruikers zouden niet telkens aan ieder contact opnieuw hoeven te vragen om het delen van hun locatie uit en weer aan te zetten wanneer ze een extra apparaat toevoegen.

Volgens de beschrijving bevatte het payload een relatie-ID, een sleutelindex, een 32 bytes lange sleutel voor gehashte advertenties en een representatie van een privésleutel van 85 bytes. Samen wijzen die velden erop dat het ontsleutelen van Find My-locatieberichten afhankelijk is van materiaal dat specifiek is voor een relatie en een bepaalde sleutelversie, en dat dit via IDS opnieuw kan worden verspreid.

De openbare technische beschrijving toont synchronisatie- en rotatiegedrag, maar legt geen universeel interval voor sleutelrotatie vast. Dat onderscheid is belangrijk: het onderzoek laat zien hoe de actuele sleutelstatus wordt afgeleverd, niet hoe het volledige openbare schema voor Apples sleutelbeheer eruitziet.

Wat de client wel en niet kon

De geteste client had bewust een beperkte functie. Hij kon een reeds geaccepteerd locatie delen op het Apple Account van de onderzoeker uitlezen en de gegevens lokaal verwerken. Ook de geofencing — het uitvoeren van acties op basis van het binnenkomen in of verlaten van een bepaald gebied — draaide lokaal, niet als Apple-functie op de server.

Volgens de technische beschrijving kon de client niet:

• nieuwe uitnodigingen voor locatie delen versturen;
• bestaande deelrechten aanpassen;
• gezinsleden toevoegen;
• door Apple gehoste geofences aanmaken; of
• opdrachten naar apparaten sturen.

Daarom gaat het hier om een interoperabiliteits- en vertrouwensgrensbevinding, niet om een exploit waarmee op afstand willekeurige personen kunnen worden gevolgd. Het realistischer beveiligingsrisico ligt bij een overgenomen Apple Account of een ongeautoriseerd apparaat dat aan zo’n account wordt toegevoegd: locatiegegevens die het account al mocht zien, zouden dan mogelijk kunnen uitlekken.

Verschil met het nRootTag-onderzoek uit 2025

De demonstratie van Zerotistic en nRootTag hebben betrekking op verschillende onderdelen van Find My en kennen een ander dreigingsmodel.

Zerotistic richtte zich op Find My People. Het project reconstrueerde de ontvangende kant van een bestaande, geautoriseerde deelrelatie. Het account en het apparaat moesten door Apple worden geaccepteerd, en de andere persoon moest de locatie al met dat account hebben gedeeld.

nRootTag richtte zich op Find My Network en offline zoeken. De onderzoekers meldden dat Apples dienst ook Bluetooth-adrestypen accepteerde die niet werden verwacht. Daardoor zou een aanvaller een computer met Bluetooth kunnen laten functioneren als een soort AirTag-achtige volgzender, waarbij Apple-apparaten in de buurt de locatie doorgeven zonder dat de eigenaar van het gevolgde apparaat daarvan weet.

Kort gezegd: Zerotistic ontving gegevens die een account al mocht bekijken; nRootTag probeerde een ongeautoriseerde trackingmogelijkheid te creëren. Die twee onderzoeken op één hoop gooien maakt de Linux-demonstratie veel krachtiger dan de beschikbare bewijzen rechtvaardigen.

Het oorspronkelijke doel en de tijdsinschatting

De oorspronkelijke motivatie was volgens de beschrijving toestemming-gebaseerde automatisering. Een vriend die zijn locatie al deelde, stemde ermee in dat een Linux-systeem lokale geofences zou bijhouden en Discord-meldingen zou sturen wanneer die persoon op bepaalde plaatsen aankwam of vertrok.

Zerotistic verwachtte aanvankelijk dat het project zou neerkomen op één geauthenticeerd webverzoek en schatte dat het ongeveer een avond werk zou kosten. Het reverse-engineeringwerk bleek uiteindelijk aanzienlijk omvangrijker. De beschikbare berichtgeving geeft geen precies totaal aantal uren of dagen voor het voltooide project, waardoor een exactere tijdsduur speculatief zou zijn.

Wat Apple heeft gezegd

De aangehaalde berichtgeving bevestigt de demonstratie, maar bevat geen geverifieerde openbare reactie van Apple over precies deze Linux-implementatie van Find My People. Ook is er geen bevestigde oplossing of openbaar gemaakte bugbounty-uitkomst in de aangehaalde bronnen.

De centrale les blijft daardoor overeind: een functie beperken tot Apple-hardware maakt die hardware niet automatisch tot de beveiligingsgrens. Als vertrouwen aan de serverkant vooral wordt toegekend op basis van accountgegevens, certificaten, mogelijkheden en protocolgedrag, kan een voldoende compatibele client op een ander besturingssysteem de productgrens passeren — terwijl hij nog steeds wordt beperkt door de accountrechten en cryptografische sleutels die hij rechtmatig verkrijgt.