Meilleures pratiques en matière de sécurité du système

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

Authentification biométrique

Acquérez, stockez et traitez soigneusement les données biométriques pour l’authentification des utilisateurs. Tu devrais:

  • Exigez 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 lors de l'utilisation de modalités biométriques passives, telles que la reconnaissance faciale, pour des transactions (par exemple, des paiements) qui impliquent 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 caractéristiques dérivées) hors de l'appareil. Si possible, conservez ces données dans un environnement isolé et sécurisé, tel que Trusted Execution Environment (TEE) ou Secure Element.

Les appareils dotés de 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 tirer parti de l'authentification basée sur la biométrie dans leurs applications. Seules des données biométriques solides peuvent s'intégrer à BiometricPrompt et les intégrations doivent suivre les directives du document de définition de compatibilité Android (CDD).

Pour plus de directives biométriques, voir Directives de mise en œuvre biométriques HAL .

SELinux

SELinux fournit la définition et l'application d'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 aider à atténuer l'impact des vulnérabilités de sécurité. Tous les appareils Android doivent implémenter une politique SELinux robuste pour cette raison.

  • Mettez en œuvre une politique de moindre privilège.
  • Évitez d'accorder les autorisations CAP_DAC_OVERRIDE , CAP_SYS_ADMIN et CAP_NET_ADMIN .
  • N'enregistrez pas les données du 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 étiquettes par défaut ne sont pas utilisées et que l’accès ne leur est pas accordé.
  • La stratégie spécifique à l’appareil doit représenter 5 à 10 % de la stratégie globale exécutée sur un appareil. Les personnalisations de l'ordre de 20 % et plus contiennent presque certainement des domaines surprivilégiés et des politiques mortes. Une stratégie inutilement volumineuse gaspille de la mémoire, gaspille de l’espace disque en nécessitant une image de démarrage plus grande et affecte négativement les temps de recherche de stratégie d’exécution.

Chargement dynamique de la politique SELinux

Ne chargez pas dynamiquement la stratégie SELinux sur les appareils Android. Cela peut entraîner des problèmes tels que :

  • Empêcher l’acceptation de correctifs de sécurité critiques.
  • Exposer la possibilité de rooter un appareil via le rechargement des politiques.
  • Exposer un vecteur d'attaques de l'homme du milieu contre le programme de mise à jour de la politique.
  • Cela entraîne des appareils maçonnés en raison d’erreurs liées aux mises à jour des politiques.

Portes dérobées

Les applications Android ne doivent pas avoir 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 un accès spécial aux diagnostics, au débogage, au développement ou à la réparation sous garantie, sécurisé par des secrets connus du développeur. Pour empêcher les portes dérobées :

  • Analysez toutes les applications tierces à l'aide d'un outil d'analyse des vulnérabilités des applications reconnu par l'industrie.
  • Effectuez des révisions de code de tout le code avec un accès sensible, y compris les bibliothèques tierces.
  • Utilisez Google Play Protect en téléchargeant des applications sur Google Play pour analyse. Vous pouvez télécharger des applications à numériser sans les publier sur Google Play.
  • Ne préchargez pas d’outils axés sur les diagnostics ou les réparations sur les versions de version. Installez ces outils uniquement à la demande pour résoudre des problèmes spécifiques. De plus, ces outils ne doivent pas fonctionner sur ou télécharger des 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 sont pas intégrés aux versions de production :

  • Développez une liste noire des hachages des outils de débogage et de test internes et analysez les versions de ces APK avant d'utiliser l'image système.
  • Analysez toutes les applications propriétaires à l'aide d'un outil d'analyse des vulnérabilités des applications reconnu par l'industrie.
  • Embauchez une société tierce de 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, verbalement ou par chat, lors d'une session d'assistance. Stockez les artefacts de consentement et désactivez l’outil après avoir collecté les informations de diagnostic nécessaires.
  • Conservez 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 personnellement identifiables (PII) 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 pertinentes pour le 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 pour les logiciels espions, telles que l'enregistrement des frappes au clavier, l'utilisation du microphone ou de la caméra, ne sont pas utilisées sans le consentement explicite de l'utilisateur. Les applications utilisant ces méthodes potentiellement envahissantes pour la vie privée doivent être très clairement divulguées, accompagnées d'une politique de confidentialité à laquelle l'utilisateur doit consentir. Des applications comme celle-ci ne doivent pas être activées sans le consentement explicite de l'utilisateur.

Voici quelques suggestions supplémentaires à prendre en compte lors de la mise en œuvre de la divulgation et du consentement :

Divulgation dans l'application

  • Affichez l'utilisation normale de l'application directement dans l'application. N'exigez pas que l'utilisateur navigue dans un menu ou des paramètres.
  • Décrivez le type de données collectées et expliquez comment les données seront utilisées.
  • Idéalement, n’intégrez pas ces informations dans une politique de confidentialité ou des conditions de service. Ne l'incluez pas avec d'autres divulgations sans rapport avec la collecte de données personnelles ou sensibles.
  • Le consentement doit être affirmatif. Ne considérez pas la navigation en dehors de la divulgation, y compris le fait d'appuyer sur le bouton Retour ou Accueil, comme un consentement.
  • Présentez la boîte de dialogue de consentement de manière claire et sans ambiguïté.
  • Exiger une action positive de l'utilisateur, comme appuyer pour accepter ou prononcer une commande, pour accepter.
  • Ne collectez pas de données personnelles ou sensibles avant d’obtenir un consentement affirmatif.
  • N'utilisez pas de messages à suppression automatique ou à expiration.

Fonctionnalité intégrée dans AOSP

L'intégration de fonctionnalités supplémentaires dans AOSP peut souvent avoir un comportement et des conséquences inattendues ; procéder avec prudence.

  • Assurez-vous que l'utilisateur est invité s'il souhaite utiliser différentes applications par défaut (par exemple, moteur de recherche, navigateur Web, lanceur) et divulgue l'envoi de données depuis 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’un support de sécurité continu pendant au moins deux ans à compter de leur lancement. Cela inclut la réception de mises à jour régulières qui corrigent les vulnérabilités de sécurité connues.

  • Travaillez avec des partenaires matériels, tels que vos fournisseurs de SoC, pour mettre en place des accords de support 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 pour augmenter la probabilité que les utilisateurs acceptent et installent les mises à jour sur leur appareil Android. La mise en œuvre de mises à jour système transparentes ou d’une fonctionnalité de sécurité équivalente est fortement recommandée.
  • Assurez-vous de bien comprendre les exigences cumulatives du niveau de correctif de sécurité Android (SPL), telles que déclarées 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 pour tous les problèmes signalés dans tous les bulletins de sécurité précédents.

Mises à jour dynamiques du noyau

Ne modifiez pas dynamiquement les composants système critiques. Bien que certaines recherches suggèrent que les mises à jour dynamiques du noyau contribuent à protéger contre les menaces d'urgence, le coût estimé dépasse actuellement les avantages. Créez plutôt une méthode de mise à jour OTA robuste pour distribuer rapidement les protections contre les vulnérabilités.

Gestion des clés

Maintenir de bonnes politiques et pratiques de gestion des clés pour garantir la sécurité des clés de signature.

  • Ne partagez pas les clés de signature avec des parties externes.
  • Si une clé de signature est compromise, générez une nouvelle clé et signez deux fois toutes les applications à l'avenir.
  • Stockez toutes les clés dans du matériel ou des services de modules de haute sécurité nécessitant plusieurs facteurs d'accès.

Signature d'image système

La signature de l'image système est essentielle pour déterminer l'intégrité du périphérique.

  • Ne signez pas d’appareils avec une clé publiquement connue.
  • Gérez les clés de signature des appareils d'une manière conforme aux pratiques standard du secteur en matière de gestion des clés sensibles, y compris un module de sécurité matériel (HSM) qui fournit un accès limité et vérifiable.

Chargeurs de démarrage déverrouillables

De nombreux appareils Android prennent en charge le déverrouillage, permettant 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 d'un développement au niveau du système sur l'appareil. Par exemple, pour déverrouiller l'image système sur un Google Nexus ou Pixel, un utilisateur peut exécuter fastboot oem unlock , qui affiche ce message :

En tant que bonne pratique, les appareils Android déverrouillables doivent effacer en toute sécurité toutes les données utilisateur avant d'être déverrouillés. Le fait de ne pas supprimer correctement toutes les données lors du déverrouillage peut permettre à un attaquant physiquement proche d'obtenir un accès non autorisé aux données confidentielles des utilisateurs Android. Pour empêcher la divulgation des données utilisateur, un appareil prenant en charge 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 activé avant la fin de la suppression sécurisée.
  • Si une suppression sécurisée ne peut pas être effectuée, l'appareil doit rester dans un état verrouillé.
  • S'il est pris en charge par le périphérique de bloc sous-jacent, ioctl(BLKSECDISCARD) ou équivalent doit être utilisé. Pour les appareils MultiMediaCard (eMMC) intégrés, cela signifie utiliser une commande Secure Erase ou Secure Trim. Pour eMMC 4.5 et versions ultérieures, cela signifie utiliser un effacement ou un découpage normal suivi d'une opération de désinfection.
  • Si BLKSECDISCARD n'est pas pris en charge par le périphérique de bloc sous-jacent, ioctl(BLKDISCARD) doit être utilisé à la place. Sur les appareils eMMC, il s’agit d’une opération Trim normale.
  • Si BLKDISCARD n'est pas pris en charge, l'écrasement des périphériques de bloc avec tous 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 reverrouillé. Cependant, nous recommandons fortement que le reverrouillage du chargeur de démarrage avec une réinitialisation d'usine ultérieure rétablisse 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. Le fait de ne pas mettre en œuvre ces protections est considéré comme une vulnérabilité de sécurité de niveau modéré .

Un appareil déverrouillé peut ensuite être reverrouillé à l'aide de la commande fastboot oem lock . Le verrouillage du chargeur de démarrage 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 du fabricant d'origine de l'appareil (par exemple, les données utilisateur seront effacées si l'appareil est à nouveau déverrouillé).

Test d'intrusion des appareils

Les appareils doivent être examinés par un pentester compétent avant leur expédition. Le test d'intrusion doit établir que l'appareil a suivi les directives de sécurité fournies ici ainsi que les directives de sécurité internes du OEM.

Tests de sécurité

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

  • Utilisez des outils de sécurité de la mémoire pendant le développement : utilisez MTE là où il est pris en charge (ARMv9 et supérieur) et HWASan là où il ne l'est pas. Exécutez autant de tests que possible avec ces outils activés.
  • Utilisez GWP-ASan et KFENCE en production, pour une détection probabiliste des problèmes de sécurité de la mémoire.