En fait, Android 6.0 a Cryptage complet du disque comme indiqué dans le Document de définition de la compatibilité Android 6.0 - Section 9.9 Cryptage intégral du disque (Full Disk Encryption) avec des exceptions si le matériel était insuffisant pour effectuer l'opération.
Donc votre cas d'un mot de passe non spécifié pour l'écran de verrouillage est en fait appelé :
Si l'utilisateur n'a pas spécifié de code d'accès à l'écran de verrouillage ou a désactivé l'utilisation du code d'accès pour le chiffrement, le système DEVRAIT utiliser un code d'accès par défaut pour envelopper la clé de chiffrement. Si le dispositif fournit un keystore soutenu par le matériel, l'algorithme d'étirement du mot de passe DOIT être lié cryptographiquement à ce keystore. La clé de chiffrement NE DOIT PAS être envoyée hors de l'appareil (même lorsqu'elle est enveloppée du code de passe de l'utilisateur et/ou de la clé liée au matériel). Le projet Android Open Source en amont fournit une implémentation préférée de cette fonctionnalité basée sur la fonctionnalité dm-crypt du noyau Linux.
Il devrait donc y avoir un code d'accès par défaut dans votre scénario, mais certains fabricants peuvent l'éviter, très probablement sur du matériel dont les performances de cryptage sont médiocres et qui a été publié avec une version antérieure d'Android.
Si vous vous demandez ce qui s'est passé avant l'introduction du cryptage intégral du disque dans Android 5.0, la réponse est que le fabricant aurait dû modifier Android pour prendre en charge le cryptage. Samsung serait un exemple, car ils ont leur propre système de cryptage. API Knox pour la gestion des appareils remontant à Gingerbread/Honeycomb (2.x/3.x)
Mise à jour concernant la séquence de démarrage pour le chiffrement intégral du disque (Full Disk Encryption)
Je pense que votre question est
If the disk is encrypted, how does it boot?
La documentation du cadre Android sur Cryptage complet du disque couvre effectivement le comportement au démarrage :
Afin de crypter, décrypter ou effacer /data , /data ne doit pas être monté. Cependant, afin d'afficher une interface utilisateur (IU), le framework doit être lancé et le framework a besoin de /data pour courir. Pour résoudre cette énigme, un système de fichiers temporaire est monté sur /data . Cela permet à Android de demander des mots de passe, de montrer la progression ou de suggérer un nettoyage des données si nécessaire. Il impose une limitation : pour passer du système de fichiers temporaire au système de fichiers réel, le système de fichiers temporaire doit être utilisé. /data le système doit arrêter tous les processus ayant des fichiers ouverts sur le système de fichiers temporaire et redémarrer ces processus sur le système de fichiers réel. /data système de fichiers.
Si je me souviens bien, pour les appareils avec un chiffrement complet du disque, au démarrage, une fois que le mot de passe/pin de l'utilisateur était entré, l'appareil prenait un certain temps pour que tout soit configuré. Ceci est impliqué par le fait que tous les processus en cours d'exécution ont dû passer d'un système de fichiers temporaire au système de fichiers crypté.
