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

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

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

  • Android 12 introduces the BiometricManager.Strings API, which provides localized strings for apps that use BiometricPrompt for authentication. These strings are intended to be device-aware and provide more specificity about which authentication type(s) may be used. Android 12 also includes support for under-display fingerprint sensors
  • Support added for under-display fingerprint sensors
  • Introduction of the Fingerprint Android Interface Definition Language (AIDL)
  • Support for new Face AIDL
  • Introduction of Rust as a language for platform development
  • The option for users to grant access only to their approximate location added
  • Added Privacy indicators on the status bar when an app is using the camera or microphone
  • Android's Private Compute Core (PCC)
  • Added an option to disable 2G support

Android 11

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

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

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

  • Encryption. Added support to evict key in work profile.
  • Verified Boot. Added Android Verified Boot (AVB). Verified Boot codebase supporting rollback protection for use in boot loaders added to AOSP. Recommend bootloader support for rollback protection for the HLOS. Recommend boot loaders can only be unlocked by user physically interacting with the device.
  • Lock screen. Added support for using tamper-resistant hardware to verify lock screen credential.
  • KeyStore. Required key attestation for all devices that ship with Android 8.0+. Added ID attestation support to improve Zero Touch Enrollment.
  • Sandboxing. More tightly sandboxed many components using Project Treble's standard interface between framework and device-specific components. Applied seccomp filtering to all untrusted apps to reduce the kernel's attack surface. WebView is now run in an isolated process with very limited access to the rest of the system.
  • Kernel hardening. Implemented hardened usercopy, PAN emulation, read-only after init, and KASLR.
  • Userspace hardening. Implemented CFI for the media stack. App overlays can no longer cover system-critical windows and users have a way to dismiss them.
  • Streaming OS update. Enabled updates on devices that are are low on disk space.
  • Install unknown apps. Users must grant permission to install apps from a source that isn't a first-party app store.
  • Privacy. Android ID (SSAID) has a different value for each app and each user on the device. For web browser apps, Widevine Client ID returns a different value for each app package name and web origin. net.hostname is now empty and the dhcp client no longer sends a hostname. android.os.Build.SERIAL has been replaced with the Build.SERIAL API which is protected behind a user-controlled permission. Improved MAC address randomization in some 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 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)