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

Nota: Bueno, la recompensa expiró y una posible razón podría ser el esfuerzo requerido para abordarlo mientras me reúno de los comentarios. Al ver el número de votos a favor, parece ser de interés para otros también. Todavía me gustaría obtener una respuesta, así que esto es lo que propongo: una buena respuesta dentro de un mes, obtendrá un bono de 50. Espero que esto dé un tiempo e incentivo adecuados

He estado tratando de entender el proceso de cifrado de Android y sus vulnerabilidades por un tiempo

Hay muchas preguntas que abordan partes de este tema en este sitio y también en el sitio hermano. Para aclarar mi punto de vista, estas preguntas abordan porciones y no el todo (que recuerda a "¿ ciegos y un elefante ?" :)

• ¿Qué protege el cifrado Marshmallow?
• ¿El cifrado completo del dispositivo protege mis datos de Google y del gobierno?
• /android/137334/if-we-encrypt-our-device-can-user-connecting-to-adb-get-it
• Preguntas relacionadas con el cifrado de la tarjeta SD
• cifrado de Android cuando el teléfono está encendido
• android-cyanogenmod-encryption-vs-gnu
• is-there-cryptographic-material-in-a-phones-sim-card-that-can-can-used-with-rsa
• cifrado de dispositivo Android

Mi entendimiento (¿o malentendido?)

1. La contraseña de cifrado se genera a partir de una combinación de PIN de pantalla de bloqueo de usuario y algoritmo de cifrado (en esto radica una debilidad inherente debido a la longitud limitada de PIN)
2. Esto es salado y almacenado en la ubicación raíz, no accesible para los usuarios
3. Esto se utiliza para generar la contraseña real para cifrar / descifrar y la contraseña real se almacena en la RAM
4. Esto se fortaleció al vincular el Paso 1 con el SoC del dispositivo ( ¿qué versión de Android? ¿Cuál es el elemento de hardware que identifica de forma exclusiva el dispositivo? ¿Puede reemplazarse por falso? )
5. Por lo tanto, no es posible descifrar datos sin la clave de cifrado y el dispositivo (también se mantiene para SD externo)
6. Posibles métodos de recuperación: fuerza bruta, captura de información de RAM (paso 3) para obtener la clave
7. ¿Los dispositivos enraizados parecen ser más susceptibles de acceder a los datos del paso 2 a través de la recuperación personalizada / posiblemente ROM y flasheo del núcleo? ( si es cierto, ¿por qué no se promociona esto como un gran riesgo? )
8. Incluso si se obtiene esta información, supongo que no es un esfuerzo trivial generar la contraseña real
9. Marshmallow puede tratar la SD externa como "almacenamiento interno" o "almacenamiento portátil". Lógicamente, no debería hacer una diferencia, pero no estoy seguro

En mi opinión, existen lagunas, probablemente también se pierdan otros aspectos clave.

Entonces, estoy buscando una explicación canónica para comprender desde la perspectiva del usuario

• Proceso de cifrado completo (incluida SD externa)

• Variación de implementación en las versiones de Android: desde KitKat hasta Marshmallow (incluidas las opciones duales para SD externo en Marshmallow)

• Vulnerabilidades a nivel de usuario

Nota

• Soy consciente del riesgo de que la pregunta se considere demasiado amplia, pero la OMI garantiza un tratamiento integral

• Al tener algo de experiencia en seguridad de la comunicación, entiendo el desafío de traducir conceptos criptográficos a nivel de usuario. Preferiría la respuesta para abordar esto, con indicadores explicativos para una comprensión más profunda. Los ejemplos del proceso no necesitan ser criptográficamente correctos en un sentido riguroso, sino que deben transmitir la esencia.

• Una posible ventaja podría ser "duplicar" futuras preguntas sobre aspectos relacionados

• A costa de la repetición, las respuestas deben ser principalmente a nivel del usuario , pero con una explicación adecuada para una comprensión más profunda. Dividir la respuesta en dos partes puede ser una forma adecuada.

• Me gustaría hacer un voto negativo en las respuestas triviales / casuales / parche para alentar respuestas integrales

Imagino que funciona así:

• El almacenamiento se cifra mediante una clave aleatoria sincrónica.
• Cuando el usuario elige o cambia una contraseña que se basa en cualquier entrada, ya sea una contraseña compuesta de letras y números y caracteres, o bien sea un código PIN, o deslizar un patrón, o huella digital, o cualquier otra entrada, un cifrado asíncrono El algoritmo se utiliza para cifrar la clave maestra, de modo que la identificación correcta termina descifrando la entrada que resulta en la clave maestra, lo que a su vez hace posible cifrar y descifrar el almacenamiento.
• En el momento en que el usuario cierra sesión, se sobrescribe la memoria que contiene la clave maestra

El gran truco aquí es el cifrado asincrónico de la clave maestra. Una vez que Android tiene la clave maestra, tiene la capacidad de intercambiar datos con el almacenamiento. Solo cuando el usuario inicia sesión, se conoce esa clave maestra. El cifrado asincrónico es lo que se llama cifrado de clave pública. Lo que sucede es que una clave pública cifra los datos (la clave maestra en este caso) y una clave privada descifra los datos. No debe confundirse con el cifrado de almacenamiento aquí. El almacenamiento es solo cifrado sincrónico. Allí se usa la misma clave para cifrar y descifrar. Pero el hallazgo / recuperación de esa clave "maestra" es el problema. Significa que si en un momento tiene un método de inicio de sesión débil, como por ejemplo "1234" como código PIN, y cambia de opinión, y cambia el código PIN a "5364", que es más difícil de adivinar, a menos que sea anterior "1234 " fue robado, fisgoneado, en cualquier momento, la seguridad acaba de mejorar. El mismo trato cuando se cambia el método de inicio de sesión a una contraseña completa que es imposible de adivinar o ataque de diccionario. No es necesario volver a cifrar el almacenamiento en sí. Se trata de ocultar esa clave maestra internamente. El usuario nunca ve esa clave maestra, porque lo más probable es que se trate simplemente de un código aleatorio de hash: nada "encontrará" o "adivinará" ese código hash. Ni siquiera la NSA o cualquier otro organismo de seguridad en el planeta podría encontrar una clave coincidente como esa. El único vector de ataque está esperando una debilidad por parte del usuario. Quizás el usuario eligió un inicio de sesión de código PIN. Si son 4 dígitos, entonces es un máximo de 10000 códigos PIN posibles. El sistema operativo puede "bloquear" el dispositivo después de probar algunos en poco tiempo. La solución es entonces "piratear" el sistema operativo, de modo que sea posible probar todos los códigos PIN posibles sin que el sistema operativo intervenga y bloquee el dispositivo. Creo que así es como el FBI finalmente tuvo acceso al teléfono de un criminal. Una compañía de terceros (alguna compañía israelí por lo que recuerdo) hizo el hackeo para el FBI, creo. Pasaron por alto ese límite de prueba de código PIN. Si el inicio de sesión es una contraseña completa, y si el usuario eligió una contraseña segura, y está sol. No en un tiempo de vida con todo el poder de la CPU en el planeta lo hackeará en un millón de años. No estoy comprando nada de la NSA puede descifrar cualquier rumor. Creo que esas personas vieron demasiadas películas de hombres de negro. Todo lo que tiene que hacer es mirar los documentos científicos sobre los diversos algoritmos de cifrado (por ejemplo, AES), y sabrá que el pirateo simplemente no sucederá, excepto en los viejos tiempos cuando había claves de 40 bits. Esos días han quedado atrás. AES128 ya es inquebrantable, creo, y si alguien está preocupado, saltar a AES256 lo hace más seguro en gran medida al tamaño del universo. Tal vez algún día las computadoras cuánticas puedan descifrarlo, pero soy escéptico. No estoy seguro de si es posible tener un sistema de probabilidad, simplemente resalte la solución. Veremos sobre eso, eventualmente. Tal vez eso esté a unas pocas vidas de todos modos. Nada de qué preocuparse en este momento.

Por lo tanto, al final del día, la limitación de seguridad radica completamente en el método de inicio de sesión que se utiliza. Se puede cambiar el método sin tener que volver a cifrar el almacenamiento. Todo esto debido al cifrado asíncrono de clave pública de la clave maestra.

Debido a 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 la siguiente. Por lo tanto, la principal preocupación no es el cifrado en sí, sino dónde se está ejecutando el proceso. Y si esa plataforma tiene vulnerabilidades, entonces la fortaleza del algoritmo de cifrado en sí mismo tiene poca o ninguna importancia.

Básicamente, una vez que su dispositivo descifra los archivos, se puede acceder directamente a ellos mediante un proceso con privilegios de Súper Usuario. Este proceso podría obtener acceso a su dispositivo explotando una debilidad en la ROM (sistema operativo Android). (Esto fue recientemente en las noticias ya que algunos defectos fueron expuestos por WikiLeaks)

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

Antes de rootear : Para rootear un dispositivo, debe usar herramientas externas, todas las cuales tienen 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) ¿Realmente podemos confiar en ellos? Confío en algunos más que en los demás. Por ejemplo, KingoRoot instaló un programa en mi PC que se comportó de manera similar a un virus (tuvo que usar arranque dual para eliminarlo).

Después de rootear : dar acceso a un programa compilado (APK) significa que puede hacer lo que quiera sin restricciones ni indicar qué intención utilizará. (Las intenciones son una forma para que los APK accedan a cosas como WiFi, cámara, etc.) Por lo tanto, una "aplicación de confianza", después de tener acceso a la raíz, puede acceder fácilmente a cualquier tipo de información y enviarla de vuelta a su servidor.

¿El cifrado completo del dispositivo protege mis datos de Google y del gobierno?

Google, sí. No tiene la clave para desbloquear.

Gobierno (o hacker) - no. porque el gobierno o el pirata informático pueden usar esencialmente un exploit que interceptará los archivos como mencioné anteriormente.

Las complejidades de los procedimientos / algoritmos de seguridad son de poca utilidad si se pueden interceptar y omitir.

Editar: 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 notificarle que se ha realizado la actualización. E incluso en un dispositivo rooteado, no parece haber una manera de bloquear esto sin perder funciones clave (Play Store, Maps, Sync, etc.)