Algoritmo para descifrar datos con trazos dibujados

Question

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 lo necesite (p. Ej., Cada vez que inicie su aplicación), probablemente prefiera tener que escribir una contraseña de 20 caracteres en el minúsculo teclado, y aún así obtendrían la seguridad que les daría una contraseña de 20 caracteres (dependiendo de qué tan complicada sea la forma/símbolo que dibujen).

El símbolo que dibujarían probablemente sería un trazo (por ejemplo, una vez que levanta el dedo) pero puede ser muy complejo, por lo que es difícil para otra persona repetirlo, incluso si lo ven dibujar pulg. Algo así como cómo la firma de cada persona es única y difícil de duplicar. En realidad, esto puede complicarlo demasiado si tiene 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 verdadera pregunta es cómo convertir el mismo (razonablemente) golpe de forma consistente a la misma tecla (por ejemplo, valor hash). Obviamente debería haber algún umbral de tolerancia 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 desencriptado agrega una dimensión completamente diferente a este problema. Nunca desea almacenar el valor hash generado en ningún lugar en forma descifrada, porque entonces alguien podría tener acceso a esa parte del disco duro y obtener la clave de descifrado sin necesidad de pasar por todo el proceso de dibujo y descifrar el archivo manualmente. También es probable que no desee 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 el símbolo "&". Imagine que un usuario dibuja este símbolo en su iPhone cada vez que necesita 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 mantenga su dispositivo. Idealmente, en ambos casos, debido a que el símbolo se dibujó, en relación con los trazos del usuario, lo mismo, debería ser capaz de generar el mismo valor hash y así descifrar el archivo.

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

Otra cosa que pensé es que podría romper el símbolo que se dibuja en pequeños segmentos y luego ejecutar el reconocimiento de símbolos en los mismos. Imagine que tiene 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 un valor hash. Entonces imagine que el usuario eligió como su símbolo de descifrado la letra minúscula "r". Entonces comenzarían dibujando una línea vertical hacia abajo, seguida de una línea vertical arriba, seguida por 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 desee tener en cuenta cuánto tiempo dura cada segmento individual (por ejemplo, en incrementos de 40 píxeles). De esta forma, si alguien dibuja una "r" deformada donde la joroba sale cerca del fondo, no se reconoce como el mismo símbolo y, por lo tanto, no se descifra el archivo.

Un tercer método podría ser dividir la pantalla en una cuadrícula (aún no estoy seguro de su tamaño) 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 esto podría implementarse? ¿Alguna vez has oído hablar de algo como esto? ¿Existen fallas fundamentales que impidan que un sistema como este funcione?

Gracias

Answer 1

El problema de la encriptación de datos con keymaterial que pueden tener pequeños errores ha sido estudiado bastante extensamente. En particular, hay una serie de propuestas para proteger datos usando datos biométricos (por ejemplo, huellas dactilares o una exploración de retina) como una clave. Un enfoque típico es usar un código de corrección de errores apropiado, tomar su material clave K original, calcular el síndrome y almacenar solo el síndrome. Una vez que obtiene una segunda lectura de su material clave K ', el síndrome se puede usar para restaurar K de K' si K y K 'están lo suficientemente cerca (donde' bastante cerca 'por supuesto depende del esquema de corrección de errores.)

Para comenzar, aquí hay un documento que propone un fuzzy vault scheme. Esta es una propuesta general para un esquema de cifrado que utiliza una clave "difusa". Por supuesto, aún necesita examinar cómo extraer características de dibujos que sean lo suficientemente estables para utilizando un esquema de corrección de errores. También tendrá que examinar la cantidad de entropía que puede extraer de tales dibujos. Por malas que sean las contraseñas con respecto a la entropía, pueden ser difíciles de superar.

Answer 2

Gestos.

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

Se puede definir es el propietario algoritmos para gestos particulares. Por ejemplo, un círculo,

1.Encuentre el punto de inicio 2. busque la mayoría de los puntos a la izquierda, más a la derecha y más lejos y obtenga un radio aproximado. 3. compruebe todos los puntos contra el radio con un margen de error (25%?) 4. Si el radio marca, tiene un círculo.

Vertical Línea recta: 1. Compruebe el punto de inicio y el punto final en las posiciones X e Y. 2. Compare los puntos intermedios con las xey del inicio y el final. 3. Si están más o menos en las mismas coordenadas X, pero en coordenada Y ascendente o descendente, tiene una línea vertical.

Y así sucesivamente, cada vez más complejo para los gestos más complicados.

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

Answer 3

Probaría una variación de la variante de segmentación: Reconozco patrones simples. Me limitaré a líneas rectas y diagonales para esto, pero en teoría también podría agregar círculos, arcos y tal vez otras cosas.

Puede estar absolutamente seguro cuando una línea termina y otra comienza, ya que hay 8 direcciones y puede detectar un cambio de dirección (o para un enfoque más simple, simplemente detecte la pluma y la pluma hacia abajo y úselas como delimitadores de línea) . La primera línea da un factor de escala, por lo que la longitud de cada otra línea se puede representar como un factor (por ejemplo, en una forma L habitual, la primera línea vertical daría la "longitud base" b y la otra línea tendría entonces la longitud de aproximadamente 0.5 * b). Una vez que el usuario finaliza, puede usar el factor más pequeño para "redondear" las longitudes, de modo que tenga 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 frente a las incrustaciones.

Ahora convierta de alguna forma estas informaciones (longitudes y direcciones) en una cadena (o un valor hash, como prefiera) y será igual para las mismas líneas, 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 para 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 cuerda (1 línea arriba-abajo, 1 línea izquierda-derecha longitud 0.5). Así que el almacenamiento de posiciones fortalece un poco todo, pero es opcional.

EDIT:

Si se toma el ángulo de la primera línea como un ángulo de la base, incluso se puede hacer de este robusto para la rotación.

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

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

Para reducir el riesgo de que alguien lo vea, puede hacer que cada línea desaparezca después de haberla dibujado o cambiar el color a un color con un contraste muy bajo al fondo.

Answer 4

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

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

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

Answer 5

¿Qué pasa si tomas todas las coordenadas x, y del trazo y realizaste algún tipo de operación lineal de 2 vías sobre ellas? Luego puede calcular un hash 'aproximado', y si el número calculado cuando el trazo está dentro ... digamos el 10% de su aproximación, entonces otorga acceso ...

Answer 6

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

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

Answer 7

Todo depende del tipo de ataque que está tratando de evitar. Si quieres un cifrado completo, donde supones que el atacante tiene acceso completo al archivo cifrado, necesitarás muchos bits de entropía para lograr un nivel de protección decente. Suponiendo que obtiene los algoritmos correctos, puede tomar los dos a la potencia de la entropía de entrada en bits (el límite superior para esto es el número de entradas posibles diferentes), multiplicar por la cantidad de tiempo que tarda el procedimiento de configuración de la clave, divida por cuánto más poder de cómputo tiene el atacante y obtenga el tiempo que el atacante debe tomar para romper su encriptación por fuerza bruta.

Por ejemplo, algo así como el método de desbloqueo de 9 celdas de Android puede obtener 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 crackear. Cualquier pérdida de entropía en la entrada o ineficiencia en la configuración de la clave y encriptación lo reducirá rápidamente a minutos, sin mencionar si se usan grupos de computadoras.

Para ser franco, que no va a ser mucho mejor que simplemente almacenar el archivo en un formato de archivo oscura y esperando que nadie se lo imagina

Answer 8

He tenido otra pensar en esto. No soy una persona de ciencia ficción, pero me gustaría algo como este trabajo.

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

Entonces ... tomemos todos los puntos generados, ya sea 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, pongámoslos 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 de lienzo se dividen en una cuadrícula, y las "posiciones promedio" se trazan en su coordenada más cercana.

Luego verifique la distancia relativa entre todos los grupos. Entonces el 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 grilla deberían ayudar a suavizar algo, si no toda la entropía.

Puede que tenga que pedirle al usuario que dibuje su patrón varias veces, y compare cada grupo con grupos de intentos anteriores. De esta forma, puede identificar qué grupos pueden trazar los usuarios de forma coherente. Tiene el beneficio adicional de entrenar la mano de los usuarios para dibujar su patrón.

Sospecho que cuantos más puntos y grupos tenga, más preciso será este.

De hecho, voy a intentarlo yo mismo.