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

Apple ha recentemente fatto scalpore all'interno della comunità tecnologica rifiutando di conformarsi alle forze dell'ordine per quanto riguarda l'accesso ai dati utente crittografati. La loro dichiarazione era che non avevano la capacità tecnica di decrittografare questi dati.

Come utente Android, esiste una possibilità simile (preferibilmente integrata nel sistema operativo anziché di terze parti) che posso utilizzare per ottenere una protezione simile anche da Google e dal mio produttore di dispositivi? So che esiste la "Crittografia completa del dispositivo" nelle mie impostazioni, ma questo impedisce a Google ecc. Di accedervi?

Per riferimento, il mio dispositivo esegue Android Lollipop ed è OnePlus Two. Se altre versioni come Marshmallow mi permettessero di farlo, va bene.

security encryption

— malexdev
fonte

Google non ha idea di quale sia la chiave di crittografia per il tuo dispositivo. L'intero processo si svolge sul dispositivo e la chiave non viene mai trasmessa da nessuna parte. La chiave stessa non è inoltre memorizzata in testo normale sul dispositivo :

Memorizzazione della chiave crittografata

La chiave crittografata viene archiviata nei metadati crittografici. Il supporto hardware viene implementato utilizzando la funzionalità di firma TEE (Trusted Execution Environment). In precedenza, abbiamo crittografato la chiave master con una chiave generata applicando scrypt alla password dell'utente e al salt memorizzato. Al fine di rendere la chiave resistente agli attacchi off-box, estendiamo questo algoritmo firmando la chiave risultante con una chiave TEE memorizzata. La firma risultante viene quindi trasformata in una chiave di lunghezza appropriata da un'altra applicazione di scrypt. Questa chiave viene quindi utilizzata per crittografare e decrittografare la chiave principale.

Quindi, anche se qualcuno avesse una copia della chiave master crittografata, non potrebbe decrittografarla senza la chiave TEE dal SoC del dispositivo.

Pertanto, al di fuori di un difetto nell'implementazione, la crittografia completa del dispositivo impedirà a chiunque di accedere ai tuoi dati a meno che non sappiano / ottengano la tua password O possano indovinare la tua password (ad es. Tramite forzatura forzata o qualche tipo di tecniche di social engineering). Sui dispositivi privi del supporto hardware necessario, FDE tenterà di crittografare la chiave utilizzando un metodo solo software.

— eldarerathis
fonte

@beeshyams È una funzionalità del processore. L'implementazione di ARM si chiama "TrustZone", ma anche altre architetture forniscono meccanismi simili. L'idea è che puoi generare una chiave del dispositivo, conservarla in un posto accessibile solo al TEE, quindi non rivelarla mai al mondo esterno. Quando devi crittografare / decrittografare qualcosa, chiedi al codice in esecuzione in TEE di farlo per te, quindi la chiave rimane sicura. Wikipedia ha un articolo (-ish) decente .

— eldarerathis,

@eldarerathis Quello che ho sentito è che iPhone 6 e versioni successive sono al sicuro anche dagli aggiornamenti OEM, poiché la verifica della password ( incluso il ritardo / blocco temporizzato) è implementata interamente nell'hardware. Quello che sto chiedendo è se Android fa qualcosa di simile o se si tratta semplicemente di un blocco del software, che ovviamente può essere ignorato da un aggiornamento del firmware. Sto anche chiedendo se esistono telefoni basati su Android con bootloader che rifiutano gli aggiornamenti senza l'inserimento del passcode specificato dall'utente, il che renderebbe più facile bypassare i periodi di blocco del software.

— Bob,

Ancora un altro modo di riformulare è se esiste un modo per richiedere che la decrittografia (con password utente) avvenga prima che gli aggiornamenti siano consentiti. In altre parole, gli aggiornamenti (OEM, firmati) sono installabili senza la chiave di decrittazione (senza una cancellazione obbligatoria dei dati utente)?

— Bob,

@Bob Per quanto ne so, Android non richiede la password di decrittazione per eseguire il processo di aggiornamento, perché crittografa solo la /userdatapartizione, non le partizioni che l'aggiornamento verrebbe effettivamente modificato ( /systeme /boot, in generale). È praticamente nella stessa barca dell'iPhone 5 (e inferiore).

— eldarerathis,

Aggiungerei, non sono sicuro che il ritardo generale per tentativo sia qualcosa che può essere "disabilitato" da un aggiornamento, o se Android lo ridimensiona artificialmente. Android utilizza scrypt round durante il processo di generazione delle chiavi, quindi dovrebbe essere utilizzato anche durante la decrittazione della chiave, e scrypt è progettato specificamente per essere difficile da accelerare, come mitigazione contro la forza bruta. Questo sarebbe rimasto coerente. Un blocco dopo il numero X di tentativi falliti (o un blocco in scala, se presente) verrebbe implementato nel software, tuttavia, AFAIK.

— eldarerathis,

-1

La crittografia completa del dispositivo proteggerà il tuo dispositivo se utilizzi una chiave troppo a lungo per la forza bruta, anche quando gli aggressori sono in grado di utilizzare le tecniche della forza bruta, supponendo che ci siano modi per consentire loro di farlo. Snowden afferma che 64 caratteri sono abbastanza lunghi per una crittografia davvero indistruttibile. Quindi è possibile ottenere la sicurezza completa - se non ti dispiace digitare una frase di 64 caratteri ogni volta che riattivi il telefono.

— Andrew Brown
fonte

Sei a conoscenza della limitazione della lunghezza del PIN per il blocco dello schermo? Considera di riavviare la risposta di conseguenza

— beeshyams,

Sì, 16 caratteri sono la limitazione se si controlla il codice sorgente .

— Firelord