Application Layer Transport Security (ALTS)

Par Cesar Ghali, Adam Stubblefield, Ed Knapp, Jiangtao Li, Benedikt Schmidt et Julien Boeuf

Le contenu du présent livre blanc est réputé correct et représente l'état des connaissances à sa date de rédaction, soit décembre 2017. Les règles et les systèmes de sécurité de Google Cloud peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.

Résumé à l'intention des responsables informatiques

  • ALTS (Application Layer Transport Security) est un système d'authentification mutuelle et de chiffrement des données en transit développé par Google. Il est généralement employé pour sécuriser les communications RPC (Remote Procedure Call, appel de procédure à distance) au sein de l'infrastructure de Google. Le système ALTS présente un concept semblable à celui de l'authentification mutuelle TLS, mais il a été conçu et optimisé pour répondre aux besoins des environnements de centre de données de Google.
  • Le modèle de confiance d'ALTS a été spécialement créé pour les applications conteneurisées de type cloud. Les identités sont liées à des entités plutôt qu'à un nom de serveur ou à un hôte spécifique. Ce modèle de confiance facilite la réplication transparente des microservices, l'équilibrage de charge et la replanification entre les hôtes.
  • ALTS repose sur deux protocoles : le protocole de handshake (avec reprise de session) et le protocole d'enregistrement. Ils régissent la façon dont les sessions sont établies, authentifiées, chiffrées et reprises.
  • ALTS est une solution personnalisée de sécurisation de la couche de transport utilisée par Google. Nous avons adapté ALTS à notre environnement de production, raison pour laquelle il existe certains compromis entre ALTS et TLS, le standard de l'industrie. Consultez la section Compromis pour en savoir plus.

Présentation

Les systèmes de production de Google consistent en une multitude de microservices1 qui émettent collectivement O(1010) appels de procédure à distance (RPC) par seconde. Lorsqu'un ingénieur Google planifie une charge de travail de production2, tous les appels RPC émis ou reçus par cette charge sont protégés par défaut par ALTS. Cette protection automatique, qui ne nécessite aucune configuration, est fournie par le système ALTS (Application Layer Transport Security) de Google. En plus de conférer des protections automatiques aux appels RPC, ALTS facilite également la réplication des services, l'équilibrage de charge et la replanification entre les machines de production. Ce document présente le système ALTS et décrit son déploiement sur l'infrastructure de production de Google.

Audience : ce document s'adresse aux professionnels de la sécurité d'infrastructure qui souhaitent en savoir plus sur les systèmes d'authentification et de sécurité de la couche de transport exploités à grande échelle par Google.

Conditions préalables : en plus de cette présentation, nous partons du principe que vous possédez des connaissances de base sur la gestion des clusters par Google.

ALTS et sécurité au niveau des applications

Depuis les navigateurs Web jusqu'aux VPN, de nombreuses applications reposent sur des protocoles de communication sécurisés, tels que TLS (Transport Layer Security) et IPSec, qui assurent la protection des données en transit3. Chez Google, nous utilisons ALTS, un système d'authentification mutuelle et de chiffrement des données en transit qui s'exécute au niveau de la couche d'application afin de protéger les communications RPC. La sécurisation au niveau de cette couche permet aux applications de disposer d'une identité de pair distant authentifiée, qui peut servir à mettre en œuvre des règles d'autorisation précises.

Pourquoi ne pas utiliser TLS ?

Il peut sembler étrange que Google exploite une solution de sécurité personnalisée telle qu'ALTS, alors que la majorité du trafic Internet utilise le chiffrement TLS. Google a entamé le développement d'ALTS en 2007. À l'époque, TLS était compatible avec un certain nombre d'anciens protocoles qui ne respectaient pas nos normes de sécurité minimales. Nous aurions pu concevoir notre solution de sécurité en reprenant les composants utiles de TLS, puis en mettant en œuvre les autres composants auxquels nous souhaitions recourir. Toutefois, il s'avérait plus avantageux de partir de zéro et créer intégralement un système parfaitement adapté à Google, plutôt que d'appliquer des "rustines" sur un système existant. En outre, ALTS répond davantage à nos besoins et présente historiquement une sécurisation plus poussée que le protocole TLS vieillissant. Vous trouverez ci-dessous la liste des principales différences entre TLS et ALTS.

  • Il existe une différence significative entre les modèles de confiance4 de TLS (avec une sémantique HTTPS) et d'ALTS. Avec le protocole TLS, les identités de serveur sont liées à un nom spécifique et au schéma de nommage correspondant. Dans ALTS, une même identité peut être utilisée avec plusieurs schémas de nommage. Ce niveau d'indirection offre davantage de flexibilité et simplifie considérablement le processus de réplication des microservices, d'équilibrage de charge et de replanification entre les hôtes.
  • Le système ALTS présente une conception et une mise en œuvre simplifiées par rapport à TLS. Il facilite ainsi la surveillance des bugs et des failles de sécurité, grâce à une inspection manuelle du code source ou à des tests à données aléatoires étendus.
  • ALTS sérialise ses certificats et messages de protocole à l'aide d'un tampon de protocole, tandis que TLS exploite des certificats X.509 encodés en ASN.1. La plupart de nos services de production utilisent des tampons de protocole pour la communication (et parfois le stockage), raison pour laquelle ALTS est une solution plus adaptée à l'environnement de Google.

Conception d'ALTS

ALTS est conçu pour assurer une fiabilité élevée ainsi que l'authentification et la sécurité de service à service, le tout avec une intervention minimale de la part des utilisateurs. Voici la liste des propriétés intégrées à la conception d'ALTS qui permettent d'atteindre cet objectif :

  • Transparence : la configuration d'ALTS est transparente au niveau de la couche d'application. Par défaut, les appels RPC aux services sont sécurisés à l'aide du système ALTS. Cela permet aux développeurs d'applications de se concentrer sur la logique fonctionnelle de leurs services, sans avoir à se soucier de la gestion des identifiants ni des configurations de sécurité. Lors de l'établissement d'une connexion entre plusieurs services, ALTS fournit aux applications une identité de pair distant authentifiée, qui permet de créer des vérifications d'autorisation précises et de réaliser des audits.
  • Cryptographie de pointe : tous les protocoles et primitives cryptographiques utilisés par ALTS sont à jour, afin de détecter l'intégralité des attaques recensées actuellement. Comme ALTS s'exécute sur des machines contrôlées par Google, les protocoles cryptographiques compatibles peuvent être mis à niveau facilement et déployés rapidement.
  • Modèle reposant sur les identités : ALTS effectue principalement l'authentification à l'aide d'une identité plutôt que d'un nom d'hôte. Chez Google, chaque entité réseau (telle qu'un utilisateur professionnel, un ordinateur physique, un service de production ou une charge de travail) est associée à une identité. Toutes les communications entre les services sont basées sur une authentification mutuelle.
  • Distribution des clés : pour chaque charge de travail, ALTS exploite une identité exprimée sous la forme d'un ensemble d'identifiants. Ces identifiants sont déployés dans chaque charge de travail lors de l'initialisation, sans aucune action requise de la part de l'utilisateur. En parallèle, une racine et une chaîne de confiance sont définies pour les identifiants des machines et charges de travail. Le système permet d'alterner et de révoquer automatiquement les certificats, sans aucune intervention requise de la part des développeurs d'applications.
  • Évolutivité : le système ALTS est conçu pour offrir une grande évolutivité, afin de pouvoir gérer l'étendue de l'infrastructure de Google. Cette exigence a donné lieu au développement de la fonction particulièrement performante de reprise de session.
  • Connexions à longue durée de vie : les opérations cryptographiques d'échange de clés authentifiées nécessitent d'importantes ressources de calcul. Afin de gérer l'étendue de l'infrastructure de Google, les connexions peuvent être conservées plus longtemps après un premier handshake ALTS, ce qui améliore les performances globales du système.
  • Simplicité : TLS est compatible par défaut avec les anciennes versions de protocoles et a été conçu dans un souci de rétrocompatibilité. Le système ALTS est bien plus simple, car Google contrôle à la fois les clients et les serveurs, qui ont été conçus pour être compatibles nativement avec ALTS.

Modèle de confiance d'ALTS

ALTS effectue principalement l'authentification à l'aide d'une identité plutôt que d'un nom d'hôte. Chez Google, chaque entité réseau (telle qu'un utilisateur professionnel, un ordinateur physique ou un service de production) est associée à une identité. Ces identités sont intégrées aux certificats ALTS et utilisées pour l'authentification des pairs lors de l'établissement de la connexion sécurisée. Nous préconisons un modèle dans lequel nos services de production s'exécutent en tant qu'entités de production, pouvant être gérées par nos ingénieurs en fiabilité des sites (SRE)5. Les versions de développement de ces services s'exécutent en tant qu'entités de test, qui peuvent être gérées à la fois par les SRE et par les développeurs.

Supposons par exemple que nous disposons d'un produit comportant deux services : service-frontend et service-backend. Les SRE peuvent lancer la version de production de ces services : service-frontend-prod et service-backend-prod. Les développeurs peuvent créer et lancer des versions de développement de ces services (service-frontend-dev et service-backend-dev) à des fins de test. La configuration des autorisations relatives aux services de production est paramétrée de façon à ne pas faire confiance aux versions de développement.

Identifiants ALTS

Il existe trois types d'identifiants ALTS, qui sont tous exprimés sous la forme d'un message de tampon de protocole.

  • Certificat principal : il est signé par un service de signature distant et permet de vérifier les certificats de handshake. Le certificat principal contient une clé publique associée à une clé principale privée (une paire de clés RSA, par exemple). Cette clé privée sert à signer les certificats de handshake. Lorsqu'ils sont utilisés dans le cadre de la règle ALTS décrite ci-dessous, ces certificats sont essentiellement des certificats intermédiaires contraignants d'autorité de certification. Les certificats principaux sont généralement délivrés pour des machines de production et des programmeurs de charges de travail conteneurisées, tels que le Borgmaster6.
  • Certificat de handshake : créé et signé localement par la clé principale privée. Ce certificat contient les paramètres utilisés lors du handshake ALTS (établissement de la connexion sécurisée), tels que les paramètres statiques Diffie-Hellman (DH) et les algorithmes de chiffrement de handshake. Le certificat de handshake contient également le certificat principal dont il est dérivé (c'est-à-dire le certificat associé à la clé principale privée qui signe le certificat de handshake).
  • Clé de reprise : code secret permettant de chiffrer les tickets de reprise. Cette clé est identifiée par un identifiant de reprise IDR, unique pour (et partagé par) toutes les charges de travail de production qui s'exécutent avec la même identité et dans la même cellule de centre de données. Pour en savoir plus sur la reprise de session dans ALTS, consultez la section Reprise de session.

La figure 1 illustre la chaîne de certificats ALTS, qui se compose d'une clé de validation du service de signature, d'un certificat principal et d'un certificat de handshake. Les clés de validation du service de signature constituent la racine de confiance dans ALTS ; elles sont installées sur toutes les machines Google de nos réseaux de production et d'entreprise.

Figure 1 : Chaîne de certificats ALTS

Dans ALTS, un service de signature certifie les certificats principaux, qui certifient à leur tour les certificats de handshake. Comme ces derniers sont créés plus souvent que les certificats principaux, cette architecture permet de réduire la charge placée sur le service de signature. La rotation des certificats a lieu régulièrement chez Google, en particulier dans le cas des certificats de handshake7. Cette rotation fréquente compense le fait que les paires d'échange de clés statiques soient incluses dans les certificats de handshake8.

Émission des certificats

Pour pouvoir participer à un handshake sécurisé ALTS, les entités du réseau doivent recevoir des certificats de handshake. L'émetteur obtient d'abord un certificat principal signé par le service de signature, puis le transmet éventuellement à l'entité. Un certificat de handshake est ensuite créé et signé par la clé principale privée associée.

L'émetteur correspond généralement à notre autorité de certification (CA) interne lorsque des certificats sont délivrés à des machines et à des utilisateurs, ou au contrôleur Borgmaster lorsqu'ils sont délivrés à des charges de travail. Toutefois, l'émetteur peut également représenter n'importe quelle autre entité, telle qu'un contrôleur Borgmaster confiné à une cellule de centre de données de test.

La figure 2 décrit le processus de création d'un certificat principal par le service de signature. Ce processus comprend les étapes suivantes.

Figure 2 : Émission d'un certificat

  1. L'émetteur du certificat envoie une demande de signature de certificat (CSR) au service de signature. Celui-ci est alors invité à créer un certificat associé à l'identité A. Cette identité peut par exemple représenter un utilisateur d'entreprise ou un service de production Google.
  2. Le service de signature définit l'émetteur du certificat (inclus dans la demande CSR) en tant que demandeur (l'émetteur du certificat, dans le cas présent) et le signe. Rappelez-vous que la clé publique (de validation) du service de signature est installée sur toutes les machines Google.
  3. Le service de signature renvoie le certificat signé.
  4. Un certificat de handshake est créé pour l'identité A, puis signé par la clé principale privée associée au certificat.

Comme indiqué dans le processus ci-dessus, l'émetteur et le signataire d'un certificat sont deux entités logiques différentes dans le système ALTS. Dans cet exemple, l'émetteur est l'entité émettrice du certificat, tandis que le signataire est le service de signature.

Les certificats ALTS se divisent en trois grandes catégories : certificat d'utilisateur, certificat de machine et certificat de charge de travail. Les sections suivantes décrivent la façon dont ces certificats sont créés et employés.

Certificats d'utilisateur

Google sécurise les appels RPC émis par des utilisateurs humains aux services de production à l'aide d'ALTS. Pour émettre un appel RPC, un utilisateur doit fournir un certificat de handshake valide. Par exemple, si Alice souhaite émettre un appel RPC protégé par ALTS depuis une application, elle peut s'authentifier auprès de notre autorité de certification interne. Elle doit pour cela fournir son nom d'utilisateur et son mot de passe, et passer par une authentification à deux facteurs. Alice obtient ainsi un certificat de handshake valide pendant 20 heures.

Certificats de machine

Chaque machine de production des centres de données de Google dispose d'un certificat principal de machine. Celui-ci permet de créer des certificats de handshake pour les applications principales qui s'exécutent sur une machine spécifique, telles que des daemons de gestion de machine. L'identité principale incorporée à un certificat de machine représente l'objectif typique de celle-ci. Par exemple, les machines qui permettent d'exécuter divers types de charges de travail de production et de développement peuvent posséder des identités différentes. Les certificats principaux ne sont utilisables que par des machines exécutant des piles logicielles vérifiées. Dans certains cas, la racine de confiance provient d'un matériel de sécurité personnalisé9. Tous les certificats principaux de machine de production sont délivrés par l'autorité de certification et alternés au bout de quelques mois. Les certificats de handshake sont quant à eux alternés au bout de quelques heures.

Certificats de charge de travail

L'avantage du système ALTS est qu'il repose sur le concept d'identité de charge de travail, qui facilite la réplication des services, l'équilibrage de charge et la replanification entre les machines. Dans notre réseau de production, nous gérons les clusters et allouons des ressources aux machines à grande échelle à l'aide d'un système appelé Borg10. Borg délivre des certificats dans le cadre de la mise en œuvre des identités de charges de travail ALTS, qui ne dépendent pas des machines.

Chaque charge de travail de notre réseau de production s'exécute dans une cellule Borg. Chaque cellule contient un contrôleur centralisé de manière logique appelé Borgmaster ainsi que plusieurs processus d'agent (appelés Borglets) qui s'exécutent sur chaque machine de cette cellule. Les charges de travail sont initialisées avec les certificats de handshake de charge de travail associés qui ont été délivrés par le Borgmaster. La figure 3 illustre le processus de certification d'une charge de travail dans ALTS avec Borg.

Figure 3 : Création d'un certificat de handshake dans le réseau de production de Google

Le Borgmaster est maintenant prêt à planifier les charges de travail devant utiliser ALTS. Les étapes ci-dessous ont lieu lorsqu'un client planifie l'exécution d'une charge de travail sur Borg sous une identité donnée.

  1. Chaque Borgmaster contient par défaut un certificat principal de machine et une clé privée associée (non représentée sur le schéma).
  2. L'ALTSd11 génère un certificat de handshake Borgmaster et le signe à l'aide de la clé principale privée de machine. Ce certificat de handshake permet au Borgmaster d'émettre des appels RPC protégés par ALTS.
  3. Le Borgmaster crée un certificat principal de charge de travail de base et la clé privée correspondante. Il demande ensuite au service de signature (via un appel RPC protégé par ALTS) de signer ce certificat principal de charge de travail de base. Le service de signature définit alors le Borgmaster en tant qu'émetteur de ce certificat.
  4. Le Borgmaster vérifie que le client est autorisé à exécuter des charges de travail sous l'identité spécifiée dans la configuration de la charge de travail. Si tel est le cas, le Borgmaster planifie la charge de travail Borg sur le Borglet, puis délivre un certificat de handshake de charge de travail et la clé privée correspondante. Ce certificat est obtenu à partir du certificat principal de charge de travail de base. Le certificat de handshake de charge de travail et sa clé privée sont ensuite envoyés de manière sécurisée au Borglet (via un canal protégé par authentification mutuelle ALTS entre le Borgmaster et le Borglet). Tous les deux jours environ, le Borgmaster alterne son certificat principal de charge de travail de base et délivre des certificats de handshake pour toutes les charges de travail en cours d'exécution. En outre, chaque charge de travail exécutée par un même utilisateur au sein d'une même cellule reçoit la même clé de reprise et le même identifiant (IDR) provisionnés par le Borgmaster.
  5. Lorsque la charge de travail doit effectuer un appel RPC protégé par ALTS, elle utilise le certificat de handshake de charge de travail dans le protocole de handshake. L'IDR permet également d'initier la reprise de session dans le cadre du handshake. Pour plus d'informations sur la reprise de session dans ALTS, consultez la section Reprise de session.

Application de la stratégie ALTS

La stratégie ALTS est un document qui répertorie les émetteurs autorisés à délivrer certaines catégories de certificats à des identités spécifiques. Ce document est distribué à toutes les machines de notre réseau de production. Par exemple, la stratégie ALTS permet à l'autorité de certification de délivrer des certificats à des machines et à des utilisateurs, et au Borgmaster d'en délivrer à des charges de travail.

Nous avons constaté que l'application de la stratégie apportait davantage de flexibilité lors de la validation du certificat que lors de son émission. Cette approche permet en effet d'appliquer différentes stratégies sur divers types de déploiement. Par exemple, un utilisateur peut vouloir utiliser une stratégie plus permissive dans un cluster de test que dans un cluster de production.

Lors du handshake ALTS, la validation du certificat inclut une vérification de la stratégie ALTS. La stratégie garantit que l'émetteur spécifié dans le certificat en cours de validation est autorisé à le délivrer. Si ce n'est pas le cas, le certificat est rejeté et le processus de handshake échoue. La figure 4 illustre le fonctionnement de l'application de la stratégie dans ALTS. Pour reprendre le scénario de la figure 2, imaginons que Mallory (une utilisatrice d'entreprise qui cherche à élever ses privilèges) souhaite délivrer un certificat principal à l'administrateur réseau, une identité puissante capable de reconfigurer le réseau. Il va sans dire que la stratégie ALTS n'autorise pas Mallory à effectuer cette opération.

Figure 4 : Émission et utilisation du certificat

  1. Mallory délivre un certificat principal à l'identité d'administrateur réseau et le fait signer par le service de signature. Cette démarche est semblable aux trois premières étapes de la figure 2.
  2. Mallory crée et signe localement un certificat de handshake pour l'administrateur réseau à l'aide de la clé principale privée associée au certificat principal généré.
  3. Si Mallory tente d'usurper l'identité de l'administrateur réseau en utilisant le certificat de handshake créé, l'outil d'application de la stratégie ALTS bloque l'opération auprès du pair avec lequel Mallory tente de communiquer.

Révocation des certificats

Chez Google, un certificat perd sa validité lorsqu'il expire ou lorsqu'il est inclus dans notre liste de révocation de certificats (CRL). Cette section décrit la conception des mécanismes de révocation de certificats internes de Google, qui étaient encore en cours de test de déploiement lors de la rédaction du présent document.

Tous les certificats délivrés à des utilisateurs d'entreprise possèdent un horodatage quotidien d'expiration qui les oblige à se réauthentifier chaque jour. La plupart des certificats délivrés à des machines de production n'utilisent pas d'horodatage d'expiration. Nous évitons de recourir aux horodatages d'expiration pour les certificats de production, car cela peut entraîner des interruptions dues à des problèmes de synchronisation de l'horloge. Nous utilisons plutôt la liste de révocation de certificats comme source d'informations pour la rotation et pour la gestion des certificats en cas d'incident. La figure 5 décrit le fonctionnement de la liste de révocation de certificats (CRL).

Figure 5 : Création d'un certificat principal avec un ID de révocation

  1. Lorsqu'une instance de notre autorité de certification est initialisée12, elle contacte le service CRL et demande une plage d'ID de révocation. Un ID de révocation est un ID de 64 bits ayant deux composants : une catégorie de certificat de 8 bits (par exemple, un certificat d'utilisateur ou de machine) et un identifiant de certificat de 56 bits. Le service CRL choisit une plage de ces ID et la renvoie à l'autorité de certification.
  2. Lorsque l'autorité de certification reçoit une demande de certificat principal, elle le génère et y incorpore un ID de révocation choisi dans la plage.
  3. En parallèle, l'autorité de certification mappe le nouveau certificat à l'ID de révocation et envoie ces informations au service CRL.
  4. L'autorité de certification délivre le certificat principal.

Les ID de révocation attribués aux certificats de handshake dépendent de l'utilisation du certificat. Par exemple, les certificats de handshake délivrés à des utilisateurs d'entreprise héritent de l'ID de révocation du certificat principal de l'utilisateur. Dans le cas des certificats de handshake délivrés à des charges de travail Borg, l'ID de révocation est attribué par la plage d'ID de révocation du Borgmaster. Cette plage d'ID est attribuée au Borgmaster par le service CRL lors d'un processus semblable à celui décrit dans la figure 5. Lorsqu'un pair est impliqué dans un handshake ALTS, il vérifie une copie locale du fichier CRL pour s'assurer que le certificat du pair distant n'a pas été révoqué.

Le service CRL compile tous les ID de révocation dans un fichier pouvant être transmis à toutes les machines Google qui utilisent ALTS. Bien que la base de données CRL fasse plusieurs centaines de mégaoctets, le fichier CRL généré n'occupe que quelques mégaoctets (grâce à diverses techniques de compression).

Protocoles ALTS

ALTS repose sur deux protocoles : le protocole de handshake (avec reprise de session) et le protocole d'enregistrement. Cette section vous offre une vue d'ensemble de chacun d'eux. Ces brèves descriptions ne doivent pas être considérées comme des spécifications détaillées des protocoles.

Protocole de handshake

Le protocole de handshake ALTS est un protocole d'échange de clé authentifiée basé sur Diffie-Hellman. Il est compatible avec la confidentialité persistante parfaite (PFS) et la reprise de session. L'infrastructure d'ALTS garantit que chaque client et chaque serveur dispose d'un certificat avec ses identités respectives ainsi que d'une clé ECDH (Elliptic Curve Diffie-Hellman) permettant d'obtenir une clé de validation de service de signature approuvée. Dans ALTS, la fonctionnalité PFS n'est pas activée par défaut, car les clés ECDH statiques sont fréquemment mises à jour afin de renouveler la confidentialité persistante (même si la fonctionnalité PFS n'est pas utilisée lors d'un handshake). Au cours d'un handshake, le client et le serveur négocient de manière sécurisée une clé de chiffrement en transit partagée ainsi que le protocole d'enregistrement qui sera protégé par la clé de chiffrement. Par exemple, le client et le serveur peuvent convenir d'une clé de 128 bits pour protéger une session RPC à l'aide d'AES-GCM. Le handshake se compose de quatre messages de tampon de protocole sérialisés, qui sont présentés dans la figure 6.

Figure 6 : Messages du protocole de handshake ALTS

  1. Le client initie le handshake en envoyant un message ClientInit. Celui-ci contient le certificat de handshake du client ainsi qu'une liste des algorithmes de chiffrement liés au handshake et des protocoles d'enregistrement compatibles avec le client. Si le client tente de reprendre une session terminée, le message inclut un identifiant de reprise et un ticket de reprise de serveur chiffré.

  2. À la réception du message ClientInit, le serveur vérifie le certificat client. S'il est valide, le serveur choisit un algorithme de chiffrement de handshake et un protocole d'enregistrement dans la liste fournie par le client. Le serveur calcule le résultat de l'échange DH en combinant les informations contenues dans le message ClientInit et ses propres informations locales. Ce résultat est utilisé avec la transcription du protocole en tant qu'entrée de fonctions de dérivation de clés13, afin de générer les secrets de session suivants :

    • Une clé secrète de protocole d'enregistrement M qui permet de chiffrer et d'authentifier les messages avec charge utile.
    • Un secret de reprise R à utiliser dans un ticket de reprise lors de sessions futures.
    • Un secret d'authentificateur A.

    Le serveur envoie un message ServerInit contenant son certificat, l'algorithme de chiffrement de handshake choisi, le protocole d'enregistrement, et éventuellement un ticket de reprise chiffré.

  3. Le serveur envoie un message ServerFinished contenant un authentificateur14 de handshake. La valeur de cet authentificateur est obtenue à l'aide d'un code HMAC (Hash-based Message Authentication Code), calculé à partir d'une chaîne de bits prédéfinie et du secret d'authentificateur A.

  4. Lorsque le client reçoit le message ServerInit, il vérifie le certificat du serveur, calcule le résultat de l'échange DH de la même manière que le serveur, et dérive les mêmes secrets M, R et A. Le client vérifie la valeur de l'authentificateur du message ServerFinished à l'aide du secret A dérivé. À ce stade du processus de handshake, le client peut commencer à chiffrer les messages à l'aide de la clé M. Comme le client peut désormais envoyer des messages chiffrés, nous pouvons dire qu'ALTS dispose d'un protocole de handshake à 1 DAR.

  5. À la fin du handshake, le client envoie un message ClientFinished contenant une valeur d'authentificateur semblable (voir l'étape 3) calculée à partir d'une autre chaîne de bits prédéfinie. Si nécessaire, le client peut inclure un ticket de reprise chiffré pour les sessions futures. Une fois ce message reçu et validé par le serveur, le protocole de handshake ALTS est conclu et le serveur peut commencer à chiffrer et à authentifier d'autres messages avec charge utile à l'aide de la clé M.

Le protocole de handshake a été révisé par Thai Duong, membre de l'équipe d'analyse de la sécurité interne de Google, et officiellement vérifié à l'aide de l'outil Proverif15 par Bruno Blanchet, avec l'assistance de Martin Abadi.

Protocole d'enregistrement

La section Protocole de handshake vous a expliqué la façon dont nous négocions un code secret de protocole d'enregistrement à l'aide du protocole de handshake. Ce secret permet de chiffrer et d'authentifier le trafic réseau. La couche de la pile qui effectue ces opérations est appelée ALTSRP (ALTS Record Protocol, protocole d'enregistrement ALTS).

ALTSRP contient une suite de schémas de chiffrement qui possèdent diverses tailles de clé et fonctionnalités de sécurité. Lors du handshake, le client envoie sa liste de schémas privilégiés, triés par ordre de préférence. Dans cette liste, le serveur choisit le premier protocole correspondant à sa configuration locale. Cette méthode de sélection de schéma permet aux clients et aux serveurs d'utiliser des préférences de chiffrement différentes, et nous offre la possibilité d'intégrer (ou de supprimer) des schémas de chiffrement.

Trames

Les trames représentent la plus petite unité de données dans ALTS. Chaque message ALTSRP peut comprendre une ou plusieurs trames, selon sa taille. Chaque trame contient les champs suivants :

  • Longueur : valeur non signée de 32 bits qui indique la longueur de la trame, en octets. Ce champ de 4 octets n'est pas inclus dans la longueur totale de la trame.
  • Type : valeur de 32 bits qui spécifie le type de trame (exemple : trame de données).
  • Charge utile : données authentifiées et éventuellement chiffrées qui sont en cours d'envoi.

La longueur maximale d'une trame est de 1 Mo, plus les 4 octets du champ de longueur. Pour les protocoles RPC actuels, nous limitons davantage la longueur de trame afin de réduire la mémoire requise pour la mise en mémoire tampon. En outre, des trames plus longues pourraient être la cible d'un éventuel pirate lors d'une attaque par déni de service (DoS) visant à priver un serveur de ses ressources. En plus de restreindre la longueur de trame, nous limitons également le nombre de trames pouvant être chiffrées à l'aide du même secret de protocole d'enregistrement M. La limite varie en fonction du schéma utilisé pour chiffrer et déchiffrer la charge utile de la trame. Une fois cette limite atteinte, la connexion doit être fermée.

Charge utile

Dans ALTS, chaque trame contient une charge utile protégée en intégrité et éventuellement chiffrée16. Au moment de la publication du présent document, ALTS est compatible avec les modes suivants :

  • AES-128-GCM et AES-128-VCM : il s'agit des modes AES-GCM et AES-VCM avec des clés de 128 bits. Ils protègent la confidentialité et l'intégrité de la charge utile à l'aide des schémas respectifs GCM et VCM17.
  • AES-128-GMAC et AES-128-VMAC : ces modes permettent de protéger l'intégrité de la charge utile à l'aide des schémas respectifs GMAC et VMAC, pour le calcul des tags. La charge utile est convertie en texte brut à l'aide d'un tag cryptographique qui protège son intégrité.

Google emploie divers modes de protection en fonction du modèle de gestion des menaces et des exigences en matière de performances. Si les entités qui communiquent se situent au sein de la même limite physique contrôlée par ou pour le compte de Google, seule la protection de l'intégrité est utilisée. Ces entités peuvent toujours choisir de passer au chiffrement authentifié, selon la sensibilité de leurs données. Si les entités qui communiquent se situent dans différentes limites physiques contrôlées par ou pour le compte de Google (lorsque les communications transitent via le réseau étendu), nous renforçons automatiquement la sécurité de la connexion pour qu'elle utilise le chiffrement authentifié, quel que soit le mode choisi. Google protège les données en transit de diverses façons lorsqu'elles sont transmises en dehors d'une limite physique contrôlée par ou pour le compte de Google, car il est impossible de leur appliquer les mêmes mesures de sécurité rigoureuses.

Chaque trame est protégée séparément en intégrité, et elle est éventuellement chiffrée. Les deux pairs gèrent les compteurs de requêtes et de réponses, qui se synchronisent en mode de fonctionnement normal. Si le serveur reçoit des requêtes répétées ou dans le désordre, la vérification de l'intégrité cryptographique échoue, ce qui annule la requête. De même, le client annule les réponses lorsqu'elles sont répétées ou dans le désordre. De plus, comme les deux pairs gèrent les compteurs (au lieu d'inclure leur valeur dans l'en-tête de la trame), vous économisez des octets supplémentaires sur le réseau.

Reprise de session

ALTS permet à ses utilisateurs de reprendre des sessions précédentes sans avoir à exécuter de lourdes opérations cryptographiques asymétriques. La reprise de session est une fonctionnalité intégrée au protocole de handshake ALTS.

Le handshake ALTS permet aux clients et aux serveurs d'échanger (et de mettre en cache) de manière sécurisée des tickets de reprise servant à reprendre des connexions futures18. Chaque ticket de reprise mis en cache est indexé par un identifiant de reprise (IDR) unique pour toutes les charges de travail qui s'exécutent avec la même identité et dans la même cellule de centre de données. Ces tickets sont chiffrés à l'aide de clés symétriques associées à leurs identifiants correspondants.

ALTS accepte deux types de reprise de session :

  1. Reprise de session côté serveur : un client crée et chiffre un ticket de reprise contenant l'identité du serveur et le secret de reprise dérivé R. Le ticket de reprise est ensuite envoyé au serveur au sein du message ClientFinished, à la fin du handshake. Dans les sessions futures, le serveur peut choisir de reprendre la session en renvoyant le ticket au client dans son message ServerInit. À la réception du ticket, le client peut récupérer le secret de reprise R et l'identité du serveur, qui lui permettent de reprendre la session.

    L'IDR est toujours associé à une identité et non à des connexions spécifiques. Dans ALTS, plusieurs clients peuvent utiliser la même identité au sein du même centre de données. Cela leur permet de reprendre des sessions avec des serveurs avec lesquels ils n'avaient peut-être jamais communiqué (par exemple, dans le cas d'un équilibreur de charge qui redirige le client vers un autre serveur exécutant la même application).

  2. Reprise de session côté client : à la fin d'un handshake, le serveur envoie un ticket de reprise chiffré au client au sein du message ServerFinished. Ce ticket comprend le secret de reprise R ainsi que l'identité du client. Il permet au client de reprendre une connexion avec n'importe quel serveur partageant le même IDR.

Lors de la reprise d'une session, le secret de reprise R sert à dériver les nouveaux secrets de session M', R' et A'. M' permet de chiffrer et d'authentifier les messages avec charge utile, A' sert à authentifier les messages ServerFinished et ClientFinished, et R' est encapsulé dans un nouveau ticket de reprise. Sachez qu'un même secret de reprise R n'est jamais utilisé plus d'une fois.

Compromis

Attaques d'usurpation d'identité par compromission de clé

De par sa conception, le protocole de handshake ALTS est sujet aux attaques d'usurpation d'identité par compromission de clé (KCI, Key Compromise Impersonation). Si une personne mal intentionnée compromet la clé privée DH ou la clé de reprise d'une charge de travail, elle peut s'en servir pour usurper l'identité d'autres charges de travail associées19. Ce point est explicitement mentionné dans notre modèle de gestion des menaces concernant la reprise, car nous souhaitons que les tickets de reprise émis par une instance d'identité soient utilisables par d'autres instances de cette identité.

Il existe une variante du protocole de handshake ALTS qui vous protège contre les attaques KCI, mais elle n'est utile que dans les environnements dans lesquels vous ne souhaitez pas exploiter la reprise de session.

Confidentialité des messages de handshake

Le système ALTS n'est pas conçu pour dissimuler les identités internes qui communiquent. Il ne chiffre donc pas les messages de handshake pour masquer les identités des pairs.

Confidentialité persistante parfaite

La confidentialité persistante parfaite (PFS) est disponible dans ALTS, mais n'est pas activée par défaut. À la place, nous alternons régulièrement les certificats afin d'établir une confidentialité persistante pour la plupart des applications. Avec TLS 1.2 (et versions précédentes), la reprise de session n'est pas protégée par la confidentialité persistante parfaite. Lorsque la fonctionnalité PFS est activée dans ALTS, elle est également activée pour les sessions reprises.

Reprise sans aller-retour

TLS 1.3 fournit une reprise de session qui ne nécessite aucun aller-retour (0-DAR), mais cette méthode affaiblit toutefois les propriétés de sécurité20. Nous avons décidé de ne pas inclure l'option 0-DAR dans ALTS, car les connexions RPC de Google disposent généralement d'une longue durée de vie. Par conséquent, il n'était pas intéressant de réduire la latence de configuration de canal au vu de la complexité supplémentaire requise par les handshakes 0-DAR, et de l'affaiblissement de la sécurité qui les accompagne.

Autres références

Notes de bas de page

1Un microservice est un style architectural qui structure une application sous la forme d'un ensemble de services faiblement couplés mettant en œuvre des fonctionnalités d'entreprise.
2Une charge de travail de production est une application que des ingénieurs Google prévoient d'exécuter dans nos centres de données.
3Pour en savoir plus sur la protection des données en transit de Google, consultez notre livre blanc Chiffrement en transit dans Google Cloud.
4Un modèle de confiance est un mécanisme qui permet au protocole de sécurité d'identifier, de distribuer et d'alterner des identifiants et des identités.
5Certains services sont gérés directement par les développeurs.
6Le Borgmaster se charge de la planification et de l'initialisation des charges de travail de production de Google. Pour en savoir plus, consultez la page Gestion à grande échelle des clusters Google avec Borg.
7Pour en savoir plus sur la fréquence de rotation des certificats, consultez le livre blanc Chiffrement en transit dans Google Cloud.
8Si une clé est compromise, le trafic n'est visible par le pirate que pendant la durée de vie de cette paire de clés.
11ALTSd : daemon responsable de la création des certificats de handshake ainsi que d'autres opérations ALTS.
12En pratique, l'autorité de certification a accès aux clés privées du service de signature. Les deux entités logiques ne constituent donc qu'une seule entité physique.
13En particulier, HKDF-Extract et HKDF-Expand tels que définis dans le document RFC-5869.
14La mise en œuvre du protocole de handshake ALTS concatène les messages ServerInit et ServerFinished en une seule charge utile réseau.
16Le chiffrement de la charge utile est négocié dans le cadre du protocole d'enregistrement du handshake.
17Le schéma AES-GCM 128 bits est basé sur la recommandation 800-38D du NIST. Le schéma AES-VCM est abordé en détail dans l'article AES-VCM, une construction du schéma AES-GCM qui exploite une fonction de hachage universelle basée sur des entiers.
18La reprise de session n'implique des opérations symétriques légères que si vous n'utilisez pas de paramètres éphémères.