Je viens d'installer Marshmallow sur un Nexus 5 via une mise à jour poussée. Je suis confus quant au fonctionnement du cryptage. J'ai une bonne connaissance technique du chiffrement sur les ordinateurs. Je voudrais acquérir des connaissances similaires sur Android 6.

Ce qui suit est ce que j'ai fait et comment je suis devenu confus. Après une réinitialisation d'usine, j'ai configuré un code PIN puis crypté l'appareil. Au démarrage, il m'a demandé mon code PIN, ce qui était attendu. J'ai ensuite supprimé le code PIN et redémarré l'appareil. Il n'a pas demandé de code PIN au démarrage, mais l'appareil s'est toujours signalé comme crypté dans le menu de configuration. Ce dernier est ce qui m'embrouille car je m'attendais à ce que le code PIN déverrouille la clé de déchiffrement.

Des questions:

• Dans le cas d'un chiffrement sans code PIN, d'où vient la clé de déchiffrement? Je suppose qu'il est stocké sur une puce similaire à un TPM, est-ce correct? Si oui, qu'est-ce qui empêche un pirate de demander cette clé à la puce? Vérifie-t-il le hachage du firmware? Rien d'autre? Des détails techniques seraient très appréciés.
• Dans le cas du cryptage avec un code PIN, le code PIN est-il utilisé comme jeton supplémentaire pour accéder à la clé de décryptage? Ou le processus de décryptage fonctionne-t-il exactement comme s'il n'y avait pas de code PIN.

Réponse TL; DL:

La clé de déchiffrement est déverrouillée avec tous les éléments suivants:

• Le code PIN (ou mot de passe, etc.) ou un mot de passe par défaut s'il n'y en a pas
• Un TEE (un générateur de signature soutenu par du matériel qui utilise des clés qui ne peuvent pas être extraites)
• Un sel (facilement disponible mais prévenant les attaques des tables arc-en-ciel)

Je cite le manuel Android ici , mais:

REMARQUE:

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

TL: DR

Je vais répondre aux questions du PO maintenant. Les détails techniques suivront.

1. La clé de chiffrement par défaut provient d'une source matérielle (une puce similaire à un TPM) et du mot de passe par défaut d'AOSP défini comme default_passworddans le cryptfs.cfichier source, voir ci-dessous.

2. Oui, pas seulement la valeur 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 disposant d'un accès UART / JTAG aux puces sur le SoC de l'appareil pourrait techniquement avoir accès à la clé TEE, ou un noyau personnalisé peut divulguer ces informations à un pirate. Certaines agences à 3 lettres dans les théories du complot 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 à côté. Encore une fois, consultez la dernière section de cette réponse pour plus de détails.

La seule chose qui empêche un pirate d'accéder à la clé est la quantité d'efforts nécessaires pour le faire.

4. La vérification du hachage (somme de contrôle) du firmware (appelé "Verified Boot" par Google) est en fait effectuée 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, cela est indépendant du statut de chiffrement.

Source: guide de sécurité AOSP ici .

5. À propos du processus impliqué dans le décryptage du système avec un mot de passe personnalisé, voir ci-dessous. Je vais juste vous dire ici que le mot de passe utilisateur est impliqué à la fois dans la création et l'utilisation de la clé de cryptage.

Aperçu

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 hache avec un mot de passe par défaut et du sel stocké. Le mot de passe par défaut est: "default_password" Cependant, le hachage résultant est également signé via un TEE (tel que TrustZone), qui utilise un hachage de la signature pour crypter la clé principale.

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

Lorsque l'utilisateur définit le code PIN / passe ou le mot de passe sur l'appareil, seule la clé de 128 bits est rechiffrée et stockée. (c.-à-d. que les changements de code PIN / passe / modèle utilisateur ne provoquent PAS le rechiffrement de la partition de données utilisateur.)

Démarrage d'un appareil chiffré avec le chiffrement par défaut

C'est ce qui se produit lorsque vous démarrez un appareil chiffré sans mot de passe. Étant donné que les appareils Android 5.0 sont chiffrés au premier démarrage, aucun mot de passe ne doit être défini et il s'agit donc de l'état de chiffrement par défaut.

1. Détectez les données chiffrées / sans mot de passe

Détectez que l'appareil Android est crypté car / data ne peut pas être monté et l'un des indicateurs encryptableou forceencryptest défini.

volddéfinit vold.decryptsur trigger_default_encryption, qui démarre le defaultcryptoservice. trigger_default_encryptionvérifie le type de cryptage pour voir si / data est crypté avec ou sans mot de passe.

2. Déchiffrer / données

Crée le dm-cryptpériphérique sur le périphérique bloc afin que le périphérique soit prêt à être utilisé.

3. Montage / données

voldmonte ensuite la partition réelle / données déchiffrée, puis prépare la nouvelle partition. Il définit la propriété vold.post_fs_data_donesur 0puis définit vold.decryptsur trigger_post_fs_data. Cela provoque l' init.rcexécution de ses post-fs-datacommandes. Ils vont créer des répertoires ou des liens nécessaires et mis vold.post_fs_data_doneà 1.

Une fois voldvoit le 1 dans cette propriété, il définit la propriété vold.decryptà: trigger_restart_framework. Cela provoque init.rcle redémarrage des services dans la classe mainet le démarrage des services dans la classe late_start pour la première fois depuis le démarrage.

4. Cadre de démarrage

Maintenant, le framework démarre tous ses services en utilisant les données décryptées et le système est prêt à l'emploi.

Démarrage d'un appareil chiffré sans chiffrement par défaut

C'est ce qui se produit lorsque vous démarrez un appareil crypté avec un mot de passe défini. Le mot de passe de l'appareil peut être une broche, un motif ou un mot de passe.

1. Détecter l'appareil crypté avec un mot de passe

Détectez que l'appareil Android est crypté car l'indicateur ro.crypto.state = "encrypted"

voldest défini vold.decryptsur trigger_restart_min_framework/ data est crypté avec un mot de passe.

2. Monter tmpfs

initdéfinit cinq propriétés pour enregistrer les options de montage initiales données pour / data avec des paramètres transmis depuis init.rc. voldutilise 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 hexadécimal ASCII à 8 chiffres précédé de 0x)

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

Le cadre démarre et voit qu'il vold.decryptest réglé sur trigger_restart_min_framework. Cela indique au framework qu'il démarre sur un tmpfs /datadisque et qu'il doit obtenir le mot de passe utilisateur.

Cependant, il doit d'abord s'assurer que le disque a été correctement chiffré. Il envoie la commande cryptfs cryptocompleteà vold. voldrenvoie 0 si le cryptage s'est terminé avec succès, -1 en cas d'erreur interne ou -2 si le cryptage n'a pas été effectué avec succès. volddétermine cela en recherchant le CRYPTO_ENCRYPTION_IN_PROGRESSdrapeau dans les métadonnées cryptographiques . S'il est défini, le processus de cryptage a été interrompu et il n'y a pas de données utilisables sur l'appareil.

Si voldrenvoie une erreur, l'interface utilisateur doit afficher un message à l'utilisateur pour redémarrer et réinitialiser le périphérique en usine, et donner à l'utilisateur un bouton à appuyer pour le faire.

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

Une fois cryptfs cryptocompleteréussi, le framework 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à vold. Si le mot de passe est correct (qui est déterminé en montant avec succès le déchiffré /dataà un emplacement temporaire, puis en le démontant), vold enregistre le nom du périphérique de bloc déchiffré dans la propriété ro.crypto.fs_crypto_blkdevet renvoie l'état 0 à l'interface utilisateur. Si le mot de passe est incorrect, il renvoie -1 à l'interface utilisateur.

5. Arrêter le cadre

L'interface utilisateur met en place un graphique de démarrage crypto, puis appelle vold avec la commande cryptfs restart. volddéfinit la propriété vold.decryptà trigger_reset_main, ce qui provoque le init.rcfaire class_reset main. Cela arrête tous les services de la mainclasse, ce qui permet de les tmpfs /datadémonter.

6. Montage / données

voldmonte ensuite la /datapartition réelle déchiffrée et prépare la nouvelle partition (qui n'aurait peut-être jamais été préparée si elle avait été chiffrée avec l'option d'effacement, qui n'est pas prise en charge dans la première version). Il définit la propriété vold.post_fs_data_donesur 0puis définit vold.decryptsur trigger_post_fs_data. Cela provoque l' init.rcexécution de son post-fs-data commands. Ils vont créer des répertoires ou des liens nécessaires et mis vold.post_fs_data_doneà 1. Une fois que le voldvoit 1dans cette propriété, il définit la propriété vold.decryptsur trigger_restart_framework. Cela provoque init.rcle redémarrage des services en classe mainet le démarrage des services en classe late_startpour la première fois depuis le démarrage.

7. Démarrer le framework complet

Maintenant, le framework démarre tous ses services en utilisant le système de fichiers décrypté / données, et le système est prêt à l'emploi.

Stockage de la clé cryptée

La clé chiffrée est stockée dans les métadonnées cryptographiques. La sauvegarde matérielle est implémentée à l'aide de la capacité de signature de Trusted Execution Environment (TEE). Auparavant, nous cryptions la clé principale avec une clé générée en appliquant scryptau 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 autre application de scrypt. Cette clé est ensuite utilisée pour chiffrer et déchiffrer la clé principale. Pour stocker cette clé:

1. Générez une clé de chiffrement de disque (DEK) aléatoire de 16 octets et un sel de 16 octets.
2. Appliquez scryptau mot de passe utilisateur et au sel pour produire la clé intermédiaire 32 octets 1 (IK1).
3. Remplissez IK1 avec zéro octet à 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. Signe rempli IK1 avec HBK pour produire 256 octets IK2.
5. Appliquer scryptsur IK2 et sel (même sel que l'étape 2) pour produire IK3 32 octets.
6. Utilisez les 16 premiers octets de IK3 comme KEK et les 16 derniers octets comme IV.
7. Chiffrez DEK avec AES_CBC, avec la clé KEK et le vecteur d'initialisation IV.