Renforcement de la sécurité

Android améliore en permanence ses fonctionnalités et ses offres de sécurité. Consultez les listes des améliorations par version dans le panneau de 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 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 13:

  • Android 13 est compatible avec les présentations multi-documents. Cette nouvelle interface de session de présentation permet à une application de réaliser une présentation multi-documents, ce qui n'est pas possible avec l'API existante. Pour en savoir plus, consultez la section Identifiant d'identité.
  • Dans Android 13, les intents provenant d'applications externes sont transmis à un composant exporté si et seulement si les intents correspondent à leurs éléments de filtre d'intent 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 les modules de framework avaient accès à cette interface. En le convertissant en interface stable du fournisseur, les modules HAL peuvent également communiquer avec les éléments sécurisés via le service OMAPI. Pour en savoir plus, consultez la page Interface stable du fournisseur OMAPI.
  • À partir d'Android 13-QPR, les UID partagés sont obsolètes. Les utilisateurs d'Android 13 ou version ultérieure doivent ajouter la ligne "android:sharedUserMaxSdkVersion="32"" dans leur fichier manifeste. Cette entrée empêche les nouveaux utilisateurs d'obtenir un UID partagé. Pour en savoir plus sur les UID, consultez la section Signature d'application.
  • Android 13 prend désormais en charge les primitives cryptographiques symétriques Keystore telles que l'AES (Advanced Encryption Standard), le HMAC (Keyed-Hash Message Authentication Code) et les algorithmes cryptographiques asymétriques (y compris les courbes elliptiques, RSA2048, RSA4096 et Curve 25519).
  • Android 13 (niveau d'API 33) ou version ultérieure prend en charge une autorisation d'exécution pour l'envoi de notifications non exemptées depuis une application. Cela permet aux utilisateurs de contrôler les notifications d'autorisation qu'ils voient.
  • Ajout d'une invite par utilisation pour les applications qui demandent à accéder à tous les journaux de l'appareil, ce qui permet aux utilisateurs d'autoriser ou de refuser l'accès.
  • a lancé le framework de virtualisation Android (AVF), qui rassemble différents hyperviseurs dans un même 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 utilisent le schéma de signature v3.1 par défaut pour cibler la rotation pour Android 13 et versions ultérieures.

Consultez les notes de version complètes d'AOSP et la liste des fonctionnalités et modifications pour les développeurs 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 types might 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 comprend 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é. Pour obtenir la liste complète des modifications apportées à Android 10, consultez les notes de version d'Android 10.

Sécurité

BoundsSanitizer

Android 10 déploie BoundsSanitizer (BoundSan) dans Bluetooth et les codecs. BoundSan utilise le nettoyeur de limites d'UBSan. Cette atténuation est activée au niveau du 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 en lecture seule

Par défaut, les sections de code exécutable pour les binaires système AArch64 sont marquées comme exécutables uniquement (non lisibles) afin de renforcer la protection contre les attaques de réutilisation de code juste-à-temps. Le code qui mélange des données et du code, et le code qui inspecte intentionnellement ces sections (sans remappeur au préalable les segments de mémoire en tant que lisibles) ne fonctionnent plus. Les applications dont le SDK cible est Android 10 (niveau d'API 29 ou version ultérieure) sont concernées si elles tentent de lire des sections de code de bibliothèques système compatibles avec la mémoire en lecture seule (XOM) en mémoire sans marquer d'abord la section comme lisible.

Accès étendu

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

Authentification faciale

L'authentification par reconnaissance faciale permet aux utilisateurs de déverrouiller leur appareil simplement en le regardant. Android 10 prend en charge une nouvelle pile d'authentification par reconnaissance faciale qui peut traiter de manière sécurisée les images de l'appareil photo, préservant ainsi la sécurité et la confidentialité lors de l'authentification par reconnaissance faciale sur le matériel compatible. Android 10 permet également aux implémentations conformes aux exigences de sécurité d'intégrer facilement des applications pour les transactions telles que les services bancaires en ligne ou d'autres services.

Nettoyage des valeurs d'entiers en cas de dépassement

Android 10 active la santé de l'overflow d'entier (IntSan) dans les codecs logiciels. Assurez-vous que les performances de lecture sont acceptables pour tous les codecs qui ne sont pas compatibles avec 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 leur mise à jour en dehors du cycle de publication normal d'Android. Voici quelques-uns de ces modules:

OEMCrypto

Android 10 utilise la version 15 de l'API OEMCrypto.

Scudo

Scudo est un outil d'allocation de mémoire dynamique en mode utilisateur conçu pour être plus résilient face aux failles liées aux tas de mémoire. Il fournit les primitives d'allocation et de désallocation standard en C, ainsi que les primitives C++.

ShadowCallStack

ShadowCallStack (SCS) est un mode d'instrumentation LLVM qui protège contre les écrasements d'adresses 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 feuilles et en chargeant l'adresse de retour à partir de l'instance ShadowCallStack dans l'épilogue de la fonction.

WPA3 et Wi-Fi Enhanced Open

Android 10 est compatible avec les normes de sécurité WPA3 (Wi-Fi Protected Access 3) et Wi-Fi Enhanced Open pour améliorer la confidentialité et la robustesse contre les attaques connues.

Confidentialité

Accès de l'application lorsque vous ciblez Android 9 ou 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 plate-forme 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 requête.

Restrictions d'activité en arrière-plan

À partir d'Android 10, le système limite le démarrage d'activités en arrière-plan. Ce changement de comportement permet de réduire les interruptions pour l'utilisateur et de lui donner plus de contrôle sur ce qui s'affiche à l'écran. Tant que votre application démarre des activités en raison directe de l'interaction 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 sur l'alerte des utilisateurs sur les événements sensibles au temps dans votre application.

Métadonnées de l'appareil photo

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 pour accéder aux métadonnées potentiellement spécifiques à l'appareil incluses dans la valeur renvoyée par 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

Sauf si votre application est l'éditeur de méthode d'entrée (IME) par défaut ou l'application actuellement sélectionnée, elle ne peut pas accéder aux données du presse-papiers sur Android 10 ou version ultérieure.

Localisation de l'appareil

Pour permettre aux utilisateurs de contrôler davantage 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 que l'accès d'une application à la position lorsqu'elle s'exécute en arrière-plan. Une application est considérée comme accédant aux données de 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é un type de service de premier plan de location.
    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 une version ultérieure. Découvrez comment les services de premier plan peuvent continuer les actions déclenchées par l'utilisateur qui nécessitent l'accès à la position.

Stockage externe

Par défaut, les applications ciblant Android 10 ou version ultérieure bénéficient d'un accès limité au stockage externe, ou espace de stockage cloisonné. Ces applications peuvent voir les types de fichiers suivants sur un appareil de stockage externe sans avoir à demander d'autorisations utilisateur liées au stockage:

  • Fichiers du répertoire spécifique à l'application, accessibles à l'aide de getExternalFilesDir().
  • Photos, vidéos et extraits audio créés par l'application à partir du MediaStore

Pour en savoir plus sur l'espace de stockage cloisonné, ainsi que sur le partage, l'accès et la modification des fichiers enregistrés sur des appareils de stockage externes, consultez les guides sur la gestion des fichiers dans l'espace de stockage externe et sur l'accès et la modification des fichiers multimédias.

Sélection aléatoire de l'adresse MAC

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

  • Obtenir une adresse MAC aléatoire: les applications propriétaires de l'appareil et les applications propriétaires 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 d'usine réelle:les applications propriétaires de l'appareil peuvent récupérer l'adresse MAC matérielle réelle de l'appareil en appelant getWifiMacAddress(). Cette méthode est utile pour suivre des parcs 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, y compris le code IMEI et le numéro de série.

Si votre application ne dispose pas de cette autorisation et que vous essayez de demander des informations sur les identifiants non réinitialisables, la réponse de la plate-forme 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 d'API 28) ou une version antérieure, la méthode renvoie null ou des données d'espace réservé si l'application dispose de l'autorisation READ_PHONE_STATE. Dans le cas contraire, une erreur 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 son activité physique, comme la marche, le vélo ou le déplacement dans un véhicule. Il est conçu pour permettre aux utilisateurs de voir comment 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, sauf si l'utilisateur a accordé cette autorisation à votre application.
Les seuls capteurs intégrés de l'appareil qui nécessitent de déclarer cette autorisation sont les capteurs compteur de pas et détecteur de pas.
Si votre application cible Android 9 (niveau d'API 28) ou version antérieure, le système accorde automatiquement l'autorisation android.permission.ACTIVITY_RECOGNITION à votre application, si nécessaire, si votre application répond à 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 accorde automatiquement l'autorisation android.permission.ACTIVITY_RECOGNITION, votre application conserve l'autorisation après avoir mis à jour votre application pour cibler Android 10. Toutefois, 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 équipés d'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 plus rechercher la façon dont les autorisations sont regroupées dans l'UI.

Suppression de l'affinité des contacts

À partir d'Android 10, la plate-forme ne suit plus 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 triés par fréquence d'interaction.
Le guide sur ContactsProvider contient une notification décrivant les champs et méthodes spécifiques obsolètes sur tous les appareils à partir d'Android 10.

A limité l'accès au contenu affiché à 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 le champ d'application des autorisations READ_FRAME_BUFFER, CAPTURE_VIDEO_OUTPUT et CAPTURE_SECURE_VIDEO_OUTPUT. Depuis Android 10, ces autorisations sont signature-access uniquement.
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 d'autoriser l'accès.

Numéro de série de l'appareil USB

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

Wi-Fi

Les applications qui ciblent Android 10 ou une version ultérieure ne peuvent pas activer ni 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 concernant 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 stratégie d'appareil (DPC). Un DPC donné peut être le propriétaire de l'appareil ou le propriétaire du profil.
Si votre application cible Android 10 ou version ultérieure, et qu'elle n'est pas une application système ni 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

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

  • File-based encryption. Encrypting at the file level, instead of encrypting the entire storage area as a single unit, better isolates and protects individual users and profiles (such as personal and work) on a device.
  • Direct Boot. Enabled by file-based encryption, Direct Boot allows certain apps such as alarm clock and accessibility features to run when device is powered on but not unlocked.
  • Verified Boot. Verified Boot is now strictly enforced to prevent compromised devices from booting; it supports error correction to improve reliability against non-malicious data corruption.
  • SELinux. Updated SELinux configuration and increased seccomp coverage further locks down the Application Sandbox and reduces attack surface.
  • Library load-order randomization and improved ASLR. Increased randomness makes some code-reuse attacks less reliable.
  • Kernel hardening. Added additional memory protection for newer kernels by marking portions of kernel memory as read-only, restricting kernel access to userspace addresses and further reducing the existing attack surface.
  • APK signature scheme v2. Introduced a whole-file signature scheme that improves verification speed and strengthens integrity guarantees.
  • Trusted CA store. To make it easier for apps to control access to their secure network traffic, user-installed certificate authorities and those installed through Device Admin APIs are no longer trusted by default for apps targeting API Level 24+. Additionally, all new Android devices must ship with the same trusted CA store.
  • Network Security Config. Configure network security and TLS through a declarative configuration file.

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 antérieures.
  • Démarrage validé 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 en bon état, du bootloader au système d'exploitation.
  • Sécurité isolée par matériel Nouvelle couche d'abstraction matérielle (HAL) utilisée par l'API Fingerprint, l'écran de verrouillage, le chiffrement de l'appareil 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'une simple pression du doigt. Les développeurs peuvent également utiliser les nouvelles API pour verrouiller et déverrouiller des clés de chiffrement à l'aide d'empreintes digitales.
  • Adoption de la carte SD Les supports amovibles peuvent être adoptés sur un appareil et augmenter l'espace de stockage disponible pour les données locales de l'application, les photos, les vidéos, etc., tout en étant protégés par le chiffrement au niveau des blocs.
  • Trafic en texte clair Les développeurs peuvent utiliser un nouveau mode strict pour s'assurer que leur application n'utilise pas de texte clair.
  • Renforcement du système. Durcissement du système via des règles 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 renforcement supplémentaire des domaines SELinux et un accès /proc extrêmement limité.
  • Contrôle des accès USB:les utilisateurs doivent confirmer pour autoriser l'accès USB aux fichiers, au stockage ou à d'autres fonctionnalités du téléphone. La valeur par défaut est désormais Charger uniquement, avec un accès au stockage nécessitant l'approbation explicite de l'utilisateur.

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 (through NFC, Bluetooth) or being used by someone with a trusted face.
  • Multi user, restricted profile, and guest modes for phones and 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 allows 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 ou version antérieure

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

  • Android sandbox reinforced with SELinux. Android now uses SELinux in enforcing mode. SELinux is a mandatory access control (MAC) system in the Linux kernel used to augment the existing discretionary access control (DAC) based security model. This provides additional protection against potential security vulnerabilities.
  • Per User VPN. On multi-user devices, VPNs are now applied per user. This can allow a user to route all network traffic through a VPN without affecting other users on the device.
  • ECDSA Provider support in AndroidKeyStore. Android now has a keystore provider that allows use of ECDSA and DSA algorithms.
  • Device Monitoring Warnings. Android provides users with a warning if any certificate has been added to the device certificate store that could allow monitoring of encrypted network traffic.
  • FORTIFY_SOURCE. Android now supports FORTIFY_SOURCE level 2, and all code is compiled with these protections. FORTIFY_SOURCE has been enhanced to work with clang.
  • Certificate Pinning. Android 4.4 detects and prevents the use of fraudulent Google certificates used in secure SSL/TLS communications.
  • Security Fixes. Android 4.4 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.

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 apps. 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 apps or affect system behavior.
  • No setuid or setgid programs. Added support for filesystem capabilities to Android system files and removed all setuid or setgid programs. This reduces root attack surface and the likelihood of potential security vulnerabilities.
  • ADB authentication. Starting in 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 apps 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 apps. This prevents Android apps and apps launched from the shell from acquiring privileged capabilities.
  • AndroidKeyStore Provider. Android now has a keystore provider that allows apps to create exclusive use keys. This provides apps with an API to create or store private keys that cannot be used by other apps.
  • KeyChain isBoundKeyAlgorithm. Keychain API now provides a method (isBoundKeyType) that allows apps 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 can't 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 app code. This prevents Android apps from performing operations that can elevate privileges through 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 or 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:

  • App verification: Users can choose to enable Verify Apps and have apps screened by an app verifier, prior to installation. App verification can alert the user if they try to install an app that might be harmful; if an app is especially bad, it can block installation.
  • More control of premium SMS: Android provides a notification if an app attempts to send SMS to a short code that uses premium services that might cause additional charges. The user can choose whether to allow the app to send the message or block it.
  • Always-on VPN: VPN can be configured so that apps won't have access to the network until a VPN connection is established. This prevents apps from sending data across other networks.
  • Certificate pinning: The Android core libraries now support certificate pinning. Pinned domains receive a certificate validation failure if the certificate doesn't chain to a set of expected certificates. This protects against possible compromise of certificate authorities.
  • Improved display of Android permissions: Permissions are 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 apps to prevent memory corruption.
  • ContentProvider default configuration: Apps that target API level 17 have export set to false by default for each Content Provider, reducing default attack surface for apps.
  • 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 Android 1.5 à 4.1:

Android 1.5
  • ProPolice pour éviter les dépassements de tampon de pile (-fstack-protector)
  • safe_iop pour réduire les débordements d'entiers
  • Extensions de dlmalloc OpenBSD pour éviter les failles de double free() et les attaques de consolidation de blocs. Les attaques de consolidation de blocs sont un moyen courant d'exploiter la corruption de tas.
  • calloc OpenBSD pour éviter les débordements d'entiers lors de l'allocation de mémoire
Android 2.3
  • Protection contre les failles de chaîne de format (-Wformat-security -Werror=format-security)
  • NX (Never eXecute) matériel pour empêcher l'exécution de code sur la pile et la mémoire heap
  • Linux mmap_min_addr pour atténuer l'escalade des droits d'accès en cas de déréférencement de pointeur nul (encore amélioré dans Android 4.1)
Android 4.0
La randomisation de la disposition de l'espace d'adressage (ASLR, Address Space Layout Randomization) pour randomiser les emplacements clés en mémoire
Android 4.1
  • Compatibilité avec les fichiers exécutables indépendants de la position (PIE)
  • Déplacements en lecture seule / liaison immédiate (-Wl,-z,relro -Wl,-z,now)
  • dmesg_restrict activé (éviter les fuites d'adresses de noyau)
  • kptr_restrict activé (pour éviter les fuites d'adresses de kernel)