Android Lollipop rétropédale sur le chiffrement par défaut
Publié par Jacques Cheminat le | Mis à jour le
Le chiffrement par défaut prévu dans Android 5.0 ne serait pas si automatique. Google aurait adapté sa politique en laissant aux fabricants le soin de l'activer ou non pour des questions de performances.
En septembre dernier, en réponse à la politique d'Apple, Google avait indiqué que la prochaine version d'Android (connue à l'époque sous la lettre L) intégrerait le chiffrement par défaut des contenus. Un porte-parole de la firme de Mountain View avait alors expliqué au Wall Street Journal : « pendant 3 ans, nous avons offert le chiffrement avec des clés qui ne sont pas stockées en dehors du terminal. Dans le cadre de la prochaine version d'Android, le chiffrement sera activé par défaut, comme cela vous n'aurez pas besoin de penser à l'allumer ». Une orientation confirmée dans une note de blog datant d'octobre dernier.
Un assouplissement de la règle
Quelques mois plus tard, après l'arrivée d'Android 5.0 (nom de code Lollipop), qu'en est-il de l'implantation de ce chiffrement par défaut ? Nos confères d'Ars Technica ont profité du Mobile World Congress, qui se déroule à Barcelone, pour observer la mise en oeuvre de cette politique auprès des constructeurs de terminaux mobiles. Or, ils ont constaté que les derniers modèles présentés comme le Moto E de seconde génération de Motorola et même le Galaxy S6 ne comprenaient pas l'activation du chiffrement par défaut.
Intrigué, le journaliste du site américain a trouvé la réponse dans un document correspondant à la définition de compatibilité pour Android que Google transmet aux constructeurs. Et ce document comporte un assouplissement dans les exigences du cryptage par défaut. L'exigence se transforme en une recommandation forte et l'obligation est reportée aux « futures versions d'Android ».
Les constructeurs ne sont pas prêts
Pourquoi ce changement de cap ? Pour le site, la réponse est à chercher du côté de la performance des terminaux. Le chiffrement nécessite des calculs importants et donc la mise en place de mémoire spécifique et rapide, comme la flash avec le système de ficher F2FS (Flash Friendly File-System) ou l'UFS 2.0 de 128 Go qui peut atteindre les 350 Mo/s en lecture pour 150 Mo/s en écriture. Or aujourd'hui, les intégrateurs ne sont pas capables de construire des terminaux optimisés pour le cryptage. En assouplissant la règle, Google veut laisser du temps aux constructeurs pour s'adapter et proposer des terminaux capables de gérer correctement le chiffrement par défaut.
Un gain de temps qui fera sans aucun doute le bonheur du FBI et de la NSA qui sont résolument contre le chiffrement des contenus sur les terminaux mobiles. Même le président Barack Obama a mis en garde les géants du web sur cette politique du tout chiffrement : « Si nous trouvons des preuves d'un complot terroriste et qu'en dépit d'un numéro de téléphone, d'une adresse de médias sociaux ou d'une adresse e-mail, nous ne pouvons pas pénétrer leur système, c'est un problème », avait expliqué le président américain.
A lire aussi :
Chiffrement : comment échapper à la curiosité de la NSA
UE : les acteurs IT forcés à livrer les clés de chiffrement ?
Chiffrement des données sur iOS 8 : juste de la poudre aux yeux ?