Comment Android L obtient-il un cryptage fort avec une phrase secrète à faible entropie?
Après la mise à niveau vers Android L sur mon Nexus 5, j'ai été ravi de constater que je peux activer le chiffrement en utilisant un modèle comme phrase secrète.
Cependant, cela m'a vite fait réfléchir. Je suppose que la clé de chiffrement est finalement dérivée du modèle qui est une entropie très faible. J'ai fait un calcul au dos de l'enveloppe et j'ai constaté que le nombre total de motifs uniques sur une grille de 3x3 points atteignait un peu moins d'un million. Même à 0,1 supposition par seconde, il ne faudrait que 115 jours pour rechercher l'intégralité de l'espace de touches.
J'ai commencé à lire et j'ai découvert n article détaillant comment Android fait le chiffrement du disque . Il semble prétendre que Android L utiliser un stockage sécurisé soutenu par du matériel pour stocker et dériver la clé de chiffrement afin qu'il puisse essentiellement permettre aux phrases de passe à faible entropie d'avoir toujours le même niveau de sécurité.
Cependant, je ne comprends pas très bien pourquoi. Pourquoi l'utilisation d'un périphérique de stockage sécurisé avec support matériel permet-elle soudainement des phrases secrètes à faible entropie pour obtenir une sécurité élevée? Suis-je juste en train de rater quelque chose d’évident?
Les cartes bancaires à puce utilisent généralement un code PIN à 4 chiffres. Il faudrait au plus quelques heures pour les essayer tous si la carte ne protégeait pas contre les tentatives de force brute. La carte protège contre les tentatives de force brute en se brisant après 3 échecs consécutifs. L'adversaire n'a pas accès à un hachage du PIN (il y a des protections physiques dans la carte qui rendent extrêmement difficile la lecture de sa mémoire), mais seulement à une boîte noire qui prend 4 chiffres comme entrées et réponses "oui" ou "non". La clé de la sécurité ici est que l'adversaire ne peut faire que des tentatives en ligne, pas des tentatives hors ligne . Chaque la tentative nécessite un calcul sur l'appareil défenseur, il ne s'agit pas seulement de faire le calcul.
Un Android ou tout autre ordinateur peut faire la même chose avec sa clé de chiffrement de stockage. La clé n'est pas dérivée de la phrase de passe (ou du modèle), mais stockée quelque part et chiffrée avec la phrase de passe. La plupart les systèmes de chiffrement du stockage ont cette indirection de sorte que la modification de la phrase secrète ne nécessite pas de rechiffrer tout le stockage, et que le stockage puisse être effacé efficacement en effaçant les quelques octets qui composent la clé chiffrée (la clé de chiffrement du stockage est uniformément aléatoire, contrairement à une clé dérivée d'une phrase secrète, elle n'est pas soumise à la force brute: l'adversaire doit obtenir au moins la clé de stockage cryptée pour prendre pied).
Si l'adversaire peut lire la clé de stockage chiffrée, il peut alors effectuer des tentatives rapides de force brute sur la clé d'un cluster de PC. Mais si la clé de stockage est stockée dans un stockage inviolable, l'adversaire ne peut pas le lire et ne peut soumettre que des tentatives de phrase secrète à l'appareil, donc l'appareil peut appliquer des politiques telles que "limiter le taux de tentatives à 3 par minute" ou "exiger une seconde phrase de passe plus longue après 10 tentatives infructueuses".
La nouvelle fonctionnalité de Android L est la prise en charge en amont d'une clé de stockage chiffrée qui n'est pas stockée sur la mémoire flash (à partir de laquelle elle peut être vidée avec un peu de soudure ou avec un accès root), mais à la place dans une certaine mémoire protégée (qui peut être accessible uniquement au mode sécurisé de TrustZone ). Tous les téléphones exécutant Android L n'ont cependant pas une telle mémoire protégée, et même si c'est présent, il n'y a aucune garantie qu'il est utilisé pour le cryptage. Toutes les modifications Android L fournissent le code requis dans le cadre de l'image de base Android, ce qui le rend plus facile). pour les fournisseurs de téléphones à intégrer.
Android fournit une API pour vérifier si le stockage du trousseau d'application est en mémoire protégée ). Je ne sais pas s'il existe une API correspondante pour vérifier la protection de la clé de chiffrement du stockage.
Je ne sais pas si c'est ainsi Android le fait, mais un périphérique de stockage sécurisé soutenu par du matériel peut bloquer les tentatives répétées qui sont faites trop rapidement, ce qui rend votre hypothèse de 0,1 supposition par seconde invalide. Supposons qu'il autorise initialement une tentative tous les 0,01 de seconde, mais qu'il double le temps entre les tentatives à chaque échec après les cinq premiers. Après seulement 50 tentatives, vous devrez attendre 250 000 ans avant de pouvoir réessayer (et il cela vous aura pris 250 mille ans pour en arriver là.) Mais tant que vous pouvez toujours saisir correctement votre mot de passe en 10 tentatives ou moins, vous ne remarquerez aucun retard.
La génération d'une clé et l'utilisation d'une phrase de passe sont deux choses différentes. Les clés, par exemple en cryptographie asymétrique, sont générées en utilisant l'entropie provenant de l'environnement informatique (comme /dev/urandom, qui pourrait ou non être une bonne source d'entropie, mais c'est un autre débat). La clé elle-même n'a donc rien à voir avec la phrase de passe. La phrase de passe sera juste utilisée pour crypter la clé elle-même dans un conteneur conçu pour stocker la clé.
Si quelqu'un veut vous déchiffrer les données du disque, il a besoin de la clé. Trouver la clé devrait être presque impossible dans les bonnes conditions. Si cela est fait correctement, la rupture du cryptage du conteneur de clés devrait également être impossible sans la clé.
En ce qui concerne le forçage brutal de la clé, cela pourrait en fait être une opération triviale si l'attaquant avait accès au fichier de clé crypté, compte tenu de l'espace de clé faible. Il s'agit de l'appareil chargé de rendre ce fichier de clé crypté non disponible pour l'attaquant.
De votre article lié, je lis:
L'obtention d'une copie brute d'une partition de disque n'est généralement pas possible sur la plupart des appareils commerciaux, mais peut être obtenue en démarrant une image de démarrage d'acquisition de données spécialisée signée par le fabricant de l'appareil, en exploitant une faille dans le chargeur de démarrage qui permet de démarrer des images non signées (comme comme celui-ci), ou tout simplement en démarrant une image de récupération personnalisée sur des appareils avec un chargeur de démarrage déverrouillé (une première étape typique pour "rooter").
Ces attaques, sinon impossibles, nécessitent un certain investissement (en terme de temps, ou d'argent). Toute sécurité est un compromis.
J'ai également lu:
En supposant que l'implémentation est similaire à celle du magasin d'informations d'identification soutenu par le matériel, les clés de chiffrement de disque doivent être chiffrées par une clé de chiffrement de clé inextractible stockée dans le SoC, afin d'obtenir une copie du pied de page de chiffrement et de la partition de données utilisateur chiffrées, et de renforcer brutalement le la phrase secrète de l'écran de verrouillage ne devrait plus être suffisante pour déchiffrer le contenu du disque.
Ce qui devrait résoudre ce dernier problème.
Je pense que les quatre approches suivantes couvrent plus ou moins toutes les possibilités de ce qui pourrait être fait:
- Utilisez une fonction de dérivation de clé coûteuse (en termes de temps CPU). Cependant, ralentir l'attaquant de quelque manière que ce soit ralentira les attaques légitimes par le même facteur. Et en réalité, l'attaquant pourra utiliser plus de puissance CPU que celle présente sur un seul appareil mobile, et l'attaquant peut probablement attendre plus longtemps une réponse que ce qu'un utilisateur est prêt à attendre lors du déverrouillage de l'appareil. Comme vous l'avez bien compris, cette approche nécessite plus d'entropie qu'un million de phrases de passe possibles différentes pourraient atteindre.
- Utilisez du matériel inviolable. Placez la clé dans un matériel spécialisé qui limitera le nombre de tentatives d'extraction de la clé à un taux spécifié et diminuera ce taux en cas d'échec. Peut-être même en détruisant la clé après un grand nombre de tentatives infructueuses. Cela ne fonctionne que contre un adversaire qui ne peut pas démonter ce matériel et extraire la clé de l'intérieur.
- Utilisez un service en ligne. Si vous avez accès à un service en ligne, ce service pourrait fournir une partie du calcul nécessaire et imposer une limite de taux. Une opération RSA en aveugle pourrait y parvenir sans divulguer aucune information sur la clé ou les données cryptées au service en ligne. Mais pas très pratique, car l'appareil peut ne pas avoir accès à une connexion réseau à chaque fois que vous souhaitez le déverrouiller.
- Utilisez la mémoire quantique. Il s'agit essentiellement d'une variante du matériel inviolable, mais impose la destruction de la clé après un nombre maximum de tentatives en s'appuyant sur la physique quantique. Également peu pratique, car je ne pense pas que quiconque ait réussi à concevoir une mémoire quantique qui puisse contenir des données presque assez longtemps pour l'utiliser pour des données persistantes.
De ce qui précède, le matériel inviolable semble être l'approche la plus pratique.