Accueil La cyber-sécurité Rendre Chrome plus sécurisé en apportant l’épinglage de clé à Android

Rendre Chrome plus sécurisé en apportant l’épinglage de clé à Android

0
Rendre Chrome plus sécurisé en apportant l’épinglage de clé à Android


Chrome 106 a ajouté la prise en charge de l’application par défaut des codes PIN sur Android, amenant Android à la parité avec Chrome sur les plates-formes de bureau. Mais qu’est-ce que l’épinglage de clé ?

L’une des raisons pour lesquelles Chrome implémente l’épinglage de clé est le « règle de deux». Cette règle fait partie du développement sécurisé holistique de Chrome processus. Il indique que lorsque vous écrivez du code pour Chrome, vous ne pouvez en choisir que deux : du code écrit dans un langage non sécurisé, le traitement d’entrées non fiables et l’exécution sans bac à sable. Cet article de blog explique comment l’épinglage de clé et la règle de deux sont liés.

La règle de deux

Chrome est principalement écrit dans les langages C et C++, qui sont vulnérables aux bogues de sécurité de la mémoire. Des erreurs avec les pointeurs dans ces langages peuvent conduire à une mauvaise interprétation de la mémoire. Chrome investit dans une architecture multiprocessus toujours plus solide, basée sur le sandboxing et l’isolation des sites pour aider à se défendre contre les problèmes de sécurité de la mémoire. Les fonctionnalités spécifiques à Android peuvent être écrites en Java ou Kotlin. Ces langages sont sécurisés en mémoire dans le cas courant. De même, nous travaillons sur l’ajout d’un support à écrire du code Chrome dans Rustqui est également sécurisé en mémoire.

Une grande partie de Chrome est en bac à sable, mais le bac à sable nécessite toujours un processus de « courtier » central à privilèges élevés pour coordonner la communication et lancer les processus en bac à sable. Dans Chrome, le courtier est le processus du navigateur. Le processus du navigateur est la source de vérité qui permet au reste de Chrome d’être mis en bac à sable et coordonne la communication entre le reste des processus.

Si un attaquant parvient à créer une entrée malveillante dans le processus du navigateur qui exploite un bug et lui permet d’exécuter du code à distance (RCE) dans le processus du navigateur, cela lui donnerait effectivement un contrôle total sur le navigateur Chrome de la victime et potentiellement le reste de l’appareil. À l’inverse, si un attaquant atteint le RCE dans un processus en bac à sable, tel qu’un moteur de rendu, ses capacités sont extrêmement limitées. L’attaquant ne peut pas sortir du bac à sable à moins de pouvoir exploiter en plus le bac à sable lui-même.

Sans sandboxing, qui limite les actions qu’un attaquant peut entreprendre, et sans sécurité de la mémoire, qui supprime la capacité d’un bug à perturber le flux de contrôle prévu du programme, la règle de deux exige que le processus du navigateur ne gère pas les entrées non fiables. Les risques relatifs entre les processus en bac à sable et le processus du navigateur expliquent pourquoi le processus du navigateur n’est autorisé qu’à analyser les entrées dignes de confiance et les messages IPC spécifiques.

Les entrées fiables sont définies de manière extrêmement stricte : une « source fiable » signifie que Chrome peut prouver que les données proviennent de Google. En pratique, cela signifie que dans les situations où le processus du navigateur a besoin d’accéder à des données provenant de sources externes, celles-ci doivent être lues à partir des serveurs de Google. Nous pouvons prouver cryptographiquement que les données proviennent des serveurs de Google si ces données proviennent :

Le programme de mise à jour des composants et le framework de variantes sont des services spécifiques à Chrome utilisés pour fournir des mises à jour et des informations de configuration contenant uniquement des données. Ces services utilisent tous deux une cryptographie asymétrique pour authentifier leurs données, et la clé publique utilisée pour vérifier les données envoyées par ces services est livrée dans Chrome.

Cependant, Chrome est un navigateur riche en fonctionnalités avec de nombreux cas d’utilisation différents et de nombreuses fonctionnalités différentes au-delà de la simple mise à jour. Certaines fonctionnalités, telles que la connexion et le flux Discover, doivent communiquer avec Google. Pour des fonctionnalités comme celle-ci, cette communication peut être considérée comme fiable si elle provient d’un serveur HTTPS épinglé.

Lorsque Chrome se connecte à un serveur HTTPS, le serveur indique « un tiers en qui vous avez confiance (une autorité de certification ; CA) s’est porté garant de mon identité ». Pour ce faire, il présente un certificat délivré par une autorité de certification de confiance. Chrome vérifie le certificat avant de continuer. Le Web moderne compte nécessairement de nombreuses autorités de certification, qui peuvent toutes assurer l’authentification de n’importe quel site Web. Pour garantir davantage que le processus du navigateur Chrome communique avec un serveur Google digne de confiance, nous souhaitons vérifier quelque chose de plus : si un spécifique CA se porte garant du serveur. Nous faisons cela en créant une carte des sites → autorités de certification attendues directement dans Chrome. Nous appelons cela épinglage de clé. Nous appelons la carte la jeu de broches.

Qu’est-ce que l’épinglage de clé ?

L’épinglage de clé est né comme une défense contre les attaques réelles observées dans la nature : des attaquants qui peuvent tromper une autorité de certification pour qu’elle émette un certificat apparemment valide pour un serveur, puis l’attaquant peut usurper l’identité de ce serveur. Ce c’est arrivé à Google en 2011, lorsque l’autorité de certification DigiNotar a été compromise et utilisée pour émettre des certificats malveillants pour les services Google. Pour se prémunir contre ce risque, Chrome contient un jeu de broches pour toutes les propriétés Google, et nous considérons qu’une entrée HTTPS n’est digne de confiance que si elle est authentifiée à l’aide d’une clé de ce jeu de broches. Cela protège contre l’émission malveillante de certificats par des tiers.

L’épinglage des clés peut être fragile et vaut rarement le risque. Permettre que le code PIN soit obsolète peut conduire à exclure les utilisateurs d’un site Web ou d’autres services, potentiellement de manière permanente. Lors de l’épinglage, il est important de disposer de soupapes de sécurité telles que le fait de ne pas appliquer l’épinglage (c’est-à-dire l’échec de l’ouverture) lorsque les broches n’ont pas été mises à jour récemment, y compris une broche de clé de « secours », et d’avoir des mécanismes de secours pour l’amorçage. Il est difficile pour chaque site de gérer tous ces mécanismes, c’est pourquoi épinglage dynamique sur HTTPS (HPKP) était obsolète. L’épinglage de clé reste cependant un outil important pour certains cas d’utilisation, où une communication à privilèges élevés doit avoir lieu entre un client et un serveur exploités par la même entité, tels que les navigateurs Web, les mises à jour logicielles automatiques et les gestionnaires de packages.

Avantages de sécurité de l’épinglage de clé dans Chrome, désormais sur Android

En épinglant Chrome, nous pouvons protéger les utilisateurs contre la compromission de l’autorité de certification. Nous prenons des mesures pour empêcher qu’un jeu de pins obsolète bloque inutilement l’accès des utilisateurs à Google ou aux services de Google. Cependant, en tant que fournisseur de navigateur et opérateur de site, nous disposons d’outils supplémentaires pour garantir que nos ensembles de codes PIN sont à jour. Si nous utilisons une nouvelle clé ou un nouveau domaine, nous pouvons l’ajouter simultanément au jeu de codes PIN dans Chrome. temps. Dans notre implémentation originale de l’épinglage, le jeu de broches est directement compilé dans Chrome et la mise à jour du jeu de broches nécessite la mise à jour de l’intégralité du binaire Chrome. Pour garantir que les utilisateurs des anciennes versions de Chrome peuvent toujours communiquer avec Google, l’épinglage n’est pas appliqué si Chrome détecte qu’il date de plus de 10 semaines.

Historiquement, Chrome appliquait la limite d’âge en comparant l’heure actuelle à l’horodatage de construction dans le binaire Chrome. Chrome n’imposait pas l’épinglage sur Android, car l’horodatage de construction sur Android ne reflétait pas toujours l’âge du jeu de broches Chrome, ce qui signifiait que le risque d’une incompatibilité de broches faussement positive était plus élevé.

Sans appliquer de broches sur Android, Chrome limitait la manière dont les ingénieurs pouvaient créer des fonctionnalités conformes à la règle de deux. Pour supprimer cette limitation, nous avons créé un mécanisme amélioré pour distribuer le jeu de broches intégré aux installations Chrome, y compris les appareils Android. Chrome contient toujours un jeu de broches intégré compilé dans le binaire. Cependant, nous distribuons désormais également le jeu de broches via le programme de mise à jour des composants, qui est un mécanisme permettant à Chrome de diffuser dynamiquement des mises à jour de données uniquement sur toutes les installations Chrome sans nécessiter une mise à jour complète ou un redémarrage de Chrome. Le composant contient la dernière version du jeu de broches intégré, ainsi que la liste des journaux de transparence des certificats et le contenu du Magasin racine de Chrome. Cela signifie que même si Chrome est obsolète, il peut toujours recevoir des mises à jour du jeu de broches. Le composant inclut également l’horodatage de la dernière mise à jour de la liste de broches, plutôt que de s’appuyer sur l’horodatage de construction. Cela réduit considérablement le risque de faux positifs liés à l’activation de l’épinglage de clé sur Android.

Après avoir déplacé le jeu de broches vers le programme de mise à jour des composants, nous avons pu déployer lentement l’application de l’épinglage sur Android. Nous avons déterminé que le risque de faux positifs était désormais conforme aux plates-formes de bureau et avons activé l’application de l’épinglage de clé par défaut depuis Chrome 106, publié en septembre 2022.

Ce changement a été totalement invisible pour les utilisateurs de Chrome. Même si toutes les modifications que nous apportons à Chrome ne sont pas spectaculaires, nous travaillons constamment en coulisses pour maintenir Chrome aussi sécurisé que possible et nous sommes ravis d’apporter cette protection à Android.

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici