3 points par GN⁺ 2024-11-18 | 1 commentaires | Partager sur WhatsApp
  • iOS 18 a introduit une nouvelle fonction de sécurité de redémarrage pour inactivité : « redémarrage automatique après 3 jours sans déverrouillage »
  • Saisir le code au premier allumage de l’iPhone et saisir le code plus tard pour le déverrouiller sont deux choses très différentes
  • Lorsqu’on saisit le code au premier démarrage de l’iPhone, le trousseau de clés du Secure Enclave Processor (SEP) est ouvert, et c’est lui qui chiffre les données de l’iPhone
    • En état BFU (Before First Unlock, avant le premier déverrouillage), les données utilisateur sont chiffrées, Face ID et Touch ID ne fonctionnent pas et la saisie du code est nécessaire. Les mots de passe Wi-Fi étant chiffrés, la connexion Wi-Fi est impossible, mais une connexion au réseau cellulaire reste possible si la SIM n’est pas protégée par un PIN. Aucun aperçu du contenu des notifications n’est affiché.
    • En état AFU (After First Unlock, après le premier déverrouillage), les données utilisateur sont déchiffrées. Tant qu’iOS est en cours d’exécution, le trousseau de clés reste ouvert, ce qui permet la connexion Wi-Fi et l’aperçu des notifications de messages. Mais cet état est plus vulnérable aux attaques.
  • Faiblesses de sécurité en état AFU : si un attaquant contourne l’écran de verrouillage, il peut accéder aux données déchiffrées. En cas d’accès physique, la probabilité d’exploiter des vulnérabilités via USB, Wi-Fi, Bluetooth ou des attaques matérielles augmente

Rumeurs autour du redémarrage de l’iPhone

  • Les forces de l’ordre conservent les iPhone dans l’état AFU tout en les isolant d’Internet afin d’obtenir des données importantes d’un point de vue forensique.
  • Une rumeur affirme que, dans iOS 18, l’iPhone redémarre même lorsqu’il est complètement isolé des réseaux sans fil
  • Une autre affirmation soutient aussi qu’un iPhone sous iOS 18 pourrait ordonner sans fil à un iPhone sous une version plus ancienne d’iOS de redémarrer (possibilité technique peu probable)

Découverte de la fonction de redémarrage pour inactivité

  • Lorsqu’Apple ajoute une nouvelle fonction, l’entreprise laisse souvent des indices via des chaînes de débogage
    • À partir d’iOS 18.1, la chaîne inactivity_reboot apparaît. Dans iOS 18.2, elle devient inactivity_reboot_enabled
  • Les tests ont confirmé qu’un redémarrage pour inactivité se produit après 3 jours (72 heures) sans déverrouillage

Reverse engineering du redémarrage pour inactivité

  • Le Secure Enclave Processor (SEP) suit l’heure du dernier déverrouillage et, si 3 jours sont dépassés, envoie une notification au module noyau AppleSEPKeyStore.
  • Le module noyau AppleSEPKeyStore notifie l’espace utilisateur pour lancer le redémarrage. SpringBoard arrête proprement tous les processus de l’espace utilisateur.
  • Après le redémarrage, keybagd lit la variable NVRAM « aks-inactivity » et, si elle est définie, envoie un événement analytique à Apple.
  • En cas d’échec du redémarrage, un kernel panic se produit

Rétro-ingénierie du Secure Enclave Processor

  • Le SEP est l’un des secrets les mieux protégés d’Apple, et son firmware est chiffré.
  • Le firmware du SEP est composé de plusieurs apps, et celle liée à SEPKeyStore s’appelle « sks ».
  • Le SEP génère un message lorsqu’une durée de 3 jours (72 heures) est dépassée, puis l’envoie à l’extension noyau SEPKeyStore.

Une mesure visant uniquement la police ?

  • Effet d’amélioration de la sécurité : les médias ont présenté cette fonction comme visant principalement les forces de l’ordre, mais elle apporte aussi une amélioration majeure contre le vol.
    • Du matériel ancien utilisé par les forces de l’ordre est souvent vendu à bas prix sur des plateformes comme eBay, et cette fonction réduit les cas où des voleurs s’en servent pour accéder aux données d’un iPhone.
    • En pratique, il est difficile pour des voleurs de se procurer les outils de piratage les plus récents ou de réunir les moyens nécessaires pour déverrouiller l’appareil en moins de 3 jours.
  • Importance des mises à jour de l’appareil : maintenir la dernière version d’iOS est crucial pour protéger les données personnelles.
  • Nécessité d’adaptation pour les forces de l’ordre :
    • Les forces de l’ordre doivent ajuster leurs procédures d’extraction de données afin de les terminer dans un délai de 3 jours.
    • Certains fabricants d’outils forensiques ont déjà annoncé qu’ils pouvaient organiser l’extraction des données dans les 24 heures.
    • Cela montre la limite selon laquelle les données ne peuvent être extraites qu’en état AFU.
  • Asymétrie des menaces de sécurité :
    • Pour les voleurs, cette fonction rend l’accès aux données pratiquement impossible et agit comme une barrière de sécurité majeure.
    • En revanche, les forces de l’ordre doivent simplifier leurs processus et réagir plus vite.

Points clés

  • Aucun lien avec l’activité sans fil :
    • Cette fonction n’est pas liée à l’activité des réseaux sans fil.
    • Il est difficile de faire confiance à l’affirmation figurant dans des documents des forces de l’ordre selon laquelle un « redémarrage causé par une communication sans fil entre appareils » serait en cause.
    • Le redémarrage d’appareils antérieurs à iOS 18 est probablement dû à un bug logiciel.
  • Rôle du SEP :
    • La mesure du temps d’inactivité et le déclenchement du redémarrage sont assurés par le SEP.
    • Le SEP communique avec l’extension noyau SEPKeyStore pour exécuter la commande de redémarrage.
    • Une manipulation externe du temps via Internet ou le réseau cellulaire n’a probablement pas d’effet sur le minuteur de 3 jours.
  • Fonction de sécurité robuste :
    • Pour empêcher un redémarrage pour inactivité, un attaquant doit disposer d’une capacité d’exécution de code dans le noyau.
    • Même si des analystes forensiques pouvaient retarder le redémarrage afin d’extraire des données, le piratage initial devrait malgré tout être réalisé dans les 3 jours.
  • Évolution du paysage des menaces :
    • Cela crée de nouveaux défis à la fois pour les voleurs et pour les analystes forensiques.
    • Pour les voleurs, l’accès aux comptes bancaires et autres données sensibles stockées sur l’iPhone est pratiquement bloqué.
    • Les forces de l’ordre subissent une pression accrue pour réagir plus vite afin d’accéder aux données.

1 commentaires

 
GN⁺ 2024-11-18
Avis Hacker News
  • Les données utilisateur sont déchiffrées en état AFU. Les développeurs peuvent choisir différentes clés pour protéger les données. Apple utilise des clés spécifiques pour protéger des informations sensibles comme les données de santé des utilisateurs

    • Des informations sur les classes de protection des données d’Apple sont disponibles ici
  • Une question est soulevée sur la raison pour laquelle tant d’importance est accordée à l’absence de connexion réseau. GrapheneOS propose déjà une fonction de redémarrage automatique après un certain temps, ce qui est efficace pour prévenir les fuites de données

  • Deux questions sont soulevées :

      1. Si un iPhone verrouillé redémarre systématiquement tous les 3 jours, cela peut poser problème dans des cas d’usage légitimes
      1. Si l’article est correct, il redémarre pour revenir à l’état « Before First Unlock » dans un but de sécurité. On peut alors se demander pourquoi il n’est pas possible de revenir à cet état sans redémarrer
    • Question bonus : les téléphones Android exigent le mot de passe, comme après un redémarrage, lorsqu’il n’y a eu aucun mouvement pendant plusieurs heures. On se demande si cela diffère de l’état « Before First Unlock » de l’iPhone
  • Une interrogation est soulevée sur la raison pour laquelle Apple chiffre le firmware du SEP. Si cela n’est pas essentiel au modèle de sécurité, c’est peut-être pour protéger la propriété intellectuelle

  • C’est un excellent article qui montre qu’Apple a une longueur d’avance en matière de sécurité des appareils

  • Il est mentionné qu’iOS 18 pourrait ordonner à distance à d’autres téléphones de redémarrer sans fil, mais cela ne semble pas être abordé de nouveau ensuite

  • Certains estiment que cela ressemble à la manière dont AOSP gère le déverrouillage BFU et AFU

  • Il est probable que cela soit géré dans le Secure Enclave. Cela le rendrait très difficile à désactiver, même si iOS était complètement compromis

  • Une question est posée sur la raison du choix précis de 3 jours, plutôt qu’un délai configurable par l’utilisateur

  • Merci pour cet excellent article et cette très bonne analyse