¿Es razonablemente seguro usar el código PIN para el cifrado?

En Android 4.0 (Samsung Galaxy Nexus) existe la posibilidad de encriptar el teléfono. Encontré esto sobre el cifrado en Android 3.0, ¿se usan los mismos algoritmos en Android 4? http://source.android.com/tech/encryption/android_crypto_implementation.html

Mi pregunta principal se refiere al uso de un código PIN para descifrar su teléfono. ¿Por qué me veo obligado a usar la misma contraseña para desbloquear mi pantalla y descifrar mi teléfono? Esta restricción solo me permitirá usar una contraseña de baja complejidad (como un número PIN), ya que sería demasiado difícil escribirla, es decir, 17 caracteres para desbloquear mi teléfono para una simple llamada telefónica.

Los intentos de fuerza bruta contra el desbloqueo de la pantalla podrían evitarse, es decir, mediante un reinicio forzado cada 5 intentos. Por lo tanto, no hay necesidad de una contraseña muy segura allí, un PIN podría ser lo suficientemente bueno.
Este tipo de protección no se puede utilizar en el disco, por lo que aquí existe una mayor necesidad de contraseñas más seguras. (No ayuda mucho que la cantidad de contraseñas haya aumentado, ya que habrá muy pocos usuarios con una contraseña compleja, por lo que un atacante podría simplemente probar la mayoría de las contraseñas de baja complejidad). ¿Cuál es el motivo por el que te obligan a usar la misma contraseña para ambas funciones?

Digo que debe usar un PIN o contraseña de pantalla de bloqueo . La contraseña puede tener hasta 17 caracteres y puede contener cualquier letra, número o símbolo (basado en una prueba rápida). Eso es mucha más entropía. Por supuesto, sería más seguro sin límite máximo, pero aún así.
Sí, pero si uso la contraseña, necesitaría usarla para simplemente desbloquear mi pantalla. No es muy útil escribir 17 caracteres para hacer una llamada rápida. Por lo tanto, la mayoría de los usuarios cumplirán con los números PIN y eso sería lo primero que intentaría un atacante. Quizás un mejor enfoque sería permitir frases de contraseña para el cifrado del disco y permitir números PIN simples en la pantalla de bloqueo. Para evitar intentos de fuerza bruta en la pantalla de bloqueo, podría haber un reinicio forzado después de 3 intentos fallidos que resulten en una solicitud de contraseña.
Parece que lo que estás buscando simplemente no existe, entonces.
Bueno, estoy buscando una respuesta a si hay algún razonamiento detrás de esto. Si alguien sabe una forma de evitar esto. De lo contrario, ¿cuál es un buen lugar al que acudir para dejar una solicitud de función? ¿El equipo de Google Android o Samsung (ejecutando una instalación limpia de Android 4.0.1)?
Desafortunadamente, no sé si nadie más que Google podría decirte el razonamiento. Probablemente podría probar el rastreador de errores de Android para presentar una solicitud de función. Esto parece una cosa sensata para archivar allí.
bueno, el comportamiento actual para desbloquear la pantalla (en android gingerbread 2.3.6) es que cada cinco intentos te hace esperar 30 segundos. Pospondría un poco cualquier ataque de fuerza bruta, ¿no crees?
Sí, contra el intento de inicio de sesión en la pantalla de desbloqueo, pero no contra el descifrado del disco duro. Eso es lo que estoy tratando de decir, el desbloqueo de la pantalla no necesita ser tan largo como el cifrado del disco duro (que debe ser mucho más largo que 4 números) y, por lo tanto, uno no debería verse obligado a usar lo mismo para ambos.
+1, estoy totalmente contigo @ChristopherKäck Esa decisión no tiene sentido, los ingenieros de Google deberían haberlo sabido mejor, espero que lo arreglen pronto.
Estás preguntando en el lugar equivocado, esta es una pregunta para Seguridad de la Información . La mayoría de los expertos en Android aquí no estarían calificados para responder o hacer un voto informado sobre las respuestas a esta pregunta.
@lie_ryan Bueno, la pregunta que estaba buscando era más bien una razón de Android-y/software-dev por la que compartirían la contraseña para las diferentes tareas. Sé que no es seguro usar 4 dígitos como contraseña de cifrado de disco.
@Christopher: pero está basando su decisión en una premisa incorrecta, el cifrado en el disco era AES de 128 bits, no el PIN de 4 dígitos. Determinar si este esquema es seguro o intrínsecamente defectuoso no es competencia de Android.SE.
@LieRyan Todavía comparten la contraseña independientemente del esquema de cifrado utilizado para el cifrado del disco. El problema es que los usuarios no elegirán una frase de contraseña larga si también necesitan usar la misma frase de contraseña larga para simplemente desbloquear la pantalla. Lo cual estoy -muy- convencido de que no es seguro. Entonces, ¿cuál puede ser la razón por la que el usuario se ve obligado a usar el mismo código de acceso para ambas funciones? ¿Alguna limitación en el sistema operativo?
@Christopher: No hay limitación sobre lo que se puede hacer con el software. Debe hacer una pregunta de seguridad en Seguridad de la información . Puede ser que resulte que el uso de claves diferentes en realidad no sea más seguro, o podría ser simplemente un descuido o una compensación práctica. De cualquier manera, obtendrá mejores respuestas allí que aquí. Como lo veo aquí, hay 5 respuestas mediocres; La respuesta de GAThrawn se acerca más a ser la respuesta más informada, pero no es una respuesta completa.

Respuestas (6)

Creo que he encontrado la solución. Consulta este enlace . Es un truco y requiere que un teléfono esté rooteado, pero le permite usar una contraseña alfanumérica para el cifrado y un PIN para desbloquear la pantalla.

Puede usar este comando en un shell raíz para cambiar la contraseña de cifrado:

su -c vdc cryptfs changepw <new_password>

Donde <new_password>debe ser reemplazado por su contraseña.

Fuente: http://nelenkov.blogspot.be/2012/08/ Changing -androids-disk-encryption.html

Al usar una contraseña/frase en lugar de un PIN de cuatro dígitos, está aumentando la seguridad de su dispositivo. El truco es que, incluso con una contraseña de cuatro caracteres, acaba de aumentar su seguridad por dos razones:

  • Has aumentado los caracteres disponibles.
  • Le ha quitado a los atacantes el conocimiento de su longitud de pw.

Si un atacante sabe que su contraseña tiene 14 caracteres, es más segura que una contraseña de cuatro u ocho caracteres, pero las estadísticas típicas usan rangos (1-4, 1-8, 1-14) y no la realidad (que sería simplemente calcular combinaciones disponibles de una longitud).

Actualmente, es simplemente MUY FÁCIL acceder a los datos de su teléfono. Tu abuela tiene la capacidad de hacerlo (sin ofenderte ni a ti ni a tu familia :P). Entonces, si bien tiene razón en que existen limitaciones de este cifrado, la versión 'rota' funciona MUCHO mejor que los datos no cifrados que se practican actualmente.

Depende de usted juzgar cuán confidenciales y privados son sus datos, así como qué tan objetivo es para el robo de dichos datos. Elegir una contraseña adecuada es su responsabilidad una vez que haya evaluado estos riesgos.

Sí, pero creo que sería una solución simple al problema tener diferentes contraseñas para desbloquear la pantalla y para descifrar el dispositivo (como mencioné aquí android.stackexchange.com/questions/17086/… ) ya que se usan en diferentes senarios y necesitan tener diferentes atributos.

Si está tratando de descifrar el cifrado del disco, independientemente del resto del dispositivo en un escenario en el que tiene un dispositivo apagado o solo los chips de memoria, entonces este es un vector de ataque diferente al que se usa en un dispositivo encendido. dispositivo protegido por contraseña en el que la clave de descifrado puede estar almacenada en la memoria (lo que genera vulnerabilidades utilizadas por cosas como los ladrones de claves de cifrado Firewire que prevalecen en las PC que utilizan software de cifrado FDE más antiguo y no un módulo de tipo TPM), o la pantalla de desbloqueo podría ser brutal. forzado (o tener sus propias vulnerabilidades).

Si está atacando el disco directamente, en este caso no está atacando el PIN de 4 dígitos o la contraseña de usuario que cifra el dispositivo, lo que está atacando es la clave AES de 128 bits:

La clave maestra es un número de 128 bits creado mediante la lectura de /dev/urandom. Se cifra con un hash de la contraseña de usuario creado con la función PBKDF2 de la biblioteca SSL. El pie de página también contiene una sal aleatoria (también leída de /dev/urandom) que se usa para agregar entropía al hash de PBKDF2 y evitar ataques de tablas de arco iris en la contraseña.

Desde el punto 4 bajo " Habilitar el cifrado en el dispositivo " de las Notas sobre la implementación del cifrado en Android 3.0 al que se vinculó.

(Iba a ser un comentario pero terminó demasiado largo)

¡Gracias por este lindo comentario! Sin embargo, una cosa; ¿No estoy buscando la contraseña de usuario (que probablemente será un pin de 4 dígitos, porque se ve obligado a compartir la clave con el desbloqueo de pantalla y cualquier otra cosa será una molestia para escribir para hacer una llamada telefónica) para descifrar el bit 128 clave AES? (en lugar de buscar la clave directamente). Si hago hash de los 10000 pines con la función PBKDF2 + sal, ¿no hay solo 10000 intentos de descifrado para mí entonces?
@Melpomene El " ataque de la tabla del arco iris " del que hablan es donde se cifran previamente las 10,000 combinaciones para ver cómo se ven encriptadas y luego simplemente se compara lo que hay en el disco con lo que hay en la tabla del arco iris. La " sal aleatoria " es lo que se usa para ayudar a prevenir esto al crear más de 10,000 combinaciones que tendrás que adivinar (a menos que logres resolver la "sal" primero).
Un arcoíris es una forma inteligente de almacenar contraseñas encriptadas, sí. Y si se usa una sal, probablemente deba construirse especialmente solo para descifrar contraseñas con esa sal. Esta no es una operación muy difícil cuando solo hay 10,000 contraseñas para elegir. Tenga en cuenta que Salt siempre se considera conocido por el atacante (dado que parece leerse de /dev/urandom en los documentos, lo más probable es que esté almacenado en texto sin cifrar o cifrado con la contraseña del usuario). De cualquier manera, la contraseña del usuario es el eslabón débil.
Pero ni siquiera necesitaría construir una tabla de arco iris ya que almacenar (o calcular) 10,000 hashes no es tan difícil para mi memoria (procesador).
El uso de una función de derivación de clave como PBKDF2 parece una buena noticia, pero un pin típico de 4 dígitos todavía tiene solo 10000 combinaciones posibles.
Para aclarar algunas confusiones: la sal se almacena sin cifrar en un pie de página de 16 KB de la partición cifrada. nelenkov.blogspot.be/2012/08/…

Una posible solución para esto es usar susurro, pero requiere que rootees tu dispositivo.

También llené una solicitud de función en la página del proyecto de Android .

Si tiene habilitado el borrado remoto (suponiendo que aún funcione con un dispositivo encriptado), es posible que el PIN no asegure su dispositivo para siempre, pero puede hacerlo lo suficiente como para darle tiempo para borrar su dispositivo.

El problema es que un PIN corto solo puede proteger el dispositivo cuando está encendido. Por lo tanto, apagar un dispositivo robado evita que el dispositivo se borre y, además, el PIN se puede romper en un ataque de fuerza bruta fuera de línea. Por lo tanto, un PIN corto no le ayuda en esta situación.
@Robert, no estoy muy familiarizado con el funcionamiento del borrado remoto. Si se hace a través de Exchange, ¿el teléfono tiene que estar en el mismo momento en que se emite el comando de borrado remoto? Creo que si puedo emitir un borrado remoto dentro de los 30 minutos posteriores a la pérdida de mi teléfono, eso es lo suficientemente bueno para mí, pero no tengo ningún dato financiero, mi principal preocupación es mi correo electrónico de trabajo de GMail.
El teléfono debe estar encendido y en línea algún tiempo después de haber emitido el comando de borrado remoto. Si el teléfono ha sido apagado (y permanece apagado), el comando de borrado es inútil.
¿Es razonablemente seguro usar el código PIN para el cifrado?
RespuestasAquíPolítica de privacidad1y, 0v