Sécurité des applications

Éléments des applications

Android fournit une plate-forme et un environnement d'application Open Source pour les appareils mobiles. Le système d'exploitation principal est basé sur le noyau Linux. Les applications Android sont le plus souvent écrites en langage de programmation Java et exécutées 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.

Les principaux composants d'une application Android sont les suivants:

• 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 niveau supérieur (en particulier les activités, les services, les broadcast receivers et les fournisseurs de contenu décrits ci-dessous) d'une application. Il spécifie également les autorisations requises.

• Activités: une activité est généralement 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 de l'application.

• Services: un service est un corps de code exécuté en arrière-plan. 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 dessus 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 multimédia, il a probablement toujours l'intention de continuer à écouter de la musique. Un service permet de continuer à écouter de la musique même lorsque l'UI est terminée.

• Broadcast Receiver: un BroadcastReceiver est un objet instancié lorsqu'un mécanisme IPC appelé 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, peuvent avoir un impact négatif sur l'expérience utilisateur, le réseau ou les données de l'appareil.

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

Voici la liste de ces API:

• Fonctions de l'appareil photo
• Données de localisation (GPS)
• Fonctions Bluetooth
• Fonctions de téléphonie
• Fonctions SMS/MMS
• Connexions réseau/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 Android 6.0 et ultérieures utilisent un modèle d'autorisations d'exécution. Si un utilisateur demande une fonctionnalité à 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 plus l'utilisateur des autorisations accordées à l'application. Les applications incluses dans le système d'exploitation principal ou groupées par un OEM ne demandent pas d'autorisations à l'utilisateur. Les autorisations sont supprimées si une application est désinstallée. Une réinstallation ultérieure entraîne donc à nouveau l'affichage des autorisations.

Dans les paramètres de l'appareil, les utilisateurs peuvent consulter les autorisations des applications qu'ils ont installées précédemment. Les utilisateurs peuvent également désactiver certaines fonctionnalités de manière globale s'ils le souhaitent, par exemple 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 le fichier manifeste de l'application, l'échec de l'autorisation entraîne généralement le retour d'une exception de sécurité dans l'application. Les vérifications des autorisations d'API protégées sont appliquées au niveau le plus bas possible pour éviter toute contournement. La figure 2 présente un exemple de message utilisateur lorsqu'une application est installée tout en demandant l'accès à des API protégées.

Les autorisations par défaut du système sont décrites à l'adresse https://developer.android.com/reference/android/Manifest.permission.html. Les applications peuvent déclarer leurs propres autorisations pour que d'autres applications puissent les utiliser. Ces autorisations ne sont pas listées à l'emplacement indiqué 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 en savoir plus sur la création et l'utilisation d'autorisations spécifiques à une application, consultez la page https://developer.android.com/guide/topics/security/security.html.

Certaines fonctionnalités de l'appareil, telles que la possibilité d'envoyer des intents de diffusion par 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 de faire savoir aux utilisateurs quand ils interagissent avec des applications tierces et de les informer des fonctionnalités de ces applications. Avant l'installation d'une application, un message clair s'affiche pour l'utilisateur concernant les différentes autorisations demandées par l'application. Après l'installation, l'utilisateur n'est plus invité à confirmer les autorisations.

De nombreuses raisons peuvent expliquer pourquoi vous devez afficher les autorisations immédiatement avant l'installation. Il s'agit du 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.

Certaines autres plates-formes adoptent une approche différente pour les notifications aux utilisateurs, en demandant l'autorisation au début de chaque session ou lorsque les applications sont utilisées. L'objectif d'Android est de permettre aux utilisateurs de passer facilement d'une application à l'autre à leur guise. Fournir des confirmations à chaque fois ralentirait l'utilisateur et empêcherait Android de lui offrir une expérience utilisateur de qualité. Demander à l'utilisateur d'examiner les autorisations au moment de l'installation lui permet 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é que trop de requêtes à l'utilisateur le poussent à répondre "OK" à toutes les boîtes de dialogue qui s'affichent. L'un des objectifs de sécurité d'Android est de transmettre 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 apprendra à ignorer. En présentant les informations importantes une seule fois, et uniquement lorsqu'elles sont importantes, l'utilisateur est plus susceptible de réfléchir à ce à quoi il accepte.

Certaines plates-formes choisissent de ne pas afficher aucune information 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 prendre toujours des décisions é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'autorisations inattendues peuvent inciter les utilisateurs plus expérimentés à poser des questions critiques sur le fonctionnement de l'application et à partager leurs préoccupations dans des endroits tels 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 n'importe quel mécanisme de type UNIX traditionnel. Exemples : système de fichiers, sockets locaux ou signaux. Toutefois, les autorisations Linux continuent de s'appliquer.

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

• Liaison: mécanisme d'appel de procédure à distance léger basé sur les capacités, conçu pour des performances élevées lors des appels intra-processus et inter-processus. Le liaisonneur est implémenté à l'aide d'un pilote Linux personnalisé. Voir https://developer.android.com/reference/android/os/Binder.html.

• Services: les services (décrits ci-dessus) peuvent fournir des interfaces directement accessibles à l'aide d'un liant.

• Intents: un intent est un objet de message simple qui représente une "intention" d'effectuer une action. Par exemple, si votre application souhaite afficher une page Web, elle exprime son "intent" pour afficher l'URL en créant une instance d'intent et en la transmettant au système. Le système recherche un autre élément de code (dans ce cas, le navigateur) qui sait gérer cet intent, puis l'exécute. Les intents peuvent également être utilisés pour diffuser des événements intéressants (comme une notification) à l'échelle du système. Voir https://developer.android.com/reference/android/content/Intent.html.

• ContentProvider: un ContentProvider est un entrepôt de données qui fournit un accès aux données de l'appareil. L'exemple classique est le ContentProvider 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 via un ContentProvider. Elle peut également définir ses propres ContentProviders pour exposer ses propres données. Consultez la page https://developer.android.com/reference/android/content/ContentProvider.html.

Bien qu'il soit possible d'implémenter l'IPC à l'aide d'autres mécanismes tels que des sockets réseau ou des fichiers accessibles en écriture, il s'agit des frameworks IPC Android recommandés. Les développeurs Android seront encouragés à suivre les bonnes pratiques en matière de sécurisation des données des utilisateurs et d'évitement de l'introduction de 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 devra 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 court qui utilise des services premium pouvant entraîner des frais supplémentaires. L'utilisateur peut choisir d'autoriser l'application à envoyer le message ou de le bloquer.

Accès à la carte SIM

Les applications tierces n'ont pas accès à 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 sa mémoire. 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). Le RIL ne fournit aucune API de haut niveau pour ces commandes.

Informations personnelles

Android a placé les API qui donnent accès 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 d'autorisations de l'OS Android pour protéger les données contre les applications tierces.

Figure 2. L'accès aux données utilisateur sensibles n'est disponible que via des API protégées.

Les fournisseurs de contenu système susceptibles de contenir des informations personnelles ou permettant d'identifier personnellement l'utilisateur (contacts et agenda, par exemple) ont été créés avec des autorisations clairement identifiées. Cette précision indique clairement à l'utilisateur les types d'informations qui 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 aura accès aux données demandées à tout moment lors de son installation.

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

Périphériques d'entrée de données sensibles

Les appareils Android fournissent fréquemment des dispositifs d'entrée de données sensibles qui permettent aux applications d'interagir avec l'environnement environnant, tels que 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 à demander l'autorisation d'accéder au capteur par nom.

Si une application souhaite connaître la position de l'utilisateur, elle doit disposer 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écocher les options "Utiliser les réseaux sans fil" et "Activer les satellites GPS". Cela désactivera les services basés sur la position pour toutes les applications de l'appareil de l'utilisateur.

Métadonnées de l'appareil

Android s'efforce également de limiter 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 matérielle / réseau. Si une application demande à accéder à ces informations au moment de l'installation, le programme d'installation invite l'utilisateur à indiquer si l'application peut y accéder. 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 autorités de certification fournies sur leurs appareils. Toutefois, les appareils équipés d'Android 7.0 ou version ultérieure disposeront d'un ensemble uniforme d'autorités de certification système, car les modifications apportées par les fabricants d'appareils ne sont plus autorisées.

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

Il existe encore des autorités de certification spécifiques à l'appareil qui ne doivent pas être incluses dans l'ensemble de base des autorités de certification AOSP, comme les autorités de certification 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. Les fabricants d'appareils sont invités à n'inclure les autorités de certification privées que dans les composants/applications qui doivent leur faire confiance. Pour en savoir plus, consultez la section Configuration de la sécurité du réseau.

Signature d'application

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

Sur Google Play, la signature d'application permet de s'assurer que Google fait confiance au développeur et que le développeur fait confiance à son application. Les développeurs savent que leur application est fournie, non modifiée, sur l'appareil Android. Ils peuvent également ê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 pas accéder à une autre application que via un IPC bien défini.

Lorsqu'une application (fichier APK) est installée sur un appareil Android, le Gestionnaire de paquets 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 tout autre APK sur l'appareil, le nouvel APK peut spécifier dans le fichier manifeste qu'il partagera un UID avec les autres APK signés de la même manière.

Les applications peuvent être signées par un tiers (OEM, opérateur, marché alternatif) ou autosignées. Android fournit la 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 validation de l'autorité de certification pour les certificats d'application.

Les applications peuvent également déclarer des autorisations de sécurité au niveau du niveau de 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 un Application Sandbox partagé est autorisée via la fonctionnalité d'UID partagé, qui permet à deux applications ou plus signées avec la même clé de développeur de déclarer un UID partagé dans leur fichier manifeste.

Validation des applications

Android 4.2 et versions ultérieures sont compatibles avec la validation des applications. Les utilisateurs peuvent choisir d'activer "Vérifier les applications" et de faire évaluer les applications par un vérificateur d'applications 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 dangereuse, elle peut bloquer l'installation.

Gestion des droits numériques

La plate-forme Android fournit un framework extensible de gestion des droits numériques (DRM) qui permet aux applications de gérer le contenu protégé par des droits en fonction des contraintes de licence associées au contenu. Le framework DRM est compatible avec de nombreux schémas DRM. Le fabricant de l'appareil est responsable de la sélection des schémas DRM compatibles avec l'appareil.

Le framework DRM Android est implémenté en deux couches architecturales (voir figure ci-dessous):

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

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

Figure 3. Architecture du DRM sur la plate-forme Android