Éléments d'application
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 exécutées dans la machine virtuelle Dalvik. Cependant, les applications peuvent également être écrites en code natif. Les applications sont installées à partir d'un seul fichier avec l'extension de fichier .apk.
Les principaux éléments constitutifs de l'application 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 les autorisations requises.
Activités : Une activité est, généralement, le code d'une tâche unique, centrée sur l'utilisateur. Cela inclut généralement l'affichage d'une interface utilisateur à 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 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. 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 sur celui-ci 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 multimédia, l'utilisateur a probablement toujours l'intention de continuer à jouer de la musique. 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 enregistrer un récepteur pour le message de batterie faible, par exemple, et modifier son comportement en fonction de ces informations.
Le modèle d'autorisation Android : accéder aux API protégées
Toutes les applications sur Android s'exécutent dans une 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 sur l'appareil.
Ces restrictions sont mises en œuvre sous différentes formes. Certaines fonctionnalités sont limitées par un manque intentionnel d'API à la fonctionnalité sensible (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 fournit 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 protégées par un mécanisme de sécurité appelé autorisations.
Ces API protégées incluent :
- 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 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é à partir 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 chez l'utilisateur, le système ne notifie plus l'utilisateur 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, de sorte qu'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 à l'échelle mondiale 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 de l'API protégée sont appliqués au niveau le plus bas possible pour empêcher tout contournement. Un exemple de messagerie utilisateur lorsqu'une application est installée lors d'une demande d'accès à des API protégées est illustré à 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 les utilisent. 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 des autorisations spécifiques à l'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 par SMS, ne sont pas disponibles pour les applications tierces, mais peuvent être utilisées par des applications préinstallées par l'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 de 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 juste avant l'installation. C'est à ce moment 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 à leurs 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 de la notification des utilisateurs, demandant l'autorisation au début de chaque session ou pendant que les applications sont en cours d'utilisation. 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'en invitant trop l'utilisateur, l'utilisateur commence à dire "OK" à toute 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 entraîné à 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 s'engage.
Certaines plates-formes choisissent de ne montrer 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 toujours prendre des décisions en toute connaissance de cause, le modèle d'autorisations d'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 sophistiqués à 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 pour tous les utilisateurs.
| Autorisations lors de l'installation de l'application -- Google Maps | Autorisations d'une application installée - Gmail |
 |  |
Figure 1. Affichage des autorisations pour les applications
Communication interprocessus
Les processus peuvent communiquer à l'aide de n'importe quel mécanisme traditionnel de type UNIX. Les exemples incluent le système de fichiers, les sockets locaux ou les signaux. Cependant, les autorisations Linux s'appliquent toujours.
Android fournit également de nouveaux mécanismes IPC :
Binder : Un mécanisme léger d'appel de procédure à distance basé sur les capacités conçu pour des performances élevées lors de l'exécution d'appels in-process et inter-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 de binder.
Intents : Un Intent est un objet message simple 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 (tels qu'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 qui est 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 par le monde, 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 plate-forme 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 intégrée à 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 qui utilise 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 pas d'API de haut niveau pour ces commandes.
Renseignements personnels
Android a placé les API qui permettent d'accéder aux données des utilisateurs 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 n'est disponible que via des API protégées
Les fournisseurs de contenu du système susceptibles de contenir des informations personnelles ou personnellement identifiables telles que les contacts et le 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.
Toutes les applications qui collectent des informations personnelles verront, par défaut, ces données limitées uniquement à l'application spécifique. Si une application choisit de mettre les données à la disposition d'autres applications via IPC, l'application accordant 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 d'entrée de données sensibles qui permettent aux applications d'interagir avec l'environnement environnant, comme l'appareil photo, le microphone ou le GPS. Pour qu'une application tierce puisse accéder à ces appareils, l'utilisateur doit d'abord lui fournir explicitement l'accès via l'utilisation des autorisations du système d'exploitation Android. Lors de l'installation, le programme d'installation demandera à l'utilisateur de demander l'autorisation d'accéder au capteur par son nom.
Si une application veut connaître l'emplacement de l'utilisateur, l'application 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. À tout moment, si l'utilisateur ne souhaite pas qu'une application accède à sa position, il peut exécuter l'application "Paramètres", aller dans "Localisation et sécurité" et décocher les cases "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 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 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 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. Cependant, les appareils exécutant 7.0 et versions ultérieures auront un ensemble uniforme d'autorités de certification système, car la modification par les fabricants d'appareils n'est plus autorisée.
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é contre Android ( https://code.google.com/p/android/issues/entry ) pour que l'autorité de certification soit ajoutée au stock Android CA défini dans le projet Android Open Source (AOSP).
Il existe encore des autorités de certification spécifiques à l'appareil et 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 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, voir Configuration de la sécurité réseau .
Signature d'applications
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 et d'autorisations compliquées. 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 le programme d'installation du package sur l'appareil Android.
Sur Google Play, la signature d'application établit un pont entre la confiance que Google a avec le développeur et la confiance que le développeur a avec son application. Les développeurs savent que leur application est fournie sans modification à 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 ID 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 applications 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 externes. Les demandes ne doivent pas être signées par une autorité centrale. Actuellement, Android n'effectue pas de vérification CA pour les certificats d'application.
Les applications peuvent également déclarer des autorisations de sécurité au niveau de la protection de la signature, limitant l'accès uniquement aux applications signées avec la même clé tout en conservant des UID et des sandbox 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 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 essaie d'installer une application qui pourrait être nuisible ; 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 cadre DRM prend en charge 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é 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 s'exécute via la machine virtuelle Dalvik pour les applications standard.
Un gestionnaire DRM de code natif, qui implémente le cadre DRM et expose une interface pour les plug-ins DRM (agents) pour gérer la gestion des droits et le déchiffrement pour divers schémas DRM
Figure 3. Architecture de la gestion des droits numériques sur la plate-forme Android