Android 6.0 : le chiffrement intégral obligatoire sur les appareils assez puissants
On prend (presque) les mêmes et on recommence
Le 21 octobre 2015 à 06h31
4 min
Société numérique
Société
Avec Android 6.0, Google rend obligatoire le chiffrement intégral du stockage sur les nouveaux appareils qui en sont capables. Pour le constructeur, cela signifie tout terminal délivrant une puissance suffisante, afin que l’activation du processus ne provoque pas de ralentissement perceptible par l’utilisateur.
Quand Android 5.0 est sorti, le chiffrement intégral du stockage était déjà sur la table. On se rappelle d’ailleurs qu’entre l’annonce de Google et le renforcement du chiffrement dans iOS 8, le directeur du FBI, James Comey, s’était largement ému de ce virage : « Ce qui m’ennuie avec tout ceci est que des entreprises fassent expressément la promotion de quelque chose qui permettra aux gens de se placer hors de portée de la loi ». Depuis, le chemin s’est dégagé, la Maison Blanche ayant officiellement renoncé à affaiblir le chiffrement.
Chiffrement par défaut pour les nouveaux appareils s'ils ont assez de puissance
On ne sait pas si cette décision a joué, mais Google revient à la charge sur le chiffrement intégral des données dans la dernière version de son document « Compatibility Definition », daté du 16 octobre, et à destination des constructeurs équipant leurs terminaux du système mobile. Page 64, on trouve un chapitre particulièrement intéressant : si un appareil est capable de réaliser du chiffrement AES d’au moins 128 bits au rythme de 50 Mio/s (mébioctets par seconde), le chiffrement intégral doit obligatoirement être activé.
Plusieurs points sont à souligner. D’une part, cela ne concerne que les nouveaux appareils qui seront directement commercialisés avec Android 6.0. Pour rappel, le Nexus 6 lancé l’année dernière possédait bien un chiffrement activé par défaut. Il est donc logique de penser que les nouveaux modèles 5X et 6P l’ont eux aussi. D’autre part, la précision de performances minimales renvoie au demi-tour fait par Google sur Android 5.0, quand la puissance de calcul est devenu un problème réel. Le chiffrement de toutes les données en continu est en effet une opération gourmande, et certains appareils montraient clairement leurs limites, comme le montraient en mars dernier des tests réalisés par AnandTech et Ars Technica. Enfin, par chiffrement intégral, Google entend plus précisément les dossiers /data et /sdcard, tous ceux concentrant les données de l’utilisateur.
Personne ne doit posséder la clé de chiffrement
Enfin, et c’est un point crucial, le document précise bien que la clé de chiffrement ne doit jamais être donnée à l’utilisateur. Elle sera liée au mécanisme de déverrouillage de l’appareil et elle-même chiffrée via AES par un algorithme de « slow stretching » tel que PBKDF2 (pour rendre le mot de passe ou la séquence plus résistante aux attaques par force brute). En d’autres termes, si l’utilisateur a un trou de mémoire, la seule solution sera une réinitialisation complète de son appareil et donc la perte des données qui y seront stockées (si elles n’ont pas été sauvegardées ailleurs évidemment).
Les acheteurs de ces nouveaux portables ont donc intérêt à être informés des « risques ». Quant à ceux qui ont déjà un smartphone puissant, la question mérite d’être posée. Le chiffrement intégral permet de protéger efficacement les données en cas de perte ou de vol de l’appareil. Reste à voir si son activation provoque une chute visible des performances et/ou si cette sécurité supplémentaire vaut le risque de pertes des données en cas d’oubli du code de déverrouillage, quel qu’il soit.
On signalera quand même que si cette décision est importante, elle ne change rien pour l'écrasante majorité des smartphones actuellement en circulation. Il s'agit d'un souci récurrent sur le parc Android, comme on a pu le voir avec les failles Stagefright.
Android 6.0 : le chiffrement intégral obligatoire sur les appareils assez puissants
-
Chiffrement par défaut pour les nouveaux appareils s'ils ont assez de puissance
-
Personne ne doit posséder la clé de chiffrement
Commentaires (87)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 21/10/2015 à 13h52
Je trouve consternant que sur Next Inpact, depuis quelques temps, on ne peut plus avoir d’opinion sans avoir quelqu’un qui, d’un ton condescendant, s’en moque et dise que c’est débile. Le simple fait de souligner que l’on ne fait plus confiance à telle chose ou que l’on pense quelque chose, et ça y est, des hordes s’abattent sur toi pour te montrer que ce que tu dis, c’est débile !
On peut très bien ne plus avoir confiance en Google et utiliser Android tout de même, et j’imagine que c’est le cas pour pas mal de gens. Mais bien entendu y’a quelqu’un pour dire que c’est débile. Mais quel choix a t’on ? Apple ? Tizen ? BlackBerry ? Des projets à moitié finis ?
Pour ma part j’utilise Cyanogenmod, qui reste la solution la moins pire de l’univers Android, sur un OnePlus One. J’ai installé les pico GApps pour avoir uniquement le Play Store, afin de pouvoir utiliser quelques applications achetées auparavant. Malgré tout, cela installe les services Google Play, plus de 300 services qui tournent en permanence sur le téléphone, et je n’aime pas ça, et en plus ça me bouffe la batterie.
Oui on ne peut pas avoir confiance dans les pilotes propriétaires du matériel de son téléphone, oui les applications ont accès aux données non chiffrées, merci de ne rien m’apprendre. Et donc ? Je fais quoi avec ça ? Je m’isole dans une grotte ? J’utilise un 3310 ? Ah les belles remarques ! Merci pour votre sagesse.
Franchement j’ai même plus envie de commenter sur Next Inpact tellement c’est systématique cet acharnement contre ceux qui osent partager leur avis ou posent des questions légitimes. Qu’il est loin l’esprit PCI. Alors qu’il serait tellement plus convivial de partager cordialement son avis sans descendre celui d’un autre.
Le 21/10/2015 à 14h10
Le pb est pas tant ton manque de confiance pour tel ou tel solution. J’ai pas “confiance” en eu non plus. le pb est de croire que parce que tu as pas les app google tu risque rien de la part de google en ayant un android.
Je n’ai pas d’android, je suis chez la pomme, je me dis pas “oulala j’espère qu’ils revendent pas mes info à la NSA”. Je me dis ben aujourd’hui si je veut etre sur que la NSA n’ai pas mes info ou tout du moins n’ai pas la possibilité d’avoir mes info bah soit j’ai un 3310 soit je met pas mes info dans mon tel…
Quand a Cyanogenmod les dernier écho que j’ai eut, depuis 1⁄2 ans sont très loin d’etre bon et assez loin de ce que c’était à la base mais je me suis pas penché plus que cela sur la question…
Le 21/10/2015 à 14h23
Si je n’ai aucune application Google d’installée sur mon Cyanogenmod, je ne vois pas trop ce que je peux craindre de Google. Je sais par contre pertinemment que je ne suis pas à l’abri de l’espionnage et de la fuite de données personnelles, et n’ai jamais affirmé le contraire.
Quand à Cyanogenmod, tu confonds peut être avec Cyanogen OS, l’OS commercial de la société Cyanogen. Cyanogenmod est open source et fourni sans aucune application Google de base.
Beaucoup de matériels n’ont pas de pilote open source, donc bien souvent dans les distributions dédiées à un appareil particulier on inclut des blobs propriétaires dont on peut se questionner sur ce qu’ils font réellement. C’est cela, ou par exemple accepter de ne plus avoir de wifi.
Les opérateurs de téléphonie sont également autant d’yeux tournés vers votre appareil.
Le fait est, que l’on ne peut pas y faire grand chose dès lors que l’on possède un smartphone. La confiance est perdue, mais l’usage quasi-obligatoire.
Le 21/10/2015 à 15h26
Le 21/10/2015 à 15h44
Curieuse image d’illustration, en anglais le terme safety ne désigne pas la sécurité au sens ou on l’entend, et encore moins la sécurité informatique… :)
Le 21/10/2015 à 16h08
Le constructeur doit activer le chiffrement par défaut, mais est-ce que l’utilisateur final a l’option pour le désactiver ?
Au pire, peut-il faire un factory reste et désactiver le chiffrement ?
Merci.
Le 21/10/2015 à 16h09
Le 21/10/2015 à 16h13
C.f lien que j’ai donné dans le post juste avant.
ici
" />
Le 21/10/2015 à 19h07
Ca veut dire qu’on ne pourra pas récupérer nos photos en copiant sur carte sd ?
Le 21/10/2015 à 19h18
Personne ne doit posséder la clé de chiffrement (..) le document précise bien que la clé de chiffrement ne doit jamais être donnée à l’utilisateur
Ok, l utilisateur n a pas la clef, mais est elle stockée qque part chez Google?
Si oui, le “Personne” est trompeur!
En comparaison, chez MS, un ordi ou tablette entièrement crypté sous BitLocker a une clef qu on peut récuperer sur son compte MS. Par contre, c est pas encore possible sous WP8.
Mais comme dit plus haut, le chiffrage ne protège que du vol physique, en aucun cas d un piratage ou action NSA like…
Le 21/10/2015 à 22h58
Google n’a pas la clé vu qu’elle est stockée chiffrée (AES) sur le téléphone à l’aide du mot de passe de déverrouillage. Quand bien même Google aurait la clé chiffrée que ça ne lui servirait pas à grand chose non plus.
Le 22/10/2015 à 07h03
J’ai un peu de mal à croire qu’une fois que le téléphone est locké, le déchiffrement est impossible. Sous Android, les applications peuvent lancer des services, qui peuvent effectuer un traitement quand le téléphone est locké, soit périodiquement (timer) soit en fonction d’un événement (réception d’un SMS de ta belle-mère). Ce serait étonnant que ces applications soient tout-à-coup bannies.
Le 22/10/2015 à 07h34
Alors c’est moi qui me plante " />
Mais en effet, ça serait le meilleur scénario … le souci restant toutes les taches de fond.
Le 22/10/2015 à 07h50
On va dire que… peut-être … une appli lancée continue à pouvoir accéder au contenu, mais qu’il n’est pas possible de lancer une nouvelle appli.
Enfin, tout ça pour dire qu’on ne sait pas le fin mot de l’histoire en fait. " />
Le 21/10/2015 à 09h26
Le 21/10/2015 à 09h28
Les données sont chiffrés sur la mêmoire et sur la carte SD.
Il n’y a qu’en ram qu’il y a des données déchiffrés. Donc si on te vole ton tél et qu’il est locké, alors tout ce que peut récupérer un voleur c’est les données “actuellement en RAM” (et en téhorie la clé de déchiffrement ne devrait pas rester en RAM " />)
SI c’est bien fait, tant qu’il est délocké la clé de déchiffrement est en ram, et dés qu’il se lock la clé est vidée, en attente du prochaine délockage.
Le 21/10/2015 à 09h28
Le 21/10/2015 à 09h28
Bah il dis pas qu’il y a mieu! il dis juste que c’est débile de dire : “ je n’ai pas confiance en google” puis de dire “ j’ai un android”
Si on a pas confiance en google ben on prend pas google!^^ sur ebay il y a des 3310 " />
Après pour moi les gens ne serons jamais content… Google ne chiffre pas, c’est pour facilité le taff de la nsa.
Google chiffre, oui mais ils vont donné les clé à la nsa…
Du coup google dois faire quoi? " />
Le 21/10/2015 à 09h30
Sans vouloir trop m’avancer sur le mécanisme que je ne connais pas, il semble très improbable que les données soient déchiffrée au déverrouillage du téléphone.
En pratique, il doit y avoir un mécanisme qui ‘reconstitue’ la clé à partir de ton code de déverrouillage, et cette clé est utilisée pour chiffrer/déchiffer à la volée les données que tu lis/écrit. Donc sur la carte SD, tout est chiffré, tout le temps.
Par contre, si tu te fais voler ton téléphone déverrouillé, le voleur peut accéder aux données chiffrées via le téléphone, à condition qu’il ne le laisse jamais se reverrouiller. Même s’il sort la carte SD à chaud, il ne pourra pas l’utiliser ailleurs.
#overgrillé
Le 21/10/2015 à 09h31
Le 21/10/2015 à 09h33
En théorie, avec une partie dédiée dans le CPU, l’iNPact n’est pas violent. Mais en effet, ça coûte quand même…
Le 21/10/2015 à 09h37
Il aurait été judicieux de donner quelques pré-requis hardware pour se faire une idée de quels smartphone deja commercialisés sont compatibles. Dommage que Google ne le fasse pas même si une puissance équivalente à un N6 donne plus ou moins une idée.
Le 21/10/2015 à 09h42
Le souci c’est que ça ne dépend pas de la “puissance brute”, mais de la présence d’une partie de chiffrement/déchiffrement dans le SOC.
Tu peux avoir des CPU bas de gamme qui auront la puissance suffisante quand un processeur haut de gamme de génération précédente en sera incapable.
Le 21/10/2015 à 09h43
Il a peut-être une ROM AOSP sans les GApps hein.
Le 21/10/2015 à 09h43
Le 21/10/2015 à 09h45
Les GApps ne sont pas les seuls apport de google à android hein.
Le 21/10/2015 à 09h48
C’est quand même magique : on crypte tout, ça fait bien pour le client… il suffit d’une faille de l’OS pour accéder au données…
Le 21/10/2015 à 09h50
La contribution au code ok peut-être mais une ROM AOSP ne communique pas avec Google, c’est ce que je voulais dire vu que c’est le sujet de la conversation.
Le 21/10/2015 à 09h53
C’est toujours mieux que rien! ;)
Le 21/10/2015 à 10h22
Le 21/10/2015 à 08h45
Attend, d’un coté on me dit que la NSA a tout pouvoir ils installent des backdoor partout, et de l’autre, il faut que ça soit Google qui upload ta clé ?
Ils l’envoient en zip par mail toutes les clés de chiffrement à la NSA ? " />
Le 21/10/2015 à 08h55
Je ne suis pas certain que ta question soit pertinente. A partir du moment où tu installes quelque chose sur ton téléphone qui a accès à tes données (dont les Google services), il faut que tu lui fasses confiance. Le chiffrement n’y change rien, ni en bien, ni en mal.
Dit autrement, si les Google services ne sont pas dignes de confiance, qu’ils transmettent la clé de chiffrement ou directement les données, pour toi, c’est du pareil au même. Le chiffrement ne te protègerait pas des états pour lesquels Google travaillerait, mais serait toujours bon à prendre contre les voleurs à la tire.
Si tu veux te protéger de façon fiable contre les états, il faut que tu utilise uniquement des composants sur lesquels tu as un contrôle ou une confiance totale, aussi bien hardware que software (bon courage!)
Le 21/10/2015 à 08h58
Le 21/10/2015 à 08h59
Je n’ai juste plus confiance en cette entreprise au vu de tout ce qu’elle récupère sur ses utilisateurs. D’ailleurs lors du flash de ma prochaine rom je n’installerai plus les Google Apps dans mon téléphone, j’ai trouvé des alternatives à la plupart de mes applications disponibles sur Google Play.
Dites-vous bien que si ça a été autorisé par le gouvernement US, c’est qu’ils ont les moyens de passer outre le chiffrage.
Après, en cas de vol, le chiffrage des données est bienvenu, c’est clairement une avancée. Si c’est pour ne pas se faire espionner par les gouvernements par contre, là ça me fait rigoler.
Le 21/10/2015 à 09h00
Oui tu as raison, c’est plus ou moins ce que je dis dans mon précédent message. :-)
Le 21/10/2015 à 09h07
Le 21/10/2015 à 09h13
Le cas de l’OHA est un cas particulier. Ils ont le droit de forker, (et ne s’en privent pas), mais doivent juste assurer la compatibilité pour avoir le droit de dire que leur OS est un Android.
Et dieu sait que Samsung ne s’en est pas privé pour le support du stylet ou du capteur d’empreinte (en faisant de la merde, mais bon, c’est Samsung)
Les OEM font ce qu’ils veulent, mais si tu ne fais pas un OS compatible avec l’OHA, tu sors de l’OHA, c’est tout.
Tout comme Linux est projet Libre et Open Source, mais pour pouvoir se nomer “POSIX” il y a une norme.
AOSP est à 100% Open Source. OHA est un club fermé avec des régles. C’est si compliqué ? " />
Le 21/10/2015 à 09h14
Alors retire ta puce radio aussi parce que tu n’as aucune raison de faire confiance à Qualcomm (ou autre) non plus.
Le 21/10/2015 à 09h15
Le 21/10/2015 à 09h16
" />
plus confiance en Google mais a quand même un smartphone Android même si c’est une ROM venant de x ou y, il reste toujours des petites choses de Google donc …
Le 21/10/2015 à 09h18
Tu as mieux ? Un OS complémentent libre de tout code fermé dont on ne peut pas avoir confiance ?
Le 21/10/2015 à 09h21
Doucement!^^ il ne disait pas ce que lui pense mais plutôt se moquais de ce que dis JCD… ^^
Le 21/10/2015 à 09h22
Je plussoie .
Ils voulaient juste l’accès à la porte de la bonne ;)
Le 21/10/2015 à 09h22
non et il n’y a pas en stock, puis comme tu as dit dans un autre commentaire il faut aussi voir pour la puce radio la puce truc la puce chose …. tout le smartphone quoi " />
Mais bon le coup de dire j’ai plus confiance en X et avoir un OS de X à la base …
Le 21/10/2015 à 09h24
Et ? Parce que c’est rigolo, rigolo de se moquer, mais est ce qu’il a mieux ? C’est une vraie question … Est ce qu’on peut faire confiance en Firefox OS qui est lié aux mêmes contraintes que Google niveau NSA ? Tizen ? …
Le 21/10/2015 à 09h24
Le 21/10/2015 à 10h26
Plasma Mobile " />
Bon ok, c’est pas encore au point. Et dans tous les cas, il restera la composante matérielle qui restera toujours difficile à maitriser.
Le 21/10/2015 à 10h27
Le 21/10/2015 à 10h28
Pour les appareils ne disposant pas de puce dédiée pour le traitement de AES oui le proco doit faire ça lui-même.
Bien pour ça que ce n’est OBLIGATOIRE et AUTOMATIQUE pour Android 6.0 QUE sur les appareils disposant de cette puce qui permet d’être totalement fluide.
Les autres doivent l’activer volontairement “à la main” et assument les conséquences en cas de ralentissements.
Le 21/10/2015 à 10h29
Ah merde, il va falloir que je m’achète une batterie portable supplémentaire…..
Le 21/10/2015 à 10h51
Le 21/10/2015 à 11h37
Sous android, il faut absolument que le téléphone soit déverrouillé ( donc selon le mode de déverrouillage facial, biométrique, un dessin, un code etc…) pour accéder aux fichier en USB. Donc pas un code particulier, faut pas que le téléphone soit verrouillé.
en plus, le protocole de communication entre le téléphone et le PC est le MTP, c’est le CPU du téléphone qui gère ( donc il prend en compte le cryptage)
Le 21/10/2015 à 11h42
Ils auront bien du mal à trouver des fabricants de SoC qui tolèrent de fournir les sources des drivers qu’ils utilisent… d’habitude, ils fournissent sous la forme de blob binaire, et uniquement aux OEM
Le 21/10/2015 à 12h07
Merci " />
Le 21/10/2015 à 12h31
Il y a en gros trois zones non open source:
Les firmwares du matériel (typiquement la radio), là le doute subsiste
Les firmwares/drivers du système, qui sont parfois open source selon le matériel
Les applis Google, qui n’ont a priori pas de passe droit et donc pas de possibilité d’aller tripatouiller la clé de chiffrement (ce qu’on peut vérifier en lisant le code source d’Android).
Il est tout à fait imaginable de concevoir un téléphone dont on maîtrise à la fois les firmwares radio et la recompilation des drivers matériel, et donc sur lequel on peut garantir que Google ne peut pas lire les clés de chiffrement de la partition data.
Le 21/10/2015 à 12h33
La partition chiffrée est montée sur un emplacement qui est lisible “en clair” au moment ou tu tapes la clé au démarrage du système. Après ça, le point de montage n’est jamais démonté et les données sont donc théoriquement lisibles par n’importe quelle appli, même si le téléphone est vérrouillé.
Le 21/10/2015 à 12h48
Les Google services ont accès aux données de la mémoire, pas besoin de la clé de chiffrement pour ça.
La clé de chiffrement ne sert qu’à empêcher les voleurs de lire tes données s’ils ont un accès matériel au téléphone.
Les applis ne sont pas impactées par le chiffrement, une appli qui peut lire ta mémoire interne pourra toujours le faire une fois le chiffrement activé. Idem pour les play services donc.
Le 21/10/2015 à 12h51
D’ailleurs c’était l’origine d’une faille, la clé de chiffrement étant stockée en RAM, il suffisait d’exploiter une propriété physique des puces de ram qui est qu’elles conservent les données même lorsqu’on coup le courant si la température est suffisamment basse.
Il suffisait de laisser son téléphone au congélateur, et d’installer un recovery bidouillé qui permettait de dumper la ram dès le boot pour récupérer la clé de chiffrement.
Je ne pense pas que cette faille soit corrigée…
Le 21/10/2015 à 12h57
Le 21/10/2015 à 13h16
J’ai Cyanogenmod 12.1 avec les pico GApps. Et j’envisage de passer à Cyanogenmod sans installer les GApps.
Le 21/10/2015 à 13h19
Se moquer de moi, si tu veux, rire, c’est important, même si ça n’apporte pas grand chose au débat.
Le 21/10/2015 à 13h34
Hors de question. Chiffrer des données c’est long, surtout pour les gens comme moi qui regardent beaucoup de films, et le risque de perte de données est assez élevé.
J’espère que CyanogenMod n’obligera pas les utilisateurs à faire ça aussi.
Pour ce qui est du verrouillage du téléphone, moi j’utilise Cerberus, je peux changer mon code à distance à tout moment en cas d’oubli ou de changement non désiré par un tiers.
Le 21/10/2015 à 06h46
Si c’était “illégal” jusqu’à maintenant, pourquoi la Surface 2 le fait depuis le début et que c’est dans Windows 10 Mobile ?
Le 21/10/2015 à 06h47
Je n’ai peut être pas tout à fait compris, mais ce qui me gêne, c’est que l’utilisateur ne puisse pas gérer ses propres clefs. De plus qu’est-ce qui nous dit que ces clefs ne sont pas envoyées à Google ? Bref à moins d’information complémentaire sur le sujet, je me montre méfiant quant à l’efficacité de ce chiffrage des données. Sachant que la NSA est soupçonnée de pouvoir déchiffrer de vastes quantités de connexions chiffrées (source :http://thehackernews.com/2015/10/nsa-crack-encryption.html )
Le 21/10/2015 à 06h47
J’ai pas vu de différence quand j’avais testé ça l’année dernière sur un Nexus 5.
Sinon dans ce même document de référence il y un autre passage important (point 9.1 Permissions) :
Les OEM ne pourront plus donner des autorisations à leurs apps pré-installé (ouais les bloatwares) et ils devront demander à l’utilisateur, via la fenêtre de dialogue qu’on connait maintenant, s’il veut donner tel ou tel autorisation.
C’est dans les pré-requis non négociable du document.
Si Samsung, LG, ou autres veut remplacer par exemple l’application de dialer, l’utilisateur devra au premier lancement lui dire qu’il veut bien donner l’accès à ses contacts et à la fonction téléphone, sinon le constructeur ne pourra pas installer l’application.
C’est une bonne nouvelle pour les futurs acheteurs d’Androidphone autres que Nexus.
Le 21/10/2015 à 06h48
Je trouve que c’est une très mauvaise idée de forcer le chiffrement intégral (carte sd y compris).
Pour mon cas, je l’avais fait et le natel est tombé en panne. J’ai perdu toute les données de la carte SD car impossible à récupérer … " />
Le 21/10/2015 à 06h52
Tu ne fais jamais de sauvegarde Nioniotte?
Par contre si on n’a pas la clef…
Le 21/10/2015 à 06h55
Heu. Y a les photos qui étaient sauvegardée chez G. " />
Le 21/10/2015 à 06h57
J’espère que le chiffrement de la carte SD est optionnel. On fait comment pour partager une carde SD avec quelqu’un d’autre sinon ? Comme le dit Nioniotte, si le tel tombe en panne, on aurait l’air fin…
Le 21/10/2015 à 07h03
Mais personne n’a jamais dit que c’était illégal
Le 21/10/2015 à 07h10
Le 21/10/2015 à 07h19
Qu’est-ce qui te le dit ? C’est dans le code open source d’Android, que des experts en sécurité passent leur temps à lire pour essayer de trouver des failles.
Que l’utilisateur ne puisse pas gérer ses propres clés, c’est un peu dommage, mais c’est aussi une garantie de sécurité supplémentaire.
Et la NSA peut déchiffrer de grosses quantités de données en exploitant les failles des chiffrements “faibles” qui sont utilisés encore sur beaucoup de sites. Je ne pense pas qu’ils aient accès ni même le besoin d’avoir les clés de chiffrement de tes données sur ton téléphone.
Pour rappel le chiffrement local n’est utile qu’en cas de vol du téléphone verrouillé ou éteint. Si le téléphone est allumé au moment du vol, les données sont déjà déchiffrées. S’il est verrouillé, il n’est normalement pas possible d’y accéder. Mais elles restent déchiffrées.
Le 21/10/2015 à 07h31
Je ne comprends pas que ce ne soit toujours pas la norme sous Android.
Ca me parait tout de même vital de chiffrer ses données. Surtout sur un appareil qui peut être facilement perdu/volé.
Le 21/10/2015 à 07h32
Tu m’as compris : “affaiblissement du chiffrement” pour être OK côté USA, donc ce que veut dire que soit le chiffrement était assez faible chez Microsoft, soit ils allait à l’encontre des directives américaines. On est proche d’une forme d’illégalité aux yeux des américains.
Le 21/10/2015 à 07h41
ou alors le chiffrement de MS est bon, mais si la loi imposant l’affaiblissement du chiffrement était passée, Ms aurait été aussi impacté.
Le 21/10/2015 à 07h42
Ils ont renoncé à mettre en place une loi qui allait en ce sens, dont ça n’a jamais été illégal.
Le 21/10/2015 à 07h42
Non justement. Ça voulait dire qu’ils voulaient que le chiffrement “continue”, mais en mettant éventuellement en place des portes dérobées pour les forces de l’ordre. Lis le lien qui vient justement dans le passage de la Maison Blanche.
Le 21/10/2015 à 08h08
Ok, bien compris.
Le 21/10/2015 à 08h13
Et en parlant de sécurité sur Android, j’ai aussi vu passer cette news sur le capteur d’empreinte :
http://www.engadget.com/2015/10/20/android-marshmallow-fingerprint-reader-requir…
qui indique que Google impose que la detection se passe en full hardware => au même niveau de sécurité qu’Apple grossièrement. Ce qui est une bonne chose " />
Le 21/10/2015 à 08h17
Le 21/10/2015 à 08h21
Chiffrement cosmétique car, boites américaine oblige, il y aura toujours des Backdoors pour ces messieurs des services pas si secrets que ça. L’espionnage est inscrit dans l’ADN des yankees.
Le 21/10/2015 à 08h23
Reste à voir si son activation provoque une chute visible des performances
Quid de l’impact autonomie ?
Le 21/10/2015 à 08h32
Quelle proportion de gens font des sauvegardes de leur téléphone ?
Le 21/10/2015 à 08h33
Le 21/10/2015 à 08h34
tu confonds toujours projet open source et projet libre ? " />
AOSP est un projet Open Source. Ce n’est pas un projet libre.
Android a une base open source sur lequel se rajoute plein de paquet/drivers/outils qui ne sont ni libre ni open source. Et ça a toujours été le cas …
De toute façon si la backdoor se situe dans le firmware de la puce radio, quel que soit l’OS au dessus il n’y aura rien à faire …
Mais bon de toute façon on peut dire qu’une chose : Android n’est “pas pire” que iOS / Windows sur ce point " />
Le 21/10/2015 à 08h35
Bonne nouvelle que ça ne soit pas les services Google qui gèrent le chiffrement, mais la base “open source” d’Android AOSP " />
Le 21/10/2015 à 08h38
Une fois le téléphone déverrouillé, qu’est ce qui empêche les services Google Play (ou tout autre service) d’envoyer les clés où bon lui semble ?