Google a commencé à introduire le Full Disk Encryption (FDE) par défaut avec Android 5.0 Lollipop. Au début, lorsque le cryptage a été implémenté dans les appareils Nexus 6, de nombreux utilisateurs se sont plaints de la dégradation des performances lors de la lecture et de l'écriture de données sur le disque, mais à partir de la version d'Android 6.0, ce problème semble être résolu.Le chiffrement intégral du disque protège toutes les informations du téléphone même si l'appareil est tombé entre les mains des forces de l'ordre ou d' autres intrus.Lorsque le cryptage est activé, toutes les informations sur le téléphone sont automatiquement cryptées à la volée avec la clé AES avant d'écrire sur le support. Et vice versa, lors de la lecture des informations, elles sont automatiquement décryptées avec cette clé.Sur les appareils iOS 9, cette clé est un dérivé du mot de passe utilisateur et une clé matérielle unique de 256 bits câblée en usine au smartphone. Même le FBI ne peut pas casser ce niveau de cryptage en utilisant la force brute, comme on le sait dans l'histoire récente avec le smartphone du tireur de San Bernardino, à cause de quoi le FBI et Apple ont été traduits en justice . En conséquence, le FBI a quand même réussi à casser le téléphone en utilisant une vulnérabilité 0day inconnue. Comme on peut le comprendre d'après les mots de la structure du chef de l'État, les pirates ont dû payer plus d'un million de dollars pour contourner la protection du FBI .
Cryptage complet du disque dans iOSAinsi, la force brute FDE n'est possible qu'en utilisant un périphérique matériel spécifique. Cela complique grandement l'attaque. Dans le cas habituel, vous pourriez créer un million de copies et paralléliser la bruteforce dans le service cloud, ce qui vous permet de trouver très rapidement 99% des vrais mots de passe. Mais dans ce cas, nous devons nous limiter au seul appareil sur lequel Apple ajoute des interférences supplémentaires - retards entre les tentatives de mot de passe, limite sur le nombre maximal de tentatives, etc. C'est pourquoi il est extrêmement important pour les services spéciaux de trouver un moyen de récupérer l'UID matériel, puis le mot de passe par force brute devient une tâche technique courante.Le chiffrement complet du disque dans Android 5.0+ est implémenté quelque peu différemment que dans iOS 9, et est décrit en détail dansBlog de Nikolay Elenkov et documentation officielle Android .Ici, la clé de cryptage est également un dérivé du mot de passe utilisateur généralement faible , mais également de la clé principale de 128 bits générée de façon aléatoire (Device Encryption Key - DEK) et du sel de 128 bits généré de manière aléatoire. Le champ de génération DEK est protégé à l'aide d'un schéma soigneusement pensé qui utilise les valeurs saisies par l'utilisateur - code PIN / mot de passe / modèle (clé graphique) pour la saisie. Ensuite, le DEK crypté est placé dans un stockage crypté spécial appelé crypto footer . Tous ces niveaux de cryptage doivent être surmontés avant de décrypter DEK, puis toute information enregistrée sur le disque.
Comme dans le cas d'iOS 9, le système d'exploitation Android implémente la liaison du schéma de chiffrement à un matériel spécifique pour empêcher la force brute sur les copies du système d'exploitation. La fonction de liaison matérielle est exécutée par un stockage matériel spécial - KeyMaster, qui fonctionne dans un environnement d'exécution sécurisé (TEE) spécial, qui est complètement indépendant du système d'exploitation Android. La sécurité des clés dans l'environnement KeyMaster est essentielle. Seulement cela protège le système de chiffrement complet du disque contre la réalisation d'une force brute efficace dans des flux parallèles sur des copies du système d'exploitation.Sur les appareils Android, un environnement isolé n'émet jamais sa propre clé dans un environnement «dangereux». Au contraire, le module KeyMaster reçoit un «blob de clé» d'un environnement non sécurisé, déchiffre la clé qui y est stockée et la restitue. En d'autres termes, le fonctionnement du système de cryptage n'est possible que directement sur le périphérique matériel, mais pas dans un environnement virtuel sur un autre ordinateur.En général, l'ensemble du processus peut être schématiquement représenté dans un tel diagramme, que Nikolai Elenkov donne .
La protection de l'environnement KeyMaster et l'exécution des commandes sur un processeur sécurisé dédié sont assurées par l'environnement protégé fourni par l'équipementier. Dans le cas de Qualcomm, il s'agit du QSEE (Qualcomm Secure Execution Environment). Il permet uniquement à de petites applications distinctes appelées trustlets de s'exécuter sur un processeur dédié. L'un de ces trustlets est KeyMaster. Le code source Android contient des instructions pour accéder à l'application KeyMaster. En fait, le trustlet ne prend en charge que quatre instructions: * Commands supported
*/
enum keymaster_cmd_t {
KEYMASTER_GENERATE_KEYPAIR = 0x00000001,
KEYMASTER_IMPORT_KEYPAIR = 0x00000002,
KEYMASTER_SIGN_DATA = 0x00000003,
KEYMASTER_VERIFY_DATA = 0x00000004,
};
KeyMaster fonctionne exactement comme décrit ci-dessus: il reçoit le blob de clés, calcule la signature et la place dans le tampon.Et maintenant, nous sommes arrivés exactement au stade où le nouvel exploit opère, qui est apparu dans le domaine public le 30 juin ( référentiel sur Github ). L'exploit exploite les vulnérabilités récemment découvertes CVE-2015-6639 et CVE-2016-2431 .L'auteur de l'exploit, le spécialiste de la sécurité Gal Beniamini a écrit une fausse version de l'application QSEE et, en utilisant les vulnérabilités susmentionnées, a réussi à la charger dans un environnement sécurisé, augmentant ainsi les privilèges et brisant la protection de l'environnement QSEE, qui est impliqué dans le processus de génération d'une clé pour chiffrer le disque.Ainsi, un attaquant hypothétique peut "truquer" le composant matériel de la clé de chiffrement et implémenter la force brute des composants restants, contournant la protection Android par le nombre de tentatives. Il ne reste plus qu'à sélectionner le PIN / mot de passe utilisateur par force brute.Soit dit en passant, dans les rares cas où l'utilisateur a défini un mot de passe très complexe avec une entropie élevée pour le chiffrement et ne peut pas être récupéré avec force brute pendant un temps acceptable, il existe un plan de sauvegarde. Si briser le cryptage est vraiment nécessaire, vous pouvez trouver exactement le même téléphone, du même modèle, avec les mêmes rayures et un étui de protection - et le programmer pour envoyer un mot de passe dès que la victime y entre. Ce faux appareil est attaché à la victime au lieu de l'original. Pour éviter la divulgation et en même temps éliminer le risque que la victime entre le mauvais mot de passe du premier coup, le téléphone doit être programmé pour n'accepter aucun mot de passe comme étant le bon.Mais c'est bien sûr un cas extrême. Il est en fait assez facile de récupérer des codes PIN et des mots de passe ordinaires s'il n'y a pas de restrictions matérielles sur la force brute.Il y a un point intéressant. L'environnement sécurisé sur les appareils mobiles n'est pas défini par Qualcomm lui-même, mais par les OEM. Ils peuvent coopérer avec les autorités répressives du pays dans lequel ils se trouvent et répondre aux exigences des demandes judiciaires. En conséquence, si un tel schéma cryptographique est mis en œuvre par un fabricant russe, les informations sur le smartphone seront déclassifiées à la demande du tribunal russe.Et encore un moment intéressant. Malgré le fait que Gal Benyamini discute de ces vulnérabilités avec Qualcomm et Google depuis plusieurs mois, les corriger n'est pas si facile - il n'y a pas assez de mise à niveau logicielle (pour deux vulnérabilités, des correctifs pour Android ont été publiés en janvier et mai ), et une mise à niveau matérielle peut être nécessaire. Le fait est que si un attaquant reçoit un appareil, il peut théoriquement annuler une mise à niveau logicielle, ramener l'appareil à une version vulnérable et mener une attaque.Comme mentionné ci-dessus, le code d'exploitation est publié sur Github . Voici un schéma de son travail.
Gal Benyamini a écrit plusieurs scripts Python qui simplifient la force brute après le déclenchement d'un exploit. Dans les commentaires sur le blog de son collèguea exprimé le désir d' aider à porter le script sur la plateforme bruteforce hashcat / oclHashcat la plus puissante .Benjamini suggère que Google, en collaboration avec les constructeurs OEM, développera un nouveau schéma de cryptage matériel-logiciel absolument fiable, qui même théoriquement ne peut pas être craqué.Espérons qu'un tel schéma soit implémenté sur une nouvelle génération d'appareils Android.