Je cite le manuel Android ici mais :

NOTE :

La source que j'ai utilisée n'est pas directement pertinente pour Marshmallow mais l'est pour Lollipop et les versions supérieures.

TL:DR

Je vais maintenant répondre aux questions de l'OP. Les détails techniques suivront.

1. La clé de cryptage par défaut provient d'une source matérielle (une puce similaire à un TPM) et le mot de passe par défaut de l'AOSP défini comme suit default_password dans le cryptfs.c le fichier source, voir ci-dessous.

2. Oui, pas seulement le mot de passe par défaut, mais tout mot de passe est transformé en clé et est stocké sur une puce de type TPM, appelée TEE (abréviation de "Trusted Execution Environment", voir ci-dessous pour plus de détails).

3. Un pirate ayant un accès UART/JTAG aux puces du SoC de l'appareil pourrait techniquement avoir accès à la clé TEE, ou un noyau personnalisé pourrait divulguer ces informations à un pirate. Certaines agences de 3 lettres dans les théories de conspiration peuvent éventuellement s'associer avec l'OEM pour obtenir ces noyaux non sécurisés utilisés dans les appareils de production, mais je ne mettrais pas beaucoup de magasins par là. Encore une fois, voir la dernière section de cette réponse pour plus de détails.

La seule chose qui empêche un pirate d'avoir accès à la clé est la quantité d'efforts nécessaires pour y parvenir.

4. Vérification du hachage (checksumming) du microprogramme (appelé "Botte vérifiée" par Google) se fait en fait sur et au-dessus de Lollipop par défaut (et est disponible à partir de JellyBean 4.3), par un module de noyau appelé dm-verity . Cependant, ceci est indépendant du statut de cryptage.

Fuente: Guide de sécurité de l'AOSP ici .

5. Pour le processus de décryptage du système avec un mot de passe personnalisé, voir ci-dessous. Je vous dirai simplement ici que le mot de passe de l'utilisateur est impliqué dans la création et l'utilisation de la clé de cryptage.

Vue d'ensemble

Au premier démarrage, l'appareil crée une clé principale de 128 bits générée de manière aléatoire, puis la hachurée avec un mot de passe par défaut et un sel stocké. Le mot de passe par défaut est : "default_password" Cependant, le hachage résultant est également signé par un TEE (tel que TrustZone), qui utilise un hachage de la signature pour chiffrer la clé principale.

Vous pouvez trouver le mot de passe par défaut défini dans le projet Android Open Source Project cryptfs.c archivo.

Lorsque l'utilisateur définit le PIN/pass ou le mot de passe sur l'appareil, seule la clé de 128 bits est re-cryptée et stockée. (c'est-à-dire que les changements de PIN/pass/mot de passe de l'utilisateur n'entraînent PAS le re-cryptage de la partition de données de l'utilisateur).

Démarrage d'un appareil crypté avec un cryptage par défaut

C'est ce qui se passe lorsque vous démarrez un appareil crypté sans mot de passe. Les appareils Android 5.0 étant cryptés au premier démarrage, aucun mot de passe ne devrait être défini et il s'agit donc de l'état de cryptage par défaut.

1. Détecter le /data crypté sans mot de passe

Détecter que le périphérique Android est crypté parce que /data ne peut pas être monté et que l'un des drapeaux encryptable ou forceencrypt est réglé.

vold fixe vold.decrypt a trigger_default_encryption qui lance le defaultcrypto service. trigger_default_encryption vérifie le type de cryptage pour voir si /data est crypté avec ou sans mot de passe.

2. Décrypter /data

Crée le dm-crypt sur le dispositif de blocage afin que le dispositif soit prêt à être utilisé.

3. Monter /data

vold monte ensuite la partition /data réelle décryptée et prépare ensuite la nouvelle partition. Il définit la propriété vold.post_fs_data_done a 0 et fixe ensuite vold.decrypt a trigger_post_fs_data . Cela entraîne init.rc pour exécuter son post-fs-data les commandes. Elles créeront tous les répertoires ou liens nécessaires, puis définiront les paramètres suivants vold.post_fs_data_done a 1 .

Une fois vold voit le 1 dans cette propriété, il définit la propriété vold.decrypt à : trigger_restart_framework . Cela entraîne init.rc pour commencer les services en classe main et démarre également les services de la classe late_start pour la première fois depuis le démarrage.

4. Cadre de départ

Maintenant, le framework démarre tous ses services en utilisant le /data décrypté, et le système est prêt à être utilisé.

Démarrage d'un appareil crypté sans cryptage par défaut

C'est ce qui se passe lorsque vous démarrez un appareil crypté qui a un mot de passe défini. Le mot de passe du périphérique peut être un code, un motif ou un mot de passe.

1. Détecter le dispositif crypté avec un mot de passe

Détecter que l'appareil Android est crypté car le drapeau ro.crypto.state = "encrypted"

vold fixe vold.decrypt a trigger_restart_min_framework parce que /data est crypté avec un mot de passe.

2. Monter tmpfs

init définit cinq propriétés afin de sauvegarder les options de montage initiales données pour /data avec les paramètres passés à partir de init.rc . vold utilise ces propriétés pour configurer le mappage cryptographique :

ro.crypto.fs_type

ro.crypto.fs_real_blkdev

ro.crypto.fs_mnt_point

ro.crypto.fs_options

ro.crypto.fs_flags (numéro hexagonal ASCII à 8 chiffres précédé de 0x)

3. Démarrer le cadre pour demander le mot de passe

Le cadre démarre et voit que vold.decrypt est réglé sur trigger_restart_min_framework . Cela indique au framework qu'il est en train de démarrer sur un tmpfs /data et il doit obtenir le mot de passe de l'utilisateur.

Mais d'abord, il doit s'assurer que le disque a été correctement crypté. Il envoie la commande cryptfs cryptocomplete a vold . vold renvoie 0 si le cryptage s'est déroulé avec succès, -1 en cas d'erreur interne, ou -2 si le cryptage ne s'est pas déroulé avec succès. vold détermine cela en regardant dans les métadonnées cryptographiques de l'utilisateur. CRYPTO_ENCRYPTION_IN_PROGRESS le drapeau. S'il est activé, le processus de cryptage a été interrompu et il n'y a pas de données utilisables sur l'appareil.

Si vold renvoie une erreur, l'interface utilisateur doit afficher un message invitant l'utilisateur à redémarrer et à réinitialiser l'appareil en usine, et lui donner un bouton sur lequel appuyer pour ce faire.

4. Déchiffrer les données avec un mot de passe

Une fois cryptfs cryptocomplete est réussie, le cadre affiche une interface utilisateur demandant le mot de passe du disque. L'interface utilisateur vérifie le mot de passe en envoyant la commande cryptfs checkpw a vold . Si le mot de passe est correct (ce qui est déterminé par le montage réussi du fichier décrypté /data à un emplacement temporaire, puis le démonte), vold enregistre le nom du périphérique bloc décrypté dans la propriété ro.crypto.fs_crypto_blkdev et renvoie le statut 0 à l'interface utilisateur. Si le mot de passe est incorrect, il renvoie -1 à l'interface utilisateur.

5. Arrêt du cadre

L'interface utilisateur affiche un graphique de démarrage cryptographique et appelle ensuite vold avec la commande cryptfs restart . vold définit la propriété vold.decrypt a trigger_reset_main ce qui entraîne init.rc à faire class_reset main . Cela arrête tous les services dans le main qui permet à la classe tmpfs /data pour être démonté.

6. Monter /data

vold puis monte le réel décrypté /data et prépare la nouvelle partition (qui peut ne jamais avoir été préparée si elle a été chiffrée avec l'option wipe, qui n'est pas supportée dans la première version). Il définit la propriété vold.post_fs_data_done a 0 et fixe ensuite vold.decrypt a trigger_post_fs_data . Cela entraîne init.rc pour exécuter son post-fs-data commands . Ils créeront les répertoires ou les liens nécessaires, puis mettront en place les éléments suivants vold.post_fs_data_done a 1 . Une fois que vold voit le 1 dans cette propriété, il définit la propriété vold.decrypt a trigger_restart_framework . Cela entraîne init.rc pour commencer les services en classe main de nouveau et de commencer les services en classe late_start pour la première fois depuis le démarrage.

7. Lancer le cadre complet

Maintenant, le framework démarre tous ses services en utilisant le système de fichiers /data décrypté, et le système est prêt à être utilisé.

Stockage de la clé cryptée

La clé chiffrée est stockée dans les métadonnées cryptographiques. La garantie matérielle est mise en œuvre en utilisant la capacité de signature de Trusted Execution Environment (TEE). Auparavant, nous avons crypté la clé principale avec une clé générée en appliquant scrypt au mot de passe de l'utilisateur et au sel stocké.

Afin de rendre la clé résistante aux attaques hors-boîte, nous étendons cet algorithme en signant la clé résultante avec une clé TEE stockée. La signature résultante est ensuite transformée en une clé de longueur appropriée par une application supplémentaire de l'algorithme scrypt . Cette clé est ensuite utilisée pour crypter et décrypter la clé principale. Pour stocker cette clé :

1. Générer une clé de cryptage de disque aléatoire de 16 octets (DEK) et un sel de 16 octets.
2. Appliquer scrypt au mot de passe de l'utilisateur et au sel pour produire la clé intermédiaire 1 (IK1) de 32 octets.
3. Remplir IK1 avec zéro octet jusqu'à la taille de la clé privée liée au matériel (HBK). Plus précisément, nous remplissons comme : 00 || IK1 || 00..00 ; un octet zéro, 32 octets IK1, 223 octets zéro.
4. Le signe a complété IK1 avec HBK pour produire IK2 de 256 octets.
5. Appliquer scrypt à IK2 et au sel (même sel qu'à l'étape 2) pour produire IK3 de 32 octets.
6. Utilisez les 16 premiers octets de IK3 comme KEK et les 16 derniers octets comme IV.
7. Chiffrer DEK avec AES_CBC, avec la clé KEK, et le vecteur d'initialisation IV.