En regardant l'évolution d'Android dans le temps, tous ce qu'il est possible de faire avec du soft est finalement proposé. La sortie de la version 4.4 de l'OS, sortie mi-octobre 2013 et dénommé KitKat, est l'occasion de faire le point sur l'évolution du système.

Tout est-il possible avec les API ?

De nombreux exemples montrent que les Smartphone ne sont pas des téléphones comme les autres. Les choix de Google pour son OS bouleverse encore plus nos habitudes. Nous allons parcourir quelques technologies où Android apporte une démarche d'ouverture intéressante.

L'utilisation de l'USB

Première idée étonnante : est-ce qu’un téléphone doit être considéré comme un périphérique d’un PC ou l’inverse ? Android ne tranche pas. Pour Google un téléphone peut être les deux.

La première version de l'API USB ne permettait que la gestion de périphérique client type souris/clavier/disque/appareil photo. Le téléphone est alors en mode host. Avec un cable spécial pour inverser le fournisseur de l’énergie, il est facile de brancher une souris et un clavier sur votre téléphone. Et cela fonctionne !

Puis la version suivante de l’API d’Android permet de simuler un périphérique USB via le téléphone. Celui-ci est en mode périphérique. Il peut lui-même simuler une souris, un clavier, une imprimante, un modem ou un disque externe.

Pourquoi ne pas le faire si c'est possible ? Ce n’est que du soft. Nous avons maintenant les API pour cela.

L'utilisation du NFC

Le NFC (Communication en champs proche) est une technologie permettant la communication sans fils entre périphériques, juste en les plaçant à proximités. Est-ce que le téléphone doit se contenter de consommer un tag NFC ?

Le NFC peut être utilisé suivant trois modes d'utilisation:

• Exposer un tag NFC par le téléphone pour communiquer une info à l'extérieur. (Je partage l'URL de mon navigateur avec ma tablette pour pouvoir continuer ma consultation ; Je partage une application avec mon voisin pour qu'il puisse la télécharger immédiatement sur le market ; etc). Cela est l'équivalent de l'affichage d'un QRCode.
• Lire un tag NFC par le téléphone pour récupérer une info de l’extérieur (Quelle est l'URL que tu consultes sur ton téléphone ? Ce tag sur ce produit m'emmène sur qu'elle URL ?). Cela est équivalent à scanner un tag QRCode.
• Communiquer en mode socket client avec une puce NFC pour lire une carte bancaire par exemple, et ainsi récupérer son numéro et le nom du propriétaire.

Depuis Android Kitkat un dernier est proposé :

• la simulation d'une carte à puce pour permettre la communication en mode socket serveur.

Ce dernier maillon vient d'être proposé avec Android 4.4. Pourquoi ne pas le proposer ? Ce n'est que du soft.

De plus, cela permet de s'affranchir des opérateurs. Ces derniers demandent un loyer pour installer une application dans leurs puces. Et on se demande pourquoi le NFC ne décolle pas. Avec cette nouvelle API, on peut s'en passer. Bientôt votre carte bancaire de votre banque dans votre téléphone. Vos cartes de fidélités en NFC utilisables en deux secondes.

L'utilisation des fichiers

Comme tous les OS mobiles, Android ne propose pas nativement d'accès aux fichiers du système. Android a choisi de ne pas proposer cette notion. En effet, c'est compliqué et pas nécessaire car les applications sont isolées. Les fichiers d'une applications ne sont disponibles que pour elle. Ainsi, supprimer une application permet de supprimer également tous les fichiers qu'elle a produit.

Quelques répertoires généraux et fortement typés fonctionnent en mode fichiers. C'est le cas des répertoires pour les photos, les vidéos et les musiques. Et également, la partition SDCARD.

Le Play Store regorge d'applications complémentaires permettent de naviguer dans les fichiers, sans que l'utilisateur y gagne vraiment. Que peux-t’on modifier, effacer ? Qui maîtrise l'arborescence ? Avec un accès root, les Geek peuvent s'amuser avec, mais pour les autres ?

Mais, Google Drive propose des fichiers. Il faut permettre aux applications d'y avoir accès. Plutôt que de proposer une API spécifique comme le fait Microsoft ou Apple, Android propose un framework permettant, par la simple installation d'une application, de bénéficier de différents gestionnaires de fichiers (GDrive, Mega, Dropbox, SkyDrive, iCloud, USB, Samba, FTP, SSH, etc.)

Je trouve cela malin. Car ainsi, des applications tierces pourront proposer des interfaces génériques pour l'accès aux disques externes USB, sans que l'OS viole les brevets de Microsoft sur le format FAT. Ce n'est pas Android mais les applications tierces qui violent les brevets. C'est moins lucratif lors d'une attaque juridique.

Du point de vue de l'utilisateur, c'est transparent. Utiliser un disque dans les nuages ou physiquement présent est identique. De plus, l'API utilise les composants de bases d'Android, à savoir un ContentProvider. Il est probable qu'une librairie de compatibilité soit proposée pour les versions antérieures.

C'est une très grande force d'Android par rapport aux autres OS mobile : l'intégration forte entre les composants. Une application peut être facilement invoquée par les autres.

Je pense que les développeurs de Microsoft vont faire la tête lorsqu'ils vont coder l'APK pour donner l'accès à SkyDrive pour Android. Ils ne pourront pas donner un accès aussi simple à tous les clouds de la planète dans leur OS Windows Phones. Lorsque les applications Android sauront utiliser cela, sans aucune modification, elles pourront utiliser SkyDrive et les autres. Immédiatement. Juste en installant l'application associée au Cloud. La galerie standard ou la lecture de vidéo sera capable d'utiliser les fichiers sur SkyDrive. Et ces applications l’ignorent.

Nous remarquons qu'Android évolue petit à petit pour ouvrir tous ce qu'il est possible, via des API. Les applications peuvent faire de plus en plus de choses techniques comme simuler une carte bancaire, une imprimante USB, un disque ou un VPN.

Est-ce une bonne idée d’offrir ce que le soft permet ?

Avec Android , il y a quand même une faiblesse à l'ouverture logicielle systématique à toutes les technologies : les risques de sécurité.

L'exploitation du NFC

La sécurité du NFC est basé sur la proximité. Une carte bancaire NFC doit être proche du lecteur peut permettre une transaction. Maintenant qu'il est possible de simuler une carte bancaire sous Android, nous pouvons imaginer un scénario cassant la proximité. L'objectif est de proposer une rallonge sans fils. Le scénario est le suivant :

• deux téléphones Androids communiquent entre-eux via la 3G ou via Wifi Direct pour plus de discrétion.
• Un des téléphone est en mode "lecture de carte bancaire"
• L'autre téléphone est en mode "simulation de carte bancaire"
• Toutes les trames sont échangées entre les téléphones.

Il n'est pas nécessaire de comprendre les trames, juste de les propager. Avec ce scénario, il est possible d'effectuer une transaction, à l'aide d'un complice. Le téléphone en mode lecture cherche une carte bancaire dans un sac à main ou la poche d'un pantalon. Le complice consomme un bien en utilisant la carte de la victime. Les téléphones servent de relais.

L'accès aux supports externes

Sous Android, tous les fichiers présent sur un support externe (carte mémoire, disque USB, etc.) sont potentiellement disponibles à toutes les applications. C'est le modèle traditionnel de Windows. Les applications Windows peuvent lire tous vos fichiers.

Il y a un minimum de sécurité pour limiter les applications pouvant manipuler ces supports. Deux privilèges permettent d'informer l'utilisateur qu'une application souhaite uniquement lire ou bien lire et écrire sur ces supports.

Techniquement, cela s'effectue via l'utilisation astucieuse des utilisateurs linux (dont Android dérive) et des privilèges associés. Il y a bien maintenant un privilège nécessaire à la lecture de cette zone, mais comme les applications y stockent n'importe quoi, c'est une véritable faiblesse. En fouillant dans cet espace, on trouve des fichiers personnel qu'on ne souhaite pas partager avec toutes les applications pouvant lire la carte SD ! Essayez cette commande pour vous en convaincre.

adb shell find /sdcard/-type f -and -not -name '*.obb'

En ouvrant l'accès à cette espace partagé, les développeurs peuvent faire n'importe quoi et ils ne s'en privent pas.

iOS ne permet pas l'utilisation de carte mémoire. Windows Phone chiffre la carte pour qu'elle ne soit utilisable que dans le téléphone. Impossible de l'utiliser par ailleurs. Mais impossible également de lire une carte mémoire venant d'ailleurs.

Android ouvre l'accès à toutes les applications et toutes les cartes mémoires. L'ouverture d'Android sur ces supports entraîne, dans les faits, une faiblesse sur la confidentialité (voir des attaques cross-applications en modifiant un fichier ou une base de données d'une autre application. Attention au cache WebKit !).

Comment cela fonctionne ?

Pour permettre l'utilisation de carte mémoire type SD, ne pouvant gérer la sécurité à la unix sur un système FAT , Android considère ce périphérique externe comme accessible à toutes les applications. Le mount indique un uid et un gid générique ainsi qu'un privilège 770 pour tous les fichiers. L'idée est de permettre l'extraction de cette carte pour une lecture sur un autre système (appareil photo, Box ADSL ou PC par exemple) ou l'utilisation d'une carte mémoire venant d'un autre périphérique. Encore les deux facettes d’une technologie.

Pouvoir produire et consommer du fichier. Sous Android, les répertoires des applications sont sous /data/data. C'est porté par un disque avec un file systeme type ext3 ou jffs. Ces derniers permettent l'isolation des répertoires entre les applications, car chaqu'une utilise un utilisateur Linux différent. Les applications utilisent un répertoire sur la carte SD (généralement plus lent) car il y a, a priori, plus de volume. Dans les faits, le répertoire /sdcard/ est souvent mappé sur une partition interne et non sur une carte extractible. Du coup, il y a un nouveau répertoire pour les cartes extractibles.

Les privilèges READ_EXTERNAL_STORAGE et WRITE_EXTERNAL_STORAGE sont gérés astucieusement par l'intégration de l'utilisateur de l'application dans les groupes sdcard_r et sdcard_rw. Comme le file système de la carte SD est monté avec des privilèges pour ces groupes, la gestion est sous la responsabilité du kernel Linux.

Que devrait faire les applications ?

En laissant la possibilité aux applications d'utiliser une mémoire de masse externe, dans les faits, la confidentialité des utilisateurs n'est pas préservée. Depuis l'API level 8, il existe les méthodes getExternalCacheDir() et getExternalFilesDir() pour proposer des répertoires sur ces supports. Les applications ne devraient utiliser que ces répertoires et non des répertoires exotiques dans la racine. Cela permet de référencer des répertoires dans /sdcard/Android/data. Deux nouvelles API (Level 19) permettent de gérer plusieurs supports externes (getExternalCacheDirs() et getExternalFilesDirs()). Ces répertoires sont détruits automatiquement par le système lors de la désinstallation de l’application.

Les applications devraient migrer rapidement pour n'utiliser que ces répertoires.

Je ne suis pas contre un refus par l'OS d'utiliser d'autres répertoires. Cela permet une meilleure maîtrise de la hiérarchie sur la carte SD, et d'autre part, cela permet potentiellement une isolation des répertoires par les applications.

La version KitKat 4.4 d'Android ne nécessite plus les privilèges d'accès à la carte SD pour manipuler les répertoires dédiés aux applications sur ce support. Il est donc fortement conseillé de les utiliser pour pouvoir supprimer, à terme, les privilèges dans les applications. Cette approche permet d'isoler les répertoires des applications sur ces supports. Mais un privilège READ_EXTERNAL_STORAGE permet d'avoir un accès total au support externe.

L'idée derrière l'évolution de KitKat est de réduire au maximum le nombre d'applications possédant ce privilège. Et à terme, interdire l'accès aux répertoires des applications, même avec le privilège de lecture. Il sera difficile de gérer la rétro-compatibilité. Les applications vont garder ce privilège pour être compatible avec les anciennes versions de l'OS.

Installation de l'application sur external

Les applications peuvent être installées dans une mémoire de masse externe, via un paramètre dans le manifest. Ainsi, l'application et ses répertoires confidentiels sont présents sur la carte SD. Pour protéger tous cela, Android utilise un fichier chiffré pour chaque application. La clef est unique à chaque périphérique. L'OS mount un disque virtuel sur le fichier présent sur la partition SD. Il est donc très facile de bénéficier d'une mémoire de masse plus importante sur la carte SD, sans sacrifier les privilèges. Il suffit d'un simple paramètre dans le manifest. Ainsi, on bénéficie d'un chiffrement automatique des données et d'une isolation forte entre les applications.

Utilisation de données statiques

Pour les données statiques complémentaires à l’APK, Google est capable de les distribuer et de les installer sur la carte SD, mais ils sont alors chiffrés dans un fichier d’extension OBB. Consultez l'API de Google correspondante.   La confidentialité des répertoires sur un support externe est bien pris en compte par Google, comme le montre l'évolution de KitKat. Mais pour le moment, nous somme au milieu du gué.

Alors, faut-il ouvrir ou restreindre les API ?

Android est un système ouvert, limité que par des contraintes technologiques. Tous ce qu’il est possible de proposer par logiciel est ou sera proposé. Depuis plus de cinq ans, les fondamentaux du système n'ont pas bougé. Les évolutions du systèmes peuvent fonctionner sur les anciennes versions de l'OS.

Malgré les impacts sur la sécurité, je pense que l'ouverture maximale est une excellente chose. Même s'il faut ajuster au fur et à mesure.

Philippe PRADOS