Le chiffrement Android est vulnérable et Google n'est pas à blâmer

Le seul sujet de critique que Android n’a jamais pu éviter malgré les efforts constants de Google doit être la sécurité et l’intégrité des données des utilisateurs. Les menaces ont toujours réussi à s’introduire dans le système d’exploitation mobile le plus populaire, impactant, par conséquent, la vie privée à une échelle extrêmement large. Que ce soit Hummingbird installant des applications trompeuses sur plus de 10 millions d’appareils ou Stagefright relâchant le contrôle sur des fichiers personnels, les solutions temporaires se sont toujours effondrées horriblement à long terme.

Il existe actuellement plusieurs façons dont Google s’assure que les appareils Android restent sécurisés : des correctifs mensuels par voie aérienne et une politique de chiffrement complet du disque pour les OEM. L’implémentation, cependant, pour ce dernier dépend du fabricant de matériel. Google a conçu plusieurs couches de chiffrement pour empêcher tout accès non autorisé, bien que les algorithmes ne soient pas vraiment robustes en raison du problème immense de fragmentation et donc, même une seule responsabilité ou faute peut tout divulguer.

Comment fonctionne le chiffrement Android

Le chiffrement Android est basé sur un noyau Linux bien établi (noyau central d’un système particulier), dont les détails ne sont pas nécessaires pour comprendre cela. En résumé, chaque appareil spécifique crée une clé maître unique et aléatoire de 128 bits qui est généralement appelée Clé de Chiffrement de Dispositif (DEK) et utilisée pour dissimuler les données utilisateur. Le smartphone crée également un sel supplémentaire de 128 bits qui, avec tout code PIN ou mot de passe activé par l’utilisateur – Clé de Dérivation de Clé (KEK), est utilisé pour chiffrer la DEK elle-même. Enfin, la DEK est stockée dans un espace mémoire non chiffré (intitulé “ pied de crypto ”) sur le téléphone. Pour déchiffrer le système de fichiers à des fins administratives, l’ensemble du processus est essentiellement inversé.

Cependant, il existe un autre champ privé qui est lié au matériel de chaque appareil. La dérivation de clé et le déchiffrement impliquent la valeur susmentionnée signant le KEK qui est ensuite utilisé pour décoder la DEK. Ce processus est effectué par un module séparé intégré dans Android, appelé KeyMaster. Le but principal de la mise en œuvre d’un module dédié pour le déchiffrement et de ne pas remettre les clés directement aux applications est assez évident. Une autre chose dont vous devez être conscient est l’Environnement d’Exécution de Confiance – TEE qui retient le programme KeyMaster.

Alors, quel est le problème ?

Apprendre sur le processus de chiffrement dit quelque chose sur la façon dont Google a essayé de faire sa part pour éloigner les vulnérabilités d’Android. Malheureusement, la clé générée par le matériel dépend de la façon dont les OEM la structurent. Un chercheur en sécurité a récemment tenté d’accéder à des fichiers Android privés et, étonnamment, a réussi à révéler un énorme défaut dans le système. Il a déclaré que la fonction de dérivation de clé qui est essentiellement utilisée pour signer le KEK n’est pas vraiment liée au matériel comme prévu. Il a en fait pu générer la clé à partir du logiciel de TrustZone sans aucun problème. Ainsi, même un petit trou dans le noyau ou le module KeyMaster peut entraîner un désastre complet pour l’utilisateur.

Le chercheur a trouvé un petit morceau d’espace non protégé dans le code du noyau et sans aucune défaillance du système, a écrasé la zone avec une fonction personnalisée pour fuir les clés du KeyMaster. Cela nécessite que le pirate obtienne physiquement l’appareil d’une personne, bien que ce soit un contournement technique troublant qui nécessite une attention immédiate de Google. Le problème peut être partiellement corrigé avec des correctifs de sécurité réguliers, mais quel pourcentage de distributions suit réellement les téléphones Nexus de Google ? De plus, le chercheur a mentionné que cette faille peut éventuellement être étendue à l’accès sans fil si l’utilisateur visite une application ou un site Web non sécurisé, même par accident. Comme la plus grande partie de la part de marché d’Android n’inclut pas les téléphones Nexus, ce type de vulnérabilités impacte un nombre énorme d’utilisateurs.

La seule solution qui reste ici est une refonte matérielle et une obligation pour les OEM de déployer des correctifs mis à jour chaque mois. Les téléphones phares reçoivent de nos jours ces correctifs, bien que ce soit une part étonnamment petite d’appareils. Étant donné certains événements récents, les fabricants doivent absolument aborder ces préoccupations en matière de confidentialité pour chaque téléphone, sinon de sévères malwares continueront à impacter l’ensemble de l’espace Android, ce qui pourrait finalement entraîner de graves violations de l’intégrité des données. Les clients doivent également comprendre les conséquences et, autant que possible, éviter de désactiver les vérifications de sécurité dans les paramètres et les smartphones Android qui ne reçoivent pas de mises à jour du tout.