Pregunta

Digamos que tengo un archivo cifrado en un iPhone y cada vez que quiero descifrarlo, quiero " dibujar " un símbolo de descifrado en lugar de tener que usar un teclado para escribirlo.

Si solicita al usuario que dibuje un símbolo para descifrar un archivo cada vez que sea necesario (por ejemplo, cada vez que inicie su aplicación) probablemente preferiría tener que escribir una contraseña de 20 caracteres o más en el pequeño teclado. , y aún obtendrían la seguridad que les daría una contraseña de 20 caracteres (dependiendo de lo complicada que sea la forma / símbolo que dibujen).

El símbolo que dibujarían sería probablemente un golpe (p. ej., se termina una vez que levantas el dedo) pero puede ser muy complejo, por lo que es difícil que otra persona lo repita, incluso si te ven dibujar. en. Es como que la firma de cada persona es única y difícil de duplicar. En realidad, esto puede complicarlo demasiado si tuviera que evitar que se duplique, por lo que por ahora esto puede ignorarse y podemos suponer que el símbolo no será visto por otra persona y, por lo tanto, no importa si podría repetirse. Por ellos o no.

Supongo que la pregunta real es cómo convertirías el mismo golpe (razonablemente) consistentemente a la misma clave (por ejemplo, valor hash). Obviamente, debería haber algún umbral de perdón en el algoritmo, porque no se puede esperar que el usuario repita el trazo exactamente al 100%.

El uso del símbolo como método de descifrado agrega una dimensión completamente diferente a este problema. Nunca querrá almacenar el valor hash generado en ningún sitio sin cifrar, ya que entonces alguien podría acceder a esa parte del disco duro y obtener la clave de descifrado sin tener que pasar por todo el proceso de dibujo y descifrar el archivo manualmente. También es muy probable que no quieras almacenar nada sobre cómo se dibuja la forma.

Un buen ejemplo de un trazo que un usuario podría usar como su símbolo de descifrado es " & amp; " símbolo. Imagine a un usuario dibujando este símbolo en su iPhone cada vez que necesite descifrar un archivo. El tamaño del símbolo puede no ser el mismo cada vez que se dibuja. Además, la rotación del símbolo puede ser diferente dependiendo de cómo el usuario sostiene su dispositivo. Idealmente, en ambos casos, dado que el símbolo fue dibujado, en relación con los trazos del usuario, el mismo, debería ser capaz de generar el mismo valor de hash y, por lo tanto, descifrar el archivo.

Pensé que algo como la forma o el reconocimiento de caracteres es un algoritmo similar. Donde el usuario dibuja algo (que representa razonablemente una forma) y luego lo fija a la forma correcta que tendría el mismo valor de hash cada vez que se dibuja. Sin embargo, para algo como esto es muy probable que necesites una base de datos de formas que se puedan dibujar, y si eliges algo como todas las letras del alfabeto, solo obtendrás 26 letras. Y suponiendo que el usuario solo deba dibujar un símbolo para descifrar el archivo, tiene una contraseña extremadamente insegura con solo 26 posibilidades.

Otra cosa en la que pensé es que podrías romper el símbolo que se dibuja en pequeños segmentos y luego ejecutar el reconocimiento de símbolos en ellos. Así que imagina que tienes 4 símbolos en una base de datos: línea vertical, línea horizontal y diagonal en ambas direcciones. Ahora, a medida que el usuario dibuja, cada segmento se reconoce como uno de estos, y luego se combinan para formar algún valor de hash. Así que imagine que el usuario eligió como símbolo de descifrado la letra minúscula " r " ;. Así que comenzarían dibujando una línea vertical hacia abajo, seguida de una línea vertical hacia arriba, seguida de una línea diagonal hacia arriba y hacia la derecha. Un problema con este método es cómo sabría cuándo dividir el trazo en segmentos individuales. Probablemente también querrá tener en cuenta la duración aproximada de cada segmento individual (por ejemplo, en incrementos de 40 píxeles). De esa manera, si alguien dibuja un " r " deformado donde la joroba sale cerca de la parte inferior, no se reconoce como el mismo símbolo y, por lo tanto, no descifra el archivo.

Un tercer método podría ser dividir la pantalla en una cuadrícula (no estoy seguro de qué tamaño todavía) y simplemente ver en qué celdas se dibuja el trazo y usar estos datos de alguna manera para generar una cadena.

¿Alguna otra idea de cómo se podría implementar esto? ¿Alguna vez has oído hablar de algo como esto? ¿Hay algún defecto fundamental que impida que un sistema como este funcione?

Gracias

¿Fue útil?

Solución

El problema del cifrado de datos con material clave que puede tener pequeños errores se ha estudiado ampliamente. En particular, hay una serie de propuestas para proteger los datos utilizando datos biométricos (por ejemplo, huellas dactilares o un escaneo de retina) como una clave. Un enfoque típico es utilizar un código de corrección de errores adecuado, tomar su material K original, calcular el síndrome y almacenar solo el síndrome. Una vez que obtenga una segunda lectura de su material clave K ', el síndrome puede usarse para restaurar K desde K' si K y K 'están lo suficientemente cerca (donde' lo suficientemente cerca 'depende del esquema de corrección de errores).

Para comenzar, aquí hay un documento que propone un esquema de bóveda difusa . Esta es una propuesta general para un esquema de encriptación que usa un " fuzzy " llave. Por supuesto, aún debe examinar cómo extraer las características de los dibujos que son lo suficientemente estables para usar un esquema de corrección de errores. También tendrá que examinar cuánta entropía puede extraer de tales dibujos. Aunque las contraseñas son tan malas con respecto a la entropía, pueden ser difíciles de superar.

Otros consejos

Probaría una variante de la variante de segmentación: reconozca patrones simples: me atengo a las líneas rectas y diagonales para esto, pero en teoría también podría agregar círculos, arcos y quizás otras cosas.

Puede estar muy seguro de cuándo termina una línea y comienza otra, ya que hay 8 direcciones y puede detectar un cambio de dirección (o, para un enfoque más simple, simplemente detecte la pluma hacia arriba y hacia abajo y utilícelas como delimitadores de línea). La primera línea da un factor de escala, por lo que la longitud de cada una de las otras líneas se puede representar como un factor (por ejemplo, en una forma de L habitual, la primera línea vertical daría la "longitud de base" y la otra línea luego tener la longitud de aproximadamente 0,5 * b). Una vez que el usuario haya terminado, puede usar el factor más pequeño s para " round " las longitudes, para que tengas una matriz de longitudes enteras como [1 * s, 2 * s, 4 * s, 5 * s]. Esto evitará que el sistema sea demasiado exacto, y el uso de la longitud de la base hace que el sistema sea robusto contra la escala.

Ahora, de alguna manera, convierta estas informaciones (longitudes y direcciones) en una cadena (o un valor de hash, lo que quiera) y será igual para los mismos trazos, incluso si el símbolo está traducido o escalado.

Además, puede almacenar un valor de desplazamiento 2D (por supuesto " redondeado " ;, también) para cada línea después de la segunda línea, de modo que las líneas también tengan que estar en la misma posición, si no lo hace , L y T probablemente obtendrán la misma cadena (1 línea arriba-abajo, 1 línea izquierda-derecha 0,5). Así que almacenar posiciones fortalece todo un poco, pero es opcional.

EDITAR:

Si tomas el ángulo de la primera línea como un ángulo base, incluso puedes hacer que esto sea robusto a la rotación.

Tenga en cuenta que este algoritmo solo proporciona 3 bits por trazo si todas las líneas son de la misma longitud y un máximo de quizás hasta 6-8 bits por trazo, algunas más si también almacena posiciones. Esto significa que necesitaría un símbolo bastante complejo de aproximadamente 20 a 40 golpes para obtener 128 bits de seguridad.

Una forma fácil de agregar más variación / seguridad sería permitir que el usuario use diferentes colores de una paleta dada.

Para reducir el riesgo de que alguien te observe, puedes hacer que desaparezca cada línea después de que haya sido dibujada o cambiar el color a un color con un contraste muy bajo con el fondo.

El reconocimiento de escritura a menudo toma en cuenta la duración del trazo más que la longitud real y demás.

Si bien se relaciona con la sensibilidad a la presión, creo que puedes ver algunos bits conceptuales similares a lo que estás pensando aquí ... jdadesign.net/safelock/

No es exactamente el mismo tema, pero es lo más cercano que viene a la mente en este momento.

No creo que puedas obtener suficiente " bits " de un símbolo dibujado a mano para realizar el cifrado seguro. Como debe observar, debe permitir suficiente inclinación en el reconocimiento de que se tolerarán las variaciones naturales en el dibujo. En otras palabras, tiene que descartar el ruido en los trazos, suavizándolos en una señal reproducible. Pero el ruido (alta entropía) hace mejores claves criptográficas.

Piénsalo de esta manera. Si descompones el gesto en segmentos de arriba, abajo, izquierda y derecha, cada segmento representará 2 bits de información. Para una clave AES, el símbolo necesitaría 64 de estos segmentos. Es un gesto bastante complicado de recordar. Y si se simplifica repitiendo muchos segmentos en una fila (" derecha, derecha, derecha, ... ") crea una clave pésima (predecible, no aleatoria).

He tenido otro pensamiento sobre esto. No soy una persona comp-sci, pero algo como este trabajo.

Digamos que con cualquier símbolo o patrón " " alguien dibuja Lo único viable que queda para analizar son todos los puntos en el patrón generado en los eventos touchBegan, touchMoved y touchEnded.

Entonces ... tomemos todos los puntos generados, ya sean 100 o 1,000,000, realmente no importa.

Divídalos en grupos, tantos grupos como desee. Cuanto más, mejor, supongo, pero para este ejemplo, vamos a ponerlos en 4 grupos. Con 100 puntos, el grupo 1 contendría los puntos 1 > 25, el grupo 2 contiene 26 > 50 y así sucesivamente.

Para cada grupo, use todos los puntos para calcular una posición promedio.

Puede funcionar mejor si los espacios del lienzo se dividen en una cuadrícula y las 'posiciones promedio' se trazan en su coordenada más cercana.

Luego verifica la distancia relativa entre todos los grupos. Así que entre 1,2 1,3 1,4 2,3 2,4 3,4.

Ahora tiene tantos puntos distintos e información sobre esos puntos para generar una clave. Los promedios y la cuadrícula deberían ayudar a suavizar algo, si no toda la entropía.

Es posible que tenga que pedirle al usuario que dibuje su patrón varias veces, y compare cada grupo con los grupos de intentos anteriores. De esa manera, puede identificar qué grupos pueden trazar los usuarios de manera consistente. Tiene el beneficio adicional de capacitar a los usuarios para dibujar su patrón.

Sospecho que cuantos más puntos y grupos tengas, más preciso será esto.

De hecho, voy a intentarlo yo mismo.

Gestos.

http://depts.washington.edu/aimgroup/proj/dollar/

Puedes definir tus propios algoritmos para gestos particulares. Por ejemplo, un círculo,

1.Encuentra el punto de inicio 2. encuentre el más a la izquierda, más a la derecha y más alejado para los puntos y obtenga un radio aproximado. 3. compruebe todos los puntos con respecto al radio con un margen de error (25%?) 4. Si el radio sale, tienes un círculo.

Línea recta vertical: 1. Verifique el punto de inicio y el punto final de las posiciones X e Y. 2. Compara los puntos intermedios con los puntos x e y del inicio y final. 3. Si están aproximadamente en la misma coordenada X, pero en forma de Y ascendente o descendente, tiene una línea vertical.

Y así sucesivamente, se vuelve más complejo para gestos más complicados.

Incluso puedes combinar gestos. Así que digamos que tienes un algoritmo para 6 gestos. Puedes combinarlos para formar diferentes símbolos. El orden en que se crean los gestos podría ser importante, agregando una capa adicional de seguridad.

¿qué sucede si tomó todas las coordenadas x, y del trazo y realizó algún tipo de operación lineal de 2 vías en ellas? Luego, puede calcular un hash "aproximado" y, si el número se calcula cuando el trazo está dentro ... diga el 10% de su aproximación, entonces otorga acceso.

Todo depende de la clase de ataque que intenta evitar. Si desea un cifrado completo, donde asume que el atacante tiene acceso completo al archivo cifrado, necesitará una gran cantidad de bits de entropía para lograr un nivel de protección decente. Suponiendo que obtenga los algoritmos correctos, entonces puede llevar los dos a la potencia de la entropía de entrada en bits (el límite superior para esto es el número de diferentes entradas posibles), multiplicar por la cantidad de tiempo que toma el procedimiento de configuración de la clave, divida entre la cantidad de poder de cómputo que tiene el atacante y obtenga el tiempo que el atacante debe tomar para romper su cifrado por fuerza bruta.

Por ejemplo, algo como el método de desbloqueo de figura de 9 celdas de Android podría proporcionarle alrededor de 16 bits de entropía. Supongamos que utiliza 5 segundos de tiempo de CPU para calcular la clave de cifrado. Luego, con una PC promedio, toma 5 * 2 ** 16/20 segundos, o aproximadamente 4.5 horas para romper. Cualquier pérdida de entropía en la entrada o ineficiencia en la configuración de la clave y el cifrado lo reducirá rápidamente a minutos, por no mencionar si se usan grupos de computadoras.

Para ser franco, eso no será mucho mejor que simplemente almacenar el archivo en un formato de archivo oscuro y esperar que nadie lo descubra

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top