Améliorations de la sécurité

Android améliore continuellement ses capacités et ses offres de sécurité. Consultez les listes d’améliorations par version dans la navigation de gauche.

Android 14

Chaque version d'Android inclut des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des principales améliorations de sécurité disponibles dans Android 14 :

  • AddressSanitizer assisté par matériel (HWASan), introduit dans Android 10, est un outil de détection d'erreurs de mémoire similaire à AddressSanitizer . Android 14 apporte des améliorations significatives à HWASan. Découvrez comment il aide à empêcher les bugs d'apparaître dans les versions Android, HWAddressSanitizer
  • Dans Android 14, à commencer par les applications qui partagent des données de localisation avec des tiers, la boîte de dialogue d'autorisation d'exécution du système comprend désormais une section cliquable qui met en évidence les pratiques de partage de données de l'application, y compris des informations telles que la raison pour laquelle une application peut décider de partager des données avec des tiers. .
  • Android 12 a introduit une option permettant de désactiver la prise en charge de la 2G au niveau du modem, ce qui protège les utilisateurs du risque de sécurité inhérent au modèle de sécurité obsolète de la 2G. Reconnaissant à quel point la désactivation de la 2G pourrait être critique pour les clients d'entreprise, Android 14 active cette fonctionnalité de sécurité dans Android Enterprise, introduisant la prise en charge des administrateurs informatiques pour restreindre la capacité d'un appareil géré à passer à la connectivité 2G .
  • Ajout de la prise en charge du rejet des connexions cellulaires à chiffrement nul, garantissant que le trafic voix et SMS à commutation de circuits est toujours crypté et protégé contre l'interception passive en direct. Apprenez-en davantage sur le programme Android visant à renforcer la connectivité cellulaire .
  • Ajout de la prise en charge de plusieurs IMEI
  • Depuis Android 14, AES-HCTR2 est le mode préféré de cryptage des noms de fichiers pour les appareils dotés d’instructions de cryptographie accélérée.
  • Connectivité cellulaire
  • Documentation ajoutée pour Android Safety Center
  • Si votre application cible Android 14 et utilise le chargement dynamique de code (DCL), tous les fichiers chargés dynamiquement doivent être marqués comme en lecture seule. Sinon, le système lève une exception. Nous recommandons aux applications d’éviter autant que possible de charger dynamiquement du code, car cela augmente considérablement le risque qu’une application puisse être compromise par injection de code ou falsification de code.

Consultez nos notes de version complètes AOSP et la liste des fonctionnalités et modifications du développeur Android.

Android 13

Chaque version d'Android inclut des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des principales améliorations de sécurité disponibles dans Android 13 :

  • Android 13 ajoute la prise en charge des présentations multidocuments. Cette nouvelle interface de session de présentation permet à une application de faire une présentation multi-documents, ce qui n'est pas possible avec l'API existante. Pour plus d'informations, reportez-vous à Informations d'identification
  • Dans Android 13, les intentions provenant d'applications externes sont transmises à un composant exporté si et seulement si les intentions correspondent à leurs éléments de filtre d'intention déclarés.
  • L'API Open Mobile (OMAPI) est une API standard utilisée pour communiquer avec l'élément sécurisé d'un appareil. Avant Android 13, seules les applications et modules de framework avaient accès à cette interface. En le convertissant en une interface stable auprès du fournisseur, les modules HAL sont également capables de communiquer avec les éléments sécurisés via le service OMAPI. Pour plus d’informations, consultez Interface stable du fournisseur OMAPI .
  • Depuis Android 13-QPR, les UID partagés sont obsolètes. Les utilisateurs d'Android 13 ou supérieur doivent mettre la ligne « android:sharedUserMaxSdkVersion="32" » dans leur manifeste. Cette entrée empêche les nouveaux utilisateurs d'obtenir un UID partagé. Pour plus d'informations sur les UID, voir Signature d'application .
  • Android 13 a ajouté la prise en charge des primitives cryptographiques symétriques Keystore telles que AES (Advanced Encryption Standard), HMAC (Keyed-Hash Message Authentication Code) et des algorithmes cryptographiques asymétriques (y compris Elliptic Curve, RSA2048, RSA4096 et Curve 25519)
  • Android 13 (API niveau 33) et versions ultérieures prennent en charge une autorisation d'exécution pour l'envoi de notifications non exemptées à partir d'une application . Cela permet aux utilisateurs de contrôler les notifications d'autorisation qu'ils voient.
  • Ajout d'une invite d'utilisation pour les applications demandant l'accès à tous les journaux de l'appareil , donnant aux utilisateurs la possibilité d'autoriser ou de refuser l'accès.
  • a introduit le Android Virtualization Framework (AVF) , qui rassemble différents hyperviseurs sous un seul framework avec des API standardisées. Il fournit des environnements d'exécution sécurisés et privés pour exécuter des charges de travail isolées par un hyperviseur.
  • Introduction du schéma de signature APK v3.1 Toutes les nouvelles rotations de clés qui utilisent apksigner utiliseront le schéma de signature v3.1 par défaut pour cibler la rotation pour Android 13 et versions ultérieures.

Consultez nos notes de version complètes AOSP et la liste des fonctionnalités et modifications du développeur Android.

Android 12

Chaque version d'Android inclut des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des principales améliorations de sécurité disponibles dans Android 12 :

  • Android 12 introduit l' API BiometricManager.Strings , qui fournit des chaînes localisées pour les applications qui utilisent BiometricPrompt pour l'authentification. Ces chaînes sont destinées à tenir compte du périphérique et à fournir plus de précisions sur le(s) type(s) d'authentification pouvant être utilisés. Android 12 inclut également la prise en charge des capteurs d'empreintes digitales sous l'écran
  • Prise en charge ajoutée pour les capteurs d'empreintes digitales sous l'écran
  • Introduction du langage de définition d'interface Android d'empreintes digitales (AIDL)
  • Prise en charge du nouveau Face AIDL
  • Introduction de Rust comme langage de développement de plateforme
  • Ajout de l'option permettant aux utilisateurs d'accorder l'accès uniquement à leur emplacement approximatif
  • Ajout d'indicateurs de confidentialité sur la barre d'état lorsqu'une application utilise la caméra ou le microphone
  • Le noyau de calcul privé (PCC) d'Android
  • Ajout d'une option pour désactiver le support 2G

Android 11

Chaque version d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Pour obtenir une liste de certaines des principales améliorations de sécurité disponibles dans Android 11, consultez les notes de version d'Android .

Android 10

Chaque version d'Android inclut des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Android 10 inclut plusieurs améliorations en matière de sécurité et de confidentialité. Consultez les notes de version d'Android 10 pour une liste complète des modifications apportées à Android 10.

Sécurité

Désinfectant pour limites

Android 10 déploie BoundsSanitizer (BoundSan) dans Bluetooth et codecs. BoundSan utilise le désinfectant pour limites d'UBSan. Cette atténuation est activée au niveau de chaque module. Il permet de sécuriser les composants critiques d’Android et ne doit pas être désactivé. BoundSan est activé dans les codecs suivants :

  • libFLAC
  • libavcdec
  • libavcenc
  • libhevcdec
  • libmpeg2
  • libopus
  • libvpx
  • libspeexresampler
  • libvorbisidec
  • libaac
  • libxaac

Mémoire d'exécution uniquement

Par défaut, les sections de code exécutable pour les binaires du système AArch64 sont marquées comme étant en exécution seule (non lisible) afin de renforcer l'atténuation des attaques de réutilisation de code juste à temps. Le code qui mélange les données et le code et le code qui inspecte délibérément ces sections (sans remapper au préalable les segments de mémoire comme lisibles) ne fonctionnent plus. Les applications avec un SDK cible d'Android 10 (niveau d'API 29 ou supérieur) sont concernées si l'application tente de lire des sections de code de bibliothèques système activées par la mémoire d'exécution seule (XOM) en mémoire sans d'abord marquer la section comme lisible.

Accès étendu

Les agents de confiance, le mécanisme sous-jacent utilisé par les mécanismes d'authentification tertiaires tels que Smart Lock, ne peuvent prolonger le déverrouillage que dans Android 10. Les agents de confiance ne peuvent plus déverrouiller un appareil verrouillé et ne peuvent garder un appareil déverrouillé que pendant quatre heures maximum.

Authentification faciale

L'authentification faciale permet aux utilisateurs de déverrouiller leur appareil simplement en regardant l'avant de leur appareil. Android 10 ajoute la prise en charge d'une nouvelle pile d'authentification faciale capable de traiter en toute sécurité les images de la caméra, préservant ainsi la sécurité et la confidentialité lors de l'authentification faciale sur le matériel pris en charge. Android 10 offre également un moyen simple pour les implémentations conformes à la sécurité de permettre l'intégration d'applications pour des transactions telles que les services bancaires en ligne ou d'autres services.

Désinfection par débordement entier

Android 10 permet la désinfection par débordement d'entier (IntSan) dans les codecs logiciels. Assurez-vous que les performances de lecture sont acceptables pour tous les codecs qui ne sont pas pris en charge par le matériel de l'appareil. IntSan est activé dans les codecs suivants :

  • libFLAC
  • libavcdec
  • libavcenc
  • libhevcdec
  • libmpeg2
  • libopus
  • libvpx
  • libspeexresampler
  • libvorbisidec

Composants du système modulaire

Android 10 modularise certains composants du système Android et permet de les mettre à jour en dehors du cycle de publication normal d'Android. Certains modules incluent :

OEMCrypto

Android 10 utilise l'API OEMCrypto version 15.

Scudo

Scudo est un allocateur de mémoire dynamique en mode utilisateur conçu pour être plus résistant aux vulnérabilités liées au tas. Il fournit les primitives standard d'allocation et de désallocation C, ainsi que les primitives C++.

ShadowCallStack

ShadowCallStack (SCS) est un mode d'instrumentation LLVM qui protège contre les écrasements d'adresse de retour (comme les débordements de tampon de pile) en enregistrant l'adresse de retour d'une fonction dans une instance ShadowCallStack allouée séparément dans le prologue de fonction des fonctions non-feuille et en chargeant l'adresse de retour de l'instance ShadowCallStack dans l'épilogue de la fonction.

WPA3 et Wi-Fi améliorés ouverts

Android 10 ajoute la prise en charge des normes de sécurité Wi-Fi Protected Access 3 (WPA3) et Wi-Fi Enhanced Open pour offrir une meilleure confidentialité et une meilleure robustesse contre les attaques connues.

Confidentialité

Accès aux applications lorsque vous ciblez Android 9 ou une version antérieure

Si votre application s'exécute sur Android 10 ou version ultérieure mais cible Android 9 (niveau d'API 28) ou version antérieure, la plateforme applique le comportement suivant :

  • Si votre application déclare un élément <uses-permission> pour ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION , le système ajoute automatiquement un élément <uses-permission> pour ACCESS_BACKGROUND_LOCATION lors de l'installation.
  • Si votre application demande ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION , le système ajoute automatiquement ACCESS_BACKGROUND_LOCATION à la demande.

Restrictions relatives aux activités en arrière-plan

À partir d'Android 10, le système impose des restrictions sur le démarrage d'activités en arrière-plan . Ce changement de comportement permet de minimiser les interruptions pour l'utilisateur et de lui permettre de mieux contrôler ce qui est affiché sur son écran. Tant que votre application démarre des activités en conséquence directe de l’interaction de l’utilisateur, elle n’est probablement pas affectée par ces restrictions.
Pour en savoir plus sur l'alternative recommandée au démarrage d'activités en arrière-plan, consultez le guide expliquant comment alerter les utilisateurs d'événements urgents dans votre application.

Métadonnées de la caméra

Android 10 modifie l'étendue des informations renvoyées par défaut par la méthode getCameraCharacteristics() . En particulier, votre application doit disposer de l'autorisation CAMERA afin d'accéder aux métadonnées potentiellement spécifiques à l'appareil incluses dans la valeur de retour de cette méthode.
Pour en savoir plus sur ces modifications, consultez la section sur les champs de caméra nécessitant une autorisation .

Données du Presse-papiers

À moins que votre application ne soit l' éditeur de méthode de saisie (IME) par défaut ou qu'elle soit actuellement l'application qui a le focus, votre application ne peut pas accéder aux données du Presse-papiers sur Android 10 ou version ultérieure.

Emplacement de l'appareil

Pour prendre en charge le contrôle supplémentaire dont disposent les utilisateurs sur l'accès d'une application aux informations de localisation, Android 10 introduit l'autorisation ACCESS_BACKGROUND_LOCATION .
Contrairement aux autorisations ACCESS_FINE_LOCATION et ACCESS_COARSE_LOCATION , l'autorisation ACCESS_BACKGROUND_LOCATION n'affecte l'accès d'une application à la localisation que lorsqu'elle s'exécute en arrière-plan. Une application est considérée comme accédant à la localisation en arrière-plan, sauf si l'une des conditions suivantes est remplie :

  • Une activité appartenant à l'application est visible.
  • L'application exécute un service de premier plan qui a déclaré untype d' location de service de premier plan.
    Pour déclarer le type de service de premier plan pour un service dans votre application, définissez targetSdkVersion ou compileSdkVersion de votre application sur 29 ou supérieur. Découvrez comment les services de premier plan peuvent poursuivre les actions lancées par les utilisateurs qui nécessitent un accès à la localisation.

Stockage externe

Par défaut, les applications ciblant Android 10 et versions ultérieures bénéficient d'un accès limité au stockage externe ou au stockage limité . Ces applications peuvent voir les types de fichiers suivants sur un périphérique de stockage externe sans avoir besoin de demander des autorisations utilisateur liées au stockage :

  • Fichiers dans le répertoire spécifique à l'application, accessibles à l'aide de getExternalFilesDir() .
  • Photos, vidéos et clips audio créés par l'application à partir du magasin multimédia .

Pour en savoir plus sur le stockage étendu, ainsi que sur la façon de partager, d'accéder et de modifier des fichiers enregistrés sur des périphériques de stockage externes, consultez les guides sur la façon de gérer les fichiers dans le stockage externe et d'accéder et de modifier les fichiers multimédias .

Randomisation des adresses MAC

Sur les appareils fonctionnant sous Android 10 ou version ultérieure, le système transmet par défaut des adresses MAC aléatoires.
Si votre application gère un cas d'utilisation en entreprise , la plateforme fournit des API pour plusieurs opérations liées aux adresses MAC :

  • Obtenir une adresse MAC aléatoire : les applications du propriétaire de l'appareil et les applications du propriétaire du profil peuvent récupérer l'adresse MAC aléatoire attribuée à un réseau spécifique en appelant getRandomizedMacAddress() .
  • Obtenir l'adresse MAC réelle d'usine : les applications du propriétaire de l'appareil peuvent récupérer l'adresse MAC matérielle réelle d'un appareil en appelant getWifiMacAddress() . Cette méthode est utile pour suivre les flottes d’appareils.

Identifiants d'appareil non réinitialisables

À partir d'Android 10, les applications doivent disposer de l'autorisation privilégiée READ_PRIVILEGED_PHONE_STATE pour accéder aux identifiants non réinitialisables de l'appareil, qui incluent à la fois l'IMEI et le numéro de série.

Si votre application ne dispose pas de l'autorisation et que vous essayez quand même de demander des informations sur les identifiants non réinitialisables, la réponse de la plateforme varie en fonction de la version du SDK cible :

  • Si votre application cible Android 10 ou version ultérieure, une SecurityException se produit.
  • Si votre application cible Android 9 (niveau API 28) ou inférieur, la méthode renvoie des données null ou réservées si l'application dispose de l'autorisation READ_PHONE_STATE . Sinon, une SecurityException se produit.

Reconnaissance de l'activité physique

Android 10 introduit l'autorisation d'exécution android.permission.ACTIVITY_RECOGNITION pour les applications qui doivent détecter le nombre de pas de l'utilisateur ou classer l'activité physique de l'utilisateur, comme la marche, le vélo ou les déplacements dans un véhicule. Ceci est conçu pour donner aux utilisateurs une visibilité sur la façon dont les données des capteurs de l'appareil sont utilisées dans les paramètres.
Certaines bibliothèques des services Google Play, telles que l' API Activity Recognition et l' API Google Fit , ne fournissent pas de résultats à moins que l'utilisateur n'ait accordé cette autorisation à votre application.
Les seuls capteurs intégrés à l'appareil qui nécessitent que vous déclariez cette autorisation sont les capteurs du compteur de pas et du détecteur de pas .
Si votre application cible Android 9 (API niveau 28) ou une version antérieure, le système accorde automatiquement l'autorisation android.permission.ACTIVITY_RECOGNITION à votre application, si nécessaire, si votre application remplit chacune des conditions suivantes :

  • Le fichier manifeste inclut l'autorisation com.google.android.gms.permission.ACTIVITY_RECOGNITION .
  • Le fichier manifeste n’inclut pas l’autorisation android.permission.ACTIVITY_RECOGNITION .

Si le système auto accorde l'autorisation android.permission.ACTIVITY_RECOGNITION , votre application conserve l'autorisation après avoir mis à jour votre application pour cibler Android 10. Cependant, l'utilisateur peut révoquer cette autorisation à tout moment dans les paramètres système.

Restrictions du système de fichiers /proc/net

Sur les appareils exécutant Android 10 ou version ultérieure, les applications ne peuvent pas accéder /proc/net , qui inclut des informations sur l'état du réseau d'un appareil. Les applications qui ont besoin d'accéder à ces informations, telles que les VPN, doivent utiliser la classe NetworkStatsManager ou ConnectivityManager .

Groupes d'autorisations supprimés de l'interface utilisateur

Depuis Android 10, les applications ne peuvent pas rechercher comment les autorisations sont regroupées dans l'interface utilisateur.

Suppression de l'affinité des contacts

À partir d'Android 10, la plate-forme ne conserve pas les informations d'affinité des contacts. Par conséquent, si votre application effectue une recherche sur les contacts de l'utilisateur, les résultats ne sont pas classés par fréquence d'interaction.
Le guide sur ContactsProvider contient un avis décrivant les champs et méthodes spécifiques qui sont obsolètes sur tous les appareils à partir d'Android 10.

Accès restreint au contenu de l'écran

Pour protéger le contenu de l'écran des utilisateurs, Android 10 empêche l'accès silencieux au contenu de l'écran de l'appareil en modifiant la portée des autorisations READ_FRAME_BUFFER , CAPTURE_VIDEO_OUTPUT et CAPTURE_SECURE_VIDEO_OUTPUT . À partir d'Android 10, ces autorisations concernent uniquement l'accès aux signatures .
Les applications qui doivent accéder au contenu de l'écran de l'appareil doivent utiliser l'API MediaProjection , qui affiche une invite demandant à l'utilisateur de donner son consentement.

Numéro de série du périphérique USB

Si votre application cible Android 10 ou version ultérieure, elle ne peut pas lire le numéro de série tant que l'utilisateur n'a pas accordé à votre application l'autorisation d'accéder au périphérique ou à l'accessoire USB.
Pour en savoir plus sur l'utilisation des périphériques USB, consultez le guide sur la configuration des hôtes USB .

Wifi

Les applications ciblant Android 10 ou version ultérieure ne peuvent pas activer ou désactiver le Wi-Fi. La méthode WifiManager.setWifiEnabled() renvoie toujours false .
Si vous devez inviter les utilisateurs à activer et désactiver le Wi-Fi, utilisez un panneau de paramètres .

Restrictions sur l'accès direct aux réseaux Wi-Fi configurés

Pour protéger la confidentialité des utilisateurs, la configuration manuelle de la liste des réseaux Wi-Fi est limitée aux applications système et aux contrôleurs de politique des appareils (DPC) . Un DPC donné peut être soit le propriétaire de l'appareil, soit le propriétaire du profil.
Si votre application cible Android 10 ou version ultérieure et qu'il ne s'agit pas d'une application système ou d'un DPC, les méthodes suivantes ne renvoient pas de données utiles :

Android 9

Chaque version d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Pour obtenir une liste de certaines des principales améliorations de sécurité disponibles dans Android 9, consultez les notes de version d'Android .

Android 8

Chaque version d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des principales améliorations de sécurité disponibles dans Android 8.0 :

  • Cryptage . Ajout de la prise en charge de l'expulsion de la clé dans le profil professionnel.
  • Démarrage vérifié . Ajout du démarrage vérifié d'Android (AVB). Base de code de démarrage vérifiée prenant en charge la protection contre les annulations pour une utilisation dans les chargeurs de démarrage ajoutés à AOSP. Recommander la prise en charge du chargeur de démarrage pour la protection contre la restauration pour le HLOS. Les chargeurs de démarrage recommandés ne peuvent être déverrouillés que par l'utilisateur interagissant physiquement avec l'appareil.
  • Verrouiller l'écran . Ajout de la prise en charge de l'utilisation de matériel inviolable pour vérifier les informations d'identification de l'écran de verrouillage.
  • Magasin de clés . Attestation de clé requise pour tous les appareils livrés avec Android 8.0+. Ajout de la prise en charge de l' attestation d'identité pour améliorer l'inscription sans contact.
  • Bac à sable . Plus étroitement mis en bac à sable de nombreux composants à l'aide de l'interface standard de Project Treble entre le framework et les composants spécifiques à l'appareil. Filtrage seccomp appliqué à toutes les applications non approuvées pour réduire la surface d'attaque du noyau. WebView est maintenant exécuté dans un processus isolé avec un accès très limité au reste du système.
  • Durcissement du noyau . Mise en œuvre de la copie utilisateur renforcée , de l'émulation PAN, de la lecture seule après l'initialisation et de KASLR.
  • Durcissement de l'espace utilisateur . CFI mis en œuvre pour la pile de médias. Les superpositions d'applications ne peuvent plus couvrir les fenêtres critiques pour le système et les utilisateurs ont un moyen de les ignorer.
  • Mise à jour du système d'exploitation en continu . Mises à jour activées sur les appareils dont l'espace disque est faible.
  • Installez des applications inconnues . Les utilisateurs doivent accorder l'autorisation d'installer des applications à partir d'une source qui n'est pas une boutique d'applications propriétaire.
  • Confidentialité . L'identifiant Android (SSAID) a une valeur différente pour chaque application et chaque utilisateur sur l'appareil. Pour les applications de navigateur Web, Widevine Client ID renvoie une valeur différente pour chaque nom de package d'application et origine Web. net.hostname est maintenant vide et le client DHCP n'envoie plus de nom d'hôte. android.os.Build.SERIAL a été remplacé par l' API Build.SERIAL qui est protégée par une autorisation contrôlée par l'utilisateur. Amélioration de la randomisation des adresses MAC dans certains chipsets.

Android 7

Chaque version d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des principales améliorations de sécurité disponibles dans Android 7.0 :

  • Cryptage basé sur les fichiers . Le chiffrement au niveau du fichier, au lieu de chiffrer toute la zone de stockage comme une seule unité, isole et protège mieux les utilisateurs et les profils individuels (tels que personnels et professionnels) sur un appareil.
  • Démarrage direct . Activé par le chiffrement basé sur les fichiers, Direct Boot permet à certaines applications telles que le réveil et les fonctionnalités d'accessibilité de s'exécuter lorsque l'appareil est sous tension mais pas déverrouillé.
  • Démarrage vérifié . Le démarrage vérifié est désormais strictement appliqué pour empêcher le démarrage des appareils compromis ; il prend en charge la correction d'erreurs pour améliorer la fiabilité contre la corruption de données non malveillantes.
  • SELinux . La configuration SELinux mise à jour et la couverture accrue de seccomp verrouillent davantage le bac à sable de l'application et réduisent la surface d'attaque.
  • Randomisation de l'ordre de chargement de la bibliothèque et amélioration de l'ASLR . L'augmentation du caractère aléatoire rend certaines attaques de réutilisation de code moins fiables.
  • Durcissement du noyau . Ajout d'une protection supplémentaire de la mémoire pour les nouveaux noyaux en marquant des parties de la mémoire du noyau en lecture seule, en limitant l'accès du noyau aux adresses de l'espace utilisateur et en réduisant davantage la surface d'attaque existante.
  • Schéma de signature APK v2 . Introduction d'un schéma de signature de fichier complet qui améliore la vitesse de vérification et renforce les garanties d'intégrité.
  • Magasin CA de confiance . Pour permettre aux applications de contrôler plus facilement l'accès à leur trafic réseau sécurisé, les autorités de certification installées par l'utilisateur et celles installées via les API Device Admin ne sont plus approuvées par défaut pour les applications ciblant le niveau d'API 24+. De plus, tous les nouveaux appareils Android doivent être livrés avec le même magasin CA de confiance.
  • Configuration de la sécurité réseau . Configurez la sécurité du réseau et TLS via un fichier de configuration déclaratif.

Android 6

Chaque version d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des principales améliorations de sécurité disponibles dans Android 6.0 :

  • Autorisations d'exécution . Les applications demandent des autorisations au moment de l'exécution au lieu d'être accordées au moment de l'installation de l'application. Les utilisateurs peuvent activer et désactiver les autorisations pour les applications M et pré-M.
  • Démarrage vérifié . Un ensemble de vérifications cryptographiques du logiciel système est effectué avant l'exécution pour s'assurer que le téléphone est sain depuis le chargeur de démarrage jusqu'au système d'exploitation.
  • Sécurité matérielle isolée . Nouvelle couche d'abstraction matérielle (HAL) utilisée par l'API Fingerprint, Lockscreen, Device Encryption et les certificats client pour protéger les clés contre la compromission du noyau et/ou les attaques physiques locales
  • Empreintes digitales . Les appareils peuvent désormais être déverrouillés d'un simple toucher. Les développeurs peuvent également tirer parti des nouvelles API pour utiliser les empreintes digitales pour verrouiller et déverrouiller les clés de chiffrement.
  • Adoption de la carte SD . Les supports amovibles peuvent être adoptés sur un appareil et étendre le stockage disponible pour les données locales de l'application, les photos, les vidéos, etc., mais toujours protégés par un cryptage au niveau du bloc.
  • Effacer le trafic de texte . Les développeurs peuvent utiliser un nouveau StrictMode pour s'assurer que leur application n'utilise pas de texte en clair.
  • Durcissement du système . Renforcement du système via des politiques appliquées par SELinux. Cela offre une meilleure isolation entre les utilisateurs, un filtrage IOCTL, une réduction de la menace des services exposés, un resserrement supplémentaire des domaines SELinux et un accès /proc extrêmement limité.
  • Contrôle d'accès USB : les utilisateurs doivent confirmer l'autorisation d'accès USB aux fichiers, au stockage ou à d'autres fonctionnalités du téléphone. La valeur par défaut est désormais facturée uniquement avec un accès au stockage nécessitant l'approbation explicite de l'utilisateur.

Android 5

5.0

Chaque version d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des principales améliorations de sécurité disponibles dans Android 5.0 :

  • Crypté par défaut. Sur les appareils livrés avec L prêt à l'emploi, le chiffrement intégral du disque est activé par défaut pour améliorer la protection des données sur les appareils perdus ou volés. Les appareils mis à jour vers L peuvent être chiffrés dans Paramètres > Sécurité .
  • Cryptage complet du disque amélioré. Le mot de passe de l'utilisateur est protégé contre les attaques par force brute à l'aide de scrypt et, le cas échéant, la clé est liée au magasin de clés matériel pour empêcher les attaques hors appareil. Comme toujours, le secret de verrouillage de l'écran Android et la clé de cryptage de l'appareil ne sont pas envoyés hors de l'appareil ni exposés à aucune application.
  • Bac à sable Android renforcé avec SELinux . Android nécessite désormais SELinux en mode d'application pour tous les domaines. SELinux est un système de contrôle d'accès obligatoire (MAC) dans le noyau Linux utilisé pour augmenter le modèle de sécurité de contrôle d'accès discrétionnaire (DAC) existant. Cette nouvelle couche offre une protection supplémentaire contre les vulnérabilités de sécurité potentielles.
  • Verrouillage intelligent. Android inclut désormais des trustlets qui offrent plus de flexibilité pour déverrouiller les appareils. Par exemple, les trustlets peuvent permettre aux appareils d'être déverrouillés automatiquement lorsqu'ils sont proches d'un autre appareil de confiance (via NFC, Bluetooth) ou lorsqu'ils sont utilisés par une personne avec un visage de confiance.
  • Modes multi-utilisateurs, profils restreints et invités pour téléphones et tablettes. Android fournit désormais plusieurs utilisateurs sur les téléphones et inclut un mode invité qui peut être utilisé pour fournir un accès temporaire facile à votre appareil sans accorder l'accès à vos données et applications.
  • Mises à jour de WebView sans OTA. WebView peut désormais être mis à jour indépendamment du framework et sans système OTA. Cela permettra une réponse plus rapide aux problèmes de sécurité potentiels dans WebView.
  • Cryptographie mise à jour pour HTTPS et TLS/SSL. TLSv1.2 et TLSv1.1 sont désormais activés, Forward Secrecy est désormais préféré, AES-GCM est désormais activé et les suites de chiffrement faibles (MD5, 3DES et suites de chiffrement d'exportation) sont désormais désactivées. Voir https://developer.android.com/reference/javax/net/ssl/SSLSocket.html pour plus de détails.
  • la prise en charge de l'éditeur de liens non PIE a été supprimée. Android exige désormais que tous les exécutables liés dynamiquement prennent en charge PIE (exécutables indépendants de la position). Cela améliore la mise en œuvre de la randomisation de la disposition de l'espace d'adressage (ASLR) d'Android.
  • Améliorations de FORTIFY_SOURCE. Les fonctions libc suivantes implémentent désormais les protections FORTIFY_SOURCE : stpcpy() , stpncpy() , read() , recvfrom() , FD_CLR() , FD_SET() et FD_ISSET() . Cela fournit une protection contre les vulnérabilités de corruption de mémoire impliquant ces fonctions.
  • Correctifs de sécurité. Android 5.0 inclut également des correctifs pour les vulnérabilités spécifiques à Android. Des informations sur ces vulnérabilités ont été fournies aux membres de l'Open Handset Alliance, et des correctifs sont disponibles dans Android Open Source Project. Pour améliorer la sécurité, certains appareils avec des versions antérieures d'Android peuvent également inclure ces correctifs.

Android 4 et versions antérieures

Chaque version d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des améliorations de sécurité disponibles dans Android 4.4 :

  • Bac à sable Android renforcé avec SELinux. Android utilise désormais SELinux en mode application. SELinux est un système de contrôle d'accès obligatoire (MAC) dans le noyau Linux utilisé pour augmenter le modèle de sécurité basé sur le contrôle d'accès discrétionnaire (DAC) existant. Cela offre une protection supplémentaire contre les vulnérabilités de sécurité potentielles.
  • VPN par utilisateur. Sur les appareils multi-utilisateurs, les VPN sont désormais appliqués par utilisateur. Cela peut permettre à un utilisateur d'acheminer tout le trafic réseau via un VPN sans affecter les autres utilisateurs sur l'appareil.
  • Prise en charge du fournisseur ECDSA dans AndroidKeyStore. Android dispose désormais d'un fournisseur de keystore qui permet l'utilisation des algorithmes ECDSA et DSA.
  • Avertissements de surveillance de l'appareil. Android fournit aux utilisateurs un avertissement si un certificat a été ajouté au magasin de certificats de l'appareil qui pourrait permettre la surveillance du trafic réseau chiffré.
  • FORTIFY_SOURCE. Android prend désormais en charge FORTIFY_SOURCE niveau 2, et tout le code est compilé avec ces protections. FORTIFY_SOURCE a été amélioré pour fonctionner avec clang.
  • Épinglage de certificat. Android 4.4 détecte et empêche l'utilisation de certificats Google frauduleux utilisés dans les communications SSL/TLS sécurisées.
  • Correctifs de sécurité. Android 4.4 inclut également des correctifs pour les vulnérabilités spécifiques à Android. Des informations sur ces vulnérabilités ont été fournies aux membres de l'Open Handset Alliance et des correctifs sont disponibles dans Android Open Source Project. Pour améliorer la sécurité, certains appareils avec des versions antérieures d'Android peuvent également inclure ces correctifs.

Chaque version d'Android inclut des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des améliorations de sécurité disponibles dans Android 4.3 :

  • Sandbox Android renforcé avec SELinux. Cette version renforce le bac à sable Android en utilisant le système de contrôle d'accès obligatoire (MAC) SELinux dans le noyau Linux. Le renforcement SELinux est invisible pour les utilisateurs et les développeurs et ajoute de la robustesse au modèle de sécurité Android existant tout en maintenant la compatibilité avec les applications existantes. Pour garantir une compatibilité continue, cette version permet l'utilisation de SELinux en mode permissif. Ce mode enregistre toutes les violations de stratégie, mais n'interrompra pas les applications ni n'affectera le comportement du système.
  • Aucun programme setuid/setgid. Ajout de la prise en charge des fonctionnalités du système de fichiers pour les fichiers système Android et suppression de tous les programmes setuid/setguid. Cela réduit la surface d’attaque des racines et la probabilité de failles de sécurité potentielles.
  • Authentification BAD. Depuis Android 4.2.2, les connexions à ADB sont authentifiées avec une paire de clés RSA. Cela empêche l’utilisation non autorisée d’ADB lorsque l’attaquant a un accès physique à un appareil.
  • Restreindre Setuid des applications Android. La partition /system est désormais montée sans identifiant pour les processus générés par zygote, empêchant les applications Android d'exécuter des programmes setuid. Cela réduit la surface d’attaque des racines et la probabilité de failles de sécurité potentielles.
  • Limite de capacité. Android Zygote et ADB utilisent désormais prctl(PR_CAPBSET_DROP) pour supprimer les fonctionnalités inutiles avant d'exécuter des applications. Cela empêche les applications Android et les applications lancées depuis le shell d'acquérir des fonctionnalités privilégiées.
  • Fournisseur AndroidKeyStore. Android dispose désormais d'un fournisseur de magasin de clés qui permet aux applications de créer des clés à usage exclusif. Cela fournit aux applications une API pour créer ou stocker des clés privées qui ne peuvent pas être utilisées par d'autres applications.
  • KeyChain estBoundKeyAlgorithm. L'API trousseau fournit désormais une méthode (isBoundKeyType) qui permet aux applications de confirmer que les clés à l'échelle du système sont liées à une racine matérielle de confiance pour l'appareil. Cela permet de créer ou de stocker des clés privées qui ne peuvent pas être exportées hors de l'appareil, même en cas de compromission racine.
  • NO_NEW_PRIVS. Android zygote utilise désormais prctl(PR_SET_NO_NEW_PRIVS) pour bloquer l'ajout de nouveaux privilèges avant l'exécution du code de l'application. Cela empêche les applications Android d'effectuer des opérations pouvant élever les privilèges via execve. (Cela nécessite la version 3.5 ou supérieure du noyau Linux).
  • Améliorations de FORTIFY_SOURCE. Activation de FORTIFY_SOURCE sur Android x86 et MIPS et appels strchr(), strrchr(), strlen() et umask() renforcés. Cela peut détecter des vulnérabilités potentielles de corruption de mémoire ou des constantes de chaîne non terminées.
  • Protections contre la réinstallation. Activation des relocalisations en lecture seule (relro) pour les exécutables liés statiquement et suppression de toutes les relocalisations de texte dans le code Android. Cela fournit une défense en profondeur contre les vulnérabilités potentielles de corruption de la mémoire.
  • EntropyMixer amélioré. EntropyMixer écrit désormais l'entropie à l'arrêt/redémarrage, en plus du mixage périodique. Cela permet de conserver toute l'entropie générée lorsque les appareils sont sous tension, et est particulièrement utile pour les appareils qui sont redémarrés immédiatement après le provisionnement.
  • Correctifs de sécurité. Android 4.3 inclut également des correctifs pour les vulnérabilités spécifiques à Android. Des informations sur ces vulnérabilités ont été fournies aux membres de l'Open Handset Alliance et des correctifs sont disponibles dans le projet Android Open Source. Pour améliorer la sécurité, certains appareils dotés de versions antérieures d'Android peuvent également inclure ces correctifs.

Android fournit un modèle de sécurité multicouche décrit dans la présentation de la sécurité Android . Chaque mise à jour d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des améliorations de sécurité introduites dans Android 4.2 :

  • Vérification des applications - Les utilisateurs peuvent choisir d'activer "Vérifier les applications" et faire vérifier 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, cela peut bloquer l'installation.
  • Plus de contrôle sur les SMS premium - 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.
  • VPN permanent - Le VPN peut être configuré de manière à ce que les applications n'aient pas accès au réseau tant qu'une connexion VPN n'est pas établie. Cela empêche les applications d'envoyer des données sur d'autres réseaux.
  • Épinglage de certificat - Les bibliothèques principales d'Android prennent désormais en charge l' épinglage de certificat . Les domaines épinglés recevront un échec de validation de certificat si le certificat n'est pas lié à un ensemble de certificats attendus. Cela protège contre une éventuelle compromission des autorités de certification.
  • Amélioration de l'affichage des autorisations Android - Les autorisations ont été organisées en groupes plus facilement compréhensibles par les utilisateurs. Lors de l'examen des autorisations, l'utilisateur peut cliquer sur l'autorisation pour afficher des informations plus détaillées sur l'autorisation.
  • Renforcement installd - Le démon installd ne s'exécute pas en tant qu'utilisateur root, ce qui réduit la surface d'attaque potentielle pour l'élévation des privilèges root.
  • durcissement des scripts d'initialisation - les scripts d'initialisation appliquent désormais la sémantique O_NOFOLLOW pour empêcher les attaques liées aux liens symboliques.
  • FORTIFY_SOURCE - Android implémente désormais FORTIFY_SOURCE . Ceci est utilisé par les bibliothèques système et les applications pour empêcher la corruption de la mémoire.
  • Configuration par défaut de ContentProvider - Les applications qui ciblent le niveau d'API 17 auront "export" défini sur "false" par défaut pour chaque fournisseur de contenu , réduisant ainsi la surface d'attaque par défaut pour les applications.
  • Cryptographie - Modification des implémentations par défaut de SecureRandom et Cipher.RSA pour utiliser OpenSSL. Ajout de la prise en charge SSL Socket pour TLSv1.1 et TLSv1.2 à l'aide d'OpenSSL 1.0.1
  • Correctifs de sécurité - Les bibliothèques open source mises à niveau avec des correctifs de sécurité incluent WebKit, libpng, OpenSSL et LibXML. Android 4.2 inclut également des correctifs pour les vulnérabilités spécifiques à Android. Des informations sur ces vulnérabilités ont été fournies aux membres de l'Open Handset Alliance et des correctifs sont disponibles dans Android Open Source Project. Pour améliorer la sécurité, certains appareils avec des versions antérieures d'Android peuvent également inclure ces correctifs.

Android fournit un modèle de sécurité multicouche décrit dans la présentation de la sécurité Android . Chaque mise à jour d'Android comprend des dizaines d'améliorations de sécurité pour protéger les utilisateurs. Voici quelques-unes des améliorations de sécurité introduites dans les versions 1.5 à 4.1 d'Android :

Android 1.5
  • ProPolice pour éviter les débordements de tampon de pile (-fstack-protector)
  • safe_iop pour réduire les débordements d'entiers
  • Extensions à OpenBSD dlmalloc pour empêcher les doubles vulnérabilités free() et pour empêcher les attaques de consolidation de blocs. Les attaques par consolidation de blocs sont un moyen courant d'exploiter la corruption de tas.
  • Calloc OpenBSD pour empêcher les débordements d'entiers lors de l'allocation de mémoire
Android 2.3
  • Protections contre les vulnérabilités de chaîne de format (-Wformat-security -Werror=format-security)
  • No eXecute (NX) basé sur le matériel pour empêcher l'exécution de code sur la pile et le tas
  • Linux mmap_min_addr pour atténuer l'escalade des privilèges de déréférencement de pointeur nul (encore amélioré dans Android 4.1)
Android 4.0
Randomisation de la disposition de l'espace d'adresse (ASLR) pour randomiser les emplacements clés dans la mémoire
Android 4.1
  • Prise en charge de PIE (Position Independent Executable)
  • Déplacements en lecture seule / liaison immédiate (-Wl,-z,relro -Wl,-z,now)
  • dmesg_restrict activé (évite les fuites d'adresses du noyau)
  • kptr_restrict activé (évite les fuites d'adresses du noyau)