Les journaux ont beaucoup médiatisé l’affaire du FBI voulant forcer Apple a créer un outil déverrouillant facilement les iPhone 5. Mais qu’en est-il de la sécurité des appareils Android ?
Je vois 3 cas de figure :
1
L’appareil n’a pas de partition /data chiffrée. Pas de challenge. Le FBI peut tout lire sans souci en branchant l’appareil à un port USB d’un ordinateur. C’est le cas par défaut des appareil sous Android < 6.0 (95% des appareils actifs aujourd’hui)
2
Si l’appareil a les GoogleApps installés (pour faire simple, si l’application GooglePlayStore est installée) et qu’il est connecté à Internet, le FBI a juste à demander à Google de réinitialiser le mot de passe ou d’installer en douce l’application du FBI qui leur permettrait de rentrer de contrôler le téléphone a distance avec les droits root. Le chiffrement de la partition /data est inutile contre cette attaque.
En effet, à travers les GoogleApps, Google a les droits root sur votre appareil. Et par l’application GooglePlay Services, il entretient une communication constante avec votre appareil. Ce privilège permanent de Google sur plus d’un milliard d’appareil personnel est alarmant mais peu s’en préoccupent.
Google a déjà par le passé fait usage de cette position privilégiée pour supprimer et installer des applications sur votre appareil sans votre consentement ni notification.
Avant de vous plaindre, sachez que c’est écrit dans les conditions d’usage du PlayStore (vous savez les conditions que vous passez quand vous démarrez la première fois votre appareil tout neuf et qu’il faut un compte Google pour l’utiliser….)
2.4 From time to time, Google may discover a Product on Google Play that violates the Developer Distribution Agreement or other legal agreements, laws, regulations or policies. You agree that in such an instance Google retains the right to remotely remove those applications from your Device at its sole discretion.
L’utilisateur profite également de ce super pouvoir de Google pour installer des application depuis un autre appareil en utilisant simplement l’interface web du PlayStore (vous croyiez que c’était magique?) ou remplacer les applications (mise à jour) sans notification.
Google peut réinitialiser le mot de passe de verrouillage de l’appareil. Et permet également à l’utilisateur de le faire depuis l’interface web de son compte Google.
Google peut également effacer la mémoire du téléphone à distance. Si un pirate trouve le kill switch et qu’il le lance sur le petit milliard d’appareil, on va rigoler :D
Si l’appareil est éteint, il suffit de lui mettre une carte SIM 3G sans PIN et les GoogleApps vont se connecter automatiquement aux serveurs de Google au démarrage.
Je pense qu’on rentre là dans les 99% des cas.
3
Dans les 0.001% restant de geeks n’ayant pas les GoogleApps installés et une partition chiffrée, il faudrait, sauf exploitation d’une vulnérabilité, casser le chiffrement de la partition /data.
Sur Android pré-4.4, PBKDF2 est utilisé pour dériver la clé de chiffrement à partir du mot de passe utilisateur. Le nombre d’itération étant fixé 2000. On peut retrouver facilement le mot de passe utilsateur avec des GPU :
Even when run on the GPU of a mobile computer (NVIDIA GeForce 730M), hashcat can achieve more than 20,000 PBKDF2 hashes per second, and recovering a 6 digit PIN takes less than 10 seconds. On the same hardware, a 6-letter (lowercase only) password takes about 4 hours.
Sur Android 4.4 et suivant, scrypt est utilisé. Il est plus résistant aux attaques par GPU et FPGA.
Sur Android 6, une clé de chiffrement inscrite en dur dans une puce matérielle de l’appareil peut intervenir dans la génération de la clé, ce qui complique la recherche de mot de passe depuis un autre appareil. Ceci présuppose toutefois qu’il n’y ait pas de faille dans la puce matérielle et que le fabricant n’ait pas de backdoor pour le FBI ou une copie de la clé de chiffrement… (d’où l’intérêt de la NSA d’aller fouiller chez GEMALTO pour récupérer les clés de chiffrement contenues dans les cartes SIM. Qu’en est il de Qualcomm?)
Dans ce cas, ça me parait très similaire à la technique utilisée par Apple dans ses Iphone avec iOS 9.
Note au passage :
PBKDF2 est aussi utilisé pour le chiffrement de disque sous GNU/Linux avec LUKS. Cependant le nombre d’itérations est prévu pour prendre 2 secondes sur votre machine. (1 sec si cryptsetup < 1.7)
Il y a un rapport de bug pour passer à une fonction plus resistante aux GPU ouvert depuis 2012. Le projet répond à sa manière à cette critique :
There is some discussion that a hash-function should have a « large memory » property, i.e. that it should require a lot of memory to be computed. This serves to prevent attacks using special programmable circuits, like FPGAs, and attacks using graphics cards. PBKDF2 does not need a lot of memory and is vulnerable to these attacks. However, the publication usually referred in these discussions is not very convincing in proving that the presented hash really is « large memory » (that may change, email the FAQ maintainer when it does) and it is of limited usefulness anyways. Attackers that use clusters of normal PCs will not be affected at all by a « large memory » property. For example the US Secret Service is known to use the off-hour time of all the office PCs of the Treasury for password breaking. The Treasury has about 110’000 employees. Assuming every one has an office PC, that is significant computing power, all of it with plenty of memory for computing « large memory » hashes. Bot-net operators also have all the memory they want.
Ping Google remote control – Tuxicoman