Service Google Cloud Key Vault

Nous décrivons un service cloud qui utilise du matériel sécurisé pour stocker des clés cryptographiques de sorte que l'accès à celles-ci soit protégé par un facteur de connaissance à faible entropie (par exemple, un code d'écran de verrouillage). Le matériel sécurisé est conçu pour empêcher les attaques par force brute, en rendant les clés cryptographiques stockées définitivement irrécupérables après un trop grand nombre de tentatives infructueuses pour fournir le facteur de connaissances approprié.

Auteur:Shabsi Walfish
Date de la version:06-03-2018

Remarque: Ce document est toujours en cours de développement, et les détails de sa mise en œuvre ne sont pas encore finalisés. Au fur et à mesure que le système se stabilise et que davantage de documentation peut être produite, nous mettrons à jour ce livre blanc avec des informations plus détaillées (en particulier, en particulier avec les versions Open Source pertinentes).

Présentation

Traditionnellement, le chiffrement (utilisé pour assurer la confidentialité des données) nécessite l'utilisation de secrets à entropie élevée du point de vue du pirate informatique. Une entropie élevée est requise, car le schéma de chiffrement doit résister aux attaques par force brute qui explorent l'espace de tous les secrets probables jusqu'à ce que le bon soit trouvé. Compte tenu de la puissance de calcul actuellement disponible, une exigence d'entropie minimale raisonnable pour les secrets cryptographiques pourrait se situer autour de 70 à 80 bits. Malheureusement, les êtres humains trouvent très difficile de mémoriser et de rappeler de manière fiable les mots de passe ou d'autres secrets avec une telle quantité d'entropie¹, en particulier s'ils sont rarement utilisés (mais l'utilisation fréquente d'un mot de passe à entropie élevée est difficile et fastidieuse). Cela nous pose un problème difficile : comment protéger les données privées à l'aide d'une technologie de chiffrement, si nous voulons que le secret soit un "facteur de connaissance" dont l'utilisateur se souviendra très probablement ? Pour diverses raisons, ce problème est si difficile à résoudre que les services de stockage cloud ne chiffrent généralement les données qu'à l'aide de secrets gérés par le fournisseur de stockage cloud lui-même, plutôt que de compter sur l'utilisateur pour mémoriser son propre code secret.

Une approche permettant de combler l'écart entre les exigences relatives aux secrets cryptographiques et celles nécessitant une mémorisation humaine consiste à utiliser un service Cloud Key Vault (CKV) pour stocker une "clé de récupération" à entropie élevée, protégée par un secret mémorisable par l'humain à faible entropie. Le service CKV ne cédera la clé de récupération qu'à une partie prouvant qu'elle connaît le bon secret mémorisable par l'humain. Les attaques par force brute visant le secret mémorable humain peuvent être contrées par le service CKV, qui applique une limite absolue au nombre de tentatives infructueuses pour prouver la connaissance du secret. La clé de récupération elle-même est une clé symétrique cryptographique standard, adaptée à un schéma de chiffrement (authentifié) capable de chiffrer facilement un grand volume de données (comme une sauvegarde sur disque) pouvant être stocké en toute sécurité n'importe où. Ces données chiffrées sont inutiles pour toute personne qui ne peut pas obtenir la clé de récupération.

Ce livre blanc décrit notre approche pour créer un service Cloud Key Vault à l'aide de modules matériels de confiance (THM). La première implémentation du service CKV est conçue pour protéger les clés de récupération à l'aide du facteur de connaissance de l'écran de verrouillage (LSKF) de l'utilisateur, c'est-à-dire le code secret, le mot de passe ou le schéma de balayage utilisé pour déverrouiller les smartphones. Les êtres humains peuvent se souvenir de leur LSKF de manière fiable. Dans le même temps, ces secrets LSKF ont généralement juste assez d'entropie pour résister à un pirate informatique qui dispose d'un nombre très limité de tentatives, ce qui les rend particulièrement adaptés au service CKV.

La première application de notre service Cloud Key Vault consistera à activer les sauvegardes Android chiffrées côté client. Auparavant, les fichiers chiffrés localement sur l'appareil Android utilisaient une clé protégée par la clé LSKF de l'utilisateur, mais les sauvegardes de ces fichiers stockés (et chiffrés) dans le cloud n'étaient pas protégées par la clé LSKF. Pour la première fois, Cloud Key Vault active également la protection de l'écran de verrouillage pour les sauvegardes Android stockées dans le cloud. En d'autres termes, les serveurs de Google ne peuvent pas accéder au contenu des sauvegardes chiffrées ni les restaurer. Seul un appareil doté du LSKF de l'utilisateur peut déchiffrer les sauvegardes.

Concepts fondamentaux

Au départ, la seule plate-forme cliente compatible avec le service Cloud Key Vault est le système d'exploitation Android 9 Pie. Dans ce livre blanc, nous faisons référence au client et à un appareil exécutant le système d'exploitation Android 9 Pie avec les services Google Play. Notre implémentation côté serveur s'exécute sur des serveurs Google spécialement conçus sur lesquels une puce Titan supplémentaire² est installée. La puce Titan conçue par Google est le composant matériel de notre module matériel de confiance. Nous lui fournissons spécifiquement un bootloader personnalisé et un micrologiciel qui implémentent nos protocoles et mécanismes d'application de la sécurité (tels que décrits dans le présent document). Nous utilisons des techniques d'attestation matérielle afin de nous assurer que notre protocole s'exécute réellement sur le matériel Titan.

Le service CKV doit évoluer pour gérer le trafic de milliards³ d'appareils Android, sans perdre de données utilisateur importantes en raison de défaillances matérielles (par exemple, les puces brûlées) ou de pannes prolongées dues à la maintenance du centre de données. Pour cette raison, les serveurs comportant les puces Titan sont organisés en cohortes, chaque cohorte composée de plusieurs THM indépendants contenant chacun une copie du même matériel de clé. Afin de garantir que le système puisse atteindre ses objectifs de disponibilité et de fiabilité, une cohorte donnée sera répartie sur des centres de données disparates physiquement dans différentes zones de maintenance. Pour des raisons d'évolutivité, les clients seront répartis entre plusieurs cohortes différentes. Nous pourrons ainsi ajuster la capacité du service en ajoutant simplement des serveurs pour augmenter le nombre de cohortes disponibles.

Nous sommes maintenant prêts à énumérer les principaux composants de l'architecture du service Cloud Key Vault.

Composants architecturaux / Glossaire

Lock Screen Knowledge Factor (LSKF) : secret mémorable par l'humain, comme un code court, un schéma de balayage sur une grille de trois x 3 points ou un mot de passe. Ce secret permet d'empêcher le déverrouillage de l'appareil localement et est considéré comme un facteur d'authentification principal (ou "fort") pour le verrouillage de l'écran de l'appareil local de l'utilisateur.

Client:appareil d'un utilisateur final exécutant le système d'exploitation Android 9 Pie et les services Google Play, ou des logiciels équivalents compatibles.

Framework Android:nous utilisons ce terme générique (ou simplement le framework) pour désigner les API dans Android 9 Pie ou version ultérieure. Il n'a pas vocation à faire référence à des versions antérieures.

Services Google Play:ensemble de services et d'applications qui s'exécutent sur l'appareil de l'utilisateur final, ce qui lui permet de fonctionner avec le système de compte et les API de serveur personnalisées de Google.

Agent de récupération:application système exécutée dans le cadre des services Google Play dans l'espace utilisateur sur un appareil Android 9 Pie (ou similaire). L'agent de récupération est chargé d'exécuter le côté client des différents protocoles et d'interagir avec le système d'exploitation Android si nécessaire afin de créer tous les messages de protocole impliquant le LSKF.

Demande de récupération:lorsque l'utilisateur souhaite récupérer la clé de récupération, il doit créer une demande de récupération, contenant une copie chiffrée de la clé LSKF qu'il prétend connaître. En règle générale, l'utilisateur est invité à saisir le LSKF de son ancien appareil sur un nouvel appareil qui tente d'accéder à la clé de récupération de l'ancien.

Clé de récupération:clé secrète de chiffrement protégée par le service Cloud Key Vault, qui permet de chiffrer (et d'authentifier) les données sur l'appareil client. Une fois la clé de récupération placée dans un coffre-fort (voir ci-dessous), la copie locale peut être supprimée dès que le client a fini de l'utiliser pour chiffrer les données.

Service Cloud Key Vault (CKV):service Internet permettant aux appareils clients de stocker des clés cryptographiques protégées par un LSKF mémorable par l'humain.

Cohorte:collection de serveurs/THM Vault pouvant servir d'instances répliquées redondantes les uns des autres.

Clé publique de cohorte: clé publique d'une paire de clés générée par une cohorte spécifique de THM. La clé privée correspondante n'est disponible que dans les THM qui se trouvaient dans la cohorte au moment de la génération de la clé.

Trusted Hardware Module (THM) : module de sécurité dédié (microcontrôleur) conçu pour fournir un environnement informatique minimal et fiable. L'élément sécurisé doit au minimum être capable de générer et/ou de stocker des clés secrètes, et de conserver un état évolutif non volatile (afin d'empêcher les attaques impliquant des réinitialisations à un état antérieur).

Vault:entrée spécifique de la base de données du service CKV, contenant la clé de récupération protégée par LSKF d'un seul appareil. Un utilisateur final peut avoir enregistré plusieurs Vault, chacun correspondant à un appareil différent ou à un fichier LSKF. Seul le THM d'un serveur Vault peut examiner ou extraire le contenu d'un serveur Vault.

Serveur Vault:ordinateur à usage général fonctionnant dans un centre de données Google, spécialement équipé d'un module matériel de confiance (THM, Trusted Hardware Module).

Conception de protocole

Le protocole CKV comprend plusieurs phases, comme suit:

Initialisation

Pour initialiser le système, Google fournit une clé publique pour une "racine de confiance" que le framework utilisera pour valider les attestations matérielles de Google. La clé de signature de cette racine de confiance est stockée hors connexion et soigneusement sécurisée de sorte qu'elle nécessite la participation de plusieurs employés pour signer. La clé publique de cette racine de confiance est intégrée à l'OS Android et ne peut être modifiée que via une mise à jour de l'OS.

Google publie également régulièrement une liste de clés publiques pour chaque cohorte de THM, ainsi qu'une attestation sur cette liste. L'attestation de la liste utilise une signature qui remonte à la racine de confiance. Chaque mise à jour de la liste publiée contient également un numéro de séquence, ce qui permet d'éviter les rollbacks. L'agent de récupération récupère la liste de clés publiques de cohorte la plus récente publiée et la fournit au framework. Le framework vérifie ensuite l'attestation et sélectionne de manière aléatoire une clé publique de cohorte dans la liste à utiliser lors de la phase de création de Vault.

Création de Vault

Après avoir aidé le framework à terminer l'initialisation en récupérant la liste des clés publiques de cohorte, l'agent de récupération demandera au framework de créer un nouveau Vault. Chaque fois que l'utilisateur saisit ensuite la LSKF, le framework génère une nouvelle clé de récupération et la chiffre d'abord à l'aide d'une clé dérivée d'un hachage de la clé LSKF, puis de la clé publique de cohorte sélectionnée par le framework lors de l'initialisation. Le blob chiffré qui en résulte est le Vault renvoyé par le framework à l'agent de récupération, qui l'importe ensuite dans le service CKV de Google.

Ouverture de Vault

Lorsque l'agent de récupération installé sur un nouvel appareil a besoin d'accéder à la clé de récupération stockée dans un Vault spécifique, il est d'abord invité à saisir le fichier LSKF de l'appareil qui a créé Vault. L'agent de récupération demandera ensuite au framework de créer une demande de récupération à l'aide de ce fichier LSKF. Le framework génère une nouvelle clé du demandeur et chiffre cette clé ainsi que le hachage de la clé LSKF revendiquée à l'aide de la même clé publique de cohorte que celle utilisée à l'origine pour le chiffrement Vault. Le blob chiffré qui en résulte est appelé Demande de récupération et le framework le transmet à l'agent de récupération, qui le présente ensuite au service CKV.

La clé CKV achemine la revendication de récupération (et la demande Vault correspondante) vers les serveurs Vault faisant partie de la cohorte appropriée. Le THM des serveurs Vault déchiffre ensuite la revendication de récupération et tente d'extraire la clé de récupération du Vault d'origine à l'aide du hachage LSKF revendiqué (pour obtenir la clé de chiffrement interne). Si le hachage LSKF d'origine et celui LSKF revendiqué correspondent, le THM extrait la clé de récupération de Vault et la chiffre à nouveau avec la clé du demandeur qui se trouvait dans la revendication de récupération. Dans le cas contraire, le THM renverra un compteur de tentatives ayant échoué. Une fois que le compteur de tentatives ayant échoué atteint sa limite, le THM refuse de traiter toute demande de récupération ultérieure pour ce Vault.

Enfin, si tout s'est déroulé comme prévu, la clé de récupération rechiffrée (qui est désormais chiffrée sous la clé du demandeur) est renvoyée du serveur Vault jusqu'au framework. Le framework déchiffre la clé de récupération à l'aide de sa copie de la clé du demandeur, et le protocole est maintenant terminé.

Mesures de sécurité

Le système Cloud Key Vault vise à fournir une "défense en profondeur" en incluant des protections de sécurité à plusieurs niveaux de notre pile. Pour vous donner une idée du fonctionnement de ces protections, nous commencerons par décrire le client, puis nous remonterons la pile jusqu'au service Cloud Key Vault.

Sécurité du client

Selon l'OEM et l'appareil, le LSKF (Lock Screen Knowledge Factor) est normalement stocké et protégé sur l'appareil à l'aide de différentes méthodes qui varient selon l'OEM. Par exemple, les appareils Pixel 2 de Google utilisent un module de sécurité matériel antivol afin de stocker le fichier LSKF au repos et d'appliquer des limites de débit basées sur le matériel lors de la validation LSKF. Les nouvelles API Framework introduites pour permettre l'utilisation de Cloud Key Vault sont conçues pour préserver autant que possible les garanties de sécurité existantes, même lorsque l'appareil utilise un module de sécurité matériel de ce type pour protéger le stockage du fichier LSKF.

Plutôt que d'essayer de fournir une vue d'ensemble de tous les mécanismes de sécurité associés au fichier LSKF, nous nous concentrerons spécifiquement sur les protections et problèmes de sécurité pertinents qui affectent la nouvelle fonctionnalité Cloud Key Vault.

Sécuriser les API Framework

Les nouvelles API de framework ajoutées pour prendre en charge le service CKV sont marquées comme @SystemApi et nécessitent des autorisations spéciales qui garantissent qu'elles ne sont disponibles que pour les applications système approuvées par l'OEM, telles que les services Google Play. Cela permet d'éliminer en grande partie la surface d'attaque directe qui pourrait être exposée aux applications que l'utilisateur installe sur l'appareil.

Les API Framework garantissent également que les coffres ne sont créés que pour les clés publiques des cohortes certifiées par une racine de confiance. La racine de confiance est intégrée au framework par l'OEM lors de son expédition et ne peut pas être modifiée sans mise à jour de l'OS. Vous avez ainsi l'assurance que le fichier LSKF n'est utilisé que pour créer des Vault qui appliqueront correctement des protections contre la force brute basées sur le matériel. En nous appuyant sur les THM du service Cloud Key Vault pour la protection par force brute du LSKF, nous pouvons assurer une sécurité comparable à l'utilisation de matériel sécurisé sur l'appareil pour la même chose (comme le font les appareils Google Pixel 2).

Étant donné que nous ne partons pas du principe que le fichier LSKF sera stocké sur l'appareil en dehors d'un matériel sécurisé, un nouveau Vault ne peut être créé qu'après le déverrouillage de l'appareil. Au moment où l'utilisateur entre dans le LSKF pour déverrouiller l'appareil, celui-ci est brièvement mis à la disposition du framework dans la RAM. C'est à ce moment-là que la nouvelle API de création de Vault utilise ces données. Il est impossible de créer un coffre-fort protégé par LSKF lorsque l'appareil est verrouillé, car ce dernier n'est pas disponible.

Sécuriser l'agent de récupération

La principale protection de sécurité que nous fournissons à l'agent de récupération est que le protocole est conçu pour l'empêcher de voir la LSKF de l'appareil actuel ou toute clé de récupération. Seul le framework doit voir ces éléments côté client, ce qui rend l'exploitation des bugs potentiels ou des failles de sécurité dans l'agent de récupération beaucoup plus difficile. L'agent Recovery est principalement utilisé pour gérer les événements de cycle de vie et le transfert de données entre le cloud et le framework. La seule exception à cette règle se produit lors d'une récupération juste avant le protocole d'ouverture de Vault, lorsque l'utilisateur doit saisir le fichier LSKF de l'ancien appareil. L'interface utilisateur qui rassemble le fichier LSKF revendiqué pour l'ancien appareil est implémentée dans l'agent de récupération⁴. Cependant, l'implémentation de l'agent de récupération "efface" la demande LSKF revendiquée dès que le framework prend en charge la construction de la demande.

Fonctionnalités de sécurité du protocole

Bien qu'une analyse complète du protocole dépasse le cadre de ce document, nous souhaitons mettre en évidence quelques-unes des protections qui y sont intégrées. En particulier, le protocole n'utilise que le hachage du LSKF. Cela signifie que si le LSKF présente une entropie élevée (par exemple, s'il s'agit d'un bon mot de passe à entropie élevée), il est préférable de stocker Vault plutôt que de stocker un hachage de mot de passe. Dans ce cas, le hachage de mot de passe peut offrir une mesure de sécurité indépendante de la sécurité du THM. Pour cette raison, nous acceptons le hachage en mémoire dure avec salage du LSKF dans le cadre du protocole. De plus, nous lisons de manière cryptographique le Vault à un identifiant de l'appareil qui l'a créé, et nous lisons la demande de récupération à un nonce qui est utilisé comme défi lors du protocole d'ouverture de Vault pour nous assurer que la demande de récupération est à jour.

La clé de récupération étant générée à chaque création dans Vault, nous implémentons la rotation des clés en remplaçant une entrée Vault existante par un nouveau Vault. L'adresse du compteur de tentatives ayant échoué utilisé par Vault est sélectionnée lors de la création de Vault. Le framework garantit que l'adresse du compteur utilisée pour les Vault suivants ne changera pas, sauf si la LSKF a été modifiée ou s'il existe une nouvelle liste certifiée de clés publiques de cohorte. Ainsi, la rotation de la clé de récupération peut être effectuée sans nuire à la protection par force brute du LSKF.

Sécurité des serveurs pour le service Cloud Key Vault

Le serveur est mis en œuvre à l'aide d'une combinaison de logiciels exécutés sur du matériel serveur ordinaire et de micrologiciels exécutés sur du matériel spécialisé (la puce Titan). Nous décrirons les protections offertes à chaque couche.

Protections matérielles

La principale protection de sécurité mise en œuvre côté serveur du service CKV est constituée de modules matériels de confiance (THM, Trusted Hardware Modules) créés à l'aide des puces Titan conçues sur mesure par Google. Les puces exécutent un micrologiciel qui expose les API nécessaires à la mise en œuvre des protocoles CKV. Ils peuvent par exemple générer une paire de clés et la partager en toute sécurité avec d'autres membres de leur cohorte, de sorte que la logique du micrologiciel protège la clé privée contre les fuites en dehors des puces Titan de la cohorte. Ils peuvent également effectuer l'opération d'ouverture de Vault et maintenir un compteur de tentatives infructueuses par incréments strictement incrémentiels (le compteur repose sur l'état stocké dans la puce Titan). Une description plus détaillée du protocole exécuté par le micrologiciel de la puce Titan CKV sera fournie dans une prochaine version de ce document.

Étant donné que la sécurité du serveur découle de la logique du micrologiciel des puces Titan, nous devons nous assurer que la logique ne change pas de manière à permettre aux puces de divulguer des secrets ou d'ignorer les limites du compteur. Pour atteindre cet objectif, nous modifions également le bootloader Titan de sorte que les données stockées dans la puce (telles que la clé privée de la cohorte) soient entièrement effacées avant toute mise à jour. L'inconvénient de cette protection est que nous ne pouvons pas corriger les bugs du micrologiciel sans perdre certaines données. D'un point de vue fonctionnel, la mise à jour du micrologiciel équivaut à détruire le matériel existant et à le remplacer par de nouvelles puces. Si un correctif de micrologiciel critique est nécessaire, Google doit produire et publier une toute nouvelle liste de clés publiques certifiées pour les cohortes, puis migrer progressivement tous les utilisateurs vers la nouvelle liste. Pour atténuer ce risque, nous essayons de limiter le codebase du micrologiciel et d'effectuer un audit approfondi pour détecter tout problème de sécurité potentiel.

Protections logicielles

En plus des limites strictes de défaillance par Vault imposées par les THM, le service CKV met également en œuvre une limitation du débit basée sur un logiciel. La limitation du débit est conçue pour empêcher un pirate informatique d'accéder au compte d'un utilisateur et d'épuiser rapidement la limite de tentatives de récupération infructueuses, bloquant ainsi l'accès de l'utilisateur réel à ses clés de récupération. Comme pour les délais imposés par l'appareil de l'utilisateur après un trop grand nombre de tentatives infructueuses de déverrouillage de l'écran, le service CKV applique un délai croissant après chaque échec de requête d'ouverture de Vault.

Nous mettons également en œuvre des mesures de sécurité standards pour les services cloud qui hébergent les données utilisateur, y compris des contrôles d'accès, une surveillance et des audits stricts.

Spécification de protocole détaillée

La spécification détaillée du protocole est toujours en cours d'élaboration, et ce document sera mis à jour pour inclure ces informations ainsi que la publication du code client dans le projet Android Open Source dans le courant de l'année.

Notes