¿Cómo logra Android L un cifrado sólido con una frase de contraseña de baja entropía?

Las tarjetas bancarias basadas en chip suelen utilizar un PIN de 4 dígitos. Tomaría a lo sumo unas pocas horas probarlas todas si la tarjeta no protegiera contra intentos de fuerza bruta. La tarjeta protege contra los intentos de fuerza bruta al bricking después de 3 fallas consecutivas. El adversario no tiene acceso a un hash del PIN (hay protecciones físicas en la tarjeta que hacen que sea muy difícil de leer su memoria), pero solo a una caja negra que toma 4 dígitos como entradas y responde "sí" o " no". La clave para la seguridad aquí es que el adversario solo puede hacer intentos en línea, no intentos sin conexión . Cada intento requiere un cálculo en el dispositivo de defensa, no es solo una cuestión de hacer los cálculos.

Un teléfono Android o cualquier otra computadora puede hacer lo mismo con su clave de cifrado de almacenamiento. La clave no se deriva de la frase de contraseña (o patrón), sino que se almacena en algún lugar y se cifra con la frase de contraseña. La mayoría de los sistemas de cifrado de almacenamiento tienen esta dirección indirecta, de modo que cambiar la frase de contraseña no requiere volver a cifrar todo el almacenamiento, y para que el almacenamiento pueda borrarse efectivamente borrando los pocos bytes que conforman la clave cifrada (la clave de cifrado del almacenamiento es uniformemente aleatoria , así que, a diferencia de una clave derivada de una frase de contraseña, no está sujeta a fuerza bruta: el adversario debe obtener al menos la clave de almacenamiento cifrada para obtener un punto de apoyo).

Si el adversario puede leer la clave de almacenamiento cifrada, entonces puede realizar intentos rápidos de fuerza bruta en la clave en un grupo de PC. Pero si la clave de almacenamiento se almacena en un almacenamiento a prueba de manipulaciones, entonces el adversario no puede leerla y solo puede enviar los intentos de frase de contraseña al dispositivo, por lo que el dispositivo puede aplicar políticas como “limitar la tasa de intentos de 3 por minuto "o" requieren una segunda frase de contraseña más larga después de 10 intentos fallidos ".

La nueva función en Android L es la compatibilidad ascendente para una clave de almacenamiento cifrada que no se almacena en la memoria flash (desde la cual se puede descargar con un poco de soldadura o con acceso a la raíz), sino en alguna memoria protegida (que puede ser accesible solo en modo seguro TrustZone ). Sin embargo, no todos los teléfonos con Android L tienen dicha memoria protegida, e incluso si está presente, no hay garantía de que se use para el cifrado. Todos los cambios de Android L incluyen el código requerido como parte de la imagen básica de Android, lo que facilita la integración de los proveedores de teléfonos.

Android proporciona una API para verificar si el almacenamiento del llavero de la aplicación está en memoria protegida ). No sé si hay una API correspondiente para verificar la protección de la clave de cifrado de almacenamiento.

No sé si así es como lo hace Android, pero un dispositivo de almacenamiento seguro respaldado por hardware puede bloquear los intentos repetidos que se realizan demasiado rápido, por lo que su suposición de 0,1 conjeturas por segundo no es válida. Supongamos que inicialmente permite un intento cada 0.01 de segundo, pero duplica el tiempo entre intentos con cada falla después de los primeros cinco. Después de solo 50 intentos, tendrá que esperar 250 mil años antes de poder volver a intentarlo (y le habrá llevado 250 mil años llegar tan lejos). Pero siempre que pueda ingresar su contraseña correctamente en 10 intentos o menos, nunca notará ningún retraso.

La generación de una clave y el uso de una frase de contraseña son dos cosas diferentes. Las claves, por ejemplo, en la criptografía asimétrica, se generan utilizando la entropía proveniente del entorno informático (como /dev/urandom , que puede o no ser una buena fuente de entropía, pero ese es otro debate). Así que la clave en sí no tiene nada que ver con la frase de contraseña. La frase de paso solo se utilizará para cifrar la clave en un contenedor diseñado para almacenar la clave.

Si alguien quiere descifrar los datos del disco, necesitan la clave. Encontrar la clave debería ser casi imposible en las condiciones adecuadas. Si se hace correctamente, romper el cifrado del contenedor de la clave también sería imposible sin la clave.

Con respecto a la clave de fuerza bruta, de hecho podría ser una operación trivial si el atacante tuviera acceso al archivo de clave cifrado, considerando el bajo espacio de clave. Es el dispositivo responsable de hacer que el archivo de clave encriptado no esté disponible para el atacante.

De tu artículo vinculado leí:

  

Por lo general, no es posible obtener una copia en bruto de una partición de disco en la mayoría de los dispositivos comerciales, pero se puede lograr al iniciar una imagen de arranque de adquisición de datos especializada firmada por el fabricante del dispositivo, aprovechando una falla en el cargador de arranque que permite que las imágenes no firmadas iniciado (como este), o simplemente iniciando una imagen de recuperación personalizada en dispositivos con un cargador de arranque desbloqueado (un primer paso típico para 'rootear').

Estos ataques, si no imposibles, requieren alguna inversión (en términos de tiempo o dinero). Toda seguridad es una compensación.

También leí:

  

Suponiendo que la implementación es similar a la del almacén de credenciales respaldado por hardware, las claves de cifrado del disco deben cifrarse mediante una clave de cifrado de clave extraíble almacenada en el SoC, por lo que se obtiene una copia del pie de cifrado y la partición de datos de usuario cifrados. y la fuerza bruta de la frase de bloqueo de la pantalla de bloqueo ya no debería ser suficiente para descifrar el contenido del disco.

Lo que debería resolver el último problema.

Creo que los siguientes cuatro enfoques cubren más o menos todas las posibilidades de lo que se podría hacer:

• Utilice una función de derivación de claves costosa (en términos de tiempo de CPU). Sin embargo, ralentizar al atacante por cualquier factor de esta manera ralentizará los ataques legítimos por el mismo factor. Y, de manera realista, el atacante podrá usar más potencia de CPU de la que está presente en un solo dispositivo móvil, y es probable que el atacante pueda esperar una respuesta más larga que lo que un usuario está dispuesto a esperar al desbloquear el dispositivo. Como se ha dado cuenta correctamente, este enfoque requiere más entropía de lo que podría lograr un millón de diferentes frases de contraseña posibles.
• Use hardware a prueba de manipulaciones. Coloque la clave en una pieza de hardware especializada que limitará el número de intentos para extraer la clave a una tasa específica y disminuirá esa tasa en los intentos fallidos. Posiblemente incluso destruyendo la clave después de un gran número de intentos fallidos. Esto solo funciona contra un adversario que no puede desarmar este hardware y extraer la clave desde adentro.
• Utilice un servicio en línea. Si tiene acceso a un servicio en línea, entonces ese servicio podría proporcionar parte del cómputo necesario y hacer cumplir un límite de tasa. Una operación RSA ciega podría lograr esto sin filtrar ninguna información sobre la clave o los datos cifrados al servicio en línea. Pero no es muy práctico, ya que es posible que el dispositivo no tenga acceso a una conexión de red cada vez que desee desbloquearlo.
• Usa la memoria cuántica. Esto es básicamente una variación del hardware resistente a la manipulación indebida, pero impone la destrucción de la clave después de un número máximo de intentos al confiar en la física cuántica. Tampoco es práctico, ya que no creo que nadie haya diseñado con éxito la memoria cuántica que pueda almacenar los datos el tiempo suficiente para usarlos en datos persistentes.

De lo anterior, el hardware a prueba de manipulaciones suena como el enfoque más práctico.