Vous êtes sur la page 1sur 5

Un OS ARM scuris : Android

Scurisation ds le dmarrage, plateforme applicative scurise et contrle de l'ensemble des logiciels installs et excuts sur chaque appareil.

La scurisation d'Android s'articule autour de plusieurs notions importantes : L'isolation des applications et le contrle des permissions o Peux-t-on contrler ce que les applications ont la possibilit de faire ? o Une application malveillante peut-elle affecter le reste du systme ? La provenance des applications o Peux-t-on faire confiance l'auteur d'une application ? Chiffrement des donnes o Les donnes sont-elles sauves si l'appareil est hack/perdu/vol ? Le contrle de l'accs l'appareil o Peux-t-on protger l'appareil contre un usage non autoris ?

Voici le schma global des diffrentes couches du modle Android :

A. Isolation des applications


Par dfaut, chaque application s'excute dans un processus spar avec un identifiant unique : user/group ID (fix tant que l'application est en vie). Il est possible pour plusieurs applications de partager un mme UID et des processus. Cela reste bas sur les anciens modles de scurit bien connus des standards UNIX de scurit (accs aux processus et fichiers systmes). Les services framework des applications tournent galement dans un processus spar (system_server). Le noyau Linux est le seul "mcanisme" de sandboxing. La machine virtuelle Java d'Android : Dalvik n'est pas une "limite de scurit" : Coder en Java ou en C/C++ ne pose pas de diffrences majeures Activation de l'utilisation de JNI (diffrent de JavaME!) Cela s'applique galement pour les applications systmes.

B. Politique de permissions par dfaut


Aucune application ne peut faire ce qu'elle veut pour affecter directement les autres applications, le systme ou encore l'utilisateur de l'appareil. Par dfaut, les applications ne peuvent donc pas : Lire/crire dans les fichiers en dehors de leur propre rpertoire Installer/dsinstaller/modifier d'autres applications

Utiliser les composantes prives des autres applications. Accder au rseau (Wifi, 3G, NFC, Bluetooth etc.) Accder aux donnes de l'utilisateur (contacts, SMS, email) Utiliser des services payants via des API (Appeler, envoyer des SMS, paiement par NFC) Maintenir l'appareil veill, redmarrer l'appareil etc.

En dehors de certains accs, valids par l'utilisateur lors de l'installation de l'application, les applications restent contenues leur propre fonctionnement et ne peuvent pas sortir de leur sandbox. Le systme de permissions permet donc un contrle plus ou moins scuris en fonction des choix de l'utilisateur. Voici un exemple de l'activation de ces permissions :
<manifestpackage="com.marakana.android.trackapp"> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/> <uses-permission android:name="android.permission.INTERNET"/> <uses-permission android:name="android.permission.VIBRATE"/> </manifest>

Voici la procdure logique d'accs aux permissions du systme :

Cependant la limite de ce systme reste la gestion des permissions qui n'est demande qu'une seule fois (premire installation); cela s'applique aux mises jour de l'application. Le mode "tout ou rien" de ce systme est le point le plus problmatique.

C. Provenance des applications (signature)


Toutes les applications (.apk) doivent tre signes numriquement avant l'installation sur un appareil et un hbergement sur l'Android Market. Le certificat embarqu peut tre autosign (pas d'autorit de certification requise) et valide au minimum pendant 25 ans. La signature des applications est faite pour assurer l'authenticit de l'auteur lors des mises jour et tablir une relation de confiance parmi les applications signes avec la mme cl (partage des permissions, UID, processus). Une application peut tre signe avec plusieurs cls. Si la cl prive connue par le dveloppeur est perdue, celui-ci ne pourra plus mettre jour l'application. De mme avec une cl vole, il n'y a pas de possibilit de la rvoquer. La signature des applications ne permet donc de scuriser la provenance des applications que pour les mises jour. La relation de confiance lors de la premire installation reste du ressort de l'utilisateur. Ainsi il est relativement facile d'utiliser les faiblesses de ce systme : Prendre une application populaire existante Injecter un code malveillant (type trojan) Recompiler et resigner avec une nouvelle cl Hberger l'application sur le market ou la distribuer sur le net Attendre les tlchargements (intentionnels ou non)

D. Donnes des applications


Les fichiers des applications sont par dfaut rendus privs, partags par les applications ayant le mme UID (signs avec la mme cl). Cependant il existe des exceptions et les applications peuvent crer des fichiers qui peuvent tre :

L'espace de stockage externe (s'il y en a) est accessible en lecture et en criture par l'ensemble du systme /mnt/sdcard avec WRITE_TO_EXTERNAL_STORAGE. Pour le chiffrement des donnes, voici les diffrentes possibilits : VPN (IPSEC) avec 3DES, AES et authentification scurise (VPN Client API valable partir d'Android 4.0 ICS) Connexion Wifi scurise 802.11 avec WPA/2. OpenSSL JCE (bas sur le fournisseur BouncyCastle) o Client Apache HTTP (supportant le SSL) o Java.net.HttpsUrlConnection Trousseau de cl accessible via API (les applications peuvent installer et stocker des certificats pour l'utilisateur, mais aussi les autorits de certificats (valable partir d'ICS 4.0).

Chiffrement de l'espace disque en entier