El cifrado de datos por defecto de Android al detalle

Con la salida al mercado del iPhone 6 y el iPhone 6 Plus, quedó un poco ensombrecido un movimiento que la competencia realizaba, el cifrado por defecto en las nuevas versiones de Android.

Hablé en su momento de las novedades que traía Apple Pay en cuanto a la seguridad, y creo que toca hacer lo propio sobre Android y su cifrado, más sabiendo la poca información que había hasta ahora del funcionamiento interno del mismo.

Para entrar en materia, podemos decir que todos los dispositivos con Android desde la versión 3.0 cuentan con una opción para habilitar un cifrado en la partición /data del usuario, de tal manera que toda información que entre o salga debe cifrarse/descifrarse antes de ser utilizada.

Para aquellos que como un servidor hayan probado (o utilicen desde entonces) el cifrado en Android, seguramente recordarán que la primera vez te pedían que insertaras una contraseña. Para colmo, al menos en la versión que yo lo activé (supongo que sería la 3.5) te obligaban además que la contraseña fuera alfanumérica de seis o más caracteres (nada de PIN o patrón de desbloqueo) y que además debía ser semejante a la de desbloqueo.

De hecho fue esta una de las razones que me llevó a utilizar este tipo de desbloqueo que tanta risa le produce a la gente que me conoce (porque reconozco que hasta que no me hice con un terminal de más de 5 pulgadas de pantalla, con el aumento del teclado y la posibilidad de tener letras y números visibles a la vez, el tener que escribir una contraseña alfanumérica cada vez que quería desbloquearlo era sencillamente una putada).

Esta restricción es debida a que el FDE (Full Disk Encryption), una versión capada del framework dm-crypt de Linux, genera una master key de 128 bits aleatoria protegida bajo un cifrado AES CBC que utiliza la contraseña. Restricción que en las nuevas versiones de Android ha desaparecido, lo que repercute en un aumento de la seguridad (no se conoce por tanto la clave pública) y de paso apunta al guardado de contraseña en hardware (técnica que ha aplicado también Apple con el User ID).

Es este elemento el que a priori me parece más interesante, ya que pasamos de una clave KEK pública y generada por el usuario (aka poco insegura) a otra que se genera y guarda en el hardware, posiblemente mediante la librería QSEE que recopila credenciales hardware compatibles con la amplia mayoría de SoCs de Qualcomm.

Agrega el factor hardware a la ecuación, lo que obliga al posible atacante a tener que lanzar el ataque por fuerza bruta en el propio dispositivo, y no en un ordenador preparado específicamente para dar solución a grandes volúmenes de procesamiento, cosa que hasta ahora solía ocurrir (bastaba con que el atacante sacara una copia del cifrado y de la partición de datos y la metiera en un ordenador con una gráfica potentilla).

Además, delega la seguridad del dispositivo en elementos donde el usuario no tiene control, por lo que este ve desplazado su puesto en la cadena de seguridad, y evita ser el eslabón más débil (algo habitual, por otra parte).

Seguramente aún así sea explotable, pero lo que antes podría llegar a romperse en 5 minutos (y lo digo en serio), ahora posiblemente lleve días o semanas.

Movimientos de compañías que juegan a favor de los intereses del usuario, y que no afectan en ningún momento a su propio negocio. El cifrado por defecto es una gran herramienta cuando el cliente pierde el terminal, e incluso cubre algunos casos de tráfico de datos entre aplicaciones que no cuentan con los permisos adecuados, por lo que bienvenido sea.

Fuente: Pabloyglesias