Outlook.com pour Android ne chiffre pas les emails stockés dans la carte SD

« Chacun ses problèmes »

Le 27 mai 2014 à 10h50

5 min

Société numérique

Société

La société Include Security critique le niveau de sécurité de l’application Outlook.com pour Android. Deux points en particulier sont mis en avant : le code de verrouillage ne sert qu’à empêcher l’accès à l’interface et le stockage des données n’est pas sécurisé. D’autres applications peuvent donc lire ces informations si elles ont les bonnes autorisations.

outlook.com android

L'application ne chiffre pas les contenus qu'elle enregistre dans la carte SD

Microsoft fournit des applications pour son webmail Outlook.com sur plusieurs plateformes, dont iOS et Android. Sur cette dernière, la sécurité laisserait à désirer selon Include Security. Le point le plus important est le stockage des données. Comme de nombreuses applications sur le système mobile de Google, Outlook.com y dépose les informations de l’utilisateur de manière classique. Il n’y a pas de chiffrement et les applications tierces disposant d’un droit de lecture vers les stockages externes (comme les cartes SD) peuvent donc y puiser des données personnelles.

Toutes les versions d’Android ne sont cependant pas concernées. Dans la pratique, KitKat (branche 4.4) oblige les applications tierces à entreposer les données dans des espaces privés. De cette manière, les autres applications ne peuvent pas venir lire les informations. Sur les versions antérieures du système, qui représentent l’écrasante majorité de l’écosystème Android (KitKat tend vers les 10 %), il suffit que les applications disposent de la permission READ_EXTERNAL_STORAGE pour piocher dans le dossier d’Outlook.com.

Une ligne de défense un peu molle chez Microsoft

Chez Microsoft, on ne partage pas cette vision des choses : « Microsoft s’engage à protéger la sécurité de vos informations personnelles. Nous utilisions tout un éventail de technologies et de procédures pour protéger vos données des accès, utilisations et divulgations non autorisés. Pour ceux qui utilisent l’application Outlook.com sur Android, les applications fonctionnent dans des sandbox où le système d’exploitation protège les données des clients. De plus, ceux qui souhaitent chiffrer leurs emails peuvent se rendre dans les paramètres du téléphone et activer le chiffrement de la carte SD » indique ainsi la firme dans un communiqué envoyé à ZDnet.

En clair, ceux qui veulent un chiffrement de leurs données doivent l’activer pour l’intégralité du stockage externe. Ce qui pose la question du curseur entre la sécurité inhérente fournie par la plateforme et celle proposée par l’application tierce : Microsoft doit-elle directement fournir une solution de chiffrement ou doit-elle laisser le système s’en occuper ?

android outlook.com include security — Include Security

La réponse nous paraît assez évidente : Microsoft devrait véritablement prendre en charge cet aspect de la sécurité. Pourquoi ? Tout simplement parce que le chiffrement complet de la carte SD n’empêchera pas une application disposant des autorisations d’aller lire les fameuses données. Et le problème est d’autant plus sérieux qu’Android 4.4 est absent de plus de 90 % du parc Android et que l’application Outlook.com a été installée entre 10 et 50 millions de fois d’après les statistiques fournies par Google Play. Il suffit donc qu’une application malveillante demande des autorisations et que l’utilisateur valide ces dernières sans trop chercher à comprendre pour que ses données soient accessibles.

Le code de verrouillage ne bloque que l'accès à l'interface

En outre, il y a selon Include Security un autre problème. L’application Outlook.com fournit en effet une barrière contre l’accès non autorisé sous la forme d’un code chiffré que l’on peut configurer dans les options. Mais ce code ne verrouille que l’interface. En aucun cas il ne s’applique aux données. Conséquence : même si l’utilisateur bloque Outlook.com avec un code, l’accès reste entier pour les applications tierces qui disposent des bonnes autorisations.

Le souci avec ce code selon Include Security est qu’il « ment » lorsque l’utilisateur va l’activer. Dans un premier temps, la fonction est décrite comme pouvant « protéger l’application ». On peut considérer que c’est le cas car l’application elle-même ne sera pas utilisable sans le bon code. Mais si l’utilisateur active la fonctionnalité, Outlook.com indique cette fois que les courriers électroniques seront protégés. Ce qui, dans la pratique, n’est pas vrai. Non seulement le problème des applications tierces reste valable, mais un smartphone avec l’outil « USB debugging » activé pourra livrer ses informations une fois relié à un ordinateur.

De fait, il est recommandé plusieurs actions aux utilisateurs. D’une part, désactiver l’outil USB debugging pour éviter une récupération des données par ce biais. D’autre part, activer le chiffrement intégral de la carte SD, car cette étape fournit dans tous les cas une meilleure sécurité. Enfin, faire déménager les données stockées par Outlook dans le stockage interne du téléphone. Sur Android 4.4, ce dernier point n’est plus nécessaire cependant. Mais le point le plus important reste le même depuis des années : faire attention aux applications que l’on installe et aux autorisations qu’elles réclament.

Commentaires (31)

Maicka

Le 27/05/2014 à 11h03

Bonjour pardon pour le h.s je suis sur la version mobile je ne sais pas ou signaler via mail à l’équipe.

Quand j’ouvre nextinpact il me m’affiche les news de ce matin 8h je suis obligé de refresh 2 fois pour avoir la page à jour.

Désolé.

lincruste_2_la vengeance

Le 27/05/2014 à 11h05

Mais le point le plus important reste le même depuis des années : faire attention aux applications que l’on installe et aux autorisations qu’elles réclament.

Là ça ne s’applique pas vraiment: les droits d’écriture sur la SD peuvent être demandés en toute légitimité par un client e-mail afin d’enregistrer les pièces jointes.

Et du coup il récupère la possibilité de stocker le cache en clair comme ici.

La gestion des droits d’Android c’est effectivement très important mais ça ne prémunit pas contre une application écrite par des bœufs infectés au prion comme ceux de MS.

arno53

Le 27/05/2014 à 11h06

Je comprends pas l’utilité du chiffrements de la SD dans ce cas ? La SD n’est chiffré qu’avec une clé et lors ce que la SD est montée (système opérationnel) toutes les applis ayant acces à la SD ont également accès aux données de Outlook.

Ca ne sert que lorsque le téléphone est éteint et volé non ?

Sinon coté WP 8.1 c’est comment ? Aussi sécurisé que Android 4.4 ?

lincruste_2_la vengeance

Le 27/05/2014 à 11h07

arno53 a écrit :

Ca ne sert que lorsque le téléphone est éteint et volé non ?

Voilà.

Kako78

Le 27/05/2014 à 11h09

Bon en même temps c’est quand même un peu naze qu’il n’y ait pas eu de mécanisme d’espace privé avant Android 4.4…

Au niveau sécurité, Google ont été encore plus légers je trouve.

John Shaft

Le 27/05/2014 à 11h12

Maicka a écrit :

Bonjour pardon pour le h.s je suis sur la version mobile je ne sais pas ou signaler via mail à l’équipe.

Quand j’ouvre nextinpact il me m’affiche les news de ce matin 8h je suis obligé de refresh 2 fois pour avoir la page à jour.

Désolé.

Pour ce type de problèmes, le plus simple est de passer par le topic dédié du forum " />

Edtech Abonné

Le 27/05/2014 à 11h22

arno53 a écrit :

Je comprends pas l’utilité du chiffrements de la SD dans ce cas ? La SD n’est chiffré qu’avec une clé et lors ce que la SD est montée (système opérationnel) toutes les applis ayant acces à la SD ont également accès aux données de Outlook.

Ca ne sert que lorsque le téléphone est éteint et volé non ?

Sinon coté WP 8.1 c’est comment ? Aussi sécurisé que Android 4.4 ?

Sous WP, les applications sont 100% sandboxées, chacune ayant sa zone de stockage inaccessible aux autres applications. De plus, l’intégralité du stockage est chiffré il me semble (en tout cas, sur les Surface, BitLocker est activé par défaut).

Après, il y a moyen de chiffrer directement dans les Apps si ont le souhaite, je ne sais pas si Outlook le fait.

Oungawak

Le 27/05/2014 à 11h22

lincruste_2_la vengeance a écrit :

Là ça ne s’applique pas vraiment: les droits d’écriture sur la SD peuvent être demandés en toute légitimité par un client e-mail afin d’enregistrer les pièces jointes.

Et du coup il récupère la possibilité de stocker le cache en clair comme ici.

La gestion des droits d’Android c’est effectivement très important mais ça ne prémunit pas contre une application écrite par des bœufs infectés au prion comme ceux de MS.

Je suis d’accord et rajoute même que c’est difficile parfois de trouver une application pour une tâche spécifique demandant uniquement les droits dont elle à réellement besoin. Pas mal de devs demandent toutes sortes de droits, soit parce qu’ils sont trop incompétent/feignant pour faire un code conçu proprement, soit (surtout même) parce qu’ils font une usine à gaz proposant plein de features inutiles pour certains utilisateurs. Ceci est encore plus vrai sur Windows Phone qui met cette gestion des droits au second plan j’ai l’impression.

Tant que les OS ne permettront pas de refuser explicitement n’importe quel droit avec possibilité de mentir à l’application pour qu’elle tourne quand même (dans les cas vraiment mal foutus voire hostiles), cette gestion fine des droits ne restera qu’un argument marketing basé sur le bonne volonté des fournisseurs d’apps…

D’ailleurs si les stores vérifiaient que les apps utilisent bien les droits qu’ils demandent, je me demande si on aurait pas quelques surprises. " />

arno53

Le 27/05/2014 à 11h32

Edtech a écrit :

Sous WP, les applications sont 100% sandboxées, chacune ayant sa zone de stockage inaccessible aux autres applications. De plus, l’intégralité du stockage est chiffré il me semble (en tout cas, sur les Surface, BitLocker est activé par défaut).

Après, il y a moyen de chiffrer directement dans les Apps si ont le souhaite, je ne sais pas si Outlook le fait.

C’est surtout sur la SD que je me pose la question surtout qu’elle devient de plus en plus utilisé avec 8.1 … Mais bon vu comment MS axe sur la sécurité de ses WP, ca ne m’étonnerait pas que chaque apps aient une zone privé sur la SD…

Je me suis souvenu que j’avais vu un truc passé sur le chiffrement et WP8.1 mais en faite ca parle du .appx qui n’est pas chiffrer sous WP 8.1

Oungawak a écrit :

Ceci est encore plus vrai sur Windows Phone qui met cette gestion des droits au second plan j’ai l’impression.

C’est pas l’impression que me donnait MS au vu de Windows 8 qui permet d’interdire l’utilisation de la webcam ou de la position géographique dans les apps … Sous Android sois tu donne le droit a skype de jouer avec la camera soit tu l’installes pas … Sous Windows 8 tu peux installer skype et tchater en ayant refuser l’accès a la webcam …

caesar

Le 27/05/2014 à 12h04

Mouais

arno53 a écrit :

Je comprends pas l’utilité du chiffrements de la SD dans ce cas ? La SD n’est chiffré qu’avec une clé et lors ce que la SD est montée (système opérationnel) toutes les applis ayant acces à la SD ont également accès aux données de Outlook.

Ca ne sert que lorsque le téléphone est éteint et volé non ?

Une appli mal intentionnée peut lire les mails et envoyé les infos…

psn00ps

Le 27/05/2014 à 12h10

Non seulement le problème des applications tierces reste valable, mais un smartphone avec l’outil « USB debugging » activé pourra livrer ses informations une fois relié à un ordinateur.

L’USB debugging ne s’enclenche pas seul. C’est l’utilisateur qui se met délibérément en danger.

Autre nouveauté dans KitKat: le montage direct de la carte SD n’est plus possible.

Il faut une application tierce avec un tél rooté.

Khalev

Le 27/05/2014 à 12h13

Edtech a écrit :

Sous WP, les applications sont 100% sandboxées, chacune ayant sa zone de stockage inaccessible aux autres applications. De plus, l’intégralité du stockage est chiffré il me semble (en tout cas, sur les Surface, BitLocker est activé par défaut).

Après, il y a moyen de chiffrer directement dans les Apps si ont le souhaite, je ne sais pas si Outlook le fait.

Kako78 a écrit :

Bon en même temps c’est quand même un peu naze qu’il n’y ait pas eu de mécanisme d’espace privé avant Android 4.4…

Au niveau sécurité, Google ont été encore plus légers je trouve.

L’article n’est pas assez précis, il faut aller sur le blog original pour voir ce qu’il se passe vraiment.

Concrètement il y a 2 fonctions pour accéder aux fichiers “externes” sous Android :

getExternalStoragePublicDirectory() qui va chercher les fichiers sur la carte externe (et pour laquelle Android 4.4 a ajouté une autorisation READ_EXTERNAL_STORAGE)

getExternalFilesDir() qui va chercher les fichiers dans le dossier réservé à l’application et accessible uniquement à l’application (et qui existe depuis Android 2.2)

Le problème c’est que Outlook va par défaut enregistrer les pièces jointes dans le stockage externe (première fonction), hors cet espace n’est pas privatisé pour les apps, c’est le principe de la carte SD que tu rajoutes sous Andro, tu y mets ta musique, tes films & co et tu veux que ça soit accessible à toute tes apps.

Sauf que du coup là tes pièces jointes sont accessibles à toutes les apps ayant la permission READ_EXTERNAL_STORAGE (ce qui est le cas de toutes les app de musique, de film, de lectures de pdf & co. c’est une des permissions les plus demandé sous Android en fait " />) sous 4.4 et sans même cette autorisation sur les versions précédentes.

Outlook.com for Android downloads email attachments to the SDcard partition by default. For almost all versions of Android this places the attachments in a world-readable folder. This would place downloaded email attachments in a storage area accessible to any user or application which can access the SDcard (e.g any app granted READ_EXTERNAL_STORAGE permission) - even if the phone was not rooted. A 3rd party would simply use ADB shell in order to find the attachments, which are located in /sdcard/attachments

Ensuite Outlook enregistre bien les mails dans le stockage dédié de l’appli, donc les mails eux-même ne sont pas accessibles aux autres applis, par contre n’importe qui ayant un accès physique à un téléphone rooté peut lire les mails, même si on met un pin code sur l’application.

If USB Debugging is enabled and the device is rooted a 3rd party would be able to access the cached emails database

Donc:

chiffrer son stockage permet d’empêcher qu’une tierce partie n’accède aux mails en clair (les apps tierces ne peuvent déjà pas y accéder). Mais le pincode de l’appli ne protège pas contre ça (contrairement à ce que l’ont pourrait en attendre)

chiffrer son stockage externe permet de protéger la carte SD de la même manière mais n’empêche pas l’accès des applications tierces aux pièces jointes (une fois le stockage monté il est accessible en clair à toutes les apps pouvant y accéder).

Android 4.4 n’introduit pas la séparation des stockage entre appli, cela existe depuis Android 2.2, cependant il ajoute une permission qui permet d’empêcher une appli d’accéder à la carte SD. Sauf que c’est du tout ou rien : soit tu accèdes à toute la carte SD soit tu n’y accèdes pas.

Avec la configuration d’Outlook par défaut il suffit qu’une appli ait les autorisations INTERNET et READ_EXTERNAL_STORAGE pour uploader les pièces jointes en clair, pincode ou pas pincode.

psn00ps

Le 27/05/2014 à 12h20

Khalev a écrit :

Ensuite Outlook enregistre bien les mails dans le stockage dédié de l’appli, donc les mails eux-même ne sont pas accessibles aux autres applis, par contre n’importe qui ayant un accès physique à un téléphone rooté peut lire les mails, même si on met un pin code sur l’application.

Tu veux du chiffrement => tu ne rootes pas le téléphone, ou seulement pendant l’installation, et tu coupes l’usb debugging. Next " />

Khalev

Le 27/05/2014 à 12h29

psn00ps a écrit :

Tu veux du chiffrement => tu ne rootes pas le téléphone, ou seulement pendant l’installation, et tu coupes l’usb debugging. Next " />

C’est très con ce que tu dis là. tu peux vouloir rooter ton téléphone ET chiffrer tes données…

Après l’USB debuging pour l’utiliser souvent sur mes télépones je ne pense pas tout le temps à le désactiver. Ça n’emp^che pas que je veuille avoir mes données chiffrées.

Par contre j’ai dit une connerie:

le READ_EXTERNAL_STORAGE existait avant. Ce qu’introduit android 4.4 c’est le fait d’avoir des zones réservées sur le stockage externe.

Le READ_EXTERNAL_STORAGE donne accès à un espace partagé sur le stockage externe dans android 4.4 et à tout le stockage externe (qui est donc considéré comme entièrement partagé) pour les versions précédentes.

Ballos

Le 27/05/2014 à 12h42

Kako78 a écrit :

Bon en même temps c’est quand même un peu naze qu’il n’y ait pas eu de mécanisme d’espace privé avant Android 4.4…

Au niveau sécurité, Google ont été encore plus légers je trouve.

Il n y a pas sur la carte SD. Sur la mémoire interne c’est protégé depuis longtemps.

Pourquoi et comment de la part de Google qui sont à la pointe de la sécurité des utilisateurs en général (double authentification, blocage dans un pays suspect, récupération par SMS etc.. ) ??

Parce que les utilisateurs Android veulent utiliser une carte SD, cette même carte SD ne peut être formaté qu’en FAT32 pour pouvoir être lue sur un PC windows, parce que Microsoft refuse obstinément de prendre en charge d’autre type de formatage que ceux où il perçoit les royalties (même chose avec H264 et d’autres histoires) . Donc Google était obligé d’utiliser le FAT qui comme on le sait est un vieux système qui ne permet la gestion des droits.. Ils auraient pu prendre l’ext4 opensource et très performant mais les utilisateurs android auraient eu une carte SD qu’il ne peuvent connecter avec leur windows et mac (sauf à installer des drivers).

C’est pour ça que Google à voulu forcer les constructeurs à abandonner la carte SD car il savait le risque sécurité qu’ils représentent.

Lire l’interview de Morill de 2011 sur le sujet

http://www.androidpolice.com/2011/11/18/impromptu-qa-session-with-android-engine…

anonyme_a6c552c5fb4282d70e634ed16d39416a

Le 27/05/2014 à 12h44

Kako78 a écrit :

Bon en même temps c’est quand même un peu naze qu’il n’y ait pas eu de mécanisme d’espace privé avant Android 4.4…

Au niveau sécurité, Google ont été encore plus légers je trouve.

Google depuis longtemps milite pour la disparition des stockages externes sur les terminaux androïd, si les différents constructeurs ne respectent pas ce point du cahier des charges… Chacun ses problèmes, pour reprendre le sous-titre ;)

Ensuite, je considère qu’un développeur d’appli@store doit considérer les OS auxquels il destine ses appli comme un simple hébergement web sur lequel il n’a pas de contrôle : à lui de concevoir ses appli de façon à ce qu’elles fournissent le minimum syndical en terme de sécurité. Rendre ses fichiers illisibles par des appli non autorisées me semble être la plus évidente des bonne pratiques.

Khalev

Le 27/05/2014 à 12h48

YesWeekEnd a écrit :

Rendre ses fichiers illisibles par des appli non autorisées me semble être la plus évidente des bonne pratiques.

Surtout que MS a un bon historique niveau rendre illisible des documents pour d’autres applis. Les fameux formats office (avant la version .*x)

Ballos

Le 27/05/2014 à 12h52

Khalev a écrit :

L’article n’est pas assez précis, il faut aller sur le blog original pour voir ce qu’il se passe vraiment.

Concrètement il y a 2 fonctions pour accéder aux fichiers “externes” sous Android :

getExternalStoragePublicDirectory() qui va chercher les fichiers sur la carte externe (et pour laquelle Android 4.4 a ajouté une autorisation READ_EXTERNAL_STORAGE)

getExternalFilesDir() qui va chercher les fichiers dans le dossier réservé à l’application et accessible uniquement à l’application (et qui existe depuis Android 2.2)

Le problème c’est que Outlook va par défaut enregistrer les pièces jointes dans le stockage externe (première fonction), hors cet espace n’est pas privatisé pour les apps, c’est le principe de la carte SD que tu rajoutes sous Andro, tu y mets ta musique, tes films & co et tu veux que ça soit accessible à toute tes apps.

Sauf que du coup là tes pièces jointes sont accessibles à toutes les apps ayant la permission READ_EXTERNAL_STORAGE (ce qui est le cas de toutes les app de musique, de film, de lectures de pdf & co. c’est une des permissions les plus demandé sous Android en fait " />) sous 4.4 et sans même cette autorisation sur les versions précédentes.

Ensuite Outlook enregistre bien les mails dans le stockage dédié de l’appli, donc les mails eux-même ne sont pas accessibles aux autres applis, par contre n’importe qui ayant un accès physique à un téléphone rooté peut lire les mails, même si on met un pin code sur l’application.

Donc:

chiffrer son stockage permet d’empêcher qu’une tierce partie n’accède aux mails en clair (les apps tierces ne peuvent déjà pas y accéder). Mais le pincode de l’appli ne protège pas contre ça (contrairement à ce que l’ont pourrait en attendre)

chiffrer son stockage externe permet de protéger la carte SD de la même manière mais n’empêche pas l’accès des applications tierces aux pièces jointes (une fois le stockage monté il est accessible en clair à toutes les apps pouvant y accéder).

Android 4.4 n’introduit pas la séparation des stockage entre appli, cela existe depuis Android 2.2, cependant il ajoute une permission qui permet d’empêcher une appli d’accéder à la carte SD. Sauf que c’est du tout ou rien : soit tu accèdes à toute la carte SD soit tu n’y accèdes pas.

Avec la configuration d’Outlook par défaut il suffit qu’une appli ait les autorisations INTERNET et READ_EXTERNAL_STORAGE pour uploader les pièces jointes en clair, pincode ou pas pincode.

Exactement le mécanisme et ancien et beaucoup de dev qui ne lisent pas les documents (ou ne les ont plus consultés depuis 2011) ont été surpris et sont visiblement encore surpris 3 ans après avec microsoft. Et ce malgré tout le bruit que ça fait sur les forums spécialisé. ça montre bien toute la compétence des employées de Microsoft. Bref Microsoft a fait un bon produit avec office mais pour le reste des outils grand public c’est la cata.

psn00ps

Le 27/05/2014 à 12h54

Khalev a écrit :

C’est très con ce que tu dis là. tu peux vouloir rooter ton téléphone ET chiffrer tes données…

Après l’USB debuging pour l’utiliser souvent sur mes télépones je ne pense pas tout le temps à le désactiver. Ça n’emp^che pas que je veuille avoir mes données chiffrées.

Le root est une utilisation détournée, à savoir la suppression des mécanismes de sécurité mis en place. L’utilisateur le sait, il n’a pas à se plaindre.

Khalev

Le 27/05/2014 à 13h03

psn00ps a écrit :

Le root est une utilisation détournée, à savoir la suppression des mécanismes de sécurité mis en place. L’utilisateur le sait, il n’a pas à se plaindre.

Non. Le root n’enlève pas de mécanismes de sécurité. Il te permet juste de t’en passer quand tu le désires. Mais ça ne veut pas dire qu’ils ne sont plus là. C’est comme avoir un compte administrateur sur son PC, ça ne t’empèche pas de continuer à utiliser un compte à droit restreint. Par contre quand tu as besoin tu peux avoir un peu plus de privilèges.

Et je le redis ce n’est pas parce que tu rootes ton téléphone que tu acceptes qu’il soit ouvert à tout vent. Au contraire j’ai justement rooté mon téléphone pour renforcer la sécurité de mon téléphone (en partie pour stocker des clés privées sur une partition chiffrée indépendante du stockage externe classique).

atomusk

Le 27/05/2014 à 13h10

Khalev a écrit :

Non. Le root n’enlève pas de mécanismes de sécurité. Il te permet juste de t’en passer quand tu le désires. Mais ça ne veut pas dire qu’ils ne sont plus là. C’est comme avoir un compte administrateur sur son PC, ça ne t’empèche pas de continuer à utiliser un compte à droit restreint. Par contre quand tu as besoin tu peux avoir un peu plus de privilèges.

Et je le redis ce n’est pas parce que tu rootes ton téléphone que tu acceptes qu’il soit ouvert à tout vent. Au contraire j’ai justement rooté mon téléphone pour renforcer la sécurité de mon téléphone (en partie pour stocker des clés privées sur une partition chiffrée indépendante du stockage externe classique).

Si tu as un outil “qui t’envoi un popup quand une app demande de passer Root”, alors pas de souci, l’app ne pourra pas accéder aux données.

Maintenant si tu as rooté ton téléphone comme un cochon là rien à redire " />

JCLB

Le 27/05/2014 à 13h29

Ballos a écrit :

C’est pour ça que Google à voulu forcer les constructeurs à abandonner la carte SD car il savait le risque sécurité qu’ils représentent.

/

Et surtout parce qu’ils veulent en accord avec les opérateurs que tu “cloudifies” toutes tes ressources y compris la musique. " />

kikoo25

Le 27/05/2014 à 13h41

Microsoft doit-elle directement fournir une solution de chiffrement ou doit-elle laisser le système s’en occuper ?

La réponse nous paraît assez évidente : Microsoft devrait véritablement prendre en charge cet aspect de la sécurité.

La réponse me paraît aussi évidente mais dans l’autre sens : FileZilla et Freenet considèrent tous les 2 qu’il n’est pas pertinent de chiffrer au niveau du programme lui-même plutôt que de chiffrer (la partition) au niveau de l’OS. S’il y a une appli véreuse capable de lire les e-mails stockés, elle sera aussi capable d’attendre patiemment que l’utilisateur en tape le code de déchiffrement…

Ballos

Le 27/05/2014 à 14h37

JCLB a écrit :

Et surtout parce qu’ils veulent en accord avec les opérateurs que tu “cloudifies” toutes tes ressources y compris la musique. " />

La mémoire ne coute quasiment rien et des appareils comme les xperia ou htc one récents permettent de mettre 128 gb de mémoire.

De plus la musique dans le cloud est un service gratuit sur Google music (jusqu’à 2 000 albums si je me souviens bien)

… Mais bon c’est sur qu’on est pas à l’abri de voir les constructeurs se coucher devant les opérateurs, comme avec tous les crapware qu’ils mettent dans les phones.

psn00ps

Le 27/05/2014 à 14h52

kikoo25 a écrit :

La réponse me paraît aussi évidente mais dans l’autre sens : FileZilla et Freenet considèrent tous les 2 qu’il n’est pas pertinent de chiffrer au niveau du programme lui-même plutôt que de chiffrer (la partition) au niveau de l’OS. S’il y a une appli véreuse capable de lire les e-mails stockés, elle sera aussi capable d’attendre patiemment que l’utilisateur en tape le code de déchiffrement…

Regarde le de plus près avant de dire ça " />

telperien

Le 27/05/2014 à 15h17

Ballos a écrit :

Il n y a pas sur la carte SD. Sur la mémoire interne c’est protégé depuis longtemps.

Pourquoi et comment de la part de Google qui sont à la pointe de la sécurité des utilisateurs en général (double authentification, blocage dans un pays suspect, récupération par SMS etc.. ) ??

Parce que les utilisateurs Android veulent utiliser une carte SD, cette même carte SD ne peut être formaté qu’en FAT32 pour pouvoir être lue sur un PC windows, parce que Microsoft refuse obstinément de prendre en charge d’autre type de formatage que ceux où il perçoit les royalties (même chose avec H264 et d’autres histoires) . Donc Google était obligé d’utiliser le FAT qui comme on le sait est un vieux système qui ne permet la gestion des droits.. Ils auraient pu prendre l’ext4 opensource et très performant mais les utilisateurs android auraient eu une carte SD qu’il ne peuvent connecter avec leur windows et mac (sauf à installer des drivers).

C’est pour ça que Google à voulu forcer les constructeurs à abandonner la carte SD car il savait le risque sécurité qu’ils représentent.

Lire l’interview de Morill de 2011 sur le sujet

http://www.androidpolice.com/2011/11/18/impromptu-qa-session-with-android-engine…

Si c’est pour des raisons techniques (entre autre) que google n’a pas mis en place ce système de mémoire partagée sur les cartes sd (dû au FAT32), comme cela se fait-il que ce soit possible aujourd’hui sur Kit-Kat ? Obligation d’utiliser un autre format pour la carte SD ?

Ballos

Le 27/05/2014 à 16h19

telperien a écrit :

Si c’est pour des raisons techniques (entre autre) que google n’a pas mis en place ce système de mémoire partagée sur les cartes sd (dû au FAT32), comme cela se fait-il que ce soit possible aujourd’hui sur Kit-Kat ? Obligation d’utiliser un autre format pour la carte SD ?

Parce que comme la carde SD ne permet une gestion des droits sur l’espace disque, google a du réécrire la portion système des permissions pour empêcher une app d’utiliser un espace qui ne lui appartient pas .. Mais ça reste une solution batarde car si tu perd ton phone , suffit de prendre la carte SD et de la brancher à un pc pour récupérer toutes les données non chiffrées (photo, piece jointe de outlook qui sont pas chiffrées, etc… ) .

La seul solution à ce foutoir est d’abandonner le FAT32, car en plus Microsoft avec ses plus de 85% de monopoles ne supportera jamais les formats opensource qu’il combat bec et ongles. Ils ont déjà poursuivi beaucoup de constructeurs pour les forcer à payer le brevet FAT32, surement pas envie de se passer de cette manne financière….Au final le constructeur d’un périphérique (Clef USB, appareil photo, etc…) va se poser une question : Que va faire mamie du cantal avec sa carte SD non reconnu par Windows ?? Elle va rapporter le produit et dire au vendeur “ça marche pas “.

kikoo25

Le 27/05/2014 à 16h59

psn00ps a écrit :

Regarde le de plus près avant de dire ça " />

Je ne parle pas du datastore qui brasse tous les bouts de données de tout le monde et dont même l’utilisateur n’a pas la(les) clé(s) (n’étant pas amener à lire ces données directement), je parle du cache perso (le truc de la rubrique “Protection of your downloads, uploads and Freenet browsing cache”).

ForceRouge Abonné

Le 27/05/2014 à 17h15

Ballos a écrit :

Parce que comme la carde SD ne permet une gestion des droits sur l’espace disque, google a du réécrire la portion système des permissions pour empêcher une app d’utiliser un espace qui ne lui appartient pas .. Mais ça reste une solution batarde car si tu perd ton phone , suffit de prendre la carte SD et de la brancher à un pc pour récupérer toutes les données non chiffrées (photo, piece jointe de outlook qui sont pas chiffrées, etc… ) .

La seul solution à ce foutoir est d’abandonner le FAT32, car en plus Microsoft avec ses plus de 85% de monopoles ne supportera jamais les formats opensource qu’il combat bec et ongles. Ils ont déjà poursuivi beaucoup de constructeurs pour les forcer à payer le brevet FAT32, surement pas envie de se passer de cette manne financière….Au final le constructeur d’un périphérique (Clef USB, appareil photo, etc…) va se poser une question : Que va faire mamie du cantal avec sa carte SD non reconnu par Windows ?? Elle va rapporter le produit et dire au vendeur “ça marche pas “.

Mouais, tu racontes un peu n’importe quoi. Le chroot ça existe, sinon tu peux monter un filesystem avec fuse qui te fait croire que t’es a la racine alors que t’es dans un sous répertoire de la carte sd.

Et pour finir, passer sur un autre filesystem n’empêchera pas de pouvoir lire la ds sur un Pc .

Le seul moyen de bloquer la lecture de la carte sur un Pc serait de la chiffrer avec une clef privée stocke dans une zone inaccessible du téléphone … Et je pense pas qu’on en soit la avec android.

lincruste_2_la vengeance

Le 27/05/2014 à 19h22

Alesk a écrit :

Le seul moyen de bloquer la lecture de la carte sur un Pc serait de la chiffrer avec une clef privée stocke dans une zone inaccessible du téléphone … Et je pense pas qu’on en soit la avec android.

Si si, c’est géré nativement. Sinon y’a une application.

Idiot Proof

Le 28/05/2014 à 05h28

Pourquoi s’embêter a crypter avec Microsoft ça termine de toute façon dans les bureaux de la NSA " /> avec Google aussi " />