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 de verrouillage de l'écran). 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 introuvables après trop de tentatives infructueuses de fournir le facteur de connaissance correct.

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

Remarque: Ce document est toujours en cours d'élaboration, et les détails de l'implémentation sont encore en cours de finalisation. À 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 lien avec les versions Open Source pertinentes).

Présentation

Traditionnellement, le chiffrement (qui permet de garantir la confidentialité des données) nécessite l'utilisation de secrets présentant une entropie élevée du point de vue de l'attaquant. 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 disponibilité actuelle de la puissance de calcul, une exigence d'entropie minimale raisonnable pour les secrets cryptographiques peut se situer entre 70 et 80 bits. Malheureusement, les êtres humains ont beaucoup de mal à mémoriser et à se souvenir de manière fiable des mots de passe ou d'autres secrets avec cette 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). Nous nous trouvons donc face à un problème difficile : comment protéger les données privées avec la technologie de chiffrement si nous voulons que le secret soit un "facteur de connaissance" que l'utilisateur est très susceptible de retenir ? Pour diverses raisons, ce problème est si difficile à résoudre que les services de stockage cloud ne chiffrent généralement que les données avec des secrets gérés par le fournisseur de stockage cloud lui-même, plutôt que de s'appuyer sur l'utilisateur pour qu'il se souvienne de son propre secret.

Une approche permettant de combler l'écart entre les exigences concernant les secrets cryptographiques et les secrets mémorisables par l'humain 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 à entropie faible. Le service CKV ne divulgue la clé de récupération qu'à une partie qui prouve qu'elle connaît le secret mémorisable humain correct. Les attaques par force brute contre le secret mémorisable 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é cryptographique symétrique standard, adaptée à une méthode de chiffrement (authentifiée) qui peut facilement chiffrer un grand volume de données (telles qu'une sauvegarde de disque) pouvant être stockées 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 de la création d'un service Cloud Key Vault à l'aide de modules matériels sécurisés (THM). Notre première implémentation du service CKV est conçue pour protéger les clés de récupération avec le facteur de connaissance de l'écran de verrouillage (LSKF) de l'utilisateur, c'est-à-dire le code, le mot de passe ou le schéma de balayage secret utilisé pour déverrouiller les smartphones. Les êtres humains peuvent mémoriser de manière fiable leur LSKF. En même temps, ces secrets LSKF ne disposent généralement que d'assez d'entropie pour résister à un pirate informatique qui dispose d'un nombre très limité de tentatives, ce qui les rend 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 le LSKF de l'utilisateur, mais les sauvegardes de ces fichiers stockées (et chiffrées) dans le cloud n'étaient pas protégées par le LSKF. Pour la première fois, Cloud Key Vault permet également de protéger l'écran de verrouillage des sauvegardes Android stockées dans le cloud. Cela signifie que les serveurs de Google ne peuvent pas accéder ni restaurer le contenu des sauvegardes chiffrées. Seul un appareil avec le 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. Lorsque nous faisons référence au client dans ce document technique, nous faisons référence à 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 désignés dans lesquels une puce Titan² supplémentaire est installée. La puce Titan conçue par Google sert de composant matériel dans notre module de matériel sécurisé. Nous la provisionnons spécialement avec un bootloader et un micrologiciel personnalisés qui implémentent nos protocoles et mécanismes d'application de la sécurité (comme décrit dans ce document). Nous utilisons des techniques d'attestation matérielle pour nous assurer que notre protocole s'exécute réellement sur le matériel Titan.

Le service CKV doit être évolutif pour gérer le trafic de milliards³ d'appareils Android, sans perdre une quantité importante de données utilisateur en raison de défaillances matérielles (par exemple, des puces grillées) ni de pannes prolongées en raison de la maintenance du centre de données. C'est pourquoi les serveurs équipés de puces Titan sont organisés en cohortes, chaque cohorte étant composée de plusieurs THM indépendants contenant chacun une copie du même matériel de clé. Une cohorte donnée sera distribuée dans des centres de données physiquement distincts dans différentes zones de maintenance, afin de s'assurer que le système peut atteindre ses objectifs de disponibilité et de fiabilité. Pour la scalabilité, les clients seront répartis dans un certain nombre de cohortes différentes, afin que nous puissions 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 d'architecture / Glossaire

Facteur de connaissance de l'écran de verrouillage (LSKF, Lock Screen Knowledge Factor) : secret mémorisable par l'utilisateur, comme un code court, un schéma de balayage sur une grille de 3 x 3 points ou un mot de passe. Ce secret permet de protéger la possibilité de déverrouiller 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 utilisateur final exécutant le système d'exploitation Android 9 Pie et les services Google Play, ou un logiciel compatible équivalent.

Android Framework:nous utilisons ce terme générique (ou simplement le Framework) pour désigner les API d'Android 9 Pie ou version ultérieure. Il ne doit pas être utilisé pour désigner des versions antérieures.

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

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 des messages de protocole impliquant le LSKF.

Claim de récupération:lorsque l'utilisateur souhaite récupérer la clé de récupération, il doit créer une revendication de récupération, qui contient une copie chiffrée de la clé de récupération que l'utilisateur prétend connaître. En règle générale, l'utilisateur est invité à saisir la 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 cryptographique 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 des données.

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

Cohort:ensemble de serveurs Vault/THM pouvant servir de réplicas redondants les uns des autres.

Clé publique de la 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 faisaient partie de la cohorte au moment de la génération de la clé.

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

Vault:entrée particulière 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 plusieurs Vault enregistrés, chacun correspondant à un appareil ou à un LSKF différent. Seul le THM d'un serveur Vault peut examiner ou extraire le contenu d'un Vault.

Serveur Vault:machine à usage général fonctionnant dans un centre de données Google qui a été spécialement modifiée pour ajouter un module matériel sécurisé (THM).

Conception de protocole

Le protocole CKV se compose de 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 sécurisée de manière à nécessiter la participation de plusieurs employés pour signer avec elle. La clé publique de cette racine de confiance est intégrée au système d'exploitation Android et ne peut être modifiée que via une mise à jour du système d'exploitation.

Google publie également régulièrement une liste de clés publiques pour chaque cohorte de THM, ainsi qu'une attestation sur la 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 la plus récente des clés publiques de la cohorte 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 du coffre-fort.

Création d'un 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 demande au framework de créer un nouveau coffre-fort. Chaque fois que l'utilisateur saisit la clé LSKF, le framework génère une nouvelle clé de récupération et la chiffre d'abord avec une clé dérivée d'un hachage de la clé LSKF, puis avec la clé publique de la cohorte sélectionnée par le framework lors de l'initialisation. Le blob chiffré obtenu est le coffre-fort qui est renvoyé par le framework à l'agent de récupération, qui l'importe ensuite dans le service CKV de Google.

Ouverture du coffre-fort

Lorsque l'agent de récupération sur le nouvel appareil doit accéder à la clé de récupération stockée dans un coffre-fort particulier, il invite d'abord l'utilisateur à saisir la LSKF de l'appareil d'origine ayant créé le coffre-fort. L'agent de récupération demande ensuite au framework de créer une requête de récupération à l'aide de ce LSKF. Le framework génère une nouvelle clé de demandeur et la chiffre, ainsi que le hachage de la clé LSKF revendiquée, avec la même clé publique de cohorte que celle utilisée pour chiffrer le Vault à l'origine. Le blob chiffré obtenu est appelé Recovery Claim (Revendication de récupération). Le framework le transmet à l'agent de récupération, qui le présente ensuite au service CKV.

Le CKV achemine la requête de récupération (et le coffre-fort correspondant) vers les serveurs de coffre-fort qui font partie de la cohorte appropriée. Le THM des serveurs Vault déchiffre ensuite la requête 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 dériver la clé de chiffrement interne). Si le hachage LSKF d'origine et le hachage LSKF revendiqué correspondent, le THM extrait la clé de récupération du Vault et la rechiffre avec la clé du demandeur qui figurait dans la requête de récupération. Dans le cas contraire, le THM augmentera un compteur de tentatives échouées. Une fois que le compteur des tentatives infructueuses a atteint sa limite, le THM refuse de traiter toute demande de récupération ultérieure pour ce coffre-fort.

Enfin, si tout s'est bien passé, 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 au Framework. Le framework utilise sa copie de la clé du demandeur pour déchiffrer la clé de récupération. 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 allons commencer par décrire le client, puis remonter la pile jusqu'au service Cloud Key Vault.

Sécurité du client

Selon l'OEM et l'appareil, le facteur de connaissance de l'écran de verrouillage (LSKF) est généralement stocké et protégé sur l'appareil à l'aide de diverses méthodes qui varient selon l'OEM. Par exemple, les appareils Pixel 2 de Google utilisent un module de sécurité matériel anti-piratage pour stocker la clé LSKF au repos et appliquer des limites de débit basées sur le matériel pour la validation de la clé LSKF. Les nouvelles API de framework introduites pour permettre l'utilisation de Cloud Key Vault sont conçues pour préserver les garanties de sécurité existantes dans la mesure du possible, même lorsque l'appareil utilise un tel module de sécurité matérielle pour protéger le stockage du LSKF.

Cette section se concentre spécifiquement sur les problèmes et protections de sécurité pertinents qui affectent la nouvelle fonctionnalité Cloud Key Vault, plutôt que de tenter de fournir une vue d'ensemble de tous les mécanismes de sécurité associés à LSKF.

Sécuriser les API du framework

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

Les API du framework garantissent également que les coffres ne sont créés que pour les clés publiques de cohorte attestées par une racine de confiance. La racine de confiance est intégrée au Framework par l'OEM lors de la livraison et ne peut pas être modifiée sans mise à jour de l'OS. Cela garantit que le LSKF n'est utilisé que pour créer des coffres-forts qui appliqueront correctement les protections par force brute basées sur le matériel. En nous appuyant sur les THM du service Cloud Key Vault pour la protection contre les attaques par force brute pour le LSKF, nous pouvons obtenir une sécurité comparable à celle obtenue en utilisant du 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 supposons pas que le LSKF sera stocké ailleurs sur l'appareil que sur du matériel sécurisé, un nouveau Vault ne peut être créé qu'immédiatement après le déverrouillage de l'appareil. Au moment où l'utilisateur saisit le LSKF pour déverrouiller l'appareil, le LSKF est brièvement mis à la disposition du Framework dans la RAM. C'est à ce moment que la nouvelle API permettant de créer le Vault l'utilise. Il n'est pas possible de créer un coffre-fort protégé par le LSKF lorsque l'appareil est verrouillé, car le LSKF 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 empêcher l'agent de récupération de voir la clé 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 de bugs ou de failles de sécurité potentiels dans l'agent de récupération beaucoup plus difficile. L'agent de récupération est principalement utilisé pour gérer les événements de cycle de vie et l'échange 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 du coffre-fort, lorsque l'utilisateur doit saisir le LSKF de l'ancien appareil. L'UI qui collecte le LSKF revendiqué pour l'ancien appareil est implémentée dans l'agent de récupération⁴. Toutefois, l'implémentation de l'agent de récupération "oublie" le LSKF revendiqué dès que le framework prend en charge la création de la revendication de récupération.

Fonctionnalités de sécurité du protocole

Bien qu'une analyse complète du protocole ne soit pas dans le champ d'application de ce document, nous souhaitons mettre en avant quelques-unes des protections intégrées au protocole. En particulier, le protocole n'utilise que le hachage du LSKF tout au long. 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), le stockage du Vault est strictement meilleur que le stockage d'un hachage de mot de passe. Dans ce cas, le hachage de mot de passe peut fournir une mesure de sécurité indépendante de la sécurité des THM. C'est pourquoi nous acceptons le hachage "memory hard" salé de la LSKF dans le cadre du protocole. Nous associons également de manière cryptographique le coffre-fort à un identifiant de l'appareil qui l'a créé, et associons la revendication de récupération à un nonce utilisé comme défi lors du protocole d'ouverture du coffre-fort pour nous assurer que la revendication de récupération est récente.

Étant donné que la clé de récupération est générée à chaque création de coffre-fort, nous implémentons la rotation des clés en écrasant une entrée de coffre-fort existante par un coffre-fort nouvellement créé. L'adresse du compteur d'échec de la tentative utilisée par le coffre-fort est sélectionnée lors de la création du coffre-fort. Le framework s'assure que l'adresse du compteur utilisée pour les coffres-forts suivants ne changera pas, sauf si la clé LSKF a été modifiée ou s'il existe une nouvelle liste attesté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 de la clé LSKF.

Sécurité du serveur pour le service Cloud Key Vault

Le serveur est implémenté à 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 proposées à chaque niveau.

Protections matérielles

La principale protection de sécurité implémentée côté serveur du service CKV est les modules matériels sécurisés (THM, Trusted Hardware Modules) qui sont 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 pour implémenter les protocoles CKV. Plus précisément, ils peuvent générer et partager de manière sécurisée une paire de clés avec les autres membres de leur cohorte, de sorte que la logique du micrologiciel empêche la fuite de la clé privée en dehors des puces Titan de la cohorte. Ils peuvent également effectuer l'opération d'ouverture du coffre-fort et gérer un compteur d'échecs par coffre-fort strictement incrémentiel (le compteur étant basé sur l'état stocké dans le chip Titan). Une description plus détaillée du protocole exécuté par le micrologiciel de la puce CKV Titan 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 de compteur. Pour ce faire, nous modifions également le bootloader Titan afin de nous assurer que les données stockées de la puce (telles que la clé privée de la cohorte) sont complètement effacées avant toute mise à jour. L'inconvénient de cette protection est que nous ne pouvons pas corriger les bugs du micrologiciel sans subir une perte de données. La mise à jour du micrologiciel est fonctionnellement équivalente à la destruction du matériel existant et à son remplacement par de nouveaux puces. En cas de nécessité d'un correctif de micrologiciel critique, Google devra produire et publier une liste entièrement nouvelle de clés publiques de cohortes attestées, puis migrer progressivement tous les utilisateurs vers la nouvelle liste. Pour atténuer ce risque, nous essayons de réduire au maximum le code du micrologiciel et de l'examiner attentivement pour détecter d'éventuels problèmes de sécurité.

Protections logicielles

En plus des limites strictes par échec de Vault imposées par les THM, le service CKV implémente également une limitation du débit basée sur le logiciel. La limitation de débit est conçue pour empêcher un pirate informatique d'accéder au compte d'un utilisateur et d'épuiser rapidement sa limite de tentatives de récupération infructueuses, ce qui bloque efficacement l'accès de l'utilisateur réel à ses clés de récupération. Comme les délais imposés par l'appareil de l'utilisateur après trop de tentatives infructueuses de déverrouillage de l'écran, le service CKV applique un délai croissant après chaque demande d'ouverture du coffre-fort infructueuse.

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

Spécification détaillée du protocole

La spécification détaillée du protocole est toujours en cours. Ce document sera mis à jour pour inclure ces détails, ainsi que la publication du code client dans le projet Android Open Source plus tard cette année.

Notes