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

Apple recientemente hizo olas dentro de la comunidad tecnológica al negarse a cumplir con la aplicación de la ley en lo que respecta al acceso a datos de usuario encriptados. Su declaración fue que no tienen la capacidad técnica para descifrar estos datos.

Como usuario de Android, ¿existe alguna posibilidad similar (preferiblemente integrada en el sistema operativo en lugar de un tercero) que pueda usar para lograr una protección similar incluso de Google y el fabricante de mi dispositivo? Sé que existe el "Cifrado completo del dispositivo" en mi configuración, pero ¿esto impide que Google, etc. acceda a él?

Como referencia, mi dispositivo ejecuta Android Lollipop y es un OnePlus Two. Si otras versiones como Marshmallow me permitieran hacer esto, está bien.

Respuestas (2)

Google no tiene idea de cuál es la clave de cifrado de su dispositivo. Todo el proceso se lleva a cabo en su dispositivo y la clave nunca se transmite a ninguna parte. La clave en sí tampoco se almacena en texto sin formato en su dispositivo :

Almacenamiento de la clave cifrada

La clave cifrada se almacena en los metadatos criptográficos. El respaldo de hardware se implementa mediante el uso de la capacidad de firma de Trusted Execution Environment (TEE). Anteriormente, encriptamos la clave maestra con una clave generada al aplicar scrypt a la contraseña del usuario y la sal almacenada. Para hacer que la clave sea resistente a los ataques externos, ampliamos este algoritmo firmando la clave resultante con una clave TEE almacenada. La firma resultante se convierte luego en una clave de longitud adecuada mediante una aplicación más de scrypt. Esta clave luego se usa para cifrar y descifrar la clave maestra.

Entonces, incluso si alguien tuviera una copia de su clave maestra cifrada, no podría descifrarla sin la clave TEE del SoC de su dispositivo.

Por lo tanto, aparte de una falla en la implementación, el cifrado completo del dispositivo evitará que cualquier persona acceda a sus datos a menos que conozcan/obtengan su contraseña O puedan adivinar su contraseña (por ejemplo, mediante fuerza bruta o algún tipo de técnicas de ingeniería social). En los dispositivos que carecen del respaldo de hardware necesario, FDE intentará cifrar la clave usando un método de solo software.

@beeshyams Es una característica del procesador. La implementación de ARM se llama "TrustZone", pero otras arquitecturas también proporcionan mecanismos similares. La idea es que pueda generar una clave de dispositivo, almacenarla en un lugar al que solo pueda acceder el TEE y luego nunca revelarla al mundo exterior. Cuando necesita cifrar/descifrar algo, le pide al código que se ejecuta en el TEE que lo haga por usted, para que la clave permanezca segura. Wikipedia tiene un artículo decente (-ish) .
¿Qué tan bien protege esto contra ataques de fuerza bruta a través de firmware modificado? ¿Evita las actualizaciones de firmware sin descifrar? Aparentemente, ese es el vector de ataque potencial actual para iOS (antes del iPhone 6). Sería bueno tener esa respuesta para Android también. Mantener una clave TEE local del dispositivo está muy bien, pero se debilita si los atacantes tienen la capacidad de cargar/arrancar una versión vulnerable del firmware.
@eldarerathis: Gracias. En mi opinión, requiere más comprensión. Redacción de una pregunta de recompensa . Es posible que desee responder, siempre que no sea derribado :)
@Bob Los datos cifrados en sí mismos no se pudieron descifrar solo con una actualización de ROM. Todavía necesitaría la clave (¿no estoy seguro de si eso fue lo que quiso decir con su segunda pregunta?). En cuanto a la actualización de una ROM debilitada, siempre que el gestor de arranque del dispositivo esté bloqueado, sería básicamente lo mismo que en iOS: solo se instalarán las actualizaciones firmadas por el OEM. Además, desbloquear el gestor de arranque para intentar flashear una imagen sin firmar borraría el dispositivo.
@eldarerathis Lo que escuché es que el iPhone 6 y los más nuevos están a salvo incluso de las actualizaciones OEM, ya que la verificación de la contraseña ( incluido el retraso/bloqueo cronometrado) se implementa completamente en el hardware. Lo que pregunto es si Android hace algo similar o si se trata simplemente de un bloqueo de software, que por supuesto puede evitarse mediante una actualización de firmware. También estoy preguntando si existe algún teléfono basado en Android con cargadores de arranque que rechacen las actualizaciones sin que se ingrese el código de acceso especificado por el usuario, lo que facilitaría eludir los períodos de bloqueo del software.
Otra forma más de reformular es si hay una forma de exigir que se produzca el descifrado (con contraseña de usuario) antes de que se permitan las actualizaciones. En otras palabras, ¿las actualizaciones (OEM, firmadas) se pueden instalar sin la clave de descifrado (sin un borrado obligatorio de los datos del usuario)?
@Bob Que yo sepa, Android no requiere la contraseña de descifrado para realizar el proceso de actualización, porque solo cifra la /userdatapartición, no las particiones que la actualización realmente estaría modificando ( /systemy /boot, en general). Está más o menos en el mismo barco que el iPhone 5 (e inferior).
Agregaría que no estoy seguro de si el retraso general por intento es algo que se puede "deshabilitar" mediante una actualización, o si Android lo escala artificialmente. Android usa rondas scrypt durante el proceso de generación de claves, por lo que también debería usarse al descifrar la clave, y scrypt está diseñado específicamente para ser difícil de acelerar, como una mitigación contra la fuerza bruta. Eso se mantendría consistente. Sin embargo, un bloqueo después de X número de intentos fallidos (o un bloqueo escalado, si existe) se implementaría en el software, AFAIK.
Gracias. Además, relevante: crypto.stackexchange.com/a/32891/11619 aparentemente en iOS podría ser posible actualizar el firmware "Secure Enclave" sin conocer el código de acceso y sin perder las claves. Suponiendo que eso sea cierto, al final del día, la misma vulnerabilidad (a las actualizaciones firmadas por OEM) se aplica tanto a Android como a iOS. Quizás Android sea más seguro en virtud de permitir contraseñas más largas, aunque eso depende del usuario y sería bastante inconveniente.
Bob, sospecho que "implementado en hardware" es engañoso. Lo que realmente sucede es que estas protecciones se implementan en el firmware y ese firmware se puede actualizar. La alternativa sería que no hubiera forma de corregir errores, como el problema "Error 53" en iPhones. Bruce Schneier se refiere a esto como un "agujero de seguridad", pero podría decirse que está extendiendo demasiado la definición de "agujero de seguridad". Obviamente, el firmware solo se puede actualizar si posee las claves OEM. Sabemos que esas claves se filtraron para el gusano Stuxnet (como señala Schneier) y también podrían serlo para los productos de Apple o Google.
¿Enraizar el dispositivo permitirá que cualquier persona sin las claves OEM actualice el firmware?
@JimThio Probablemente, pero solo si tuvo acceso al sistema o ADB mientras arrancaba. De lo contrario, no tendría forma de hacer uso de los permisos de root. Alternativamente, una recuperación personalizada le permitiría actualizar el firmware.

El cifrado completo del dispositivo protegerá su dispositivo si usa una clave demasiado larga para la fuerza bruta, incluso cuando los atacantes puedan usar técnicas de fuerza bruta, suponiendo que haya formas de permitirles hacer esto. Snowden dice que 64 caracteres es suficiente para un cifrado realmente indescifrable. Por lo tanto, se puede lograr una seguridad completa, si no le importa escribir una frase de contraseña de 64 caracteres cada vez que activa el teléfono.

¿Conoce la limitación de la longitud del PIN de bloqueo de pantalla? Considere reiniciar su respuesta en consecuencia
Sí, 16 caracteres es la limitación si revisa el código fuente .