La encriptación de Android es vulnerable y Google no es el culpable

El único tema de crítica que Android nunca pudo superar a pesar de los constantes esfuerzos de Google tiene que ser la seguridad y la integridad de los datos del usuario. Las amenazas siempre han logrado infiltrarse en el sistema operativo móvil más popular, impactando, como resultado, la privacidad a una escala extremadamente grande. Ya sea Hummingbird instalando aplicaciones engañosas en más de 10 millones de dispositivos o Stagefright cediendo el control sobre archivos personales, las soluciones temporales siempre han colapsado horriblemente a largo plazo.

Actualmente hay un montón de formas en que Google asegura que los dispositivos Android permanezcan seguros: parches mensuales por aire y una política de encriptación de disco completo habitual para los OEM. Sin embargo, la implementación de esta última depende del fabricante de hardware. Google ha ideado varias capas de encriptación para prevenir cualquier tipo de acceso no autorizado, aunque los algoritmos no son muy robustos debido al inmenso problema de fragmentación y, por lo tanto, incluso una sola responsabilidad o fallo puede revelar todo.

Cómo funciona la encriptación de Android

La encriptación de Android se basa en un núcleo de Linux bien establecido (núcleo central de un sistema particular), cuyos detalles no son necesarios para entender esto. En resumen, cada dispositivo específico crea una clave maestra única y aleatoria de 128 bits que generalmente se conoce como Clave de Encriptación del Dispositivo (DEK) y se utiliza para ocultar los datos del usuario. El smartphone también crea una sal adicional de 128 bits que, junto con cualquier PIN o contraseña habilitada por el usuario – Clave de Derivación de Clave (KEK), se utiliza para encriptar la DEK misma. Por último, la DEK se almacena en un espacio de memoria no encriptado (titulado “ pie de crypto ”) en el teléfono. Para desencriptar el sistema de archivos con fines de nivel administrativo, todo el proceso se invierte esencialmente.

Sin embargo, hay otro campo privado que está vinculado al hardware de cada dispositivo. La derivación de clave y la desencriptación implican el valor mencionado anteriormente que firma la KEK, que luego se utiliza para decodificar la DEK. Este proceso es llevado a cabo por un módulo separado empaquetado en Android, denominado KeyMaster. El propósito principal de implementar un módulo dedicado para la desencriptación y no entregar las claves directamente a las aplicaciones es bastante obvio. Otra cosa que debes saber es el Entorno de Ejecución Confiable – TEE que retiene el programa KeyMaster.

¿Cuál es el problema?

Aprender sobre el proceso de encriptación dice algo sobre cómo Google ha intentado hacer su parte para mantener las vulnerabilidades alejadas de Android. Desafortunadamente, la clave generada por hardware depende de cómo los OEM la estructuran. Un investigador de seguridad recientemente intentó acceder a archivos privados de Android y, sorprendentemente, logró revelar un gran fallo en el sistema. Afirmó que la función de derivación de clave, que se utiliza básicamente para firmar la KEK, no está realmente vinculada al hardware como se esperaba. De hecho, pudo generar la clave desde el software de TrustZone sin ningún problema. Por lo tanto, incluso un pequeño agujero en el núcleo o el módulo KeyMaster puede llevar a un completo desastre para el usuario.

El investigador encontró un pequeño trozo de espacio no protegido en el código del núcleo y, sin ningún fallo del sistema, sobrescribió el área con una función personalizada para filtrar claves del KeyMaster. Esto requiere que el secuestrador obtenga físicamente el dispositivo de una persona, aunque es un bypass técnico preocupante que necesita atención inmediata de Google. El problema puede ser parcialmente solucionado con parches de seguridad regulares, pero ¿qué porcentaje de distribuciones realmente se mantiene al día con los teléfonos Nexus de Google? Además, el investigador mencionó que esta brecha puede extenderse eventualmente al acceso inalámbrico si el usuario visita una aplicación o sitio web inseguro, incluso por accidente. Dado que la mayor parte de la cuota de mercado de Android no incluye teléfonos Nexus, este tipo de vulnerabilidades impacta a un enorme número de usuarios.

La única solución aquí es una revisión de hardware y la obligación para los OEM de lanzar parches actualizados mensualmente. Los teléfonos insignia están recibiendo estas correcciones hoy en día, aunque es un porcentaje asombrosamente pequeño de dispositivos. Dadas algunas circunstancias recientes, los fabricantes definitivamente necesitan abordar estas preocupaciones de privacidad para cada uno de los teléfonos que existen, de lo contrario, los malware severos seguirán impactando todo el espacio de Android, lo que podría llevar eventualmente a graves violaciones de la integridad de los datos. Los clientes también necesitan entender las consecuencias y, en la medida de lo posible, evitar desactivar las verificaciones de seguridad en la configuración y los smartphones Android que no reciben actualizaciones en absoluto.