La nouvelle fonction de sécurité d’Apple redémarre automatiquement les iPhone non déverrouillés pendant 72 heures

• Le nouveau logiciel de l’iPhone d’Apple redémarre automatiquement l’appareil s’il n’a pas été déverrouillé pendant 72 heures, ce qui rend l’accès aux données plus difficile en cas de saisie ou de perte prolongée
• La minuterie de 72 heures de l’inactivity reboot d’iOS 18 a été confirmée par une vidéo de démonstration de Jiska Classen et par Magnet Forensics
• Après le redémarrage, l’iPhone passe dans un état plus sûr où les clés de chiffrement sont verrouillées dans la Secure Enclave, ce qui le rend plus difficile à déverrouiller avec des outils d’investigation peu coûteux ou anciens
• L’accessibilité forensique varie selon les états BFU (Before First Unlock) et AFU (After First Unlock) ; le redémarrage ramène l’appareil d’un état « hot » à un état « cold », plus difficile
• Cette fonction ralentit l’accès des voleurs et de certains outils forensiques, mais Classen estime qu’elle ne bloque pas totalement les forces de l’ordre, et que trois jours restent suffisants pour coordonner des procédures avec des analystes spécialisés

---

Redémarrage automatique après 72 heures d’inactivité

• Le nouveau logiciel de l’iPhone inclut une fonction de sécurité qui redémarre l’appareil de lui-même s’il n’a pas été déverrouillé pendant 72 heures
• 404 Media rapporte que certains iPhone ont redémarré pour des raisons inconnues, compliquant l’accès aux appareils et l’extraction des données pour les forces de l’ordre et les experts forensiques
• Des chercheurs en sécurité ont ensuite confirmé qu’iOS 18 intègre un inactivity reboot qui force le redémarrage de l’appareil
• Jiska Classen, chercheuse au Hasso Plattner Institute, a publié une vidéo de démonstration montrant cette fonction : on y voit un iPhone laissé sans déverrouillage redémarrer après 72 heures
• Magnet Forensics, qui propose des produits de forensique numérique, dont Graykey, un outil d’extraction de données pour iPhone et Android, a également confirmé que la minuterie est de 72 heures

BFU et AFU déterminent la difficulté de l’analyse forensique

• L’inactivity reboot fait passer l’iPhone dans un état plus sécurisé en verrouillant les clés de chiffrement de l’utilisateur dans la puce Secure Enclave
• Classen estime que, même si un voleur laisse longtemps un iPhone allumé, il devient plus difficile de le déverrouiller avec des outils forensiques bon marché et anciens
• Le travail des forces de l’ordre qui cherchent à récupérer des données sur les appareils de criminels devient aussi plus complexe, mais cette seule fonction ne bloque pas complètement l’accès
  • Selon elle, 3 jours restent un délai suffisant pour coordonner les procédures avec des analystes spécialisés
• L’iPhone possède deux états qui influent sur les tentatives visant à trouver un mot de passe par force brute ou à extraire des données en exploitant des failles logicielles
  • BFU (Before First Unlock) : les données utilisateur sont entièrement chiffrées et l’accès est quasiment impossible sans connaître le mot de passe
  • AFU (After First Unlock) : certaines données sont déchiffrées, ce qui peut faciliter leur extraction par certains outils forensiques même si le téléphone est verrouillé
• Le chercheur en sécurité iPhone Tihmstar désigne aussi ces deux états comme des appareils cold et hot
  • De nombreuses sociétés de forensique se concentrent sur les appareils « hot » en état AFU, après que l’utilisateur a saisi une fois le bon mot de passe
  • La raison est que les informations liées au mot de passe sont alors stockées dans la mémoire de la Secure Enclave de l’iPhone
  • Un appareil « cold » redémarré est beaucoup plus difficile à compromettre, car sa mémoire ne peut pas être extraite facilement
• Depuis des années, Apple ajoute de nouvelles fonctions de sécurité auxquelles les forces de l’ordre s’opposent, ces dernières critiquant le fait qu’elles rendent leur travail plus difficile
• En 2016, le FBI a intenté une action en justice pour contraindre Apple à créer une porte dérobée permettant d’ouvrir l’iPhone d’un auteur de fusillade de masse ; par la suite, la startup australienne Azimuth Security a aidé le FBI à pirater cet iPhone
• Apple n’a pas répondu à une demande de commentaire

[GN⁺]

Avis sur Hacker News

• Les terminaux de paiement doivent redémarrer périodiquement à cause des exigences PCI, et presque tous les terminaux de point de vente du marché redémarrent toutes les 24 heures

  • Cela ressemble à une bonne stratégie de défense en profondeur. Aujourd’hui, la plupart des systèmes ont une chaîne de démarrage plutôt bien sécurisée, si bien qu’après un redémarrage on peut considérer que le système est dans un état valide et que d’éventuelles modifications malveillantes ont disparu
  • Le fait qu’Apple adopte une approche similaire sur l’iPhone semble relever de la même idée, mais appliquée à la protection des données personnelles
  • Le Boeing 787 fait pareil
  • De mon côté, je redémarre l’iPhone tous les week-ends, que ce soit nécessaire ou non

• Ce serait bien de pouvoir réduire ce délai. Si le téléphone n’a pas été déverrouillé pendant une journée entière, c’est qu’il se passe quelque chose d’anormal, et il faut une suspicion de sécurité supplémentaire

  • Je me suis demandé si on pouvait faire ça avec l’app Raccourcis intégrée et j’ai cherché ; au début, j’ai cru que non parce qu’il n’y avait pas d’action « Restart »
    En fait, je regardais au mauvais endroit : c’est proposé comme option de l’action « Shut Down »
  • Un système qui redémarrerait si l’on n’est pas à proximité d’un Airtag précis, ou d’un appareil similaire, pourrait aussi être intéressant. Il faudrait évidemment pouvoir le contourner en déverrouillant le téléphone
  • Pour minimiser la gêne quand on n’a tout simplement pas touché son téléphone, environ 12 heures me sembleraient parfaites
  • Il suffit de créer une automatisation de raccourci qui redémarre le téléphone tous les jours pour régler le problème

• Cette « nouvelle » fonction est déjà prise en charge par GrapheneOS, avec une valeur par défaut de 18 heures, réglable comme on veut. Il n’y a pas de bonne raison d’imposer 72 heures à tout le monde ; c’est un choix de conception hostile aux utilisateurs

  • En réalité, il semble que cela ne s’active que lorsque le téléphone n’a pas été déverrouillé avec succès pendant 3 jours. La plupart des utilisateurs ne s’en rendront donc quasiment jamais compte
  • La première fois que j’ai vu la fonction utilisant le flash de l’appareil photo comme lampe torche, c’était dans Cyanogenmod 7. Le hotspot Wi-Fi du téléphone a lui aussi commencé sous forme d’app Cydia, à une époque où les apps officielles étaient assez inutiles
    L’écosystème du hacking a toujours apporté les fonctions les plus cool aux téléphones, mais les fabricants ont rendu l’accès à ces fonctions de plus en plus difficile
  • Sur mon téléphone personnel sous GrapheneOS, c’est une fonction indispensable. Comme je ne l’utilise généralement qu’une ou deux fois par jour, il est presque fraîchement redémarré à chaque utilisation
    J’ai lu que beaucoup de nouveaux exploits dans le mobile ne résident qu’en mémoire et sont donc bloqués par un simple redémarrage, y compris, semble-t-il, le tristement célèbre spyware Pegasus
  • C’est probablement plutôt un compromis. Un délai aussi long évite les gros titres sensationnalistes sur des utilisateurs furieux de redémarrages aléatoires, et n’est pas assez court pour que les agences fédérales réagissent publiquement et demandent à nouveau une backdoor à Trump
    En même temps, c’est une mise à jour discrète qui ne sera pas très visible en dehors de la communauté tech, donc de petits criminels pourraient ne pas s’y préparer correctement. Si c’était vraiment une conception hostile aux utilisateurs, elle n’aurait tout simplement pas été implémentée
    La façon typique d’Apple est de choisir un défaut raisonnable et de ne pas embêter l’utilisateur ; parfois c’est bien, parfois non
  • Je suis curieux de savoir ce que donne Graphene à l’usage

• Si c’est vrai, en faire une option configurable serait une amélioration mineure. 72 heures devraient rester la valeur par défaut, mais les personnes ayant des exigences de sécurité plus élevées devraient pouvoir descendre à 12 heures, voire moins

  • Si c’était configurable, je mettrais 30 minutes et j’augmenterais si cela devenait gênant. J’utilise déjà mon téléphone en mode Ne pas déranger en permanence, donc le fait que les notifications soient retardées par un redémarrage n’est pas un problème, et saisir le code au lieu de FaceID toutes les 30 minutes ne me dérange pas vraiment
  • Si c’est configurable, il pourrait être difficile de le coder en dur dans la Secure Enclave de façon à empêcher sa désactivation lorsque le téléphone est jailbreaké
  • Je suis d’accord, mais le choix des 72 heures par Apple ressemble à une façon de donner du temps à la police. Peut-être parce que la police est plus organisée que les criminels
  • Le rendre configurable est l’étape logique suivante

• Cette fonction semble casser le transfert de SMS entre iDevice. Je l’ai appris à mes dépens lorsque certaines notifications de livraison de colis n’arrivaient pas tant que je n’avais pas déverrouillé mon iPhone secondaire et ouvert l’app Messages

• Je comprends qu’un téléphone verrouillé doive déjà avoir tout chargé en mémoire. Mais je me demande quel obstacle technique empêche Apple de rendre l’état verrouillé aussi sûr que l’état juste après un redémarrage

  • Dans l’état avant le premier déverrouillage, les aperçus de notifications, les informations de contact des appels entrants et d’autres données propres à l’utilisateur restent chiffrés et verrouillés. Apple ne le fait pas parce que cela changerait aussi fortement l’expérience utilisateur
  • Il existe une bonne explication de la façon dont c’est implémenté cryptographiquement : https://www.youtube.com/watch?v=BLGFriOKz6U
  • À mon avis, l’obstacle relève davantage de l’expérience utilisateur que de la technique

• 404Media semble avoir été le premier à confirmer cela. Peut-être pas. L’article est réservé aux abonnés et je n’ai pas trouvé de lien d’archive permettant de lire l’intégralité, mais c’est un média qui fait du bon travail et mérite d’être soutenu
  https://www.404media.co/apple-quietly-introduced-iphone-rebo...

• Le redémarrage automatique existe sur les téléphones Samsung depuis Android 5 Lollipop, il y a 10 ans. Heureux de voir que le progrès technique finit par arriver jusqu’à Apple

  • Du point de vue de la sécurité, ce n’est pas la même fonction. Cela ressemble plutôt à de la gestion des performances, comme redémarrer un vieux PC Windows
    L’état BFU d’Android, c’est-à-dire avant le premier déverrouillage, est assez similaire à celui de l’iPhone : les données restent verrouillées, les notifications n’arrivent pas et les apps ne s’exécutent pas. Il faut d’abord déverrouiller le téléphone pour que les apps se lancent, que les notifications arrivent et que l’état devienne plus vulnérable pour un attaquant
    J’utilise à la fois iPhone et Android, et mon Android actuel est un modèle récent, le Z Fold 5. Le Fold 5 redémarre automatiquement chaque semaine, mais après le redémarrage les apps habituelles en arrière-plan se relancent et les notifications fonctionnent normalement
    Cela signifie qu’Android, ou plus précisément OneUI, la surcouche de Samsung au-dessus d’Android, ne fait pas un redémarrage « complet » et n’offre pas l’avantage de sécurité consistant à laisser le téléphone en état BFU ou froid, comme le fait Apple

• Je me demande pourquoi on ne sépare pas carrément physiquement la mémoire des instructions de programme et la mémoire des données. Je sais qu’il existe des approximations similaires au niveau des pages, mais je ne vois pas pourquoi on laisserait le noyau modifier sa propre mémoire dès le départ
  Un dispositif mémoire qui ne chargerait que des pages signées, par exemple, devrait être possible

  • Ce que vous demandez n’est pas une architecture de von Neumann, mais un ordinateur à architecture Harvard. Cela implique des compromis
    Il faut garder à l’esprit que le JIT est une technologie très utile et que le coût de sa perte serait assez élevé ; en outre, les interpréteurs traitent toujours la mémoire de données comme de la mémoire d’instructions de programme, ce qui limite les bénéfices de cette séparation
  • Je ne sais pas à quoi cela répond. C’est déjà comme ça que ça fonctionne, et le noyau ne peut pas modifier ses propres pages de code. Il reste toutefois beaucoup de surface d’attaque, par exemple des attaques qui écrasent des pointeurs de fonction ou d’autres données
  • iOS fonctionne déjà ainsi

• Question : l’écran de redémarrage d’Apple affiche-t-il vraiment les logs dmesg ?

  • C’est probablement un Security Research Device. https://security.apple.com/research-device/
  • Sans doute pas dans la version finale ; des chercheurs en sécurité utilisaient probablement une bêta développeur avec un mode de journalisation détaillé activé