Domanda

Diciamo che ho un file crittografato su un iPhone e ogni volta che voglio decrittografarlo, voglio " disegnare " un simbolo di decrittazione invece di dover usare una tastiera per digitarlo.

Se chiedi all'utente di disegnare un simbolo per decrittografare un file ogni volta che è necessario (ad esempio ogni volta che lanciano la tua applicazione) probabilmente preferirebbero che si debba digitare una password di circa 20 caratteri sulla tastiera minuscola e otterrebbero comunque la sicurezza che potrebbe fornire loro una password di 20 caratteri (a seconda della complessità della forma / simbolo che disegnano).

Il simbolo che disegnerebbero molto probabilmente sarebbe un colpo (ad es. quando si solleva il dito è finito) ma può essere molto complesso, in modo che sia difficile per qualcun altro ripeterlo, anche se ti vedono disegnarlo un po 'come la firma di ogni persona è unica e difficile da duplicare. In realtà, questo potrebbe complicare eccessivamente se dovesse impedire di essere duplicato, quindi per ora questo può essere ignorato e possiamo supporre che il simbolo non sarà visto da qualcun altro e quindi non importa se possa essere ripetuto da loro o no.

Immagino che la vera domanda sia come convertire lo stesso tratto (ragionevolmente) in modo coerente nella stessa chiave (ad es. valore hash). Ovviamente ci dovrebbe essere una certa soglia di perdono nell'algoritmo, perché non ci si può aspettare che l'utente ripeta il colpo esattamente al 100%.

L'uso del simbolo come metodo di decodifica aggiunge un'altra dimensione a questo problema. Non vuoi mai archiviare il valore di hash generato da nessuna parte in forma non crittografata, perché qualcuno potrebbe essere in grado di accedere a quella parte del disco rigido e ottenere la chiave di decrittazione senza dover passare attraverso l'intero processo di disegno e decrittografare il file manualmente. Molto probabilmente anche tu non vuoi memorizzare nulla su come viene disegnata la forma.

Un buon esempio di un tratto che un utente potrebbe usare come simbolo di decrittazione è il " & amp; " simbolo. Immagina un utente che disegna questo simbolo sul proprio iPhone ogni volta che deve decrittografare un file. La dimensione del simbolo potrebbe non essere la stessa ogni volta che viene disegnata. Inoltre, la rotazione del simbolo può variare a seconda di come l'utente detiene il proprio dispositivo. Idealmente, in entrambi i casi, poiché il simbolo è stato disegnato, relativamente ai tratti dell'utente, lo stesso, dovrebbe essere in grado di generare lo stesso valore di hash e quindi decrittografare il file.

Ho pensato che qualcosa come la forma o il riconoscimento dei caratteri fosse un algoritmo simile. Laddove l'utente disegna qualcosa (che rappresenta ragionevolmente una forma) e quindi lo fissa sulla forma corretta che avrebbe lo stesso valore di hash ogni volta che viene disegnata. Tuttavia, per qualcosa del genere avresti probabilmente bisogno di un database di forme che possono essere disegnate e se scegli qualcosa come tutte le lettere dell'alfabeto, otterrai solo 26 lettere. E supponendo che l'utente debba solo disegnare un simbolo per decrittografare il file, hai una password estremamente insicura con solo 26 possibilità.

Un'altra cosa a cui ho pensato è che potresti spezzare il simbolo che viene disegnato in piccoli segmenti e quindi eseguire il riconoscimento del simbolo su quelli. Quindi immagina di avere 4 simboli in un database: linea verticale, linea orizzontale e diagonale in entrambe le direzioni. Ora mentre l'utente disegna, ogni segmento viene riconosciuto come uno di questi e quindi vengono tutti combinati per formare un valore di hash. Quindi immagina che l'utente abbia scelto come simbolo di decrittazione la lettera minuscola "." Quindi avrebbero iniziato tracciando una linea verticale verso il basso, seguita da una linea verticale verso l'alto, seguita da una linea diagonale verso l'alto e verso destra. Un problema con questo metodo è come sapresti quando dividere il tratto in singoli segmenti? Probabilmente vorrai anche tenere conto della lunghezza approssimativa di ogni singolo segmento (ad es. Con incrementi di 40 pixel). In questo modo se qualcuno disegnava una "r" deformata dove la gobba esce vicino al fondo non è riconosciuta come lo stesso simbolo e quindi non decifrerebbe il file.

Un terzo metodo potrebbe essere quello di dividere lo schermo in una griglia (non sono ancora sicuro di quale dimensione) e semplicemente vedere in quali celle viene disegnato il tratto e usare questi dati in qualche modo per generare una stringa.

Altre idee su come implementarlo? Hai mai sentito parlare di qualcosa del genere? Ci sono difetti fondamentali che impedirebbero a un sistema come questo di funzionare?

Grazie

È stato utile?

Soluzione

Il problema della crittografia dei dati con materiale chiave che può contenere piccoli errori è stato studiato in modo abbastanza approfondito. In particolare ci sono una serie di proposte per proteggere i dati utilizzando dati biometrici (ad esempio impronte digitali o scansione della retina) come chiave. Un approccio tipico consiste nell'utilizzare un codice di correzione dell'errore appropriato, prendere il materiale chiave K originale, calcolarne la sindrome e memorizzare solo la sindrome. Una volta ottenuta una seconda lettura del materiale chiave K ', la sindrome può essere utilizzata per ripristinare K da K' se K e K 'sono abbastanza vicini (dove "abbastanza vicino" ovviamente dipende dallo schema di correzione degli errori.)

Per iniziare, ecco un documento che propone un schema fuzzy vault . Questa è una proposta generale per uno schema di crittografia che utilizza un "fuzzy" chiave. Naturalmente, è ancora necessario esaminare come estrarre caratteristiche dai disegni sufficientemente stabili per l'utilizzo di un tale schema di correzione degli errori. Dovrai anche esaminare quanta entropia puoi estrarre da tali disegni. Per quanto cattive siano le password rispetto all'entropia, potrebbero essere ancora difficili da battere.

Altri suggerimenti

Vorrei provare una variante della variante di segmentazione: riconoscere i modelli semplici - per questo mi atterrò a linee rette e diagonali, ma in teoria potresti anche aggiungere cerchi, archi e forse altre cose.

Puoi essere abbastanza sicuro quando una linea termina e un'altra inizia quando ci sono 8 direzioni e puoi rilevare un cambio di direzione (o per un approccio più semplice, basta rilevare la penna su e la penna giù e usarle come delimitatori di linea). La prima linea fornisce un fattore di scala, quindi la lunghezza di ogni altra linea può essere rappresentata come un fattore (per esempio, in una solita forma a L, la prima linea verticale darebbe la "lunghezza di base" b e l'altra linea sarebbe quindi avere la lunghezza di circa 0,5 * b). Dopo che l'utente ha terminato, puoi utilizzare il più piccolo fattore s per "arrotondare" le lunghezze, in modo da avere una matrice di lunghezze intere come [1 * s, 2 * s, 4 * s, 5 * s]. Ciò impedirà al sistema di essere troppo esatto e l'utilizzo della lunghezza della base rende il sistema robusto contro il ridimensionamento.

Ora in qualche modo converti queste informazioni (lunghezze e direzioni) in una stringa (o in un valore di hash, qualunque cosa tu voglia) e saranno le stesse per gli stessi tratti, anche se il simbolo viene tradotto o ridimensionato.

Inoltre, puoi memorizzare un valore di offset 2D (ovviamente anche "arrotondato") per ogni riga successiva alla seconda riga in modo che anche le linee debbano trovarsi nella stessa posizione, se non lo fai , L e T avranno molto probabilmente la stessa stringa (1 linea su-giù, 1 linea sinistra-destra 0,5). Quindi memorizzare posizioni rafforza un po 'il tutto ma è facoltativo.

EDIT:

Se prendi l'angolo della prima linea come angolo base, puoi persino renderlo robusto alla rotazione.

Si noti che questo algoritmo fornisce solo 3 bit per corsa se tutte le linee hanno la stessa lunghezza e un massimo di forse fino a 6-8 bit per corsa, un po 'di più se si memorizzano anche posizioni. Ciò significa che avresti bisogno di un simbolo piuttosto complesso di circa 20-40 colpi per ottenere 128 bit di sicurezza.

Un modo semplice per aggiungere più variazioni / sicurezza sarebbe consentire all'utente di usare colori diversi da una determinata tavolozza.

Per ridurre il rischio che qualcuno ti guardi, potresti far scomparire ogni linea dopo che è stata disegnata o cambiare il colore in un colore con un contrasto molto basso rispetto allo sfondo.

Il riconoscimento della grafia spesso tiene conto della durata del tratto più della lunghezza effettiva e così via.

Mentre si riferisce alla sensibilità alla pressione, penso che potresti essere in grado di vedere alcuni pezzi concettuali simili a quello che stai pensando qui .... jdadesign.net/safelock/

Questo non è esattamente lo stesso argomento, ma è la cosa più vicina che mi viene in mente in questo momento.

Non credo che potresti ottenere abbastanza " bit " da un simbolo disegnato a mano per eseguire la crittografia sicura. Come si nota, è necessario consentire una pendenza sufficiente nel riconoscimento che le variazioni naturali nel disegno saranno tollerate. In altre parole, devi scartare il rumore nei tratti, uniformandoli in un segnale riproducibile. Ma il rumore (elevata entropia) rende migliori le chiavi crittografiche.

Pensaci in questo modo. Se si decomponesse il gesto in segmenti di su, giù, sinistra e destra, ogni segmento rappresenterebbe 2 bit di informazioni. Per una chiave AES, il simbolo avrebbe bisogno di 64 di questi segmenti. È un gesto piuttosto complicato da ricordare. E se è semplificato ripetendo molti segmenti di fila ("destra, destra, destra, ...") rende una chiave scadente (prevedibile, non casuale).

Ci ho pensato un altro. Non sono una persona comp-sci, ma farebbe qualcosa del genere.

Diciamo che con qualunque simbolo o " modello " qualcuno disegna. L'unica cosa fattibile che ti resta da analizzare sono tutti i punti del pattern generati negli eventi touchBegan, touchMoved e touchEnded.

Quindi ... prendiamo tutti i punti generati, che siano 100 o 1.000.000, non importa davvero.

Dividili in gruppi, quanti più gruppi vuoi. Più assumo meglio, ma per questo esempio, mettiamoli in 4 gruppi. Con 100 punti, il gruppo 1 conterrebbe punti 1 > 25, il gruppo 2 contiene 26 > 50 e così via.

Per ciascun gruppo, utilizzare tutti i punti per calcolare una posizione media.

Potrebbe funzionare meglio se gli spazi della tela sono divisi in una griglia e le "posizioni medie" vengono tracciate sulla loro coordinata più vicina.

Quindi controlla la distanza relativa tra tutti i gruppi. Quindi tra 1,2 1,3 1,4 2,3 2,4 3,4.

Ora hai tanti punti distinti e informazioni su quei punti per generare una chiave. Le medie e la griglia dovrebbero aiutare a livellare un po ', se non tutta l'entropia.

Potrebbe essere necessario chiedere all'utente di disegnare il proprio schema alcune volte e confrontare ciascun gruppo con i gruppi dei tentativi precedenti. In questo modo, puoi identificare quali gruppi possono essere tracciati dagli utenti in modo coerente. Ha l'ulteriore vantaggio di addestrare la mano degli utenti a disegnare il loro modello.

Sospetto che più punti e gruppi avrai, più accurato sarà.

In effetti, ci proverò da solo.

I gesti.

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

Puoi definire i tuoi algoritmi per gesti particolari. Ad esempio un cerchio,

1.Trova il punto iniziale 2. trova i punti più a sinistra, più a destra e più lontani per ottenere punti e ottieni un raggio approssimativo. 3. controlla tutti i punti rispetto al raggio con un margine di errore (25%?) 4. Se il raggio si verifica, hai un cerchio.

Linea retta verticale: 1. Controllare le posizioni X e Y dei punti iniziale e finale. 2. Confrontare i punti intermedi con la xey dell'inizio e della fine. 3. Se sono approssimativamente sullo stesso cordone X, ma ascendenti o discendenti sui cordoni Y, hai una linea verticale.

E così via, diventando più complesso per gesti più complicati.

Puoi anche combinare i gesti. Supponiamo che tu abbia un algoritmo per 6 gesti. Puoi combinarli per formare simboli diversi. L'ordine in cui vengono creati i gesti potrebbe essere importante, aggiungendo un ulteriore livello di sicurezza.

e se prendessi tutte le coordinate x, y del tratto e preformi una sorta di operazione lineare a 2 vie su di esse? Potresti quindi calcolare un hash "approssimativo" e se il numero calcolato quando il tratto si trova entro ... diciamo il 10% della tua approssimazione, quindi concedi l'accesso ..

Tutto dipende da quale tipo di attacco stai cercando di prevenire. Se vuoi la crittografia completa, dove supponi che l'attaccante abbia pieno accesso al file crittografato, avrai bisogno di un bel po 'di entropia per ottenere un livello decente di protezione. Supponendo di ottenere gli algoritmi giusti, quindi è possibile portare i due alla potenza dell'entropia di input in bit (il limite superiore per questo è il numero di diversi input possibili), moltiplicare per il tempo impiegato dalla procedura di impostazione della chiave, dividi per quanta più potenza di calcolo ha l'attaccante e ottieni il tempo che l'attaccante deve impiegare per rompere la tua crittografia con la forza bruta.

Ad esempio, qualcosa come il metodo di sblocco della figura a 9 celle di Android potrebbe farti guadagnare circa 16 bit di entropia. Supponiamo che tu usi 5 secondi di tempo CPU per calcolare la chiave di crittografia. Quindi, con un PC medio, ci vogliono 5 * 2 ** 16/20 secondi, o circa 4,5 ore per craccare. Qualsiasi perdita di entropia nell'input o inefficienza nella configurazione delle chiavi e nella crittografia richiederà rapidamente questo in pochi minuti, per non parlare dell'utilizzo di cluster di computer.

Ad essere sinceri, non sarebbe molto meglio che archiviare il file in un formato di file oscuro e sperare che nessuno lo capisca

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top