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

19

En el Android 4.0 (Samsung Galaxy Nexus) existe la posibilidad de encriptar el teléfono. Encontré esto sobre el cifrado en Android 3.0, ¿se utilizan 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 difícil escribir 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 de fuerza 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 usar en el disco, por lo tanto, existe una mayor necesidad de contraseñas más seguras aquí. (No ayuda mucho que haya aumentado el entropi de las contraseñas 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 con baja complejidad). ¿Cuál es el razonamiento detrás de verse obligado a usar la misma contraseña para ambas funciones?

security  encryption 
— Christopher Käck
fuente
3
Sí, pero si uso la contraseña, debería usarla para desbloquear mi pantalla. No es muy útil escribir 17 caracteres para realizar una llamada rápida. Por lo tanto, la mayoría de los usuarios vencerá con los números PIN y eso sería lo primero que intentaría un atacante. Un mejor enfoque quizás 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.
— Christopher Käck
1
Desafortunadamente, no sé si nadie más que Google pueda decirte el razonamiento. Probablemente podría probar el rastreador de errores de Android para presentar una solicitud de función. Parece algo sensato archivar allí.
— eldarerathis
2
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.
— Christopher Käck
1
+1, estoy totalmente con ustedes @ ChristopherKäck Esa decisión no tiene sentido, los ingenieros de Google deberían haberlo sabido mejor, espero que lo solucionen pronto.
— João Portela
1
@Christopher: pero está basando su decisión en una premisa incorrecta, el cifrado en el disco fue AES de 128 bits, no el PIN de 4 dígitos. Determinar si este esquema es seguro o es inherentemente defectuoso, no es la experiencia de Android.SE.
— Lie Ryan

Respuestas:

4

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

— Oscar_6
fuente
1

Al usar una contraseña / frase frente a un pin de cuatro dígitos, está aumentando la seguridad de su dispositivo. El truco es que, incluso al tener una contraseña de cuatro caracteres, solo ha aumentado su seguridad por dos razones:

  • Has aumentado los personajes disponibles.
  • Le has quitado a los atacantes el conocimiento de tu 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 MANERA DE FÁCIL acceder a los datos de su teléfono. Su abuela tiene la capacidad de hacerlo (sin ofender a usted ni a su familia: P). Entonces, si bien tiene razón de 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 privadas son sus datos, así como qué tan objetivo es para que dichos datos sean robados. Elegir una contraseña apropiada es su responsabilidad una vez que haya evaluado estos riesgos.

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

Si está tratando de descifrar el cifrado del disco, independientemente del resto del dispositivo en un escenario donde tiene un dispositivo apagado, o solo los chips de memoria, entonces este es un vector de ataque diferente al que se usa en un encendido dispositivo protegido por contraseña donde la clave de descifrado puede guardarse en la memoria (lo que genera vulnerabilidades utilizadas por elementos como los ladrones de claves de cifrado Firewire que prevalecen en las PC que usan 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 tiene 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 está encriptando el dispositivo, lo que está atacando es la clave AES de 128 bits:

La clave maestra es un número de 128 bits creado leyendo / dev / urandom. Se cifra con un hash de la contraseña de usuario creada 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) utilizada para agregar entropía al hash de PBKDF2 y evitar ataques de tabla de arco iris en la contraseña.

Desde el punto 4 en " Habilitación de la encriptación en el dispositivo " de las Notas sobre la implementación de la encriptación en Android 3.0 a la que se vinculó.

(iba a ser un comentario pero terminó demasiado tiempo)

— GAThrawn
fuente
1
Gracias por este bonito comentario! Una cosa sin embargo; ¿No estoy buscando la contraseña de usuario (que probablemente sea un pin de 4 dígitos, porque estás obligado a compartir la clave con el desbloqueo de la pantalla y cualquier otra cosa será una molestia para escribir para hacer una llamada telefónica) para descifrar los 128 bits Clave AES? (en lugar de buscar la clave directamente). Si hago un hash con todos los 10000 pines con la función PBKDF2 + sal, ¿no hay solo 10000 intentos de descifrado para que intente entonces?
— Christopher Käck
@Melpomene El " ataque de la mesa del arco iris " del que hablan es donde usted pre-encripta las 10,000 combinaciones para ver cómo se ven encriptadas y luego simplemente compara lo que hay en el disco con lo que está en su mesa del arco iris. La " sal aleatoria " es lo que se usa para ayudar a prevenir esto mediante la creación de más de 10,000 combinaciones que tendrá que adivinar (a menos que primero logre resolver la "sal").
— GAThrawn
1
Un arcoíris es una forma inteligente de almacenar contraseñas cifradas, sí. Y si se usa una sal, probablemente deba construirse especialmente 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 el atacante siempre considera que el Salt es conocido (ya que parece que se lee desde / dev / urandom en los documentos, lo más probable es que se almacene en texto claro o encriptado con la contraseña del usuario). De cualquier manera, la contraseña del usuario es el enlace débil.
— Christopher Käck
Pero ni siquiera necesitaría construir una tabla de arcoíris ya que almacenar (o calcular) 10,000 hashes no es tan difícil para mi memoria (procesador).
— Christopher Käck
Usar una función de derivación de teclas como PBKDF2 parece una buena noticia, pero un pin típico de 4 dígitos sigue siendo solo 10000 combinaciones posibles.
— João Portela
0

Si tiene habilitado el borrado remoto (suponiendo que todavía 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 borrarlo.

— Oportunidad
fuente
2
El problema es que un PIN corto solo puede asegurar el dispositivo cuando está encendido. Por lo tanto, apagar un dispositivo robado evita que se limpie el dispositivo 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
@Robert, no estoy muy familiarizado con el funcionamiento de la limpieza remota. Si se hace a través de Exchange, ¿el teléfono debe estar en el mismo momento en que se emite el comando de borrado remoto? Mi idea es que si puedo emitir un borrado remoto dentro de los 30 minutos de perder 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.
— Chance
2
El teléfono debe estar encendido y en línea algún tiempo después de que haya emitido el comando de borrado remoto. Si el teléfono se ha apagado (y permanece apagado), el comando de limpieza es inútil.
— Robert
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.