Sécurité des applications

Cette page décrit différents aspects de la sécurité des applications.

Éléments des applications

Android fournit une plate-forme Open Source et un environnement d'application pour les appareils mobiles. Le système d'exploitation principal est basé sur le noyau Linux. Les applications Android sont le plus souvent écrites dans le langage de programmation Java et s'exécutent dans la machine virtuelle Android Runtime (ART). Toutefois, les applications peuvent également être écrites en code natif. Les applications sont installées à partir d'un seul fichier portant l'extension APK.

Voici les principaux blocs de construction des applications Android :

• AndroidManifest.xml : le fichier AndroidManifest.xml est le fichier de contrôle qui indique au système ce qu'il doit faire avec tous les composants de premier niveau (en particulier les activités, les services, les récepteurs de diffusion et les fournisseurs de contenu décrits ci-dessous) d'une application. Il spécifie également les autorisations requises.

• Activités : une activité est, en général, le code d'une tâche unique axée sur l'utilisateur à l'aide de la classe Activity. Une activité inclut généralement l'affichage d'une UI à l'utilisateur, mais ce n'est pas obligatoire. Certaines activités n'affichent jamais d'UI. En règle générale, l'une des activités de l'application est le point d'entrée d'une application.

• Services : un service est un corps de code qui s'exécute en arrière-plan, basé sur la classe Service. Il peut s'exécuter dans son propre processus ou dans le contexte du processus d'une autre application. D'autres composants se lient à un service et appellent des méthodes sur celui-ci via des appels de procédure à distance. Un lecteur multimédia est un exemple de service : même lorsque l'utilisateur quitte l'UI de sélection de contenu multimédia, il souhaite probablement que la musique continue d'être lue. Un service permet de continuer à écouter de la musique même lorsque l'UI est terminée.

• Broadcast receiver : un broadcast receiver est un objet de la classe BroadcastReceiver. Il est instancié lorsqu'un mécanisme IPC connu sous le nom d'intent, une instance de la classe Intent, est émis par le système d'exploitation ou une autre application. Une application peut enregistrer un récepteur pour le message de batterie faible, par exemple, et modifier son comportement en fonction de ces informations.

Modèle d'autorisation Android : accéder aux API protégées

Toutes les applications sur Android s'exécutent dans un bac à sable d'application. Par défaut, une application Android ne peut accéder qu'à une gamme limitée de ressources système. Le système gère l'accès des applications Android aux ressources qui, si elles sont utilisées de manière incorrecte ou malveillante, pourraient avoir un impact négatif sur l'expérience utilisateur, le réseau ou les données de l'appareil.

Ces restrictions sont mises en œuvre de différentes manières. Certaines fonctionnalités sont limitées par l'absence intentionnelle d'API pour les fonctionnalités sensibles (par exemple, il n'existe pas d'API Android permettant de manipuler directement la carte SIM). Dans certains cas, la séparation des rôles constitue une mesure de sécurité, comme avec l'isolation du stockage par application. Dans d'autres cas, les API sensibles sont destinées à être utilisées par des applications de confiance et sont protégées par un mécanisme de sécurité appelé "Autorisations".

Voici quelques exemples d'API protégées :

• Fonctions de l'appareil photo
• Données de localisation (GPS)
• Fonctionnalités Bluetooth
• Fonctions de téléphonie
• Fonctions SMS/MMS
• Connexions réseau/de données

Ces ressources ne sont accessibles que via le système d'exploitation. Pour utiliser les API protégées sur l'appareil, une application doit définir les fonctionnalités dont elle a besoin dans son fichier manifeste. Toutes les versions d'Android 6.0 et ultérieures utilisent un modèle d'autorisations d'exécution. Si un utilisateur demande une fonctionnalité d'une application qui nécessite une API protégée, le système affiche une boîte de dialogue invitant l'utilisateur à refuser ou autoriser l'autorisation.

Une fois accordées, les autorisations sont appliquées à l'application tant qu'elle est installée. Pour éviter toute confusion, le système n'informe pas à nouveau l'utilisateur des autorisations accordées à l'application. De plus, les applications incluses dans le système d'exploitation principal ou fournies par un OEM ne demandent pas d'autorisations à l'utilisateur. Les autorisations sont supprimées si une application est désinstallée. Par conséquent, une réinstallation ultérieure entraîne à nouveau l'affichage des autorisations.

Dans les paramètres de l'appareil, les utilisateurs peuvent afficher les autorisations des applications qu'ils ont déjà installées. Les utilisateurs peuvent également désactiver certaines fonctionnalités de manière globale lorsqu'ils le souhaitent, comme le GPS, la radio ou le Wi-Fi.

Si une application tente d'utiliser une fonctionnalité protégée qui n'a pas été déclarée dans son fichier manifeste, l'échec de l'autorisation entraîne généralement le renvoi d'une exception de sécurité à l'application. Les vérifications des autorisations d'API protégées sont appliquées au niveau le plus bas possible pour éviter toute tentative de contournement. La figure 2 montre un exemple de message utilisateur lorsqu'une application est installée tout en demandant l'accès à des API protégées.

Les autorisations système par défaut sont décrites dans Manifest.permission. Les applications peuvent déclarer leurs propres autorisations pour que d'autres applications les utilisent. Ces autorisations ne sont pas listées à l'emplacement ci-dessus.

Lors de la définition d'une autorisation, un attribut protectionLevel indique au système comment l'utilisateur doit être informé des applications nécessitant l'autorisation ou de qui peut la détenir. Pour savoir comment créer et utiliser des autorisations spécifiques à une application, consultez la checklist de sécurité.

Certaines fonctionnalités de l'appareil, telles que la possibilité d'envoyer des intents de diffusion de SMS, ne sont pas disponibles pour les applications tierces, mais peuvent être utilisées par les applications préinstallées par l'OEM. Ces autorisations utilisent l'autorisation signatureOrSystem.

Comment les utilisateurs comprennent-ils les applications tierces ?

Android s'efforce d'indiquer clairement aux utilisateurs lorsqu'ils interagissent avec des applications tierces et de les informer des fonctionnalités de ces applications. Avant d'installer une application, l'utilisateur reçoit un message clair sur les différentes autorisations demandées par l'application. Une fois l'application installée, l'utilisateur n'est plus invité à confirmer les autorisations.

Il existe de nombreuses raisons d'afficher les autorisations immédiatement avant l'installation. C'est le moment où l'utilisateur examine activement les informations sur l'application, le développeur et les fonctionnalités pour déterminer si elles correspondent à ses besoins et à ses attentes. Il est également important qu'ils n'aient pas encore établi d'engagement mental ou financier envers l'application, et qu'ils puissent facilement la comparer à d'autres applications alternatives.

D'autres plates-formes utilisent une approche différente pour la notification des utilisateurs, en demandant l'autorisation au début de chaque session ou lorsque les applications sont en cours d'utilisation. La vision d'Android est de permettre aux utilisateurs de passer d'une application à l'autre de manière fluide et à volonté. Demander une confirmation à chaque fois ralentirait l'utilisateur et empêcherait Android de lui offrir une excellente expérience. Le fait de demander à l'utilisateur de vérifier les autorisations au moment de l'installation lui donne la possibilité de ne pas installer l'application s'il ne se sent pas à l'aise.

De plus, de nombreuses études sur l'interface utilisateur ont montré qu'un excès d'invites à l'utilisateur l'incite à cliquer sur OK pour toute boîte de dialogue affichée. L'un des objectifs de sécurité d'Android est de communiquer efficacement des informations de sécurité importantes à l'utilisateur, ce qui ne peut pas être fait à l'aide de boîtes de dialogue que l'utilisateur est habitué à ignorer. En présentant les informations importantes une seule fois et uniquement lorsqu'elles le sont, l'utilisateur est plus susceptible de réfléchir à ce qu'il accepte.

Certaines plates-formes choisissent de ne pas afficher d'informations sur les fonctionnalités de l'application. Cette approche empêche les utilisateurs de comprendre et de discuter facilement des fonctionnalités de l'application. Bien qu'il ne soit pas possible pour tous les utilisateurs de toujours prendre des décisions pleinement éclairées, le modèle d'autorisations Android permet à un large éventail d'utilisateurs d'accéder facilement aux informations sur les applications. Par exemple, les demandes d'autorisation inattendues peuvent inciter les utilisateurs plus avertis à poser des questions essentielles sur les fonctionnalités de l'application et à partager leurs préoccupations sur des plateformes telles que Google Play, où elles sont visibles par tous les utilisateurs.

Autorisations lors de l'installation de l'application : Google Traduction	Autorisations d'une application installée : Gmail

Figure 1. Affichage des autorisations pour les applications.

Communication inter-processus

Les processus peuvent communiquer à l'aide de l'un des mécanismes traditionnels de type Unix. Il peut s'agir, par exemple, du système de fichiers, des sockets locaux ou des signaux. Toutefois, les autorisations Linux s'appliquent toujours.

Android fournit également de nouveaux mécanismes d'IPC :

• Binder : mécanisme d'appel de procédure à distance léger basé sur les capacités, conçu pour offrir des performances élevées lors des appels intra-processus et inter-processus. Binder est implémenté à l'aide d'un pilote Linux personnalisé. Pour obtenir une description de la classe, consultez Binder.

• Services : les services peuvent fournir des interfaces directement accessibles à l'aide du binder. Pour une description plus détaillée, consultez Éléments des applications.

• Intents : un intent est un simple objet de message qui représente une intention d'effectuer une action. Par exemple, si votre application souhaite afficher une page Web, elle exprime son intention d'afficher l'URL en créant une instance d'intent et en la transmettant au système. Le système localise un autre élément de code (dans ce cas, le navigateur) qui sait comment gérer cette intention et l'exécute. Les intents peuvent également être utilisés pour diffuser des événements intéressants (tels qu'une notification) à l'échelle du système. Pour obtenir une description de la classe, consultez Intent.

• Fournisseurs de contenu : un fournisseur de contenu est un entrepôt de données qui permet d'accéder aux données sur l'appareil. L'exemple classique est le fournisseur de contenu utilisé pour accéder à la liste de contacts de l'utilisateur. Une application peut accéder aux données que d'autres applications ont exposées avec un fournisseur de contenu. Elle peut également définir son propre fournisseur de contenu pour exposer ses propres données. Pour obtenir une description de la classe, consultez ContentProvider.

Bien qu'il soit possible d'implémenter l'IPC à l'aide d'autres mécanismes tels que les sockets réseau ou les fichiers accessibles en écriture, il s'agit des frameworks IPC Android recommandés. Nous encourageons les développeurs Android à suivre les bonnes pratiques pour sécuriser les données des utilisateurs et éviter d'introduire des failles de sécurité.

API sensibles aux coûts

Une API sensible aux coûts est une fonction susceptible de générer des coûts pour l'utilisateur ou le réseau. La plate-forme Android a placé les API sensibles aux coûts dans la liste des API protégées contrôlées par l'OS. L'utilisateur doit accorder une autorisation explicite aux applications tierces qui demandent à utiliser des API sensibles aux coûts. Voici la liste de ces API :

• Téléphonie
• SMS/MMS
• Réseau/Données
• Facturation via l'application
• Accès NFC

Android 4.2 offre un contrôle plus poussé sur l'utilisation des SMS. Android envoie une notification si une application tente d'envoyer un SMS à un numéro abrégé qui utilise des services premium susceptibles d'entraîner des frais supplémentaires. L'utilisateur peut choisir d'autoriser ou de bloquer l'envoi du message par l'application.

Accès à la carte SIM

Les applications tierces n'ont pas accès au niveau inférieur de la carte SIM. L'OS gère toutes les communications avec la carte SIM, y compris l'accès aux informations personnelles (contacts) stockées dans la mémoire de la carte SIM. Les applications ne peuvent pas non plus accéder aux commandes AT, car elles sont gérées exclusivement par la couche d'interface radio (RIL). La RIL ne fournit aucune API de haut niveau pour ces commandes.

Informations personnelles

Android a placé les API qui permettent d'accéder aux données utilisateur dans l'ensemble des API protégées. En cas d'utilisation normale, les appareils Android accumulent également des données utilisateur dans les applications tierces installées par les utilisateurs. Les applications qui choisissent de partager ces informations peuvent utiliser les vérifications des autorisations de l'OS Android pour protéger les données des applications tierces.

Figure 2. L'accès aux données utilisateur sensibles n'est possible que par le biais d'API protégées.

Les fournisseurs de contenu système susceptibles de contenir des informations personnelles ou permettant d'identifier personnellement l'utilisateur, telles que les contacts et l'agenda, ont été créés avec des autorisations clairement identifiées. Cette précision permet à l'utilisateur de savoir clairement quels types d'informations peuvent être fournis à l'application. Lors de l'installation, une application tierce peut demander l'autorisation d'accéder à ces ressources. Si l'autorisation est accordée, l'application peut être installée et avoir accès aux données demandées à tout moment lorsqu'elle est installée.

Par défaut, les données personnelles collectées par les applications sont limitées à l'application spécifique. Si une application choisit de rendre les données disponibles pour d'autres applications via l'IPC, l'application qui accorde l'accès peut appliquer des autorisations au mécanisme IPC qui sont appliquées par le système d'exploitation.

Périphériques de saisie de données sensibles

Les appareils Android fournissent fréquemment des périphériques de saisie de données sensibles qui permettent aux applications d'interagir avec l'environnement, comme l'appareil photo, le micro ou le GPS. Pour qu'une application tierce puisse accéder à ces appareils, l'utilisateur doit d'abord lui accorder explicitement l'accès à l'aide des autorisations de l'OS Android. Lors de l'installation, le programme d'installation invite l'utilisateur à autoriser l'accès au capteur par son nom.

Si une application souhaite connaître la position de l'utilisateur, elle a besoin d'une autorisation pour y accéder. Lors de l'installation, le programme d'installation demande à l'utilisateur si l'application peut accéder à sa position. À tout moment, si l'utilisateur ne souhaite pas qu'une application accède à sa position, il peut exécuter l'application Paramètres, accéder à Position et sécurité, puis désélectionner Utiliser les réseaux sans fil et Activer les satellites GPS. Cette action désactive les services basés sur la localisation pour toutes les applications sur l'appareil de l'utilisateur.

Métadonnées de l'appareil

Android s'efforce également de restreindre l'accès aux données qui ne sont pas intrinsèquement sensibles, mais qui peuvent indirectement révéler des caractéristiques sur l'utilisateur, ses préférences et la manière dont il utilise un appareil.

Par défaut, les applications n'ont pas accès aux journaux du système d'exploitation, à l'historique du navigateur, au numéro de téléphone ni aux informations d'identification du matériel ou du réseau. Si une application demande l'accès à ces informations lors de l'installation, le programme d'installation invite l'utilisateur à indiquer si l'application peut accéder aux informations. Si l'utilisateur n'accorde pas l'accès, l'application ne sera pas installée.

Autorités de certification

Android inclut un ensemble d'autorités de certification système installées, qui sont approuvées à l'échelle du système. Avant Android 7.0, les fabricants d'appareils pouvaient modifier l'ensemble des AC fournies sur leurs appareils. Toutefois, les appareils équipés d'Android 7.0 et versions ultérieures disposent d'un ensemble uniforme d'AC système, car les fabricants d'appareils ne sont plus autorisés à les modifier.

Pour être ajoutée en tant que nouvelle CA publique à l'ensemble Android par défaut, la CA doit suivre la procédure d'inclusion de CA de Mozilla, puis déposer une demande de fonctionnalité pour Android ( https://code.google.com/p/android/issues/entry) afin que la CA soit ajoutée à l'ensemble de CA Android par défaut dans le Projet Android Open Source (AOSP).

Il existe toujours des AC spécifiques aux appareils qui ne doivent pas être incluses dans l'ensemble principal des AC AOSP, comme les AC privées des opérateurs qui peuvent être nécessaires pour accéder de manière sécurisée aux composants de l'infrastructure de l'opérateur, tels que les passerelles SMS/MMS. Nous encourageons les fabricants d'appareils à n'inclure les autorités de certification privées que dans les composants/applications qui doivent leur faire confiance. Pour en savoir plus, consultez Configuration de la sécurité du réseau.

Signature d'application

La signature du code permet aux développeurs d'identifier l'auteur de l'application et de la mettre à jour sans créer d'interfaces ni d'autorisations complexes. Toutes les applications exécutées sur la plate-forme Android doivent être signées par le développeur. Les applications qui tentent de s'installer sans être signées sont refusées par Google Play ou par le programme d'installation de packages sur l'appareil Android.

Sur Google Play, la signature d'application permet de faire le lien entre la confiance que Google accorde au développeur et celle que le développeur accorde à son application. Les développeurs savent que leur application est fournie sans modification à l'appareil Android et peuvent être tenus responsables du comportement de leur application.

Sur Android, la signature d'application est la première étape pour placer une application dans son bac à sable. Le certificat d'application signé définit l'ID utilisateur associé à chaque application. Différentes applications s'exécutent sous différents ID utilisateur. La signature d'application garantit qu'une application ne peut accéder à aucune autre application, sauf par le biais d'IPC bien définis.

Lorsqu'une application (fichier APK) est installée sur un appareil Android, le gestionnaire de packages vérifie que l'APK a été correctement signé avec le certificat inclus dans cet APK. Si le certificat (ou, plus précisément, la clé publique du certificat) correspond à la clé utilisée pour signer un autre APK sur l'appareil, le nouvel APK peut spécifier dans le fichier manifeste qu'il partage un UID avec les autres APK signés de manière similaire.

Les applications peuvent être signées par un tiers (OEM, opérateur, marché alternatif) ou autosignées. Android fournit une signature de code à l'aide de certificats autosignés que les développeurs peuvent générer sans assistance ni autorisation externes. Les applications n'ont pas besoin d'être signées par une autorité centrale. Android n'effectue actuellement pas de vérification de l'autorité de certification pour les certificats d'application.

Les applications peuvent également déclarer des autorisations de sécurité au niveau de la protection de la signature, en limitant l'accès aux applications signées avec la même clé tout en conservant des UID et des bacs à sable d'application distincts. Une relation plus étroite avec une Application Sandbox partagée est autorisée via la fonctionnalité d'UID partagé, où deux applications ou plus signées avec la même clé de développeur peuvent déclarer un UID partagé dans leur fichier manifeste.

Validation de l'application

Android 4.2 et versions ultérieures sont compatibles avec la validation des applications. Les utilisateurs peuvent choisir d'activer Vérifier les applications pour que les applications soient évaluées par un outil de vérification avant leur installation. La validation des applications peut alerter l'utilisateur s'il tente d'installer une application potentiellement dangereuse. Si une application est particulièrement mauvaise, elle peut bloquer l'installation.

Gestion des droits numériques

La plate-forme Android fournit un framework de gestion des droits numériques (DRM) extensible qui permet aux applications de gérer les contenus protégés par des droits en fonction des contraintes de licence associées au contenu. Le framework DRM est compatible avec de nombreux schémas DRM. Les schémas DRM pris en charge par un appareil sont laissés à la discrétion du fabricant de l'appareil.

Le framework Android DRM est implémenté dans deux couches architecturales (voir figure 3) :

• Une API de framework DRM, qui est exposée aux applications via le framework d'application Android et qui s'exécute via la VM ART pour les applications standards.

• Un gestionnaire DRM de code natif, qui implémente le framework DRM et expose une interface pour les plug-ins (agents) DRM afin de gérer la gestion des droits et le déchiffrement pour différents schémas DRM

Figure 3. Architecture de la gestion des droits numériques sur la plate-forme Android.