Google ha comenzado a introducir el cifrado de disco completo (FDE) predeterminado con Android 5.0 Lollipop. Al principio, cuando se implementó el cifrado en los dispositivos Nexus 6, muchos usuarios se quejaron de la degradación del rendimiento al leer y escribir datos en la unidad, pero desde la versión de Android 6.0 este problema parece estar resuelto.El cifrado de disco completo protege toda la información en el teléfono, incluso si el dispositivo cayó en manos de la policía u otros intrusos.Cuando el cifrado está habilitado, cualquier información en el teléfono se cifra automáticamente sobre la marcha con la tecla AES antes de escribir en los medios. Y viceversa, cuando se lee información, se descifra automáticamente con esta clave.En dispositivos iOS 9, esta clave es un derivado de la contraseña del usuario y una clave de hardware única de 256 bits conectada al teléfono inteligente en la fábrica. Incluso el FBI no puede descifrar este nivel de encriptación utilizando la fuerza bruta, como se sabe por la historia reciente con el teléfono inteligente del tirador de San Bernardino, por lo que el FBI y Apple llegaron a los tribunales . Como resultado, el FBI aún logró descifrar el teléfono usando una vulnerabilidad desconocida de 0 días. Como se puede entender de las palabras de la estructura del jefe de estado, los piratas informáticos tuvieron que pagar más de un millón de dólares para eludir la protección del FBI .
Cifrado de disco completo en iOSPor lo tanto, la fuerza bruta de FDE solo es posible utilizando un dispositivo de hardware específico. Esto complica enormemente el ataque. En el caso habitual, podría crear un millón de copias y paralelizar la fuerza bruta en el servicio en la nube, lo que le permite encontrar rápidamente el 99% de las contraseñas reales. Pero en este caso, tenemos que limitarnos al único dispositivo en el que Apple agrega interferencia adicional: demoras entre intentos de contraseña, límite en el número máximo de intentos, etc. Es por eso que es extremadamente importante que los servicios especiales encuentren una forma de recuperar el UID del hardware, luego la contraseña de fuerza bruta se convierte en una tarea técnica banal.El cifrado de disco completo en Android 5.0+ se implementa de manera algo diferente que en iOS 9, y se describe en detalle enBlog de Nikolay Elenkov y documentación oficial de Android .Aquí, la clave de cifrado también es un derivado de la contraseña de usuario generalmente débil , pero también de la clave maestra de 128 bits generada aleatoriamente (Clave de cifrado del dispositivo - DEK) y la sal de 128 bits generada aleatoriamente. El campo de generación DEK está protegido mediante un esquema cuidadosamente pensado que utiliza los valores ingresados por el usuario: código PIN / contraseña / patrón (clave gráfica) para ingresar. Luego, el DEK encriptado se coloca en un almacenamiento encriptado especial llamado cripto pie de página . Todos estos niveles de cifrado deben superarse antes de descifrar DEK, y luego cualquier información registrada en la unidad.
Como en el caso de iOS 9, el sistema operativo Android implementa la vinculación del esquema de cifrado a un hardware específico para evitar la fuerza bruta en las copias del sistema operativo. La función de enlace de hardware se realiza mediante un almacenamiento de hardware especial : KeyMaster, que opera en un entorno de ejecución de confianza (TEE) especial, que es completamente independiente del sistema operativo Android. La seguridad clave en el entorno KeyMaster es crítica. Solo esto protege al sistema de cifrado de disco completo de la realización de fuerza bruta efectiva en flujos paralelos en copias del sistema operativo.En dispositivos Android, un entorno aislado nunca emite su propia clave en un entorno "inseguro". Por el contrario, el módulo KeyMaster recibe un "blob clave" de un entorno inseguro, descifra la clave almacenada allí y la devuelve. En otras palabras, el funcionamiento del sistema de cifrado solo es posible directamente en el dispositivo de hardware, pero no en un entorno virtual en otra computadora.En general, todo el proceso se puede representar esquemáticamente en dicho diagrama, que Nikolai Elenkov ofrece .
La protección del entorno de KeyMaster y la ejecución de comandos en un procesador seguro dedicado están garantizadas por el entorno protegido proporcionado por el fabricante del equipo. En el caso de Qualcomm, este es el QSEE (Qualcomm Secure Execution Environment). Solo permite que pequeñas aplicaciones separadas llamadas trustlets se ejecuten en un procesador dedicado. Uno de estos trustlets es KeyMaster. El código fuente de Android tiene instrucciones para acceder a la aplicación KeyMaster. De hecho, el trustlet solo admite cuatro instrucciones: * Commands supported
*/
enum keymaster_cmd_t {
KEYMASTER_GENERATE_KEYPAIR = 0x00000001,
KEYMASTER_IMPORT_KEYPAIR = 0x00000002,
KEYMASTER_SIGN_DATA = 0x00000003,
KEYMASTER_VERIFY_DATA = 0x00000004,
};
KeyMaster funciona exactamente como se describió anteriormente: recibe el blob clave, calcula la firma y la coloca en el búfer.Y ahora hemos llegado exactamente a la etapa en la que opera el nuevo exploit, que apareció en el dominio público el 30 de junio ( repositorio en Github ). El exploit explota las vulnerabilidades descubiertas recientemente CVE-2015-6639 y CVE-2016-2431 .El autor del exploit, el especialista en seguridad Gal Beniamini, escribió una versión falsa de la aplicación QSEE y, utilizando las vulnerabilidades antes mencionadas, logró cargarla en un entorno seguro, aumentando así los privilegios y rompiendo la protección del entorno QSEE, que está involucrado en el proceso de generar una clave para cifrar el disco.Por lo tanto, un atacante hipotético puede "falsificar" el componente de hardware de la clave de cifrado e implementar la fuerza bruta de los componentes restantes, evitando la protección de Android por el número de reintentos. Solo queda seleccionar el PIN / contraseña del usuario por fuerza bruta.Por cierto, para el raro caso en que el usuario ha establecido una contraseña realmente compleja con alta entropía para el cifrado y no puede ser captada con fuerza bruta durante un tiempo aceptable, existe un plan de respaldo. Si realmente es necesario romper el cifrado, puede encontrar exactamente el mismo teléfono, del mismo modelo, con los mismos rasguños y una funda protectora, y programarlo para que envíe una contraseña tan pronto como la víctima ingrese. Este dispositivo falso está conectado a la víctima en lugar del original. Para evitar la divulgación y al mismo tiempo eliminar el riesgo de que la víctima ingrese la contraseña incorrecta en el primer intento, el teléfono debe estar programado para que no acepte ninguna contraseña como la correcta.Pero este es un caso extremo, por supuesto. En realidad, es bastante fácil detectar códigos PIN y contraseñas normales si no hay restricciones de hardware sobre la fuerza bruta.Hay un punto interesante. Qualcomm no establece el entorno seguro en los dispositivos móviles, sino los OEM. Pueden cooperar con las autoridades policiales del país en cuya jurisdicción se encuentran y cumplir con los requisitos de las solicitudes judiciales. En consecuencia, si dicho esquema criptográfico es implementado por un fabricante ruso, la información en el teléfono inteligente se desclasificará a solicitud del tribunal ruso.Y un momento más interesante. A pesar de que Gal Benyamini ha estado discutiendo estas vulnerabilidades con Qualcomm y Google durante varios meses, solucionarlas no es tan fácil: no hay suficiente actualización de software (para dos vulnerabilidades, se lanzaron parches para Android en enero y mayo ), y puede ser necesaria una actualización de hardware. El hecho es que si un atacante recibe un dispositivo, teóricamente puede revertir una actualización de software, devolver el dispositivo a una versión vulnerable y realizar un ataque.Como se mencionó anteriormente, el código de explotación se publica en Github . Aquí hay un diagrama de su trabajo.
Gal Benyamini ha escrito varios scripts de Python que simplifican la fuerza bruta después de que se desencadena un exploit. En los comentarios en la publicación del blog de su colegaexpresó su deseo de ayudar a portar el script a la plataforma de fuerza bruta hashcat / oclHashcat más poderosa .Benjamini sugiere que Google, junto con los fabricantes de OEM, desarrollarán un nuevo esquema de cifrado de hardware y software absolutamente confiable, que incluso teóricamente no se puede descifrar.Esperemos que dicho esquema se implemente en una nueva generación de dispositivos Android.