Explicación canónica del cifrado y las vulnerabilidades de Android

Me imagino que funciona así:

• El almacenamiento se encripta utilizando una clave aleatoria sincrónica.
• Cuando el usuario elige o cambia una contraseña basada en cualquier entrada, ya sea una contraseña compuesta por letras y números y caracteres, o ya sea un código pin, o un patrón de deslizamiento, o una huella dactilar, o cualquier otra entrada, se utiliza un algoritmo de cifrado asíncrono para cifrar la clave maestra, de manera que la identificación correcta acaba descifrando la entrada que da lugar a la clave maestra, lo que a su vez permite cifrar y descifrar el almacenamiento.
• En el momento en que el usuario cierra la sesión, la memoria que contiene la llave maestra se sobrescribe

El gran truco aquí es el cifrado asíncrono de la clave maestra. Una vez que Android tiene la clave maestra, tiene la capacidad de intercambiar datos con el almacenamiento. Sólo cuando el usuario está conectado, se conoce esa clave maestra. El cifrado asíncrono es lo que se llama cifrado de clave pública. Lo que ocurre es que una clave pública encripta los datos (la clave maestra en este caso), y una clave privada desencripta los datos. No hay que confundirlo con el cifrado de almacenamiento aquí. El almacenamiento es sólo un cifrado sincrónico. Allí se utiliza la misma clave para cifrar y descifrar. Pero la búsqueda/recuperación de esa clave "maestra" es lo más importante. Esto significa que si en un momento dado tienes un método de inicio de sesión débil, como por ejemplo "1234" como código de acceso, y cambias de opinión, y cambias el código de acceso a "5364", que es más difícil de adivinar, a menos que el anterior "1234" haya sido robado, fisgoneado, en cualquier momento, la seguridad acaba de mejorar. Lo mismo ocurre cuando se cambia el método de inicio de sesión a una contraseña completa que es imposible de adivinar o atacar por diccionario. El almacenamiento en sí no necesita ser re-encriptado en absoluto. Se trata de ocultar esa llave maestra - internamente. El usuario nunca ve esa clave maestra, porque lo más probable es que sea una especie de código hash aleatorio: nada podrá "encontrar" o "adivinar" ese código hash. Ni siquiera la NSA o cualquier otro organismo de seguridad del planeta podría encontrar nunca una clave que coincidiera con ella. El único vector de ataque es esperar una debilidad por parte del usuario. Tal vez el usuario eligió un código de acceso. Si son 4 dígitos, entonces hay un máximo de 10000 pincodes posibles. El sistema operativo podría "bloquear" el dispositivo tras probar unos cuantos en poco tiempo. La solución es entonces "hackear" el SO, para que sea posible probar todos los pincodes posibles sin que el SO intervenga y bloquee el dispositivo. Creo que así es como el FBI acabó teniendo acceso al teléfono de un delincuente. Una empresa de terceros (alguna empresa israelí por lo que recuerdo) hizo el hackeo para el FBI, creo. Se saltaron el límite de intentos de código PIN. Si el inicio de sesión es una contraseña completa, y si el usuario eligió una contraseña fuerte, y estás sol. Ni en una vida con toda la potencia de cpu del planeta se hackeará eso ni en un millón de años. No me creo nada de los rumores de que la NSA puede descifrar nada. Creo que esa gente vio demasiadas películas de hombres de negro. Todo lo que uno tiene que hacer es mirar los documentos científicos sobre los diversos algoritmos de encriptación (por ejemplo, AES), y usted sabrá que la piratería simplemente no va a suceder, excepto en los viejos tiempos cuando había claves de 40 bits. Esos días ya han pasado. AES128 ya es inhackeable, creo, y si alguien está preocupado, saltar a AES256 lo hace más seguro por una magnitud al tamaño del universo más o menos. Quizás un día los ordenadores cuánticos podrían descifrarlo, pero soy escéptico. No estoy seguro de que sea posible que un sistema de probabilidad destaque simplemente la solución. Ya lo veremos, eventualmente. De todas formas, tal vez eso esté a unas cuantas vidas de distancia. No hay que preocuparse por ahora.

Así que, al final, la limitación de la seguridad recae por completo en el método de inicio de sesión que se utilice. Uno puede cambiar el método sin tener que volver a encriptar el almacenamiento. Todo esto debido a la encriptación de clave pública asíncrona de la clave maestra.

Dado que las actualizaciones son frecuentes, la forma en que se maneja el cifrado en el teléfono (sistema operativo basado en Android) puede cambiar de una compilación a otra. Por lo tanto, la principal preocupación no es el cifrado en sí, sino dónde se ejecuta el proceso. Y si esa plataforma tiene vulnerabilidades, entonces la fuerza del algoritmo de cifrado en sí mismo se vuelve de poca o ninguna importancia.

Básicamente, una vez que el dispositivo descifra los archivos, estos pueden ser accedidos directamente por un proceso con privilegios de Super Usuario. Este proceso podría acceder a tu dispositivo explotando una debilidad en la propia ROM (sistema operativo Android). (Esto estuvo recientemente en las noticias ya que algunas fallas fueron expuestas por WikiLeaks)

Los dispositivos rooteados parecen ser más susceptibles de acceder a los datos del paso 2 a través de la recuperación personalizada / posiblemente el flasheo de la ROM y el kernel? (si es cierto, ¿por qué no se ha promocionado esto como un gran riesgo?)

Antes de root : Para rootear un dispositivo hay que utilizar herramientas externas, todas ellas con acceso profundo a la estructura interna del dispositivo. Algunas de estas herramientas están precompiladas y no son de código abierto. Tienen sitios web "oficiales", pero ¿quiénes son estas personas? (twrp.me, supersu.com por ejemplo, pero hay otros como KingoRoot) ¿Podemos realmente confiar en ellos? Yo me fío más de unos que de otros. Por ejemplo, KingoRoot instaló un programa en mi PC que se comportó como un virus (tuve que usar el arranque dual para eliminarlo).

Después de que usted Root El objetivo de este programa es dar a un programa compilado (APK) un acceso SU, lo que significa que puede hacer lo que quiera sin restricciones o indicando la intención que va a utilizar. (Las intenciones son la forma en que los APKs acceden a cosas como el WiFi, la cámara, etc.) Así que una "aplicación de confianza", después de darle acceso a root, puede acceder fácilmente a cualquier tipo de información y enviarla a su servidor.

¿Protege el cifrado completo del dispositivo mis datos de Google y del gobierno?

Google - sí. No tiene la llave de desbloqueo.

Gobierno (o hacker) - no. porque el Gobierno o el hacker pueden utilizar esencialmente un exploit que intercepte el/los archivo(s) como he mencionado anteriormente.

Las complejidades de los procedimientos/algoritmos de seguridad no sirven de mucho si se pueden interceptar y eludir.

Edición: Vale la pena mencionar que Google realmente tiene la capacidad de descargar e instalar/actualizar aplicaciones en su dispositivo Android sin pedir su permiso, o incluso notificar que la actualización ha tenido lugar. E incluso en un dispositivo rooteado, no parece haber una manera de bloquear esto sin perder las funciones clave (Play Store, Mapas, Sincronización, etc)