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

Every Android release includes dozens of security enhancements to protect users. Here are some of the major security enhancements available in Android 14:

  • Hardware-assisted AddressSanitizer (HWASan), introduced in Android 10, is a memory error detection tool similar to AddressSanitizer. Android 14 brings significant improvements to HWASan. Learn how it helps prevent bugs from making it into Android releases, HWAddressSanitizer
  • In Android 14, starting with apps that share location data with third-parties, the system runtime permission dialog now includes a clickable section that highlights the app's data-sharing practices, including information such as why an app may decide to share data with third parties.
  • Android 12 introduced an option to disable 2G support at the modem level, which protects users from the inherent security risk from 2G's obsolete security model. Recognizing how critical disabling 2G could be for enterprise customers, Android 14 enables this security feature in Android Enterprise, introducing support for IT admins to restrict the ability of a managed device to downgrade to 2G connectivity.
  • Added support to reject null-ciphered cellular connections, ensuring that circuit-switched voice and SMS traffic is always encrypted and protected from passive over-the-air interception. Learn more about Android's program to harden cellular connectivity.
  • Added support for multiple IMEIs
  • Since Android 14, AES-HCTR2 is the preferred mode of filenames encryption for devices with accelerated cryptography instructions.
  • Cellular connectivity
  • Documentation added for Android Safety Center
  • If your app targets Android 14 and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

Check out our full AOSP release notes and the Android Developer features and changes list.

Android 13

Every Android release includes dozens of security enhancements to protect users. Here are some of the major security enhancements available in Android 13:

  • Android 13 adds multi-document presentation support. This new Presentation Session interface enables an application to do a multi-document presentation, something which isn't possible with the existing API. For further information, refer to Identity Credential
  • In Android 13, intents originating from external apps are delivered to an exported component if and only if the intents match their declared intent-filter elements.
  • Open Mobile API (OMAPI) is a standard API used to communicate with a device's Secure Element. Before Android 13, only applications and framework modules had access to this interface. By converting it to a vendor stable interface, HAL modules are also capable of communicating with the secure elements through the OMAPI service. For more information, see OMAPI Vendor Stable Interface.
  • As of Android 13-QPR, shared UIDs are deprecated. Users of Android 13 or higher should put the line `android:sharedUserMaxSdkVersion="32"` in their manifest. This entry prevents new users from getting a shared UID. For further information on UIDs, see Application signing.
  • Android 13 added support Keystore symmetric cryptographic primitives such as AES (Advanced Encryption Standard), HMAC (Keyed-Hash Message Authentication Code), and asymmetric cryptographic algorithms (including Elliptic Curve, RSA2048, RSA4096, and Curve 25519)
  • Android 13 (API level 33) and higher supports a runtime permission for sending non-exempt notifications from an app. This gives users control over which permission notifications they see.
  • Added per-use prompt for apps requesting access to all device logs, giving users the ability to allow or deny access.
  • introduced the Android Virtualization Framework (AVF), which brings together different hypervisors under one framework with standardized APIs. It provides secure and private execution environments for executing workloads isolated by hypervisor.
  • Introduced APK signature scheme v3.1 All new key rotations that use apksigner will use the v3.1 signature scheme by default to target rotation for Android 13 and higher.

Check out our full AOSP release notes and the Android Developer features and changes list.

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

Every Android release includes dozens of security enhancements to protect users. For a list of some of the major security enhancements available in Android 9, see the Android Release Notes.

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

Every Android release includes dozens of security enhancements to protect users. Here are some of the major security enhancements available in Android 6.0:

  • Runtime Permissions. Applications request permissions at runtime instead of being granted at App install time. Users can toggle permissions on and off for both M and pre-M applications.
  • Verified Boot. A set of cryptographic checks of system software are conducted prior to execution to ensure the phone is healthy from the bootloader all the way up to the operating system.
  • Hardware-Isolated Security. New Hardware Abstraction Layer (HAL) used by Fingerprint API, Lockscreen, Device Encryption, and Client Certificates to protect keys against kernel compromise and/or local physical attacks
  • Fingerprints. Devices can now be unlocked with just a touch. Developers can also take advantage of new APIs to use fingerprints to lock and unlock encryption keys.
  • SD Card Adoption. Removable media can be adopted to a device and expand available storage for app local data, photos, videos, etc., but still be protected by block-level encryption.
  • Clear Text Traffic. Developers can use a new StrictMode to make sure their application doesn't use cleartext.
  • System Hardening. Hardening of the system via policies enforced by SELinux. This offers better isolation between users, IOCTL filtering, reduce threat of exposed services, further tightening of SELinux domains, and extremely limited /proc access.
  • USB Access Control: Users must confirm to allow USB access to files, storage, or other functionality on the phone. Default is now charge only with access to storage requiring explicit approval from the user.

Android 5

5.0

Every Android release includes dozens of security enhancements to protect users. Here are some of the major security enhancements available in Android 5.0:

  • Encrypted by default. On devices that ship with L out-of-the-box, full disk encryption is enabled by default to improve protection of data on lost or stolen devices. Devices that update to L can be encrypted in Settings > Security.
  • Improved full disk encryption. The user password is protected against brute-force attacks using scrypt and, where available, the key is bound to the hardware keystore to prevent off-device attacks. As always, the Android screen lock secret and the device encryption key are not sent off the device or exposed to any application.
  • Android sandbox reinforced with SELinux. Android now requires SELinux in enforcing mode for all domains. SELinux is a mandatory access control (MAC) system in the Linux kernel used to augment the existing discretionary access control (DAC) security model. This new layer provides additional protection against potential security vulnerabilities.
  • Smart Lock. Android now includes trustlets that provide more flexibility for unlocking devices. For example, trustlets can allow devices to be unlocked automatically when close to another trusted device (via NFC, Bluetooth) or being used by someone with a trusted face.
  • Multi user, restricted profile, and guest modes for phones & tablets. Android now provides for multiple users on phones and includes a guest mode that can be used to provide easy temporary access to your device without granting access to your data and apps.
  • Updates to WebView without OTA. WebView can now be updated independent of the framework and without a system OTA. This will allow for faster response to potential security issues in WebView.
  • Updated cryptography for HTTPS and TLS/SSL. TLSv1.2 and TLSv1.1 is now enabled, Forward Secrecy is now preferred, AES-GCM is now enabled, and weak cipher suites (MD5, 3DES, and export cipher suites) are now disabled. See https://developer.android.com/reference/javax/net/ssl/SSLSocket.html for more details.
  • non-PIE linker support removed. Android now requires all dynamically linked executables to support PIE (position-independent executables). This enhances Android’s address space layout randomization (ASLR) implementation.
  • FORTIFY_SOURCE improvements. The following libc functions now implement FORTIFY_SOURCE protections: stpcpy(), stpncpy(), read(), recvfrom(), FD_CLR(), FD_SET(), and FD_ISSET(). This provides protection against memory-corruption vulnerabilities involving those functions.
  • Security Fixes. Android 5.0 also includes fixes for Android-specific vulnerabilities. Information about these vulnerabilities has been provided to Open Handset Alliance members, and fixes are available in Android Open Source Project. To improve security, some devices with earlier versions of Android may also include these fixes.

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.

Every Android release includes dozens of security enhancements to protect users. The following are some of the security enhancements available in Android 4.3:

  • Android sandbox reinforced with SELinux. This release strengthens the Android sandbox using the SELinux mandatory access control system (MAC) in the Linux kernel. SELinux reinforcement is invisible to users and developers, and adds robustness to the existing Android security model while maintaining compatibility with existing applications. To ensure continued compatibility this release allows the use of SELinux in a permissive mode. This mode logs any policy violations, but will not break applications or affect system behavior.
  • No setuid/setgid programs. Added support for filesystem capabilities to Android system files and removed all setuid/setguid programs.  This reduces root attack surface and the likelihood of potential security vulnerabilities.
  • ADB Authentication. Since Android 4.2.2, connections to ADB are authenticated with an RSA keypair. This prevents unauthorized use of ADB where the attacker has physical access to a device.
  • Restrict Setuid from Android Apps. The /system partition is now mounted nosuid for zygote-spawned processes, preventing Android applications from executing setuid programs. This reduces root attack surface and the likelihood of potential security vulnerabilities.
  • Capability bounding. Android zygote and ADB now use prctl(PR_CAPBSET_DROP) to drop unnecessary capabilities prior to executing applications. This prevents Android applications and applications launched from the shell from acquiring privileged capabilities.
  • AndroidKeyStore Provider. Android now has a keystore provider that allows applications to create exclusive use keys. This provides applications with an API to create or store private keys that cannot be used by other applications.
  • KeyChain isBoundKeyAlgorithm. Keychain API now provides a method (isBoundKeyType) that allows applications to confirm that system-wide keys are bound to a hardware root of trust for the device. This provides a place to create or store private keys that cannot be exported off the device, even in the event of a root compromise.
  • NO_NEW_PRIVS. Android zygote now uses prctl(PR_SET_NO_NEW_PRIVS) to block addition of new privileges prior to execution application code. This prevents Android applications from performing operations which can elevate privileges via execve. (This requires Linux kernel version 3.5 or greater).
  • FORTIFY_SOURCE enhancements. Enabled FORTIFY_SOURCE on Android x86 and MIPS and fortified strchr(), strrchr(), strlen(), and umask() calls. This can detect potential memory corruption vulnerabilities or unterminated string constants.
  • Relocation protections. Enabled read only relocations (relro) for statically linked executables and removed all text relocations in Android code. This provides defense in depth against potential memory corruption vulnerabilities.
  • Improved EntropyMixer. EntropyMixer now writes entropy at shutdown / reboot, in addition to periodic mixing. This allows retention of all entropy generated while devices are powered on, and is especially useful for devices that are rebooted immediately after provisioning.
  • Security Fixes. Android 4.3 also includes fixes for Android-specific vulnerabilities. Information about these vulnerabilities has been provided to Open Handset Alliance members and fixes are available in Android Open Source Project. To improve security, some devices with earlier versions of Android may also include these fixes.

Android provides a multi-layered security model described in the Android Security Overview. Each update to Android includes dozens of security enhancements to protect users. The following are some of the security enhancements introduced in Android 4.2:

  • Application verification - Users can choose to enable “Verify Apps" and have applications screened by an application verifier, prior to installation. App verification can alert the user if they try to install an app that might be harmful; if an application is especially bad, it can block installation.
  • More control of premium SMS - Android will provide a notification if an application attempts to send SMS to a short code that uses premium services which might cause additional charges. The user can choose whether to allow the application to send the message or block it.
  • Always-on VPN - VPN can be configured so that applications will not have access to the network until a VPN connection is established. This prevents applications from sending data across other networks.
  • Certificate Pinning - The Android core libraries now support certificate pinning. Pinned domains will receive a certificate validation failure if the certificate does not chain to a set of expected certificates. This protects against possible compromise of Certificate Authorities.
  • Improved display of Android permissions - Permissions have been organized into groups that are more easily understood by users. During review of the permissions, the user can click on the permission to see more detailed information about the permission.
  • installd hardening - The installd daemon does not run as the root user, reducing potential attack surface for root privilege escalation.
  • init script hardening - init scripts now apply O_NOFOLLOW semantics to prevent symlink related attacks.
  • FORTIFY_SOURCE - Android now implements FORTIFY_SOURCE. This is used by system libraries and applications to prevent memory corruption.
  • ContentProvider default configuration - Applications which target API level 17 will have "export" set to "false" by default for each Content Provider, reducing default attack surface for applications.
  • Cryptography - Modified the default implementations of SecureRandom and Cipher.RSA to use OpenSSL. Added SSL Socket support for TLSv1.1 and TLSv1.2 using OpenSSL 1.0.1
  • Security Fixes - Upgraded open source libraries with security fixes include WebKit, libpng, OpenSSL, and LibXML. Android 4.2 also includes fixes for Android-specific vulnerabilities. Information about these vulnerabilities has been provided to Open Handset Alliance members and fixes are available in Android Open Source Project. To improve security, some devices with earlier versions of Android may also include these fixes.

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)