Éléments des candidatures
Android fournit une plate-forme open source et un environnement d'applications 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 exécutées sur la machine virtuelle Android Runtime (ART). Cependant, les applications peuvent également être écrites en code natif. Les applications sont installées à partir d'un seul fichier portant l'extension de fichier .apk.
Les principaux éléments constitutifs des applications Android sont :
AndroidManifest.xml : Le fichier AndroidManifest.xml est le fichier de contrôle qui indique au système quoi faire avec tous les composants de niveau supérieur (en particulier les activités, les services, les récepteurs de diffusion et les fournisseurs de contenu décrits ci-dessous) dans une application. Cela spécifie également quelles autorisations sont requises.
Activités : une activité est, généralement, le code d'une tâche unique axée sur l'utilisateur. Cela inclut généralement l’affichage d’une interface utilisateur pour l’utilisateur, mais ce n’est pas obligatoire : certaines activités n’affichent jamais d’interface utilisateur. Généralement, l'une des activités de l'application constitue le point d'entrée d'une application.
Services : Un service est un corps de code qui s'exécute 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 invoquent des méthodes via des appels de procédure à distance. Un exemple de service est un lecteur multimédia : même lorsque l'utilisateur quitte l'interface utilisateur de sélection de média, il souhaite probablement toujours que la musique continue à être diffusée. Un service maintient la musique même lorsque l'interface utilisateur est terminée.
Broadcast Receiver : Un BroadcastReceiver est un objet qui est instancié lorsqu'un mécanisme IPC appelé Intent est émis par le système d'exploitation ou une autre application. Une application peut, par exemple, enregistrer un récepteur pour le message de batterie faible et modifier son comportement en fonction de ces informations.
Le modèle d'autorisation Android : accès aux API protégées
Toutes les applications sur Android s'exécutent dans un Application Sandbox . 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 sous diverses formes. Certaines capacités sont limitées par un manque intentionnel d'API aux fonctionnalités sensibles (par exemple, il n'y a pas d'API Android pour manipuler directement la carte SIM). Dans certains cas, la séparation des rôles constitue une mesure de sécurité, comme dans le cas de 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 protégées par un mécanisme de sécurité appelé autorisations.
Ces API protégées incluent :
- Fonctions de la caméra
- 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 manifeste. Toutes les versions d'Android 6.0 et supé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 chez l'utilisateur, le système ne l'informe plus des autorisations accordées à l'application, et les applications incluses dans le système d'exploitation principal ou regroupées par un OEM ne demandent pas d'autorisations à l'utilisateur. Les autorisations sont supprimées si une application est désinstallée, donc une réinstallation ultérieure entraînera à nouveau l'affichage des autorisations.
Dans les paramètres de l'appareil, les utilisateurs peuvent afficher les autorisations pour les applications qu'ils ont précédemment installées. Les utilisateurs peuvent également désactiver certaines fonctionnalités globalement lorsqu'ils le souhaitent, comme la désactivation du GPS, de la radio ou du Wi-Fi.
Dans le cas où une application tente d'utiliser une fonctionnalité protégée qui n'a pas été déclarée dans le manifeste de l'application, l'échec de l'autorisation entraînera généralement le renvoi d'une exception de sécurité à l'application. Les contrôles d'autorisation des API protégées sont appliqués au niveau le plus bas possible pour éviter tout contournement. Un exemple de messagerie utilisateur lorsqu'une application est installée tout en demandant l'accès à des API protégées est présenté dans la figure 2 .
Les autorisations par défaut du système sont décrites sur 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 répertorié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 qui est autorisé à détenir une autorisation. Les détails sur la création et l'utilisation d'autorisations spécifiques à une application sont décrits sur https://developer.android.com/guide/topics/security/security.html .
Certaines fonctionnalités de l'appareil, telles que la possibilité d'envoyer des intentions de diffusion de SMS, ne sont pas disponibles pour les applications tierces, mais peuvent être utilisées par des applications préinstallées par le fabricant OEM. Ces autorisations utilisent l'autorisation signatureOrSystem.
Comment les utilisateurs comprennent les applications tierces
Android s'efforce d'indiquer clairement aux utilisateurs lorsqu'ils interagissent avec des applications tierces et d'informer l'utilisateur des capacités dont disposent ces applications. Avant l'installation de toute application, l'utilisateur reçoit un message clair sur les différentes autorisations demandées par l'application. Après l'installation, 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 à ce moment-là que l'utilisateur examine activement les informations sur l'application, le développeur et les fonctionnalités pour déterminer si elles correspondent à leurs besoins et 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 comparer l’application à d’autres applications alternatives.
Certaines autres plates-formes utilisent une approche différente en matière de notification aux utilisateurs, demandant l'autorisation au début de chaque session ou pendant l'utilisation des applications. La vision d'Android est de permettre aux utilisateurs de basculer de manière transparente entre les applications, à volonté. Fournir des confirmations à chaque fois ralentirait l’utilisateur et empêcherait Android d’offrir une expérience utilisateur exceptionnelle. Le fait que l'utilisateur examine les autorisations au moment de l'installation donne à l'utilisateur la possibilité de ne pas installer l'application s'il se sent mal à l'aise.
En outre, de nombreuses études sur l'interface utilisateur ont montré qu'une invite excessive de l'utilisateur l'amène à dire « OK » dans n'importe quelle boîte de dialogue affichée. 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 sera formé à ignorer. En présentant les informations importantes une seule fois, et seulement lorsqu'elles sont importantes, l'utilisateur est plus susceptible de réfléchir à ce qu'il accepte.
Certaines plates-formes choisissent de n’afficher aucune information sur les fonctionnalités des applications. Cette approche empêche les utilisateurs de comprendre et de discuter facilement des capacités des applications. 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 rend les informations sur les applications facilement accessibles à un large éventail d'utilisateurs. Par exemple, des demandes d'autorisations inattendues peuvent inciter des utilisateurs plus avertis à poser des questions critiques sur les fonctionnalités 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 Translate | Autorisations d'une application installée - Gmail |
 |  |
Figure 1. Affichage des autorisations pour les applications
Communication interprocessus
Les processus peuvent communiquer en utilisant n'importe lequel des mécanismes traditionnels de type UNIX. Les exemples incluent le système de fichiers, les sockets locales ou les signaux. Cependant, les autorisations Linux s'appliquent toujours.
Android propose également de nouveaux mécanismes IPC :
Binder : un mécanisme d'appel de procédure à distance léger basé sur les capacités, conçu pour des performances élevées lors de l'exécution d'appels en cours de processus et entre processus. Binder est implémenté à l’aide d’un pilote Linux personnalisé. Voir https://developer.android.com/reference/android/os/Binder.html .
Services : les services (discutés ci-dessus) peuvent fournir des interfaces directement accessibles à l'aide du classeur.
Intents : une intention est un simple objet de message qui représente une "intention" de faire quelque chose. Par exemple, si votre application souhaite afficher une page Web, elle exprime son « intention » d'afficher l'URL en créant une instance d'intention et en la transmettant au système. Le système localise un autre morceau de code (dans ce cas, le navigateur) qui sait comment gérer cette intention et l'exécute. Les intentions peuvent également être utilisées 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 .
ContentProviders : un ContentProvider est un entrepôt de données qui permet d'accéder aux données sur 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, et une application peut également définir ses propres ContentProviders pour exposer ses propres données. Voir https://developer.android.com/reference/android/content/ContentProvider.html .
Bien qu'il soit possible d'implémenter IPC à l'aide d'autres mécanismes tels que des sockets réseau ou des fichiers inscriptibles partout, ce sont les frameworks Android IPC recommandés. Les développeurs Android seront encouragés à utiliser les meilleures pratiques pour sécuriser les données des utilisateurs et éviter l'introduction de failles de sécurité.
API sensibles aux coûts
Une API sensible aux coûts est toute fonction susceptible de générer un coût pour l'utilisateur ou le réseau. La plateforme Android a placé les API sensibles aux coûts dans la liste des API protégées contrôlées par le système d'exploitation. L'utilisateur devra accorder une autorisation explicite aux applications tierces demandant l'utilisation d'API sensibles aux coûts. Ces API incluent :
- Téléphonie
- SMS/MMS
- Réseau/Données
- Facturation via l'application
- Accès NFC
Android 4.2 ajoute un contrôle supplémentaire sur l'utilisation des SMS. Android fournira une notification si une application tente d'envoyer des SMS à un code court utilisant des services premium, ce qui pourrait 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
L'accès de bas niveau à la carte SIM n'est pas disponible pour les applications tierces. Le système d'exploitation gère toutes les communications avec la carte SIM, y compris l'accès aux informations personnelles (contacts) sur la mémoire de la carte SIM. Les applications ne peuvent pas non plus accéder aux commandes AT, car celles-ci 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 permettent d'accéder aux données utilisateur dans l'ensemble des API protégées. Avec une utilisation normale, les appareils Android accumuleront également des données utilisateur dans des applications tierces installées par les utilisateurs. Les applications qui choisissent de partager ces informations peuvent utiliser les contrôles d'autorisation du système d'exploitation Android pour protéger les données des applications tierces.
Figure 2. L'accès aux données utilisateur sensibles est disponible uniquement via des API protégées
Les fournisseurs de contenu système susceptibles de contenir des informations personnelles ou identifiables telles que des contacts et un calendrier ont été créés avec des autorisations clairement identifiées. Cette granularité fournit à l'utilisateur une indication claire des types d'informations pouvant être fournies à 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, toutes les applications qui collectent des informations personnelles verront ces données limitées uniquement à l'application spécifique. Si une application choisit de rendre les données disponibles à d'autres applications via 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 d'entrée 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 une caméra, un microphone ou un GPS. Pour qu'une application tierce puisse accéder à ces appareils, l'utilisateur doit d'abord y accéder explicitement via l'utilisation des autorisations du système d'exploitation Android. Lors de l'installation, le programme d'installation invitera l'utilisateur à demander l'autorisation d'accéder au capteur par son nom.
Si une application souhaite connaître l'emplacement de l'utilisateur, elle nécessite une autorisation pour accéder à l'emplacement de l'utilisateur. Lors de l'installation, le programme d'installation demandera à l'utilisateur si l'application peut accéder à l'emplacement de l'utilisateur. A tout moment, si l'utilisateur ne souhaite qu'aucune application accède à sa localisation, il peut alors exécuter l'application « Paramètres », accéder à « Localisation et sécurité » et décocher « Utiliser les réseaux sans fil » et « Activer les satellites GPS ». . Cela désactivera 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 de 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 ou aux informations d'identification du matériel/réseau. Si une application demande l'accès à ces informations au moment de l'installation, le programme d'installation demandera à l'utilisateur 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 comprend un ensemble d'autorités de certification système installées, qui sont fiables à 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. Cependant, les appareils exécutant la version 7.0 et supérieure disposeront d'un ensemble uniforme d'autorités de certification système, car les modifications par les fabricants d'appareils ne sont plus autorisées.
Pour être ajoutée en tant que nouvelle autorité de certification publique à l'ensemble de stock Android, l'autorité de certification doit terminer le processus d'inclusion de l'autorité de certification Mozilla , puis déposer une demande de fonctionnalité sur Android ( https://code.google.com/p/android/issues/entry ). pour que l'autorité de certification soit ajoutée à l'autorité de certification Android d'origine définie dans le projet Android Open Source (AOSP).
Il existe encore des autorités de certification spécifiques à l'appareil et qui ne devraient 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 en toute sécurité aux composants de l'infrastructure de l'opérateur, tels que les passerelles SMS/MMS. Les fabricants d'appareils sont encouragés à inclure les autorités de certification privées uniquement dans les composants/applications qui doivent faire confiance à ces autorités de certification. Pour plus de détails, consultez Configuration de la sécurité réseau .
Signature d'application
La signature de code permet aux développeurs d'identifier l'auteur de l'application et de mettre à jour leur application sans créer d'interfaces ni d'autorisations compliquées. Chaque application exécutée sur la plateforme 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 établit un lien entre la confiance que Google accorde au développeur et la confiance que le développeur a envers son application. Les développeurs savent que leur application est fournie, non modifiée, sur l'appareil Android ; et les développeurs 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 Application Sandbox. Le certificat d'application signé définit quel identifiant utilisateur est associé à quelle 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 via un IPC bien défini.
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 tout autre APK sur l'appareil, le nouvel APK a la possibilité de spécifier dans le manifeste qu'il partagera un UID avec l'autre de la même manière. -APK signés.
Les candidatures peuvent être signées par un tiers (OEM, opérateur, marché alternatif) ou auto-signées. Android fournit la signature de code à l'aide de certificats auto-signés que les développeurs peuvent générer sans assistance ni autorisation externe. Les candidatures ne doivent pas nécessairement être signées par une autorité centrale. Android n'effectue actuellement pas de vérification CA pour les certificats d'application.
Les applications sont également capables de déclarer des autorisations de sécurité au niveau de protection Signature, limitant l'accès uniquement 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é 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 manifeste.
Vérification des candidatures
Android 4.2 et versions ultérieures prennent en charge la vérification des applications. Les utilisateurs peuvent choisir d'activer « Vérifier les applications » et faire évaluer les applications par un vérificateur d'applications avant l'installation. La vérification des applications peut alerter l'utilisateur s'il tente d'installer une application qui pourrait être dangereuse ; si une application est particulièrement mauvaise, elle peut bloquer l'installation. .
Gestion des droits numériques
La plate-forme Android fournit un cadre DRM extensible 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 prend en charge de nombreux schémas DRM ; Les schémas DRM pris en charge par un appareil sont laissés au fabricant de l'appareil.
Le framework Android DRM 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'applications Android et s'exécute via la VM ART pour les applications standard.
Un gestionnaire DRM en code natif, qui implémente le cadre DRM et expose une interface pour les plug-ins DRM (agents) afin de gérer la gestion des droits et le décryptage pour divers schémas DRM.
Figure 3. Architecture de la gestion des droits numériques sur la plateforme Android