Spiegazione canonica della crittografia e delle vulnerabilità di Android


16

Nota: Bene, la generosità è scaduta e una possibile ragione potrebbe essere lo sforzo necessario per affrontare come raccolgo dai commenti. Visto il numero di voti positivi, sembra interessare anche gli altri. Vorrei ancora ottenere una risposta, quindi ecco quello che propongo: una buona risposta entro un mese riceverà un bonus di 50. Spero di dare tempo e incentivi adeguati


Ho cercato di capire il processo di crittografia Android e le sue vulnerabilità per un po '

Ci sono molte domande che affrontano parti di questo argomento su questo sito e anche sul sito affiliato. Per riportare il mio punto a casa, queste domande riguardano porzioni e non il tutto (che ricorda " ciechi e un elefante ?" :)

La mia comprensione (o incomprensione?)

  1. La password di crittografia viene generata da una combinazione di PIN della schermata di blocco dell'utente e algoritmo di crittografia (in ciò risiede una debolezza intrinseca a causa della lunghezza limitata del PIN)
  2. Questo è salato e memorizzato nella posizione principale, non accessibile agli utenti
  3. Viene utilizzato per generare la password effettiva per crittografare / decrittografare e la password effettiva viene archiviata nella RAM
  4. Ciò è stato rafforzato collegando il Passaggio 1 al SoC del dispositivo ( Quale versione di Android? Qual è l'elemento hardware che identifica in modo univoco il dispositivo? Può essere sostituito con falso? )
  5. Pertanto, non è possibile decrittografare i dati senza chiave di crittografia e dispositivo (vale anche per SD esterna)
  6. Possibili metodi di recupero: forza bruta, acquisizione delle informazioni RAM (passaggio 3) per ottenere la chiave
  7. I dispositivi rooted sembrano essere più suscettibili all'accesso ai dati del passaggio 2 attraverso il ripristino personalizzato / eventualmente la ROM e il flashing del kernel ?? ( se vero, perché questo non è propagandato come un grosso rischio? )
  8. Anche se si ottengono queste informazioni, suppongo che sia saggio non banale generare la password effettiva
  9. Marshmallow può trattare la SD esterna come "memoria interna" o "memoria portatile". Logicamente, non dovrebbe fare la differenza ma non ne sono sicuro

Ci sono delle lacune nella mia comprensione, probabilmente perdendo anche altri aspetti chiave.

Quindi, sto cercando una spiegazione canonica per la comprensione dal punto di vista dell'utente

  • Intero processo di crittografia (inclusa SD esterna)

  • Variazione dell'implementazione tra le versioni di Android: da KitKat a Marshmallow (comprese le doppie opzioni per SD esterna in Marshmallow)

  • Vulnerabilità a livello di utente

Nota

  • Sono consapevole del rischio che la questione sia considerata troppo ampia, ma l'IMO garantisce un trattamento globale
  • Avendo una certa esperienza nella sicurezza della comunicazione, capisco la sfida nel tradurre concetti crittografici a livello di utente. Preferirei la risposta per affrontare questo, con indicazioni esplicative per una comprensione più profonda. Gli esempi del processo non devono necessariamente essere crittograficamente corretti in senso rigoroso, ma dovrebbero trasmettere l'essenza

  • Un possibile vantaggio potrebbe essere "ingannare" domande future su aspetti correlati

  • A costo di ripetizione, le risposte dovrebbero essere principalmente a livello di utente , ma con una spiegazione adeguata per una comprensione più profonda. Dividere la risposta in due parti può essere un modo adatto.

  • Vorrei sottolineare il voto negativo delle risposte banali / casuali / patch per incoraggiare risposte complete


1
I commenti non sono per una discussione estesa; questa conversazione è stata spostata in chat . //Questo potrebbe adattarsi meglio alla sicurezza . Penso anche che sia troppo ampio perché una buona parte di ciò che stai chiedendo dipende dal particolare hardware e da come il produttore lo implementa.
Matteo Leggi l'

Risposte:


3

Immagino che funzioni così:

  • L'archiviazione è crittografata mediante chiave casuale sincrona.
  • Quando l'utente sceglie o modifica una password basata su qualsiasi input, che si tratti di una password composta da lettere, numeri e caratteri, sia che si tratti di un codice PIN, di scorrimento del motivo, dell'impronta digitale o di qualsiasi altro input, una crittografia asincrona l'algoritmo viene utilizzato per crittografare la chiave master, in modo tale che l'identificazione corretta finisca per decrittografare l'input risultante nella chiave master, che a sua volta consente di crittografare e decrittografare l'archiviazione.
  • Nel momento in cui l'utente si disconnette, la memoria contenente la chiave principale viene sovrascritta

Il grande trucco qui è la crittografia asincrona della chiave master. Una volta che Android ha la chiave principale, ha la capacità di scambiare dati con l'archiviazione. Solo quando l'utente ha effettuato l'accesso, tale chiave master è nota. La crittografia asincrona è quella che viene chiamata crittografia a chiave pubblica. Quello che succede è che una chiave pubblica crittografa i dati (la chiave principale in questo caso) e una chiave privata decodifica i dati. Da non confondere con la crittografia di archiviazione qui. L'archiviazione è solo la crittografia sincrona. Lì viene utilizzata la stessa chiave per crittografare e decrittografare. Ma la ricerca / il recupero di quella chiave "master", è il grande. Significa che se ad un certo punto hai un metodo di accesso debole, come per intance "1234" come codice PIN, e cambi idea, e cambi il codice PIN in "5364", che è più difficile da indovinare, a meno che prima "1234 " è stato rubato, ficcato il naso, in ogni momento, la sicurezza è appena migliorata. Stesso affare quando si cambia il metodo di accesso in una password completa che è impossibile indovinare o attaccare dal dizionario. La memoria stessa non ha bisogno di essere nuovamente crittografata. Si tratta di nascondere quella chiave principale, internamente. L'utente non vede mai quella chiave principale, perché molto probabilmente è solo un codice hash casuale - nulla potrà mai "trovare" o "indovinare" quel codice hash. Nemmeno l'NSA o qualsiasi altro ente di sicurezza del pianeta potrebbe mai trovare una chiave simile. L'unico vettore di attacco è la speranza di una debolezza da parte dell'utente. Forse l'utente ha scelto un login con codice PIN. Se è composto da 4 cifre, è un massimo di 10000 possibili codici PIN. Il sistema operativo potrebbe "bloccare" il dispositivo dopo averne provato alcuni in breve tempo. La soluzione è quindi "hackerare" il sistema operativo, in modo che sia possibile provare tutti i possibili codici PIN senza che il sistema operativo intervenga e blocchi il dispositivo. Credo che sia così che l'FBI abbia finalmente avuto accesso a un telefono di un criminale. Una società di terze parti (qualche compagnia israeliana da ciò che ricordo) ha fatto l'hacking per l'FBI, credo. Hanno aggirato il limite del codice PIN. Se il login è una password completa e se l'utente ha scelto una password complessa, sei pronto. Non in una vita con tutto il potere della cpu sul pianeta lo hackererà in un milione di anni. Non sto acquistando nessuna delle NSA in grado di decifrare qualsiasi voce. Penso che quelle persone abbiano visto troppi film di uomini in nero. Tutto quello che bisogna fare è guardare i documenti scientifici sui vari algoritmi di crittografia (ad es. AES) e saprai che l'hacking semplicemente non accadrà, tranne nei vecchi tempi in cui c'erano chiavi a 40 bit. Quei giorni sono passati da tempo. Penso che AES128 sia già irremovibile, e se qualcuno è preoccupato, saltare ad AES256 lo rende più sicuro di una grandezza alle dimensioni dell'universo praticamente. Forse un giorno i computer quantistici potrebbero decifrarlo, ma sono scettico. Non sono sicuro se è possibile avere un sistema di probabilità semplicemente evidenziare la soluzione. Vedremo a riguardo, alla fine. Forse è comunque a qualche vita di distanza. Niente di cui preoccuparsi adesso.

Quindi, alla fine della giornata, il limite di sicurezza si basa interamente sul metodo di accesso utilizzato. È possibile modificare il metodo senza dover crittografare nuovamente la memoria. Tutto questo a causa della crittografia asincrona della chiave pubblica della chiave master.


Penso che intendi "simmetrico" e "asimmetrico". Non "sincrono" e "asincrono".
Jay Sullivan,

1

Poiché gli aggiornamenti sono frequenti, il modo in cui viene gestita la crittografia sul telefono (sistema operativo basato su Android) può cambiare da una build all'altra. Pertanto, la preoccupazione principale non riguarda la crittografia stessa, ma dove è in esecuzione il processo. E se quella piattaforma ha delle vulnerabilità, allora la forza dell'algoritmo di crittografia stessa diventa di poca o nessuna importanza.

Fondamentalmente, una volta che il dispositivo decodifica i file, è possibile accedervi direttamente tramite un processo con privilegi di Super utente. Questo processo potrebbe accedere al tuo dispositivo sfruttando un punto debole della ROM (sistema operativo Android) stesso. (Questo è stato recentemente nelle notizie poiché alcuni difetti sono stati rilevati da WikiLeaks)

I dispositivi rooted sembrano essere più suscettibili all'accesso ai dati del passaggio 2 attraverso il ripristino personalizzato / eventualmente la ROM e il flashing del kernel ?? (se vero, perché questo non è propagandato come un grosso rischio?)

Prima del root : per eseguire il root di un dispositivo devi usare strumenti esterni che hanno un accesso profondo alla struttura interna del dispositivo. Alcuni di questi strumenti sono precompilati e non sono open source. Hanno siti Web "ufficiali", ma chi sono queste persone? (twrp.me, supersu.com per esempio, ma ce ne sono altri come KingoRoot) Possiamo davvero fidarci di loro? Mi fido di alcuni più degli altri. Ad esempio KingoRoot ha installato un programma sul mio PC che si comportava in modo simile a un virus (per rimuoverlo è stato necessario utilizzare il doppio avvio).

Dopo aver effettuato il root : dare a un programma compilato (APK) un accesso SU significa che può fare tutto ciò che vuole senza restrizioni o dichiarare quale Intento utilizzerà. (L'intento è un modo per gli APK di accedere a cose come WiFi, fotocamera, ecc.) Quindi un'app "ben attendibile", dopo aver ottenuto l'accesso come root, può facilmente accedere a qualsiasi tipo di informazione e rispedirla al suo server.

La crittografia completa del dispositivo protegge i miei dati da Google e dal governo?

Google - si. Non ha la chiave per sbloccare.

Governo (o hacker) - no. perché Government o hacker possono essenzialmente utilizzare un exploit che intercetterà i file come ho detto sopra.

Le complessità delle procedure / algoritmi di sicurezza sono di scarsa utilità se possono essere intercettate e escluse.

Modifica: vale la pena ricordare che Google ha effettivamente la possibilità di scaricare e installare / aggiornare app sul tuo dispositivo Android senza chiedere la tua autorizzazione o addirittura avvisarti che l'aggiornamento è stato effettuato. E anche su dispositivi rooted, non sembra esserci un modo per bloccarlo senza perdere le funzioni chiave (Play Store, Maps, Sync, ecc.)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.