LE SYSTÈME ANDROID

LE SYSTÈME ANDROID

Activité

Une activité est une interface visuelle à travers laquelle l’utilisateur interagit avec le système d’exploitation Android et les applications installées sur le téléphone. Une application peut être constituée d’une ou plusieurs activités dépendamment de son architecture. Généralement, une seule activité est spécifiée comme étant une activité principale, et elle est présentée en premier lieu à l’utilisateur lors du lancement de l’application. Cette activité est la porte d’entrée pour l’application, et pourra par la suite démarrer d’autres activités afin d’effectuer différentes actions.
Dans notre exemple de l’application VoirDomicileContact, l’activité VoirAdresseListe (voir figure 2.1) représente l’interface utilisateur de l’application. Cette activité est marquée comme la porte d’entrée de l’application. Sa tâche consiste à afficher la liste des noms et prénoms des contacts de l’utilisateur avec l’adresse de leur domicile. L’activité VoirAdresseCarte quant à elle est utilisée pour afficher l’adresse d’un contact donné sous forme d’un marqueur sur une carte géographique.

Service

Un service (Service) se réfère à la partie du code de l’application qui s’exécute en arrièreplan, et qui ne peut pas avoir d’interface visuelle. Cependant, un service peut être lié à une activité permettant ainsi à l’utilisateur d’une application de la contrôler (démarrer ou arrêter).
Habituellement, un service s’exécute en arrière-plan d’une application ou d’une activité. Lorsqu’une activité a besoin d’exécuter une opération qui doit se poursuivre après la disparition de l’interface utilisateur (p. ex., le téléchargement d’un fichier ou jouer de la musique), elle fait appel à un service spécialement conçu pour cette action.
Dans notre exemple d’application, le service SuivreEmplacement (voir figure 2.1) de l’application DomicileContactProximite se charge de vérifier l’emplacement physique du téléphone à chaque intervalle de temps défini. Le service en question compare l’emplacement de l’utilisateur avec l’adresse de chaque contact se trouvant dans la base de données de l’application. Si l’utilisateur se trouve à la proximité de l’adresse de l’un de ses contacts figurant dans la base de données, le service émet un message afin de signaler l’événement à l’application VoirDomicileContact. Le démarrage et l’arrêt du service sont gérés par l’utilisateur à travers l’activité ControllerApp (p. ex., boutons Démarrer et Arrêter).

Récepteur de diffusion

Les récepteurs de diffusion (Braodcast Receiver) agissent comme des boîtes aux lettres pour les messages provenant d’autres applications ou du système (Enck, Ongtang et McDaniel, 2009). Leur rôle consiste à recevoir les diffusions et de réagir en fonction du contenu de chaque diffusion reçue.
Typiquement, les diffusions sont émises soit par le système, soit par les applications. Le système Android envoie souvent des diffusions pour alerter les applications des changements d’état, tels que la réception d’un SMS, le changement des préférences de langue ou encore l’annonce d’un faible niveau de la batterie.
Les applications peuvent également envoyer des diffusions destinées aux récepteurs de diffusion appartenant à la même application ou à d’autres applications installées. Ces derniers peuvent réagir à la réception des diffusions si elles sont configurées ainsi.
L’application peut avoir plusieurs récepteurs de diffusion, ce qui lui permet de recevoir les diffusions émises simultanément.
Les récepteurs de diffusion étendent la classe de base BroadcastReceiver et ne peuvent pas avoir d’interface visuelle. Cependant, ils ont la possibilité de lancer une activité suite à la réception d’une diffusion. Un récepteur de diffusion peut également notifier l’utilisateur au sujet de l’évènement qui a eu lieu en utilisant le gestionnaire de notification. Les notifications peuvent prendre la forme d’un signal sonore, une vibration ou encore une icône sur la barre d’état du système.
L’application VoirDomicileContact définit un récepteur de diffusion appelée Recevoir ContactAdresse. Le rôle de ce dernier consiste à attendre les diffusions indiquant que le téléphone se trouve à proximité de l’adresse d’un contact particulier, en provenance de l’application DomicileContactProximite. À la réception de la diffusion, l’application affiche une notification visuelle pour l’utilisateur lui demandant s’il désire lancer l’activité VoirContactCarte. Si c’est le cas, l’activité VoirAdresseCarte est démarrée et l’adresse du contact en question est affichée sur une carte géographique.

Fournisseur de contenu

Les fournisseurs de contenu (Content Provider) est le composant chargé du partage des données entre les applications, en utilisant l’interface de base de données relationnelle SQLite (Enck, Ongtang et McDaniel, 2009a). Chaque fournisseur de contenu est conçu pour traiter un type spécifique de données telles que les données audio, vidéo ou image. Ce type de composant est l’unique moyen de stocker, récupérer et partager des données entre les applications, et ce, dû à l’absence de base de données centralisée dans le système. Android est livré avec un certain nombre de fournisseurs de contenu (situés dans le cadre d’application) qui gèrent certains types de données (p. ex., les informations des contacts), et qui peuvent être utilisés par les applications. Deux méthodes existent pour rendre les données d’une application publique, soit en définissant son propre fournisseur de contenu ou soit en insérant ces données dans un fournisseur de contenu déjà existant capable de supporter le même type de données (p. ex., l’ajout d’un contact par une application autre que celle par défaut).
Le fournisseur de contenu FournisseurAdresse défini dans l’application DomicileContactProximite détient la liste des noms et prénoms des contacts de l’utilisateur et leurs adresses. Ces informations sont regroupées sous forme d’un fichier de base de données géré par le fournisseur de contenu FournisseurAdresse. Dans notre exemple, ces informations sont entrées par l’utilisateur qui spécifie l’adresse de chaque contact à travers l’activité SaisirAdresseContact.

Le fichier de déclaration AndroidManifest.xml

Chaque package d’une application Android comporte son propre fichier de déclaration structuré XML, portant toujours le nom de AndroidManifest.xml. Ce fichier comporte la déclaration des composants de l’application afin que ceux-ci puissent être reconnus et initiés par le système, lorsque nécessaire. Outre la déclaration des composants de l’application, le fichier Manifest remplit les fonctionnalités suivantes (AOSP, 2008e) :
•il identifie le nom du package de l’application qui est utilisé comme identifiant unique pour l’application.
• il présente les classes qui implémentent chacun des composants et publie leurs capacités (p. ex., les tâches qu’elles peuvent accomplir au profit des applications externes). Ces déclarations permettent au système Android de savoir ce que les composants peuvent faire et sous quelles conditions ils peuvent les faires.
• il détermine quel processus sera l’hôte des éléments de l’application.
• il déclare les permissions requises pour accéder aux parties protégées de l’API
d’application et d’interagir avec d’autres applications (plus de détails au Chapitre 3).
• il déclare aussi les permissions que les autres applications sont tenues d’avoir en vue d’interagir avec les composants de l’application (plus de détails Chapitre 3).
• il déclare le niveau minimum de l’API Android que l’application exige. En effet, il existe un niveau d’API qui correspond à une ou plusieurs version d’Android (p, ex. API 10 correspond aux versions Android 2.3.3 et Android 2.3.4)
• il énumère les bibliothèques auxquelles l’application doit être liée.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières
INTRODUCTION
CHAPITRE 1 LE SYSTÈME ANDROID
1.1 Introduction à Android
1.2 Architecture du système d’exploitation mobile Android
1.2.1 Le noyau Linux
1.2.2 Les bibliothèques natives
1.2.3 L’environnement d’exécution Android
1.2.4 Le cadre d’application
1.2.5 Couche des applications
1.3 Interaction entre les différentes couches
CHAPITRE 2 STRUCTURE DES APPLICATIONS ANDROID
2.1 Exemples d’applications Android
2.2 Les composants des applications
2.2.1 Activité
2.2.2 Service
2.2.3 Récepteur de diffusion
2.2.4 Fournisseur de contenu
2.3 Le fichier de déclaration AndroidManifest.xml
2.4 Interaction entre les composants
2.4.1 Interaction avec une activité
2.4.2 Interaction avec un service
2.4.3 Interaction avec un récepteur de diffusion
2.4.4 Interaction avec un fournisseur de contenu
CHAPITRE 3 MODÈLE DE SÉCURITÉ D’ANDROID
3.1 Mécanisme de sécurité au niveau du noyau Linux
3.1.1 Isolation des processus des applications
3.1.2 Accès aux fichiers de l’application
3.2 Mécanisme de sécurité au niveau de l’application
3.2.1 Signature numérique du package de l’application
3.2.2 Le modèle des permissions
3.2.2.1 Déclaration des permissions
3.2.2.2 Les permissions au niveau des composantes
3.2.2.3 Usage des permissions au niveau des composants
3.2.2.4 Usage des permissions au niveau des intentions
3.2.2.5 Vérification des permissions au niveau des processus
3.2.3 Les permissions sur les fournisseurs de contenu
3.2.4 Les permissions par URI
3.2.5 Composant publique et composant privé
CHAPITRE 4 ATTAQUES ET VULNÉRABILITÉS CONTRE LE SYSTÈME ANDROID33
4.1 Les applications malveillantes déclarées
4.2 Les applications sournoises
4.2.1 Applications sournoises exploitant les vulnérabilités du noyau Linux
4.2.2 Applications sournoises exploitant les vulnérabilités de la plateforme Android
4.2.3 Application malveillante exploitant le Rooting de l’appareil
4.2.4 Applications sournoises exploitant les vulnérabilités des applications installées
4.2.4.1 Vulnérabilités au niveau des composants
4.2.4.2 Vulnérabilités au niveau des données de l’application
4.2.4.3 Vulnérabilités au niveau des intentions
CHAPITRE 5 OBJECTIFS ET MOTIVATIONS DES ATTAQUES CONTRE ANDROID
5.1 Nouveauté et divertissement
5.2 Vol et vente des informations de l’utilisateur
5.3 Abus des services payants
5.4 Pourriel via SMS
5.5 Vol des informations d’authentification de l’utilisateur
5.6 Extorsion
5.7 Empoisonnement des moteurs de recherche
5.8 Publiciel
5.9 Les motivations futures
5.9.1 La communication en champ proche (NFC)
5.9.2 DDoS
CHAPITRE 6 REVUE DE LITTÉRATURE DES SOLUTIONS DE SÉCURITÉ
PROPOSÉES POUR ANDROID
6.1 Utilisation des techniques existantes
6.2 Détection d’applications malveillantes
6.2.1 Les techniques de détection de logiciels malveillants
6.2.2 La détection des applications malveillantes pour Android
6.2.2.1 Détection autonome
6.2.2.2 Architecture client-serveur
6.2.2.3 Système collaboratif
6.3 Solutions étendant le modèle de permissions
6.3.1 APEX
6.3.2 CREPE
6.3.3 Kirin
6.3.4 Secure Application INTeraction (Saint)
6.3.4.1 Les politiques de Saint
6.3.4.2 Politique d’installation
6.3.4.3 La politique des interactions
6.3.4.4 Application de la politique d’installation
6.3.4.5 Application de la politique d’interaction
CHAPITRE 7 MÉTHODES DE DÉVOPPEMENT PROPOSÉES POUR SÉCURISER LES
APPLICATIONS ANDROID
7.1 Motivation et objectifs
7.2 Méthodes de protections existantes
7.2.1 Utilisation des permissions
7.2.2 Utilisation des composants privés
7.2.3 Sécuriser les données des applications
7.2.4 Sécuriser les intentions
7.3 Définition et application des politiques de sécurité pour les applications Android
7.3.1 Définition des politiques de sécurité
7.3.1.1 La politique basée sur l’identité des applications
7.3.1.2 La politique basée sur l’identité des développeurs d’applications
7.3.1.3 La politique basée sur les permissions
7.3.1.4 La politique basée sur les actions
7.3.2 Prototype de mise en œuvre des politiques
7.3.3 Certification et authentification des applications Android
7.3.3.1 Le service de certification
7.3.3.2 L’authentificateur
7.3.3.3 Vérification des contraintes d’utilisation
7.3.3.4 Application des politiques de sécurité lors de l’envoi d’une intention
7.3.4 Analyse des méthodes proposées
CONCLUSION
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES