¿El cifrado completo del dispositivo protege mis datos de Google y del 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 cifrados. Su declaración fue que no tienen la capacidad técnica para descifrar estos datos.

Como usuario de Android, ¿hay alguna posibilidad similar (preferiblemente integrada en el sistema operativo en lugar de un tercero) que pueda usar para lograr una protección similar incluso para 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.

security encryption

— malexdev
fuente

Google no tiene idea de cuál es la clave de cifrado para su dispositivo. Todo el proceso tiene lugar en su dispositivo y la clave nunca se transmite a ningún lado. La clave en sí tampoco se almacena en texto sin formato en su dispositivo :

Almacenar la clave encriptada

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

Por lo tanto, 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, fuera de una falla en la implementación, el cifrado completo del dispositivo evitará que cualquier persona acceda a sus datos a menos que conozca / obtenga su contraseña O pueda adivinar su contraseña (por ejemplo, mediante el uso de 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á encriptar la clave utilizando un método de solo software.

— eldarerathis
fuente

@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 puede 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, por lo que la clave permanece segura. Wikipedia tiene un artículo decente (-ish) .

— eldarerathis

@eldarerathis Lo que escuché es que el iPhone 6 y versiones posteriores están a salvo incluso de las actualizaciones OEM, ya que la verificación de la contraseña ( incluido el retraso / bloqueo temporizado) se implementa completamente en el hardware. Lo que pregunto es si Android hace algo similar, o si es puramente un bloqueo de software, que por supuesto se puede evitar mediante una actualización de firmware. También pregunto si existen teléfonos basados en Android con cargadores de arranque que rechacen las actualizaciones sin ingresar el código de acceso especificado por el usuario, lo que facilitaría eludir los períodos de bloqueo de software.

— Bob

Otra forma de reformulación es si hay una manera de exigir que ocurra el descifrado (con contraseña de usuario) antes de permitir 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

@Bob Que yo sepa, Android no requiere la contraseña de descifrado para realizar el proceso de actualización, ya que solo cifra la /userdatapartición, no las particiones que la actualización realmente estaría modificando ( /systemy /boot, en general). Está prácticamente en el mismo barco que el iPhone 5 (y versiones anteriores).

— eldarerathis

Agregaría, no estoy seguro si el retraso general por intento es algo que puede ser "deshabilitado" por una actualización, o si Android lo escala artificialmente. Android usa rondas de 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 el forzamiento bruto. Eso permanecería consistente. Sin embargo, AFAIK implementaría un bloqueo después de X número de intentos fallidos (o un bloqueo escalado, si existe).

— eldarerathis

-1

El cifrado completo del dispositivo protegerá su dispositivo si usa una clave demasiado larga para la fuerza bruta, incluso cuando los atacantes pueden usar técnicas de fuerza bruta, suponiendo que haya formas de permitirles hacerlo. Snowden dice que 64 caracteres son lo suficientemente largos para un cifrado realmente irrompible. 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.

— Andrew Brown
fuente

¿Conoce la limitación de la longitud del PIN de bloqueo de pantalla? Considere reiniciar su respuesta en consecuencia

— beeshyams

Sí, 16 caracteres es la limitación si revisas el código fuente .

— Señor del fuego