Si algo es lo que más nos puede preocupar en los dispositivos móviles es el tema de la seguridad. Es fácil que podamos perder un dispositivo o que nos lo roben y que tengan acceso a una serie de datos que no desearíamos compartir.

Google se ha puesto manos a la obra en mejorar su seguridad, y ya ha confirmado que Android L traerá el cifrado de datos activado por defecto. Pero pasemos a verlo gracias a la ayuda de Nelenkov con un poco de más detalle cómo ha ido evolucionando Android en este tema.

Cifrado; de HoneyComb (3.0) a Jelly Bean (4.3)

No fue hasta la versión 3.0 de Android donde se introdujo la encriptación de disco completa (FDE desde ahora).

¿Cómo funciona el FDE?

El FDE de Android utiliza dm-crypt  del framework de Linux para implementar una encriptación de disco transparente para la partición de datos de usuario (/data).  Tan pronto como la encriptación esté habilitada, todas las escrituras que van al disco son automáticamente encriptadas antes de llevar a cabo el proceso, así como todas las lecturas desencriptadas al leerlas.

La clave de encriptación de disco (master key) es de 128 bits y se genera aleatoriamente, protegida por la contraseña de la pantalla de bloqueo. Para la encriptación se utiliza AES en modo CBC.

La estructura de parámetros de encriptación

Android, además, utiliza una estructura denominada crypto footer, la cual almacena todos los parámetros de encriptación. Es muy similar a LUKS, pero simplificándola y omitiendo algunas características (sólo almacena una copia de la master key y no tiene otras características, como la opción de recuperar la clave completa después de que haya sido borrada del disco, gracias a la clave cifrada por segmentos o también omite la suma de comprobación de la master key).

El ataque de la fuerza bruta

Toda la encriptación anterior es considerada relativamente segura. Pero al tratarse de una implementación software, por lo que si la clave maestra es suficientemente larga y compleja, un ataque por fuerza bruta (probar claves sin parar) podría tardar años.

Sin embargo, Android optó por utilizar el PIN o la contraseña de desbloqueo, que son hasta 16 caracteres. Esto nos lleva a que un ataque por fuerza bruta podría llegar a romper el FDE 1.0 de Android. Sí, es cierto que el cálculo computacional que un dispositivo móvil presenta es más limitado, pero eso no quiere decir que no podamos tener una copia del cifrado del pie de página y la partición de datos del usuario y realizar el ataque desde una máquina mucho más potente, especialmente cuando ya usamos además la GPU en lugar de la CPU.

Con esto se puede llegar a ver que con una NVIDIA GeForce 730M, recuperar un PIN de 6 dígitos se puede conseguir en menos de 10 segundos (4 horas en el caso de letras). ¿Tan seguro era? Parece que no…

Android KitKat (4.4)

No fue hasta Android KitKat (4.4) cuando realmente FDE evolucionó. Lo más importante vino de la mano de reemplazar PBKDF2 con scrypt, especialmente duro en GPUs pues requiere una gran cantidad de memoria. Por tanto, ahora la ejecución de tareas en paralelo en GPUs no es tan factible, lo que nos lleva a que un ataque por fuerza bruta tardará mucho más tiempo.

A pesar de todo, el tamaño de la clave maestra sigue siendo igual, así como el modo de cifrado del sector de disco.  Todo esto lleva a que se reinvente  un poco el proceso de ataque por fuerza bruta, y en este caso gracias a Linux FDE Bruteforcer Python se haya conseguido romper la clave igualmente, aunque en este caso necesitaremos casi 5 minutos para 1200 combinaciones de PIN.

Por tanto, sigue siendo factible descifrar la clave maestra, especialmente cuando no ponemos mucho énfasis en complicar la contraseña de bloqueo de pantalla.

Android L

Y ahora llega el turno de la versión preliminar de Android L, la cual también trae cambios respecto al cifrado de disco.  La primera novedad es que la versión del cifrado de pie de página ha subido hasta la versión 1.3, la cual utiliza un nuevo KDF (en lugar de PBKDF2 o scrypt), pero el modo de cifrado de disco y el tamaño de la clave no han cambiado.

Sin embargo, funcionalmente la principal novedad es que ya no se necesita asignar un PIN o contraseña de desbloqueo de pantalla, por lo que es muy probable que la llave maestra KEK ya no se derive de éstas.

En este caso, Android se ha apoyado de QSEE (Qualcomm Secure Execution Environment), el cual ofrece un almacén de credenciales hardware compatible con la mayoría de los dispositivos que utilizan los últimos SoCs de Qualcomm. Parece que de esta forma se almacena la clave KEK en hardware. Aun así, se sigue pudiendo utilizar la contraseña de la pantalla de desbloqueo (con scrypt).

Conclusiones

Como Android L aún está en fase prelanzamiento, seguro que tenemos mucho que descubrir aún. Sin embargo, los indicios ya apuntan a que ha habido una mejora sustancial en el cifrado de los datos de disco por parte de Google.

Aunque hay algo que debemos dar prácticamente por seguro: no estaremos 100% seguros de la protección de nuestros datos, pues igual que trabajan en la mejora de los sistemas de cifrado, también -en búsqueda de esa mejora- se trabaja en conseguir romper los existentes.