Bonnes pratiques de sécurité du système

Cette section contient des recommandations pour assurer la sécurité du système d'exploitation Android et des appareils de base.

Authentification biométrique

Acquérez, stockez et traitez soigneusement les données biométriques pour l'authentification des utilisateurs. Vous saurez :

  • Exiger la méthode d'authentification principale avant d'utiliser toute autre forme d'authentification (y compris la biométrie)
  • Exiger une confirmation explicite pour indiquer l'intention lorsque vous utilisez des modalités biométriques passives, telles que la reconnaissance faciale, pour les transactions (par exemple, les paiements) impliquant des clés liées à l'authentification.
  • Exiger la méthode d'authentification principale toutes les 72 heures.
  • Utilisez un pipeline entièrement sécurisé pour toutes les données biométriques et leur traitement.
  • N'envoyez jamais de données biométriques (y compris les mesures brutes des capteurs et les fonctionnalités dérivées) en dehors de l'appareil. Si possible, conservez ces données dans un environnement isolé sécurisé, tel que l'environnement d'exécution sécurisé (TEE) ou le composant sécurisé.

Les appareils avec données biométriques doivent prendre en charge l'API BiometricPrompt, qui offre une interface commune et cohérente permettant aux développeurs d'applications de profiter de l'authentification biométrique dans leurs applications. Seules les biométries fortes peuvent être intégrées à BiometricPrompt, et les intégrations doivent respecter les consignes du document de définition de compatibilité Android (CDD).

Pour en savoir plus sur les consignes biométriques, consultez les consignes d'implémentation du HAL biométrique.

SELinux

SELinux définit et applique une grande partie du modèle de sécurité d'Android. L'utilisation correcte de SELinux est essentielle à la sécurité des appareils Android et peut contribuer à atténuer l'impact des failles de sécurité. C'est pourquoi tous les appareils Android doivent implémenter une règle SELinux robuste.

  • Implémentez une stratégie de moindre privilège.
  • Évitez d'accorder les autorisations CAP_DAC_OVERRIDE, CAP_SYS_ADMIN et CAP_NET_ADMIN.
  • Ne journalisez pas les données système sur la carte SD.
  • Utilisez les types fournis pour l'accès au pilote, tels que gpu_device, audio_device, etc.
  • Utilisez des noms significatifs pour les processus, les fichiers et les types SELinux.
    • Assurez-vous que les libellés par défaut ne sont pas utilisés et qu'aucun accès ne leur est accordé.
  • Les règles spécifiques à l'appareil doivent représenter 5 à 10% de la règle globale exécutée sur un appareil. Les personnalisations de plus de 20%contiennent presque certainement des domaines sur-autorisés et des règles obsolètes. Une règle inutilement volumineuse gaspille de la mémoire et de l'espace disque en nécessitant une image de démarrage plus grande, et affecte négativement les temps de recherche de règles d'exécution.

Chargement dynamique des règles SELinux

Ne chargez pas de manière dynamique la règle SELinux sur les appareils Android. Cela peut entraîner des problèmes, comme les suivants:

  • Empêcher l'acceptation des correctifs de sécurité critiques
  • Exposer la possibilité d'accéder aux droits d'administrateur d'un appareil en actualisant les règles.
  • Exposition d'un vecteur d'attaque de l'homme du milieu contre le programme de mise à jour des règles.
  • Cela a entraîné la brique des appareils en raison d'erreurs liées aux mises à jour des règles.

Backdoor (porte dérobée)

Les applications Android ne doivent pas comporter de portes dérobées ni de moyens d'accéder au système ou aux données qui contournent les mécanismes de sécurité normaux. Cela inclut les diagnostics, le débogage, le développement ou l'accès spécial de réparation sous garantie contrôlé par des secrets connus du développeur. Pour éviter les portes dérobées:

  • Analysez toutes les applications tierces à l'aide d'un outil d'analyse des failles d'application reconnu dans le secteur.
  • Effectuez des examens du code de tout code avec un accès sensible, y compris les bibliothèques tierces.
  • Utilisez Google Play Protect en important des applications sur Google Play pour les analyser. Vous pouvez importer des applications pour les analyser sans les publier sur Google Play.
  • Ne préchargez pas d'outils axés sur les diagnostics ou la réparation dans les builds de version. N'installez ces outils que sur demande pour résoudre des problèmes spécifiques. De plus, ces outils ne doivent pas utiliser ni importer de données spécifiques au compte.

Outils de développement

Les outils de développement, tels que les outils de débogage, de test et de diagnostic, peuvent souvent créer des failles de sécurité involontaires sur votre appareil en révélant leur fonctionnement et les données qu'ils collectent. Pour vous assurer que les outils de développement ne figurent pas dans les builds de production:

  • Développez une liste noire de hachages d'outils de débogage et de test internes, puis analysez les builds pour ces APK avant d'utiliser l'image système.
  • Analysez toutes les applications propriétaires à l'aide d'un outil d'analyse des failles d'application reconnu dans le secteur.
  • Faites appel à une entreprise tierce spécialisée dans les tests de sécurité des applications pour évaluer toutes les applications de diagnostic critiques sur l'appareil avant toute mise à jour majeure, en particulier si l'application est développée par un tiers.
  • Assurez-vous que seul l'utilisateur peut activer l'outil, par commande vocale ou par chat, pendant une session d'assistance. Stockez les artefacts du consentement et désactivez l'outil après avoir collecté les informations de diagnostic nécessaires.
  • Stockez l'enregistrement de l'utilisation de cet outil dans un journal accessible par l'utilisateur dans son compte opérateur.
  • Assurez-vous que toutes les informations permettant d'identifier personnellement l'utilisateur ou les données de télémétrie de l'appareil collectées par l'outil sont soumises à des pratiques d'anonymisation, de conservation et de suppression adaptées au pays. Seules les données pertinentes pour l'appel d'assistance doivent être collectées. Ces données doivent être supprimées après chaque appel.
  • Assurez-vous que les techniques pouvant être utilisées par des logiciels espions, telles que la journalisation des frappes, l'utilisation du micro ou de la caméra, ne sont pas utilisées sans le consentement explicite de l'utilisateur. Les applications qui utilisent ces méthodes potentiellement intrusives sur la confidentialité doivent être très clairement indiquées, avec des règles de confidentialité auxquelles l'utilisateur doit donner son consentement. De telles applications ne doivent pas être activées sans le consentement explicite de l'utilisateur.

Voici quelques suggestions supplémentaires à suivre lors de l'implémentation de la divulgation et du consentement:

Communiqué dans l'application

  • Affichez l'utilisation normale de l'application directement dans l'application. Ne demandez pas à l'utilisateur de naviguer dans un menu ni de chercher dans les paramètres.
  • Décrivez le type de données collectées et expliquez comment elles sont utilisées.
  • Dans l'idéal, n'intégrez pas ces informations dans des règles de confidentialité ou des conditions d'utilisation. Ne l'incluez pas avec d'autres informations sans rapport avec la collecte de données sensibles ou à caractère personnel.
  • Le consentement doit être explicite. Ne pas considérer le fait que l'utilisateur quitte le communiqué (y compris en appuyant ailleurs, en revenant à l'accueil ou en appuyant sur un bouton "Retour") comme un consentement.
  • Présentez la boîte de dialogue de consentement de façon claire et non équivoque.
  • Nécessitez une action affirmative de la part de l'utilisateur pour accepter, par exemple appuyer pour accepter ou prononcer une commande.
  • Ne collectez pas de données à caractère personnel ou sensibles avant d'obtenir un consentement explicite.
  • N'utilisez pas de messages éphémères ou qui disparaissent automatiquement.

Fonctionnalité intégrée dans AOSP

L'intégration de fonctionnalités supplémentaires dans AOSP peut souvent avoir des conséquences et un comportement inattendus. Procédez avec prudence.

  • Assurez-vous que l'utilisateur est invité à utiliser différentes applications par défaut (moteur de recherche, navigateur Web, lanceur, par exemple) et indiquez l'envoi de données hors de l'appareil.
  • Assurez-vous que les APK AOSP sont signés avec le certificat AOSP.
  • Exécutez des tests de régression et conservez un journal des modifications pour déterminer si du code a été ajouté aux APK AOSP.

Mises à jour de sécurité

Les appareils Android doivent bénéficier d'une assistance de sécurité continue pendant au moins deux ans à compter de leur lancement. Cela inclut la réception de mises à jour régulières qui corrigent les failles de sécurité connues.

  • Collaborez avec des partenaires matériels, tels que vos fournisseurs de SoC, pour mettre en place des contrats d'assistance appropriés pour tous les composants de votre appareil Android.
  • Assurez-vous que les mises à jour de sécurité peuvent être installées avec une interaction minimale de l'utilisateur afin d'augmenter la probabilité que les utilisateurs acceptent et installent les mises à jour sur leur appareil Android. Nous vous recommandons vivement d'implémenter les mises à jour système fluides ou une fonctionnalité de sécurité équivalente.
  • Assurez-vous de comprendre l'exigence cumulative du niveau du correctif de sécurité Android (SPL) tel que déclaré dans le Bulletin de sécurité Android. Par exemple, les appareils qui utilisent le niveau de correctif de sécurité 2018-02-01 doivent inclure tous les problèmes associés à ce niveau de correctif de sécurité, ainsi que les correctifs de tous les problèmes signalés dans tous les bulletins de sécurité précédents.

Mises à jour du noyau dynamiques

Ne modifiez pas de manière dynamique les composants système critiques. Bien que certaines recherches suggèrent que les mises à jour dynamiques du noyau aident à se protéger contre les menaces d'urgence, le coût évalué l'emporte actuellement sur les avantages. Créez plutôt une méthode de mise à jour OTA robuste pour distribuer rapidement les protections contre les failles.

Gestion des clés

Respectez des règles et des pratiques de gestion des clés efficaces pour assurer la sécurité des clés de signature.

  • Ne partagez pas de clés de signature avec des tiers.
  • Si une clé de signature est compromise, générez une nouvelle clé et doublez la signature de toutes les applications à venir.
  • Stockez toutes les clés dans des services ou du matériel de module haute sécurité nécessitant plusieurs facteurs d'accès.

Signature de l'image système

La signature de l'image système est essentielle pour déterminer l'intégrité de l'appareil.

  • Ne signez pas d'appareils avec une clé connue publiquement.
  • Gérez les clés de signature de l'appareil de manière conforme aux pratiques standards du secteur pour la gestion des clés sensibles, y compris un module de sécurité matérielle (HSM) qui fournit un accès limité et auditable.

Bootloaders déverrouillables

De nombreux appareils Android sont compatibles avec le déverrouillage, ce qui permet au propriétaire de l'appareil de modifier la partition système ou d'installer un système d'exploitation personnalisé. Les cas d'utilisation courants incluent l'installation d'une image système tierce et l'exécution de développement au niveau du système sur l'appareil. Par exemple, pour déverrouiller l'image système sur un Google Nexus ou un Pixel, un utilisateur peut exécuter fastboot oem unlock, ce qui affiche le message suivant:

Il est recommandé que les appareils Android déverrouillables effacent de manière sécurisée toutes les données utilisateur avant d'être déverrouillés. Si toutes les données ne sont pas correctement supprimées lors du déverrouillage, un pirate informatique à proximité peut obtenir un accès non autorisé aux données utilisateur Android confidentielles. Pour éviter la divulgation des données utilisateur, un appareil compatible avec le déverrouillage doit l'implémenter correctement.

  • Une fois que l'utilisateur a confirmé la commande de déverrouillage, l'appareil doit lancer un effacement immédiat des données. L'indicateur unlocked ne doit pas être défini tant que la suppression sécurisée n'est pas terminée.
  • Si une suppression sécurisée ne peut pas être effectuée, l'appareil doit rester verrouillé.
  • Si l'appareil de bloc sous-jacent est compatible, ioctl(BLKSECDISCARD) ou un équivalent doit être utilisé. Pour les appareils eMMC (embedded MultiMediaCard), cela signifie utiliser une commande Secure Erase ou Secure Trim. Pour eMMC 4.5 et versions ultérieures, cela signifie utiliser une opération d'effacement ou de suppression normale suivie d'une opération de nettoyage.
  • Si BLKSECDISCARD n'est pas compatible avec l'appareil de bloc sous-jacent, ioctl(BLKDISCARD) doit être utilisé à la place. Sur les appareils eMMC, il s'agit d'une opération de suppression normale.
  • Si BLKDISCARD n'est pas compatible, l'écrasement des appareils de bloc avec des zéros est acceptable.
  • Un utilisateur doit avoir la possibilité d'exiger que les données utilisateur soient effacées avant de flasher une partition. Par exemple, les appareils Nexus utilisent la commande fastboot oem lock pour effacer les données utilisateur.
  • Un appareil peut enregistrer, via des eFuses ou un mécanisme similaire, si un appareil a été déverrouillé et/ou verrouillé à nouveau. Toutefois, nous vous recommandons vivement de verrouiller à nouveau le bootloader et de rétablir la configuration d'usine pour restaurer toutes les fonctionnalités de l'appareil.

Ces exigences garantissent que toutes les données sont détruites à la fin d'une opération de déverrouillage. L'absence d'implémentation de ces protections est considérée comme une faiblesse de sécurité de niveau modéré.

Un appareil déverrouillé peut être verrouillé à nouveau à l'aide de la commande fastboot oem lock. Le verrouillage du bootloader offre la même protection des données utilisateur avec le nouveau système d'exploitation personnalisé que celle disponible avec le système d'exploitation d'origine du fabricant de l'appareil (par exemple, les données utilisateur sont effacées si l'appareil est à nouveau déverrouillé).

Test d'intrusion sur un appareil

Les appareils doivent être examinés par un testeur d'intrusion compétent avant d'être expédiés. Le test d'intrusion doit établir que l'appareil a suivi les consignes de sécurité fournies ici, ainsi que les consignes de sécurité internes de l'OEM.

Tests de sécurité

Utilisez les outils de test de sécurité fournis par AOSP. En particulier

  • Utilisez des outils de sécurité de la mémoire lors du développement: utilisez MTE si compatible (ARMv9 et versions ultérieures) et HWASan si ce n'est pas le cas. Exécutez autant de tests que possible avec ces outils activés.
  • Utilisez GWP-ASan et KFENCE en production pour détecter de manière probabiliste les problèmes de sécurité de la mémoire.