Guide complet des bibliothèques d'état de sécurité dans Android

Informatec Digital » Sécurité » Guide complet des bibliothèques d'état de sécurité dans Android

Sécuriser un smartphone Android est aujourd'hui un véritable casse-tête. Face à la complexité croissante de cet écosystème, les développeurs s'appuyaient autrefois sur un indicateur très général appelé niveau de correctif de sécurité (SPL), ce qui revenait à essayer de déterminer la sécurité d'une maison en se basant uniquement sur la date de la dernière rénovation importante, sans savoir si la serrure de la porte arrière est toujours défectueuse.

Pour combler ce manque d'informations, les bibliothèques AndroidX Security State et Security State Provider ont été créées . Ces outils révolutionnaires offrent une visibilité détaillée sur l'ensemble du système, permettant aux logiciels d'être véritablement résilients aux attaques et aux applications de prendre des décisions intelligentes basées sur des preuves concrètes, et non sur de simples suppositions, établissant ainsi un modèle de confiance zéro.

Adieu au patch unique : l'ère de la granularité

Le principal problème lié à l'utilisation d'une seule bibliothèque de sécurité (SPL) est qu'Android est désormais mis à jour de manière fragmentée grâce à Project Mainline et aux mises à jour système de Google Play. Pour structurer ce système complexe, les nouvelles bibliothèques répartissent la sécurité autour de trois piliers : le système d'exploitation (mis à jour par liaison radio), les modules système (distribués via Google Play) et le noyau Linux , qui constitue la base de tout et dont la disponibilité est évaluée en versions LTS plutôt qu'en dates de publication mensuelles.

Pour chacun de ces éléments, trois états différents peuvent être consultés, offrant ainsi une vision complète de la situation :

• Dispositif SPL (DSPL) : Il indique ce qui est installé et en cours d'exécution sur l'appareil à ce moment précis, sans nécessiter de connexion Internet.
• SPL publié (PSPL) : Il s'agit de la version la plus récente publiée officiellement dans le bulletin de sécurité Android.
• SPL disponible (ASPL) : Il révèle s'il existe une mise à jour déjà téléchargée ou prête à être installée via un mécanisme de communication inter-processus (IPC).

Contrôle des vulnérabilités et audit des CVE

L'un des atouts majeurs est l'intégration avec la base de données Open Source Vulnerabilities (OSV) . Il n'est plus nécessaire de deviner si un correctif mensuel corrige une vulnérabilité spécifique ; il est désormais possible de suivre par programmation les CVE spécifiques .

C'est une aubaine pour les applications fintech, bancaires ou de santé, car elles peuvent restreindre les transferts de fonds importants ou l'accès aux données sensibles si elles détectent qu'une vulnérabilité critique Bluetooth ou NFC est toujours active sur l'appareil. Par exemple, des failles telles que l'écriture hors limites dans libimagecodec.quram.so pourraient permettre à des attaquants distants d'exécuter du code arbitraire, transformant ainsi un appareil obsolète en porte dérobée dans les réseaux d'entreprise.

Implémentation technique et flux de travail

Pour que cela fonctionne, le développeur doit ajouter la dépendance. androidx.security:security-state:1.1.0 dans votre fichier Gradle. L'initialisation est simple et nécessite un contexte Android, mais la vitesse peut être améliorée en transmettant un rapport de vulnérabilité au format JSON directement au constructeur. État du correctif de sécurité.

Le flux de travail est généralement divisé en trois types de contrôles :

• Vérifications synchrones : Ils servent à inspecter le DSPL au démarrage de l'application et à le comparer à une date de référence obligatoire.
• Requêtes asynchrones : À travers fetchAvailableSecurityPatchLevelL'application peut informer l'utilisateur qu'une mise à jour est en attente et le rediriger vers les paramètres.
• Audits approfondis : Avec queryAllAvailableUpdates Vous pouvez analyser la fraîcheur des données et découvrir quel fournisseur de mises à jour répond.

Il est important de noter que la prise en charge varie selon la version du système. Si Android 11 et les versions ultérieures offrent une prise en charge complète, Android 10 ne dispose d'aucune prise en charge officielle au niveau du noyau, et dans les versions 9 et antérieures, où les modules du projet Mainline n'existaient pas, le système renvoie par défaut la date Unix (1970-01-01) .

Le rôle du fournisseur d'état de sécurité et les nouvelles fonctionnalités d'Android 17

Pour que ce système fonctionne, il faut qu'une autorité annonce la disponibilité des mises à jour. C'est là qu'intervient le fournisseur d'état de sécurité (ASPL) , qui normalise la manière dont les clients de mise à jour communiquent avec l'ASPL. Auparavant, les informations OTA de chaque fabricant étaient cloisonnées et propriétaires ; désormais, toute application autorisée peut accéder à ces données, quelle que soit la marque du téléphone.

De plus, Android 17 a introduit une amélioration majeure pour les fabricants (OEM) grâce à un fichier XML de correctifs supplémentaires . Ce fichier leur permet de déclarer leurs propres correctifs de sécurité implémentés sans attendre la publication de la liste de correctifs de sécurité globale (SPL), garantissant ainsi que les efforts de mise à jour en cours soient immédiatement reconnus et que l'appareil ne paraisse pas vulnérable même après avoir été sécurisé.

Autres outils de l'écosystème AndroidX Security

Outre l'état du système, d'autres composants clés existent. La bibliothèque security-crypto est essentielle pour la gestion des clés et le chiffrement des fichiers ou des SharedPreferences. Bien que certaines versions de JetSec soient désormais obsolètes, il est préférable de ne pas surutiliser le stockage de données sensibles, car le modèle sandbox d'Android et le chiffrement basé sur les fichiers sont déjà très robustes.

Il convient également de mentionner security-app-authenticator , qui simplifie la vérification de la fiabilité d'une application à partir de son identité de signature. Utilisant le XML avec les noms et identités des packages, cette bibliothèque garantit que seules les applications légitimes peuvent interagir avec les composants critiques du système.

Le passage à une inspection détaillée au niveau des composants, la possibilité d'auditer les CVE via OSV et la standardisation des mises à jour OTA font d'AndroidX Security State la référence en matière de sécurité mobile renforcée. Grâce à l'intégration de ces outils, les flux de travail critiques sont renforcés et les utilisateurs finaux sont protégés en permanence contre les menaces les plus récentes du paysage numérique.