edofullo rieges
La questione è un po' articolata, potrei andare off topic.
Il PIN viene sempre richiesto al primo avvio. Il meccanismo di crittografia sotto è però pesantemente cambiato.
Fino ad Android 7.0, l'unico tipo di crittografia previsto era full disk (FDE). Questo significa che tutta la partizione dati dell'utente era crittografata, usando (se non sbaglio) LUKS. Una master key veniva generata al primo avvio e veniva protetta usando "default_password" (non sto scherzando) come chiave. Questo perché altrimenti sarebbe stato impossibile per il telefono di ricevere chiamate o far attivare sveglie prima di inserire il passcode.
Quindi, il flow era: il telefono si accende, automaticamente si arriva alla schermata di blocco usando "default_password" in modo da poter ricevere chiamate, l'utente inserisce il passcode per sbloccarlo.
Il passcode diventava la seconda chiave che permetteva lo sblocco. Come potete ben immaginare, questo meccanismo è parecchio insicuro (con Odin si poteva bypassare il bootloader usando la chiave "default_password"). Per ovviare a questo si poteva abilitare Secure Startup, che eliminava la chiave "default_password" e permetteva di avviare il dispositivo usando solo il passcode. Si tornava però al problema iniziale (nessuna sveglia e nessuna chiamata, solo uno schermo nero dove inserire il passcode prima di avviare la decriptazione dei dati).
Da Android 7.0, è possibile effettuare la FBE, ossia la File-Based Encryption. La crittografia viene quindi eseguita a livello di singoli file, usando chiavi diverse per singoli file, singole applicazioni e metadati vari. In questa maniera, è possibile ricevere chiamate prima di inserire il pin, ma i dati sono protetti usando lo stesso codice. Gli attacchi di prima non sono più possibili. Il difetto di questo meccanismo è la maggiore complessità (lo sviluppatore deve considerare cosa è accessibile senza codifica e cosa no) e un piccolo deficit prestazionale (un conto è cifrare con AES a livello di blocco e un altro cifrare a livello di singolo file con diversi livelli).
Segnalo che gli upgrade mantengono la stessa tipologia di crittografia. I reset di fabbrica invece dovrebbero (secondo le linee guida di Android) modificare la FDE in FBE.
Da questo punto di vista, IOS è stato concepito meglio a livello di sicurezza.
edofullo Sinceramente mi sembra essenziale per proteggere la crittografia dei dati in memoria visto la maggior parte delle cose devono essere decrittografate quando si arriva alla lockscreen.
Il problema è che con la FDE, le cose vengono decrittografate in automatico usando la "default_password"...
Con ADB puoi verificare il tipo di crittografia impiegata: adb shell getprop ro.crypto.type
. Ti viene restituito file o block a seconda che sia FBE o FDE. Mi era capitato che dopo un aggiornamento Avvio Protetto venisse disabilitato in automatico...
rieges Nel mio telefono (Galaxy S8) c'è ancora e si chiama avvio protetto.
Sui Samsung con una certa versione di Knox puoi avere la FBE, ma devi ripristinarlo ai dati di fabbrica (e forse forzare qualcosa nelle Developer Options).
Da quel che ho capito, FDE + Secure Startup e FBE a livello di sicurezza dovrebbero essere equivalenti (ma il secondo è più "comodo").
Aggiungo alcuni link interessanti:
https://nelenkov.blogspot.com/2014/10/revisiting-android-disk-encryption.html
https://blog.elcomsoft.com/2018/05/demystifying-android-physical-acquisition/
https://blog.elcomsoft.com/2017/10/ios-vs-android-physical-data-extraction-and-data-protection-compared/