¿Recuperación de datos de un teléfono encriptado basada en fallos de encriptación?

No soy un experto en el tema, sólo es un análisis del caso según mis limitados conocimientos.

ENCRYPTION de Android

Android admite dos modos de cifrado; FDE y FBE . FDE encripta todo el dispositivo de bloques, es decir userdata partición usando el kernel de Linux dm-crypt mientras que el FBE se basa en fscrypt disponible desde Android 7. Desde el punto de vista de la recuperación de datos, el enfoque es similar para ambos. Ambos ofrecen un fuerte cifrado y lo que ha sido atacado por los hackers no es el cifrado en sí, sino el mecanismo de Android para crear y almacenar las claves necesarias para el descifrado.

a veces hay un fallo al activar el cifrado que deja parte del almacenamiento sin cifrar

Tienes razón, es interesante. FDE, AFAIK, encripta todo el dispositivo de bloques, sólo excluyendo el pie de página criptográfico al final de la partición que incluye las claves para el descifrado. Inicialmente todos los sectores podrían no estar encriptados como es el caso de encriptación en el lugar :

vold comprueba si un sector está en uso antes de leerlo y escribirlo, lo que hace que la codificación sea mucho más rápida en un dispositivo nuevo que tiene pocos o ningún dato.

Pero los sectores omitidos son los que no contienen datos en el sistema de archivos. Sin embargo, a medida que se escriben datos en los sectores (o si el cifrado se inicializó con datos aleatorios, lo que no parece ser el caso de Android), se cifran y muy pronto todo el dispositivo de bloques se convierte en un gigantesco bloque de datos de alta entropía sin estructura visible. Es imposible distinguir los datos encriptados del ruido aleatorio. TRIM Sin embargo, si apoyado por el hardware, el kernel, el sistema de archivos y el sistema operativo, puede revelar el espacio vacío en el sistema de archivos. Pero la lectura de ese espacio sólo devuelve ceros.

POSIBLES MÉTODOS DE RECUPERACIÓN DE DATOS

La recuperación de datos funciona generalmente de dos maneras:

• Leer sólo el contenido del archivo mediante el método carving / búsqueda de firmas
• O leer los archivos completos junto con los metadatos (nombres de archivos, marcas de tiempo, permisos) del sistema de archivos

Los métodos posibles son:

• Lectura de la memoria flash a través del controlador de firmware (Flash Translation Layer) de la eMMC utilizando las APIs comúnmente disponibles, por ejemplo, del kernel de Liux. Es la FTL la que almacena el mapeo de LBAs a PBAs, y la información relacionada con las particiones, sectores defectuosos, datos borrados, etc. Esto se puede hacer exponiendo las particiones a un PC en algún modo de cargador de arranque si está disponible, o utilizando algún protocolo de comunicación de nivel inferior, por ejemplo, JTAG o por el método de chip-off.
• O acceder directamente a las células de silicio, lo que sólo es posible con equipos sofisticados que se encuentran en los laboratorios forenses, y no sin la hoja de datos del fabricante. En este caso sólo es posible el método de tallado. Los datos leídos de las celdas son bytes aleatorios del espacio no particionado y de las más de 50 particiones, incluyendo las que no tienen sistemas de archivos. Así que la probabilidad de recuperar datos útiles es casi insignificante, sobre todo de archivos razonablemente grandes. Si los datos guardados están encriptados (usando FDE, FBE o cualquier otro método), las posibilidades con este método son nulas con seguridad.

La elección del método depende de múltiples factores como, por ejemplo, si el objetivo es:

• Para recuperar los datos borrados
• Para recuperar los datos de un teléfono muerto
• Para romper el mecanismo de encriptación, por ejemplo, en caso de análisis forense, robo de teléfonos, etc.

La recuperación de datos puede hacerse de cualquier manera:

• En el dispositivo, por ejemplo, en el modo de recuperación si el dispositivo está desbloqueado y algún entorno de recuperación personalizado está disponible.
• O fuera del dispositivo. Es la única opción en la mayoría de los casos ya que los dispositivos tienen los bootloaders bloqueados. Pero si su dispositivo fue enviado con Android 5+, lo más probable es que debe tener hardware respaldado encriptación activada, lo que hace casi imposible recuperar -incluso sin borrar- los datos fuera del dispositivo, salvo que se intente alguna hacks porque no se puede fuerza bruta de claves RSA .

DESBLOQUEO DEL BOOTLOADER

Teniendo en cuenta todos los hechos anteriores y su situación, sólo se puede intentar recuperar los datos con un enfoque on-the-device o semi-offline. Pero entonces viene la parte de desbloqueo del bootloader.

Google exige a los proveedores de SoC/OEM que borren completamente los datos en desbloqueo del bootloader :

Como mejor práctica, los dispositivos Android desbloqueables deben borrar de forma segura todos los datos del usuario antes de ser desbloqueados.
...
La no aplicación de estas protecciones se considera un vulnerabilidad de seguridad de nivel moderado .

Citado en aquí :

Cuando el fastboot flashing unlock se envía el comando...
...
se debe realizar un restablecimiento de los datos de fábrica para evitar el acceso no autorizado a los datos

Dependiendo del dispositivo un BLKSECDISCARD , BLKDISCARD o se recomienda una sobreescritura completa con ceros. A continuación, se crea un sistema de archivos que puede volver a emitir TRIM . Lo mismo ocurre durante un restablecimiento de fábrica, es decir. userdata y cache particiones se borran completamente (aunque la conformidad en el pasado ha sido mal ). Véase esta respuesta para más detalles.

BLKDISCARD y FITRIM son IOCTLs del kernel de Linux que emiten comandos especiales a los dispositivos eMMC subyacentes dependiendo de sus capacidades. TRIM es emitido por el sistema de archivos al FTL, solicitando el borrado físico real de los bloques de datos (LBAs) que han sido borrados del sistema de archivos. DISCARD es una especie de TRIM para el dispositivo de bloque completo. TRIM obviamente no toca los archivos no borrados, la estructura del sistema de archivos y la tabla de particiones de la unidad. BLKDISCARD no guarda nada en absoluto en el dispositivo de bloqueo, incluyendo el pie de página criptográfico. Ambos comandos pertenecen a Saneamiento lógico nivel de borrado seguro de datos. Así es ERASE comando emitido por BLKSECDISCARD IOCTL, mientras que otros emitidos por el mismo - incluyendo SECURE TRIM , SECURE ERASE y SANITIZE - se consideran de Saneamiento digital es decir, provocan un borrado aún más seguro. Incluso una sobreescritura completa con ceros hará que los datos sean irrecuperables - al menos sin fundir la eMMC - debido al sobreaprovisionamiento y la recolección de basura.

POSIBILIDAD DE RECUPERACIÓN DE DATOS

Así que, en resumen, estos comandos (si son compatibles con el hardware subyacente y los controladores necesarios proporcionados por los proveedores) no dejan mucho espacio para la recuperación de los datos eliminados. La encriptación se suma al problema. Como se explicó anteriormente, el tipo de encriptación con FDE es, una especie de, todo o nada. Si incluso una pequeña parte del pie de página criptográfico se borra durante el desbloqueo del cargador de arranque, olvídese de la desencriptación. Citado por un ingeniero jefe de seguridad de Android ( ref ) :

Si piensas revender o desechar tu dispositivo y aún no lo has hecho, codifícalo y luego realiza un restablecimiento de fábrica

Y lo mismo ocurre con la eliminación del encabezado LUKS en Linux. Citado en la sección de advertencias de página oficial :

La mayoría de las preguntas en la lista de correo de cryptsetup son de personas que han conseguido dañar el inicio de sus particiones LUKS, es decir, la cabecera LUKS. En la mayoría de los casos, no hay nada que se pueda hacer para ayudar a estas pobres almas a recuperar sus datos.

Por lo tanto, sin el pie de página criptográfico que contiene la clave maestra encriptada, la clave RSA (vinculada al hardware) y otra información relacionada con el cifrado, todo son datos aleatorios. Pero incluso si asumimos que el crypto footer no fue borrado en tu caso y el cifrado respaldado por hardware tampoco fue un obstáculo, los problemas no han terminado. Con dm-crypt FDE una llave maestra se utiliza para cifrar / descifrar sectores (512B cada uno) individualmente cuando se escriben / leen respectivamente (cada sector tiene su propio IV). Después de descifrar userdata partiton se crea un nuevo dispositivo de bloque virtual en /dev/block/dm-0 que contiene un sistema de archivos, principalmente ext4 .

Para poder montar el sistema de archivos, los sectores que contienen la estructura básica del sistema de archivos deben estar intactos, por ejemplo, los superbloques, las entradas de los directorios, las tablas de inodos, los mapas de bits de los inodos/bloques, el diario, etc. Es casi imposible que todo esto no se haya sobrescrito al desbloquear el cargador de arranque y crear un nuevo sistema de archivos. Así que el antiguo sistema de archivos ha desaparecido y lo que te quedaría es el método de tallado, que tiene una tasa de éxito muy pequeña, especialmente debido a la fragmentación de los archivos grandes. La mayoría de las veces lo que obtienes son pequeñas miniaturas sin nombre o archivos de texto, eso también después de tantas suposiciones.

CONCLUSIÓN

Bootloader desbloqueado en un dispositivo cifrado, la probabilidad de recuperación de datos parece muy cercana a cero.

RELACIONADO

• ¿Qué dificulta la recuperación de datos?
• ¿Cómo obtener datos de un teléfono Android completamente muerto?
• Borrado fiable de datos de unidades de estado sólido basadas en flash