Au niveau du système d'exploitation, la plate-forme Android offre la sécurité du noyau Linux, ainsi qu'une fonction de communication inter-processus sécurisée (IPC) pour permettre une communication sécurisée entre les applications exécutées dans différents processus. Ces fonctionnalités de sécurité au niveau du système d'exploitation garantissent que même le code natif est limité par l'Application Sandbox. Que ce code soit le résultat d'un comportement d'application inclus ou de l'exploitation d'une vulnérabilité d'application, le système est conçu pour empêcher l'application malveillante de nuire à d'autres applications, au système Android ou à l'appareil lui-même. Voir Configuration du noyau pour les mesures que vous pouvez prendre pour renforcer le noyau sur vos appareils. Consultez le document de définition de compatibilité Android (CDD) pour les paramètres requis.
Sécurité Linux
La base de la plate-forme Android est le noyau Linux. Le noyau Linux est largement utilisé depuis des années et est utilisé dans des millions d'environnements sensibles à la sécurité. Grâce à son historique de recherches, d'attaques et de réparations constantes par des milliers de développeurs, Linux est devenu un noyau stable et sécurisé auquel de nombreuses entreprises et professionnels de la sécurité font confiance.
En tant que base d'un environnement informatique mobile, le noyau Linux fournit à Android plusieurs fonctionnalités de sécurité clés, notamment :
- Un modèle d'autorisations basé sur l'utilisateur
- Isolement du processus
- Mécanisme extensible pour IPC sécurisé
- La possibilité de supprimer les parties inutiles et potentiellement non sécurisées du noyau
En tant que système d'exploitation multi-utilisateurs, un objectif de sécurité fondamental du noyau Linux est d'isoler les ressources utilisateur les unes des autres. La philosophie de sécurité Linux est de protéger les ressources utilisateur les unes des autres, Linux :
- Empêche l'utilisateur A de lire les fichiers de l'utilisateur B
- Garantit que l'utilisateur A n'épuise pas la mémoire de l'utilisateur B
- Garantit que l'utilisateur A n'épuise pas les ressources CPU de l'utilisateur B
- Garantit que l'utilisateur A n'épuise pas les appareils de l'utilisateur B (par exemple, téléphonie, GPS et Bluetooth)
Le bac à sable des applications
La sécurité des applications d'Android est renforcée par le bac à sable des applications, qui isole les applications les unes des autres et protège les applications et le système contre les applications malveillantes. Pour plus de détails, voir Application Sandbox .
Partition système et mode sans échec
Les différentes partitions protégées par l'intégrité contiennent le noyau d'Android ainsi que les bibliothèques du système d'exploitation, l'exécution de l'application, le cadre de l'application et les applications. Cette partition est définie en lecture seule. Lorsqu'un utilisateur démarre l'appareil en mode sans échec, les applications tierces peuvent être lancées manuellement par le propriétaire de l'appareil mais ne sont pas lancées par défaut.
Autorisations du système de fichiers
Dans un environnement de type UNIX, les autorisations du système de fichiers garantissent qu'un utilisateur ne peut pas modifier ou lire les fichiers d'un autre utilisateur. Dans le cas d'Android, chaque application s'exécute comme son propre utilisateur. À moins que le développeur ne partage explicitement des fichiers avec d'autres applications, les fichiers créés par une application ne peuvent pas être lus ou modifiés par une autre application.
Linux à sécurité renforcée
Android utilise Security-Enhanced Linux (SELinux) pour appliquer des politiques de contrôle d'accès et établir un contrôle d'accès obligatoire (mac) sur les processus. Voir Security-Enhanced Linux in Android pour plus de détails.
Botte vérifiée
Android 7.0 et versions ultérieures prennent en charge le démarrage vérifié strictement appliqué, ce qui signifie que les appareils compromis ne peuvent pas démarrer. Le démarrage vérifié garantit l'intégrité du logiciel de l'appareil à partir d'une racine matérielle de confiance jusqu'à la partition système. Lors du démarrage, chaque étape vérifie de manière cryptographique l'intégrité et l'authenticité de l'étape suivante avant de l'exécuter.
Voir Botte vérifiée pour plus de détails.
Cryptographie
Android fournit un ensemble d'API cryptographiques à utiliser par les applications. Celles-ci incluent des implémentations de primitives cryptographiques standard et couramment utilisées telles que AES, RSA, DSA et SHA. De plus, des API sont fournies pour les protocoles de niveau supérieur tels que SSL et HTTPS.
Android 4.0 a introduit la classe KeyChain pour permettre aux applications d'utiliser le stockage des informations d'identification du système pour les clés privées et les chaînes de certificats.
Enracinement des appareils
Par défaut, sur Android, seul le noyau et un petit sous-ensemble des services principaux s'exécutent avec des autorisations root. SELinux contraint toujours les processus de l'espace utilisateur exécutés en tant que root. Le démarrage vérifié empêche un utilisateur ou un service disposant d'autorisations root de modifier de manière permanente le système d'exploitation.
La possibilité de modifier un appareil Android qu'ils possèdent est importante pour les développeurs travaillant avec la plate-forme Android. Sur de nombreux appareils Android, les utilisateurs ont la possibilité de déverrouiller le chargeur de démarrage afin de permettre l'installation d'un autre système d'exploitation. Ces systèmes d'exploitation alternatifs peuvent permettre à un propriétaire d'obtenir un accès root à des fins de débogage d'applications et de composants système ou d'accéder à des fonctionnalités non présentées aux applications par les API Android.
Sur certains appareils, une personne ayant le contrôle physique d'un appareil et d'un câble USB peut installer un nouveau système d'exploitation qui fournit des privilèges root à l'utilisateur. Pour protéger toutes les données utilisateur existantes contre la compromission, le mécanisme de déverrouillage du chargeur de démarrage nécessite que le chargeur de démarrage efface toutes les données utilisateur existantes dans le cadre de l'étape de déverrouillage. L'accès root obtenu en exploitant un bogue du noyau ou une faille de sécurité peut contourner cette protection.
Le chiffrement des données avec une clé stockée sur l'appareil ne protège pas les données d'application des utilisateurs root sur les appareils rootés. Les applications peuvent ajouter une couche de protection des données en utilisant le cryptage avec une clé stockée hors de l'appareil, comme sur un serveur ou un mot de passe utilisateur. Cette approche peut fournir une protection temporaire tant que la clé n'est pas présente, mais à un moment donné, la clé doit être fournie à l'application et elle devient alors accessible aux utilisateurs root.
Une approche plus robuste pour protéger les données des utilisateurs root consiste à utiliser des solutions matérielles. Les OEM peuvent choisir de mettre en œuvre des solutions matérielles qui limitent l'accès à des types de contenu spécifiques tels que les DRM pour la lecture vidéo ou le stockage de confiance lié à NFC pour le portefeuille Google. Dans le cas d'un appareil perdu ou volé, le cryptage du stockage garantit que les données de l'utilisateur ne sont pas accessibles sans connaître les informations d'identification de l'écran de verrouillage de l'utilisateur.
Fonctionnalités de sécurité utilisateur
Cryptage du stockage
Le CDD exige que tous les appareils qui se lancent avec Android 10 ou supérieur, et la plupart des appareils qui se lancent avec Android 6.0 ou supérieur, activent le chiffrement du stockage prêt à l'emploi.
L'implémentation actuelle d'Android pour le chiffrement du stockage est le chiffrement basé sur les fichiers en combinaison avec le chiffrement des métadonnées . Le chiffrement basé sur les fichiers chiffre de manière transparente le contenu et les noms des fichiers sur la partition de données utilisateur, en utilisant différentes clés pour différents répertoires. Il fournit des répertoires de stockage chiffrés par identifiants et par appareil pour chaque utilisateur, y compris des profils professionnels.
Le chiffrement des métadonnées complète le chiffrement basé sur les fichiers. Il crypte tous les blocs de la partition de données utilisateur qui ne sont pas déjà cryptés par un cryptage basé sur fichier, en utilisant une clé non liée aux informations d'identification de l'écran de verrouillage de l'utilisateur, mais toujours protégée par Verified Boot.
Protection des informations d'identification de l'écran de verrouillage
Android peut être configuré pour vérifier un identifiant d'écran de verrouillage fourni par l'utilisateur (PIN, mot de passe ou schéma) avant de fournir l'accès à un appareil. En plus d'empêcher l'utilisation non autorisée de l'appareil, les informations d'identification de l'écran de verrouillage protègent la clé cryptographique pour les données chiffrées des informations d'identification. L'utilisation d'informations d'identification d'écran de verrouillage et/ou de règles de complexité des informations d'identification peut être requise par un administrateur de périphérique.
Gestion des appareils
Android 2.2 et versions ultérieures fournissent l'API d'administration des appareils Android, qui fournit des fonctionnalités d'administration des appareils au niveau du système. Par exemple, l'application de messagerie Android intégrée utilise les API pour améliorer la prise en charge d'Exchange. Grâce à l'application de messagerie, les administrateurs Exchange peuvent appliquer des politiques d'identification de l'écran de verrouillage, y compris des mots de passe alphanumériques ou des codes PIN numériques, sur tous les appareils. Les administrateurs peuvent également effacer à distance (c'est-à-dire restaurer les paramètres d'usine par défaut) les combinés perdus ou volés.
En plus d'être utilisées dans les applications incluses avec le système Android, ces API sont disponibles pour les fournisseurs tiers de solutions de gestion des appareils. Des détails sur l'API sont fournis dans Device Administration .