Chiffrer son smartphone… Ou pas ?

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 !

14 réflexions sur “ Chiffrer son smartphone… Ou pas ? ”

  • 29 février 2016 à 13 h 35 min
    Permalink

    Salute,

    Très intéressant, merci pour le partage. J’ai remonté sur le Journal du hacker.

    Tcho !

    Réponse
  • 5 mars 2016 à 9 h 58 min
    Permalink

    Je trouve que le message véhiculé est dangereux, car sa conclusion tend à généraliser un cas spécifique.

    Les soucis que tu as rencontré, tant au niveau de la fiabilité que des performances, je ne les ai jamais rencontrés. Mais bon, j’utilise la ROM officielle (Sony), pas quelque chose comme Cyanogen. J’ai pu tester avant et après, les différences de performances étaient minimes.

    Ensuite, tu dis n’avoir pas besoin d’un tel niveau de sécurité. Très bien. Mais moi, si, comme probablement pas mal d’autres personnes qui n’ont pas que des films ou de la musique sur leur tablette. Ou qui tiennent à la confidentialité de leurs comptes, messageries ou réseaux sociaux.

    Bref, une annecdote, un retour d’expérience, c’est bien et toujours intéressant, merci pour ça.
    Mais ta conclusion est hâtive et n’avertit pas assez sur les spécificités de ton cas.

    Ceci risque d’induire en erreur bien des non spécialistes.

    Réponse
    • 15 mars 2016 à 10 h 50 min
      Permalink

      Bonjour,

      je ne vois pas en quoi je généralise quoi que ce soit, à part peut-être (mais pour le coup, c’est se fourvoyer que de prétendre le contraire) qu’une technologie quelle qu’elle soit, lâchée avant maturité dans la nature, c’est le fiasco assuré, parce qu’utiliser un truc qu’on ne maîtrise pas totalement, on sait tous ici à quoi ça peut mener.

      Pour le reste : comme précisé dans l’article, je ne parle que des ROMs et recoveries custom. Un travers du Libre, en somme : manque de devs et de matériel, donc certaines choses pas implémentées, ou mal, ou rétro-ingénierie compliquée, tout ça. Tu utilises une ROM stock, c’est ton choix, mais dans la mesure où je prends soin de bien indiquer que je ne parle pas des ROMs stock, je trouve la remarque inutile.
      Tu peux aussi trouver plusieurs tests de ROMs stock sur le net, qui prouvent ces écarts de performance dans ce cas aussi, mais je n’en ai pas parlé, puisque pas testé.

      Ensuite, si je pense avoir trouvé le niveau de confidentialité qui me convient, entre chiffrement de certaines choses, autorisations via le manager de CyanogenMod (basé sur AOSP, rappelons-le) très (voire trop) restrictives pour sécuriser l’accès de telle application à telle donnée… Je n’ai jamais dit que certaines personnes n’en ressentaient pas le besoin. Je pense à titre personnel que « trop c’est trop » et que le pseudonymat que certains recherchent est intrinsèquement biaisé par pas mal de choses, mais celle qui me semble la plus importante à souligner est ton usage d’une ROM officielle Sony. Tu sembles concerné par la sécurité de tes données, tu chiffres ces données, tu penses que tes comptes méritent un coffre-fort numérique… Sans être en total accord avec ça, je peux l’entendre. Mais utiliser la ROM Sony, fournie « telle quelle », c’est démonter ton coffre-fort à la TNT : où est la base, la sécurisation du contexte ? Ça me fait quand même un peu sourire, tout ça… Ériger un château-fort sur un marécage, ça finit par se casser la figure.

      Tout ça pour dire que je ne pense pas que le non-spécialiste se prenne le chou avec de telles problématiques, et que s’il le fait, il est en droit de savoir que c’est parfois incomplet voire foireux. Quant à la conclusion hâtive qui n’avertirait pas assez sur les spécificités de mon cas, je me permets de te renvoyer à la lecture de l’article, qui précise bien que je parle de custom roms/recoveries, de CyanogenMod et TWRP en particulier, et sur un LG G4 seulement. Tout lecteur qui aurait pris son café du matin devrait le voir.
      Je suis très concerné par la confidentialité de certaines de mes données, je suis le premier à recommander le chiffrement et à râler après pas mal de services douteux, mais à un moment donné il faut rester lucide. Je pense, finalement, qu’une CyanogenMod bien configurée est plus sécurisée qu’un Android « made in Google + Sony » chiffré. Voilà voilà…

      Réponse
      • 27 octobre 2016 à 10 h 58 min
        Permalink

        Pas d’accord, ton titre est quand même : « Chiffrer son smartphone… Ou pas ? ».

        J’avais bien vu tes précisions techniques, mais cela n’est pas clairement mis en avant et la conclusion peut prêter à confusion.

        Concernant le débat Cyanogen non chiffré vs Sony chiffré, et bien tout dépend de ton modèle de menace. Si c’est la vie privée, tu as raison. Si c’est le vol, potentiellement ciblé (pas par la NSA non plus), alors rien ne vaut le chiffrement.

        J’ai voulu faire une remarque constructive, désolé que tu l’es un peu mal pris visiblement.

        Réponse
  • 11 avril 2016 à 10 h 41 min
    Permalink

    Petit commentaire car je suis tombé sur votre article parce que justement je songeais à crypter mon Galaxy S4 sous CM13 : le biais de votre test est que CyanogenMod13 est toujours en développement. Actuellement, il est développé sous Nightlies et il n’existe aucune version stable. Une Release 1 est disponible pour plusieurs téléphones depuis peu mais elle n’est pas stable non plus.
    Difficile de juger les bugs d’une ROM qui est en plein développement (voir le JIRA de Cyanogen où les problèmes d’encryptage sont signalés et certains en cours de traitement : https://jira.cyanogenmod.org/browse/YU-3?jql=status%20in%20%28Open%2C%20%22In%20Progress%22%29%20AND%20text%20~%20%22encrypt%22 )

    Réponse
    • 13 avril 2016 à 6 h 22 min
      Permalink

      Les problèmes de chiffrement (« cryptage » est un mot qui n’existe pas en français, pour rappel on chiffre avec une clé, on déchiffre avec une clé, on décrypte un message chiffré si on ne possède pas la clé) que je soulève ne sont pas inhérents à CM13. La baisse de performances n’en est pas un à mon sens, il est normal de la quantifier, c’est tout. Ça va sans doute évoluer et il sera temps de mettre à jour ce test une fois la stable sortie. J’utilise le canal Nightly, aussi à moins d’une réinstallation complète je ne peux pas mettre le « snapshot » (de toutes façons en retard sur les nightlies).

      Donc il ne s’agit pas du tout d’un biais de CM13, puisque les soucis que j’ai rencontrés sont dus :
      – à un bug dans le firmware LG
      – à un manque de support du chiffrement de TWRP (3.0.0-0 donc stable) pour le LG G4 (et beaucoup d’autres) faute de devs impliqués.

      Je ne tape pas ici sur CM que j’utilise au quotidien.
      Pour autant, puisque tout téléphone sous CM dépend, pour une même fonction, à la fois du matériel (là généralement le firmware du fabricant est propriétaire) et du logiciel (CM + TWRP), il convient d’adopter une vision systémique de la chose, et si CM est « bien » dessus, les problèmes peuvent provenir des 2 autres variables…
      Et quand on connait comme moi les (gros) soucis que rencontrent les devs avec les smartphones Samsung (sources foireuses et qui ne correspondent pas aux blobs distribués, refus de publier certains patchs…), je serais toi, je ferai un nandroid avant tout 😉

      Bon courage si tu te lances dans le *chiffrement*, tiens moi au courant 🙂

      Réponse
    • 23 avril 2016 à 11 h 58 min
      Permalink

      Hello,
      j’ai installé cette version de TWRP il y a quelques jours. Elle corrige des bugs relatifs au chiffrement, oui, mais des bugs introduits par la version 3.0.0.1 et absents de la 3.0.0.0 utilisée pendant mon test 😉

      Bon concrètement ils ont quand même mis à jour le support du schéma comme mot de passe de chiffrement sous CM13.0 (et c’est pas rien).

      Le fait que le schéma des partitions ne soit pas supporté, par contre, ni l’accès aux « bonnes » infos de déchiffrement… est hélas lié au matériel, et doc au device tree de chaque smartphone supporté. Il faut donc qu’un dev mette le nez dans chaque modèle, je voudrais m’y pencher pour le G4 mais le temps me manque…

      Les problèmes de chiffrement représentent pourtant une grosse partie des bugs signalés sur le github de TWRP 🙁

      Réponse
  • 23 avril 2016 à 11 h 56 min
    Permalink

    Merci de ta réponse.
    Ce n’était pas une critique, juste une remarque. Et effectivement, j’ai lâché l’affaire suite à ton article.
    Sinon, juste pour info, TWRP vient de passer sous version 3.0.0.2 et corrige des bugs liés au chiffrement: https://twrp.me/site/update/2016/04/05/twrp-3.0.2-0-released.html
    Peut-être à tester, ca pourrait expliquer les soucis que tu as eu.

    Réponse
  • 24 juin 2016 à 14 h 39 min
    Permalink

    Bonjour Maxime, alors là je suis méchamment intéressé par l’article vu que je viens d’acquérir un LG G4 (pour l’instant avec l’Android 6.o d’origine LG) et une carte micro SDCA3 128Gb (90/80Mb). Je veux surtout m’en servir pour m’initier, en photo, au format RAW, et le reste pour les réseaux sociaux (Facebook en tête), avec éventuellement vidéo 4K (jeux vidéos : jamais). Seulement je suis typiquement le genre de personne à paumer régulièrement ses mots de passe hyper-chiadés…

    En fait je souhaite faire du Facebook en mode « Mon identité ok mais les données perso comme ville et boulot niet ». Du coup je ne sais pas si ça reste possible après ta phrase: « 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 ». Et franchement je ne veux pas laisser une seule trace de mes conversations écrites ou perso, ni à mon opérateur ni à qui que ce soit. Et pareils pour mes photos.

    Du coup je suis un peu dans le doute. Tu ferais quoi à ma place ?

    Réponse
    • 29 juin 2016 à 8 h 54 min
      Permalink

      Hello,

      alors, que je relise tout au fur et à mesure 😉

      Qui dit format RAW, options de la caméra, réglages manuels… et 4k (même si ce point est discutable), dit ROM « stock LG ». Bon. Exit Cyanogen et autres outils.

      Ce que je veux dire par la phrase qui attire ton attention : c’est que chiffrer la mémoire interne du téléphone la protège de tout accès externe : on te vole ton téléphone, même en extrayant la puce mémoire, on ne pourra pas la lire à moins de connaître le mot de passe de chiffrement (que tu n’as pas à retenir et encore moins égarer : le matériel s’en charge).
      Par contre ce qu’il faut bien comprendre, c’est que cela n’empêche absolument pas les applications installées d’accéder à la carte mémoire : elles y ont accès au travers d’Android et de son système de permissions. À moins que tu n’autorises pas Facebook à accéder aux fichiers/photos/etc, il pourra lire tout le contenu de la carte (sauf les données privées des autres applications, qui nécessitent des privilèges élevés que tu n’as pas si ton téléphone n’est pas « rooté »). Et si des photos contiennent des informations de localisation, voire des éléments identifiables (un monument par exemple ?), tu ne pourras pas empêcher FB de penser (à tort ou à raison) que ces infos sont exactes.

      Idem pour les communications : chiffrer la mémoire n’empêche pas tes messages SMS/MMS de passer en clair sur le réseau de ton opérateur et de l’opérateur du destinataire. À moins d’utiliser des applications comme Silence, qui chiffrent les SMS/MMS, et à la condition évidemment que le destinataire l’utilise aussi… Tout autre message sera en clair et accessible par l’opérateur (et toute personne physique ou morale, justice incluse, qui se verra autoriser l’accès).

      À ta place, j’opterais pour un « mix » : CyanogenMod dispose d’un système de gestion des permissions bien plus poussé que celui d’Android, ce qui permet éventuellement d’utiliser correctement Facebook et autres sans lui laisser lire la mémoire. Le téléphone chiffré permet de se prémunir contre le vol (physique) de données, le mot de passe « pré-boot » ajoute une sécurité, tout comme l’écran de verrouillage (avec éventuellement Locker, une application libre, qui permet d’effacer la mémoire en cas de tentatives répétées d’accès).
      Après, pour le RAW et tout ce qui s’ensuit… Je ne suis pas un grand expert même si j’aime énormément la photo, il est vrai que Snap (la caméra disponible sous CyanogenMod, bien meilleure que celle de l’Android « normal ») n’est pas aussi performant que l’application photo de LG (de mémoire, il n’y a pas d’autofocus laser par exemple, le pilote n’étant pas libre). À ce compte-là, peut-être qu’un appareil photo « dédié » est une bonne idée (même si c’est plus lourd dans la poche) ?
      Personnellement j’utilise actuellement un Sony DSC-RX100 III dont je suis très content.

      Qu’en penses-tu ? Est-ce un peu plus clair ? 🙂
      Au plaisir de te lire !

      Réponse
  • 29 juin 2016 à 21 h 02 min
    Permalink

    Bonsoir Maxime, merci pour ta réponse très détaillée; maintenant, oui, c’est plus clair pour moi: je pense que je vais rester comme je suis et laisser la parano loin. Parce qu’en fait pour répondre à ta dernière remarque sur l’achat d’un vrai APN, pour le moment je ne peux pas trop financièrement, je mets de l’argent de côté pour ça justement. Du coup ta remarque sur Snap me conforte dans l’idée de rester comme je suis; je n’ai pas vraiment envie de perdre en qualité sur les photos: ça a quand même été pour moi le motif d’achat n°1 pour ce smartphone (outre son côté haut de gamme).

    A la limite, après achat d’un vrai APN je passerai à CyanogenMod et je commencerai à chiffrer; après Android classique, si j’ai bien lu ton article, j’y gagnerai en fluidité (pour le moment c’est déjà le pied total par rapport à mon dernier smartphone). Bref, ça ne presse pas trop pour le moment.

    Tu m’as bien aidé, je te remercie. Longue vie à ton blog.

    Bonne soirée & bonnes vacances 😉

    Réponse
  • 30 juin 2016 à 18 h 50 min
    Permalink

    Bonjour,

    Très bon article intéressant.

    Mais une question m’est venu sur la fin, les deux dernières photos de ton article, je crois bien voir un truc qui te permet de gérer les accès des applications, non? Je rêve de faire ça, comment fait tu?

    Fred.

    Réponse
    • 1 juillet 2016 à 11 h 41 min
      Permalink

      Bonjour,

      il s’agit du gestionnaire de permissions de CyanogenMod. Absent des autres versions « normales » d’Android, il se trouve dans Paramètres > Confidentialité.
      Android 6 dispose d’un mécanisme similaire mais moins poussé, tu peux toujours te rabattre sur ce dernier 😉

      Réponse

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *