Chiffrer son smartphone... Ou pas ?

android 29 févr. 2016

On en entend de plus en plus causer avec ces histoires d’Apple vs. FBI. Autant sur un iDevice, on a (as usual) pas du tout la main dessus, autant sous Android, on a (dans la plupart des cas) le choix de chiffrer ou non.

La question est : est-ce que c’est facile, et est-ce que ça vaut le coup ? Verdict.

 

J’ai donc choisi, pour tester, de chiffrer mon smartphone Android, un LG G4 (donc plutôt haut de gamme, finalement) tournant sous CyanogenMod 13 (Android 6.0.1). « Chiffrer » ça consiste en quoi, déjà ?

 

Un bref point technique

Depuis un petit moment déjà, Google a ajouté un certain nombre de couches de sécurité à Android, pour éviter qu’une personne mal intentionnée et disposant d’un accès physique au smartphone (typiquement, le thug qui vous l’a fauché dans le RER alors que vous rajustiez votre écharpe rouge en cachemire) ne puisse pas vider la mémoire du téléphone comme un gros goret et réutiliser vos numéros et données, utiliser votre compte Snapchat…

Parce que de base, il suffit au voleur de brancher le smartphone à un ordinateur et de tout vider. Un mec un peu connaisseur pourra même utiliser ADB (Android Debug Bridge) pour pomper ce qui n’est normalement pas visible/récupérable. Bref, la France a peur.

 

 

Dans la série « couches de sécurité », on va en retenir 3 ici :

  • l’écran de verrouillage. Code PIN, schéma, FaceUnlock (il déverrouille en vous reconnaissant)… y’en a tout plein. Avec des options cool, genre disposer aléatoirement les chiffres pour entrer le code PIN, ce qui évite que des gens repèrent où vous tapotez à chaque fois par-dessus votre épaule. C’est vraiment la protection de base en cas de vol/perte. Notez que vous pouvez même afficher un message sur cet écran, à distance, voire le verrouiller si ce n’est pas déjà le cas, via le Gestionnaire d’Appareils Android.
  • ADB a été renforcé. Effectivement, depuis Android 4.2, pour pouvoir utiliser ADB, l’ordinateur hôte dispose d’une paire de clés privée/publique, et échange cette clé publique avec le smartphone lorsque l’utilisateur accepte la connexion. Pouvoir refuser cette connexion sous-entend d’avoir mis en place un écran de verrouillage, sinon le voleur à simplement à tapoter sur « oui » lorsque le téléphone demande à autoriser l’ordinateur…
    Retenez quand même qu’ADB peut tout faire ou presque, surtout si le téléphone dispose d’un accès root (genre de mode Dieu où le super-administrateur est accessible) : installer/désinstaller une appli, transférer des fichiers…
  • le chiffrement du téléphone. Google appelle ça FDE, pour Full Disk Encryption. La partition de la mémoire interne qui contient les applications et données est chiffrée, donc inaccessible sans la clé de (dé)chiffrement. Là encore, un smartphone chiffré mais sans écran de verrouillage, c’est pas super super utile…

 

À propos du chiffrement, donc. Elle est disponible depuis Android 3.0 « Honeycomb » et n’a, finalement, que peu évolué jusqu’à Android 4.4. C’est du classique, DM-Crypt, une clé aléatoire AES-CBC de 128 bits, stockée dans /data/misc/vold et protégée par mot de passe (celui de l’écran de verrouillage, obligatoire). C’est pas topissime, mais mieux que rien. Pour les connaisseurs, ça suit un peu le même mécanisme que LUKS, et les paramètres pour déchiffrer sont stockées dans un « crypto footer ».

Depuis Android 4.4, de grosses améliorations ont été apportées à ce mécanisme. Android 4.4 remplace en particulier la fonction qui génère la clé, PBKDF2, par scrypt, plus résistante à certaines attaques par force brute. Depuis Android 5, le mécanisme a encore évolué, et un écran de verrouillage n’est plus requis pour pouvoir chiffrer le téléphone (c’est un choix discutable), ce qui laisse supposer que le mot de passe de la clé n’est plus dérivé de celui du lockscreen. Sur la quasi-totalité des smartphone récents et basés sur un SoC Qualcomm (les seuls smartphones valables, donc), Android utilise Qualcomm Secure Execution Environment pour stocker la clé et tout son bazar dans une puce matérielle. Cette fonctionnalité était désactivée initialement, mais a été mise en fonction par la suite. Plus d’infos sur la FDE.

 

Chiffrer, c’est compliqué ?

Réponse simplissime : non. Un malheureux menu dans les paramètres de sécurité, avec un avertissement clair et explicite comme quoi une fois chiffré, pas de retour en arrière possible sans effacer le contenu du téléphone. Idem si vous perdez/oubliez le mot de passe.

 

Screenshot_20160229-120118

 

Vous allez avoir droit à 20-25min de chiffrement, le téléphone redémarre, et basta.

En activant tous les paramètres, vous pouvez même avoir des options sympa, type mot de passe au démarrage (pre-boot password). Après ça, vous êtes tranquilles, a priori ! :mrgreen:

Vous pouvez également coupler le chiffrement avec SmartLock pour l’écran de verrouillage : pas de verrouillage si vous êtes à tel endroit, ou tenez votre smartphone dans la main, ou si votre montre connectée est à portée… Tout plein d’options marrantes à essayer !

 

Chiffrer… le revers de la médaille

Pas besoin d’être grand gourou de l’informatique pour deviner que si tout est (dé)chiffré à la volée, ça risque de ralentir le téléphone. Et j’ai senti la différence sur un G4. Je n’ose pas vraiment imaginer sur du bas de gamme. Après, c’est aussi parce que j’ai un référentiel, CM13, qui est réellement bien plus fluide que l’Android d’origine LG. Du coup, en retombant à une fluidité « dans la moyenne », je me suis senti brimé, alors que cela n’a pas choqué d’autres gens autour de moi. Passer d’une fusée à une Ferrari, c’est nul, mais la Ferrari reste mieux que le Renault Scénic. Sans possibilité de comparaison (genre iPhone, qui est nécessairement chiffré), dur de dire que ça se traîne ou non, à part un ressenti personnel donc subjectif.

D’après mes mesures en lecture/écriture, avec stockage matériel via le SoC Qualcomm, je perds 35% sur les temps d’accès. Et le double avec un chiffrement matériel. Ça pique un peu.

 

Autre « petit souci » pourtant de taille. Je le disais au-dessus, un écran de verrouillage n’est plus obligatoire, ce qui laissait à penser que le mot de passe de la clé ne dépendait plus du PIN ou schéma de l’utilisateur. C’est partiellement vrai : si lockscreen il y a, le mot de passe choisi sera utilisé pour protéger la clé. C’est s’il n’y a pas d’écran de verrouillage que le bât blesse : dans ce cas, le mot de passe est… « default_password » . Si si.

 

cm_void

 

Enfin, les bugs. Ça arrive, me direz-vous. Mais là, c’est critique, on parle d’un espace de stockage entièrement verrouillé…
En l’occurrence, après chiffrement, pas de soucis. C’est après le premier redémarrage que le souci s’est montré. Les deux soucis, en fait :

  1. un bug dans le firmware LG. Il semblerait qu’à chaque démarrage, après le pre-boot password, le système vérifie la partition cryptfs, qui stocke les paramètres. Résultat (sans l’explication, malheureusement) : l’écran de verrouillage est indéverrouillable. Il ne reconnaît plus le mot de passe. Là, ça commençait à puer sévère…
  2. TWRP (le petit logiciel de maintenance/récupération que j’utilise) ne supporte pas le chiffrement. Il n’y a qu’un seul développeur sur le coup, et en plus il n’a pas de LG G4, autant dire qu’il n’est pas prêt de régler le souci. Bref, TWRP n’est pas capable de lire mes données, et donc encore moins de les exporter.

 

Et c’est là que tout s’emmêle. À trop vouloir sécuriser… On se bloque. Je me suis dit que j’allais utiliser ADB pour « pomper » les données sur l’ordinateur. Sauf que si ADB est bien autorisé pour mon PC, il ne se lance pas au démarrage du smartphone, question de sécurité là encore. Impossible de le lancer manuellement, vu qu’écran de verrouillage foireux. Impossible de programmer le lancement, puisque CyanogenMod écrase ce genre de modifications hasardeuses. Je me suis dit qu’avec un peu de chance, le recovery de CyanogenMod me permettrait de déchiffrer mes données, ou au moins d’avoir un shell pour pouvoir changer le mot de passe de l’écran de verrouillage à la volée et déverrouiller le téléphone ne serait-ce qu’une fois (ça suffisait). Sauf que ma version d’ADB n’est pas à jour (1.0.31 contre 1.0.32), et que si je fais la mise à jour, je me fais rembarrer pour cause d’empreinte de clé non autorisée. SUPER.

 

Sans déconner, j’y ai passé 2 jours / 1 nuit, et j’ai fini par renoncer. Formatage complet, réinstallation de CyanogenMod 13.

 

Moralité…

Sécuriser un peu votre Android, je dis oui. Couper le root si possible, ajuster les autorisations, couper ADB si pas besoin, mettre un écran de verrouillage, c’est important.

Chiffrer toute la partition /data, c’est autre chose. Si dans la théorie tout est prêt et fonctionne a priori très bien avec les firmwares officiels, ce n’est pas le cas des ROMs et recoveries « custom » où tout n’est pas au point, faute de temps/développeurs. Ceci étant dit, si le souci que j’ai rencontré se limite au LG G4, les autres sont à l’abri. Peut-être que LG a corrigé le tir depuis, à voir si je trouve le temps et la motivation pour flasher un KDZ d’origine pour tester…

 

Mais cela me conforte dans mon idée que tout chiffrer à tour de bras sans réfléchir est stupide et contre-productif. Soucis et lenteurs au rendez-vous. Et puis bon : chiffrer une carte mémoire, oui, mais si c’est pour laisser Facebook, Instagram, Twitter… accéder au contenu quand même, je ne saisis pas bien l’intérêt de la chose. Sauf à vivre en ermite à ongles longs, c’est de la paranoïa en mode « l’hiver vient ». Le voleur du coin de la rue ne va pas s’amuser à démonter l’EMMC et à la souder sur un autre SoC juste pour voir vos photos de vacances…

 

 

Notez que dans le même esprit, vous pouvez chiffrer un support amovible (carte SD, clé USB…) depuis le smartphone pour qu’il soit le seul à pouvoir le lire. Android 6 vous le propose à l’insertion ou via les paramètres de stockage ! 🙂

 

N’hésitez pas à partager vos expériences dans les commentaires !

Mots clés