Modèle de sécurité d’Android

Le système Android

Android est un système d’exploitation mobile développé par Google, il est basé sur une version modifiée du noyau Linux. Il a été publié en tant qu’Android AOSP (Open Source Project) en 2007. Ce système supporte la plupart des plateformes embarquées telles que ARM, MIPS, Power, x86 et est connue comme « la première plateforme mobile complète, ouverte et libre » (webappers, 2008).

Android a été conçu pour intégrer au mieux des applications existantes de Google (Gmail, cartographie, google Maps, Google Agenda, Google Talk, YouTube) et il bénéficie d’une architecture en couche complète faisant de lui une plateforme riche.

Le noyau Linux offre des services système de base tels que la sécurité, la gestion d’énergie, la gestion de mémoire, gestion de processus, etc.

La couche des bibliothèques natives est un ensemble de librairies, code ouvert, écrit en C/C++ jouant le rôle d’un logiciel médiateur. C’est sur cette couche que se greffe « Android Runtime », un moteur d’exécution et d’hébergement des applications Android, comprenant la machine virtuelle « Dalvik » et ses bibliothèques de base fournissant les fonctionnalités spécifiques à Android. Ce moteur est conçu avec un souci de compacité et d’efficacité pour un usage sur des appareils mobiles.

La couche de plateforme logicielle, nommée aussi cadre de développement. Cette couche, comme celle juste au-dessus, est écrite entièrement en Java. Elle permet de mutualiser les ressources entre les applications Java et offre aux développeurs la possibilité de produire des applications diverses et innovantes à travers un ensemble d’API (Application Programming Interface). Toutes les applications utilisent le même cadre de développement, peu importe la nature de l’application.

La couche Applications contient les logiciels installés sur l’appareil sous forme de paquets .apk, écrits par l’équipe Android ainsi que tout logiciel tiers de provenances variées : Android-Market, site Internet et, bien sûr, depuis votre ordinateur.

Modèle de sécurité d’Android 

Le modèle de sécurité d’Android est mis en œuvre sur deux couches ; au niveau applicatif et au niveau du noyau.

Au niveau du noyau Linux

Le modèle de permissions, appliqué par l’intergiciel Android, contrôle l’accès aux composants de l’application (telle que la possibilité d’invoquer un service fourni par une autre application) et l’accès aux ressources du système (telle que la possibilité d’accéder à la caméra ou le réseau).

Ce modèle est directement exposé aux développeurs d’applications Android, qui doivent préciser l’ensemble des autorisations requises à travers le fichier manifeste de leur application et aux utilisateurs finaux, qui doivent approuver l’ensemble des autorisations jugées dangereuses avant d’installer une application.

Au niveau des applications

Au niveau du noyau, le mécanisme de « sandboxing » et d’isolation des applications est nécessairement appliqué par le noyau Linux depuis la machine virtuelle Dalvik.

Mécanismes de sécurités

Android implémente nativement quelques mécanismes qui offrent un certain niveau de sécurité.

Le contrôle d’accès discrétionnaire et le sandboxing

Le mécanisme DAC (Discretionary Access Control) permet le contrôle d’accès des utilisateurs aux fichiers et aux répertoires. Il fonctionne d’une manière invisible pour les développeurs d’applications et les utilisateurs.

DAC permet d’isoler les applications des ressources systèmes. En effet, il est utilisé pour autoriser ou non les applications à accéder aux ressources système, par exemple la possibilité d’activer le Bluetooth ou des sockets réseau et la capacité d’accéder au système de fichiers sur la carte mémoire SD (Secure Digital).

Le DAC prend donc la forme de liste de contrôle d’accès ACL (Access Control List), qui permettent aux propriétaires de spécifier des permissions distinctes pour des utilisateurs et des groupes spécifiques.

DAC permet également d’isoler les applications les unes des autres. À l’installation, chaque application est attribuée à un utilisateur et un groupe unique (UID et GID, respectivement) et cette paire (UID, GID) est attribuée à des processus et des fichiers de données privées associées à l’application.

Table des matières

INTRODUCTION 
Mise en contexte
Problématique
Objectifs et réalisations
Méthodologie suivie
L’organisation du rapport
Diffusion des résultats
CHAPITRE 1 SÉCURITÉ SOUS ANDROID 
1.1 Introduction
1.2 Le système Android
1.3 Modèle de sécurité d’Android
1.3.1 Au niveau du noyau Linux
1.3.2 Au niveau des applications
1.4 Mécanismes de sécurités
1.4.1 Le contrôle d’accès discrétionnaire et le sandboxing
1.4.2 Mécanisme de permission (fichier Manifest)
1.4.3 L’encapsulation de composants
1.4.4 Unité de gestion mémoire
1.4.5 Signature des applications
1.4.6 Langage Java
1.4.7 Services et Internet
1.4.8 Suppression et mise à jour d’applications à distance
1.4.9 Bluetooth
1.5 Les vulnérabilités
1.5.1 Utilisateurs inexpérimentés
1.5.2 Marché d’applications non fiable
1.5.3 Accès temporaire au terminal
1.5.4 Environnement domestique
1.5.5 Environnement ouvert
1.6 Les attaques contre Android
1.6.1 Drive-by download
1.6.2 Les botnets
1.6.3 Hameçonnage en modifiant la configuration du serveur mandataire
1.6.4 La faille Exynos
1.6.5 L’injection du code
1.6.6 Les techniques pour surmonter les analyseurs
1.7 Sécurité des systèmes embarqués
1.8 Conclusion
CHAPITRE 2 REVUE DE LITTÉRATURE DES TECHNIQUES DE DÉTECTION DES ANOMALIES sur Android 
2.1 Introduction
2.2 La détection d’intrusion
2.2.1 Détection basée sur les signatures
2.2.2 Détection d’anomalies
2.3 Déploiement de la détection d’anomalies sur Android
2.3.1 Analyse basée sur l’hôte
2.3.2 Analyse à distance
2.4 Type de ressources monitorées
2.4.1 Paramètres statiques
2.4.2 Paramètres dynamiques
2.4.2.1 Les appels systèmes
2.4.2.2 La consommation de la batterie
2.4.2.3 Utilisation de la mémoire et du processeur
2.4.2.4 Autres
2.5 Compromis entre la détection et la consommation des ressources
2.6 Comparaison
CONCLUSION

Télécharger le rapport complet