Nueva función de seguridad de Apple reinicia automáticamente los iPhone si no se desbloquean en 72 horas

• El nuevo software del iPhone de Apple hace que el dispositivo se reinicie automáticamente si no se desbloquea durante 72 horas, lo que dificulta más el acceso a los datos en casos de incautación prolongada o pérdida
• En iOS 18, el inactivity reboot tiene un temporizador de 72 horas, confirmado mediante un video de demostración de Jiska Classen y una verificación de Magnet Forensics
• Tras reiniciarse, el iPhone pasa a un estado más seguro en el que las claves de cifrado quedan bloqueadas en Secure Enclave, por lo que resulta más difícil desbloquearlo con herramientas forenses baratas o antiguas
• La accesibilidad forense varía según el estado BFU (Before First Unlock) y AFU (After First Unlock), y el reinicio devuelve el estado más accesible “hot” al estado más difícil “cold”
• Esta función retrasa el acceso de ladrones y de algunas herramientas forenses, pero Classen cree que no bloquea por completo a las fuerzas del orden, y que tres días siguen siendo suficientes para coordinar a analistas especializados y los procedimientos

---

Reinicio automático tras 72 horas de inactividad

• El nuevo software del iPhone incluye una función de seguridad que hace que el dispositivo se reinicie por sí solo si no se desbloquea durante 72 horas
• 404 Media informó que algunos iPhone se reiniciaban por razones desconocidas, lo que causó dificultades a fuerzas del orden y especialistas forenses para acceder a los dispositivos y extraer datos
• Después, investigadores de seguridad confirmaron que iOS 18 incorpora un inactivity reboot que fuerza el reinicio del dispositivo
• Jiska Classen, investigadora del Hasso Plattner Institute, publicó un video de demostración de la función, donde se ve un iPhone reiniciándose después de 72 horas sin ser desbloqueado
• Magnet Forensics, que ofrece productos de forense digital incluyendo Graykey, una herramienta de extracción de datos de iPhone y Android, también confirmó que el temporizador es de 72 horas

BFU y AFU definen la dificultad forense

• El inactivity reboot cambia el iPhone a un estado más seguro y bloquea las claves de cifrado dentro del chip Secure Enclave
• Classen considera que, aunque un ladrón mantenga encendido el iPhone durante mucho tiempo, será más difícil desbloquearlo con herramientas forenses baratas y antiguas
• El trabajo de las fuerzas del orden para obtener datos de dispositivos de criminales también se vuelve más complicado, pero esta función por sí sola no bloquea por completo el acceso
  • La explicación es que 3 días siguen siendo tiempo suficiente para coordinar a analistas especializados y los procedimientos
• En el iPhone hay dos estados que afectan los intentos de descifrar la contraseña por fuerza bruta o de extraer datos aprovechando vulnerabilidades de software
  • BFU (Before First Unlock): los datos del usuario están completamente cifrados y, si no se conoce la contraseña, el acceso es casi imposible
  • AFU (After First Unlock): algunos datos quedan descifrados, por lo que incluso si el teléfono sigue bloqueado, algunas herramientas forenses pueden extraerlos con mayor facilidad
• El investigador de seguridad de iPhone Tihmstar también llama a estos dos estados dispositivos cold y hot, respectivamente
  • Muchas empresas forenses se enfocan en dispositivos “hot” en estado AFU, donde el usuario ya introdujo una vez la contraseña correcta
  • Esto se debe a que la información relacionada con la contraseña queda almacenada en la memoria del iPhone Secure Enclave
  • Un dispositivo “cold” que ya se reinició no permite extraer fácilmente esa memoria, por lo que es mucho más difícil de comprometer
• Apple ha ido añadiendo durante años nuevas funciones de seguridad a las que las fuerzas del orden se han opuesto, alegando que les dificultan el trabajo
• En 2016, el FBI presentó una demanda para obligar a Apple a crear una puerta trasera para desbloquear el iPhone de un autor de un tiroteo masivo, y después la startup australiana Azimuth Security ayudó al FBI a hackear ese iPhone
• Apple no respondió a una solicitud de comentarios

[GN⁺]

Opiniones de Hacker News

• Las terminales de pago requieren reinicios periódicos por los requisitos PCI, y casi todas las terminales de punto de venta del mercado se reinician cada 24 horas.

  • Parece una buena estrategia de defensa en profundidad. Hoy en día, la mayoría de los sistemas tienen una seguridad bastante decente en la cadena de arranque, así que después de un reinicio se puede considerar que el sistema está en un estado válido y que posibles cambios maliciosos desaparecieron.
  • Que Apple introduzca un enfoque similar en el iPhone parece partir de la misma idea, solo que aplicada a la protección de datos personales.
  • El Boeing 787 también hace eso.
  • Reinicio mi iPhone todos los fines de semana, sin importar si hace falta o no.

• Me gustaría que se pudiera reducir este ajuste a un periodo más corto. Si no desbloqueé el teléfono durante un día entero, algo raro está pasando y hace falta una sospecha de seguridad adicional.

  • Me dio curiosidad si esto se podía hacer con la app nativa Shortcuts, así que lo busqué; al principio pensé que no se podía porque no había una acción de "Restart".
    Resulta que estaba buscando en el lugar equivocado y está disponible como opción dentro de la acción "Shut Down".
  • También estaría bien un sistema que reinicie si no estás cerca de un Airtag específico o un dispositivo similar. Claro, debería poder omitirse desbloqueando el teléfono.
  • Para minimizar las molestias cuando simplemente no he tocado el teléfono, unas 12 horas me parecerían perfectas.
  • Se soluciona creando una automatización de shortcut que reinicie el teléfono todos los días.

• Esta función “nueva” ya está soportada en GrapheneOS, donde además el valor predeterminado es ejecutarse después de 18 horas y el usuario puede ajustarlo como quiera. No hay una buena razón para imponer 72 horas a todos; es una decisión de diseño hostil para el usuario.

  • En realidad parece funcionar solo cuando el teléfono no se ha desbloqueado correctamente durante 3 días. Por eso, la mayoría de los usuarios casi ni la van a notar.
  • La primera vez que vi la función de usar el flash de la cámara como linterna fue en Cyanogenmod 7. El hotspot Wi-Fi del teléfono también empezó como una app de Cydia cuando las apps oficiales eran bastante inútiles.
    El ecosistema de hacking siempre trajo las funciones más interesantes a los teléfonos, pero los fabricantes hicieron cada vez más difícil acceder a ellas.
  • En mi teléfono personal con GrapheneOS es una función imprescindible. Como normalmente lo uso solo una o dos veces al día, casi siempre está recién reiniciado cuando lo uso.
    Leí alguna vez que muchos exploits nuevos en el ámbito móvil existen solo en memoria y se mitigan con un simple reinicio, incluido, según entiendo, el infame spyware Pegasus.
  • Probablemente sea más bien un punto medio. Un retraso tan largo permite evitar titulares sensacionalistas sobre usuarios furiosos por reinicios aleatorios, y tampoco es tan corto como para que las agencias federales reaccionen públicamente y vuelvan a exigirle a Trump una puerta trasera.
    Al mismo tiempo, es una actualización de bajo perfil que no llama mucho la atención fuera de la comunidad técnica, así que quizá los delincuentes menores no se preparen bien. Si fuera un diseño hostil para el usuario, ni siquiera lo habrían implementado.
    El estilo típico de Apple es elegir valores predeterminados generales y no molestar al usuario; a veces eso es bueno y a veces malo.
  • Me da curiosidad saber cómo es usar Graphene en la práctica.

• Si esto es cierto, convertirlo en una opción configurable sería una mejora trivial. Deberían dejar 72 horas como valor predeterminado y permitir bajarlo a 12 horas o menos si hay mayores requisitos de seguridad.

  • Si fuera configurable, lo pondría en 30 minutos y lo aumentaría si me causa molestias. Ya uso el teléfono siempre en modo No molestar, así que no me preocupa que el reinicio retrase notificaciones, y tampoco me molesta demasiado ingresar el código en vez de usar FaceID cada 30 minutos.
  • Si se vuelve configurable, podría ser difícil hardcodearlo dentro del Secure Enclave para que no pueda desactivarse si el teléfono tiene jailbreak.
  • Estoy de acuerdo, pero que Apple haya elegido 72 horas suena como una decisión para darle tiempo a la policía. Supongo que es porque la policía está más organizada que los delincuentes.
  • Hacerlo configurable es el siguiente paso lógico.

• Esta función parece romper el reenvío de SMS entre iDevices. Lo descubrí por las malas cuando algunas notificaciones de entregas de paquetería no llegaron hasta que desbloqueé mi iPhone secundario y abrí la app Mensajes.

• Entiendo que un teléfono bloqueado tenga que tener ya todo cargado en memoria. Pero me pregunto qué obstáculo técnico impide que Apple haga que el estado bloqueado sea tan seguro como justo después de reiniciar.

  • En el estado antes del primer desbloqueo, las vistas previas de notificaciones, la información de contacto de llamadas entrantes y otros datos específicos del usuario siguen bloqueados porque no se han descifrado. Apple no lo hace así porque esas cosas también cambiarían mucho la experiencia de usuario.
  • Hay una buena explicación de cómo se implementa esto criptográficamente: https://www.youtube.com/watch?v=BLGFriOKz6U
  • Creo que el obstáculo tiene más que ver con la experiencia de usuario que con la tecnología.

• Creo que 404Media fue quien confirmó esto primero. Quizá no. Es un artículo para suscriptores y no encontré un enlace archivado para ver el contenido completo, pero es un medio que hace buen trabajo y vale la pena apoyar.
  https://www.404media.co/apple-quietly-introduced-iphone-rebo...

• El reinicio automático existe en teléfonos Samsung desde Android 5 Lollipop, hace 10 años. Me alegra que el progreso tecnológico finalmente haya llegado hasta Apple.

  • En términos de seguridad, no es la misma función. Eso se parece más a gestión de rendimiento, como reiniciar una PC vieja con Windows.
    El BFU de Android, es decir, el estado antes del primer desbloqueo, es bastante similar al del iPhone: los datos permanecen bloqueados, no llegan notificaciones y las apps no se ejecutan. Primero hay que desbloquear para que las apps se ejecuten, lleguen notificaciones y el dispositivo entre en un estado más vulnerable para atacantes.
    Uso tanto iPhone como Android, y mi Android actual es el modelo más reciente, un Z Fold 5. El Fold 5 se reinicia automáticamente cada semana, pero después del reinicio siguen cargándose las apps en segundo plano habituales y las notificaciones funcionan normalmente.
    Eso significa que Android, o más precisamente OneUI, la capa que Samsung pone encima de Android, no hace un reinicio “completo” y no ofrece la ventaja de seguridad de dejar el teléfono en estado BFU o frío como lo hace Apple.

• Me pregunto por qué no separan físicamente la memoria de instrucciones de programa y la memoria de datos. Entiendo que hay aproximaciones similares a nivel de páginas, pero no veo por qué permitir que el kernel modifique su propia memoria desde el principio.
  ¿No sería posible algo como una unidad de memoria que solo cargue páginas firmadas?

  • Lo que pides no es una computadora de arquitectura von Neumann, sino de arquitectura Harvard. Eso implica compromisos.
    Hay que tener en cuenta que JIT es una tecnología muy útil, así que perderla tiene un costo bastante alto, y que los intérpretes de todos modos tratan la memoria de datos como memoria de instrucciones de programa, lo que limita los beneficios de esa separación.
  • No entiendo de qué es respuesta esto. Ya funciona así, y el kernel no puede modificar sus propias páginas de código. Aun así quedan muchas superficies de ataque, como ataques que sobrescriben punteros de función u otros datos.
  • iOS ya funciona así.

• Pregunta: ¿la pantalla de reinicio de Apple realmente muestra el log de dmesg?

  • Probablemente sea un Security Research Device. https://security.apple.com/research-device/
  • No creo que sea en la versión final; probablemente eran investigadores de seguridad usando una beta para desarrolladores con algún modo de logs detallados activado.