Google donne les clés de chiffrement de Meet à ses clients

Le contrôle des clés de chiffrement aux mains des entreprises

La méthodologie Client-side Encryption est similaire au mécanisme de chiffrement de bout en bout (End to End Encryption ou E2EE). Le chiffrement et le déchiffrement ont lieu « sur les appareils source et de destination ». Avec l’approche E2EE, les clés sont générées sur le client, à même les appareils.

« En tant qu’administrateur, vous n’avez donc aucun contrôle sur les clés des clients et sur les personnes qui peuvent les utiliser. En outre, vous n’avez pas de visibilité sur les documents que les utilisateurs ont chiffrés », explique Google dans une FAQ.

L’approche CSE vantée par Google conserve les phases de chiffrement au niveau des clients, mais fait appel à des clés générées et stockées par un « Key management service basé sur le cloud » administré par l’entreprise.

 « Vous pouvez contrôler les clés et les personnes qui y ont accès. Par exemple, vous pouvez révoquer l’accès d’un utilisateur aux clés, même si cet utilisateur les a générés. En outre, avec CSE, vous pouvez surveiller les fichiers chiffrés des utilisateurs », lit-on dans la FAQ.

Google cloud va plus loin. La gestion des clés de chiffrement ne peut pas être effectuée depuis son propre service KMS. Il est obligatoire de faire appel à un service externe ou de déployer sa propre infrastructure de chiffrement indépendante de GCP. Lors de la première partie de la bêta, les solutions de FlowCrypt, FutureX, Virtru et Thales étaient disponibles. En amont de Cloud Next 21, Google Cloud a annoncé des partenariats avec Fortanix et l’éditeur français Stormshield.

Fortanix intègre la fonction CSE de Google Workspace à son offre Data Security Manager en mode SaaS ou on-premise. Chez le second, cela passe par la création d’une offre intitulée Stormshield Data Security for Google Workspace.

Comment fonctionne Client-side Encryption

La configuration de CSE se fait en quatre étapes. La première consiste à configurer le service externe de chiffrement. Cela peut être une solution de l’un des partenaires de Google, ou l’entreprise peut connecter son propre KMS/HSM depuis l’API Key Access Service Public.

Ensuite, il faut connecter le service de gestion de clés à la console d’administration de Google, puis relier Workspace à un gestionnaire d’identité (SSO de type OpenID Connect), lui aussi externe, de préférence.

C’est sans doute l’une des étapes les plus importantes de ce mécanisme. Cinq méthodes différentes plus ou moins aisées à mettre en place font varier le niveau d’isolation de la gestion des clés et des identités par rapport à l’infrastructure de Google Cloud. Elles dérivent de deux approches différentes : l’utilisation d’un service tiers ou le stockage par l’entreprise d’un fichier well known sur ses propres serveurs. « Votre IdP vérifie l’identité des utilisateurs avant de les autoriser à chiffrer des fichiers ou à accéder à des fichiers chiffrés », justifie la FAQ de Google.

Les phases de chiffrement et de déchiffrement entraînent des appels API validés par des tokens JWT. Les transits sont protégés à l’aide du protocole TLS. Enfin, CSE peut être activé pour certaines organisations ou toute l’entreprise. Le droit de chiffrer les documents doit être accordé par les administrateurs aux utilisateurs qui le souhaitent. Tous les membres d’une organisation peuvent lire et modifier les fichiers qu’ils leur sont expressément partagés.

La documentation de Stormshield et un billet de blog de Fortanix explicitent le fonctionnement du système de chiffrement. En clair, les documents sont chiffrés côté client par une clé nommée Data Encryption Key (DEK) générée par le navigateur Web de Google. Les clés sont placées dans des enveloppes de chiffrement (Key Encryption Key ou KEK), gérées par le KMS externe, avant même que les clés DEK ne soient stockées sur les serveurs de Google. Le client destinataire, à savoir le navigateur Web Google, déchiffre les clés DEK sur la machine de l’utilisateur à qui l’on partage les fichiers.

« SDS for Google Workspace est installé dans votre infrastructure sur site ou cloud : les clés KEK sont donc conservées chez vous et ne sont jamais transmises aux serveurs Google », assure la documentation de Stormshield. Cette affirmation semble vraie pour tous les services tiers. Fortanix reprend presque mot pour mot cet argumentaire, en précisant qu’il s’appuie sur des HSM FIPS 140-2 niveau 3.

Des restrictions et des détails à prendre en compte

Attention, car les noms des fichiers, de leurs auteurs et d’autres métadonnées sont stockés en plein texte sur le cloud. Pour protéger ces informations, Google cloud recommande d’ajouter une autre couche de chiffrement.

Par ailleurs, plusieurs restrictions de fonctionnalités sont à prendre en compte. Il n’est pas possible d’ajouter un commentaire dans Docs, importer des fichiers Microsoft Office dans Docs, Sheets ou Slides, de faire des appels externes depuis Sheets. La correction orthographique et grammaticale, la saisie vocale et la comparaison des documents, l’affichage des aperçus des fichiers ne sont pas non plus possibles.

Google Meet : un chiffrement de bout en bout, mais avec les clés des entreprises

Venons au cas de Meet. Dans sa documentation et à travers les diverses interventions de ses dirigeants, Google n’explique pas en toute transparence en quoi le mécanisme CSE diffère ou non de celui utilisé par Zoom ou Tixeo pour un chiffrement de bout en bout.

En septembre dernier, Zoom a annoncé qu’il proposerait avant la fin de l’année une solution en bêta pour que ses utilisateurs-entreprises emploient leurs propres clés de chiffrement. Zoom précise que son offre BYOK (Bring Your Own Key) reposera sur le KMS AWS, géré par les entreprises utilisatrices. De plus, il s’agit d’une option supplémentaire séparée du chiffrement de bout en bout qui, lui, reste aux mains de Zoom. Cette solution BYOK « n’est pas pensée pour les usages en temps réel », mais pour chiffrer les fichiers partagés et les vidéos enregistrées depuis son outil de visioconférence.

À première vue, l’architecture présentée par Google pour Meet semble répondre au même cas d’usage que Zoom BYOK.

LeMagIT a posé la question à Google afin de savoir si le chiffrement pouvait s’appliquer au flux vidéo et audio en temps réel, lors d’une visioconférence sur Meet. « En ce qui concerne CSE pour Meet, le chiffrement côté client est appliqué en temps réel à tous les médias envoyés et reçus par le client (le navigateur Web ou l’application Meet, N.D.L.R.). Cela inclut la vidéo, l’audio et le contenu partagé sur l’écran », répond un porte-parole de Google.

Cette réponse est à la fois précise et floue, car c’est le chiffrement qui est appliqué en temps réel sur des médias partagés entre les utilisateurs. Ces médias pourraient être échangés de manière différée. La suite de la réponse tend à le confirmer.

« Cette fonctionnalité est similaire à [l’approche] E2EE, en ce sens que le fournisseur [Google] n’a pas accès aux données, car elles sont chiffrées avant d’être téléchargées depuis un appareil. Mais dans le cas de CSE pour Meet, les administrateurs de l’entreprise cliente (et non Google) contrôlent les clés et peuvent rendre les données disponibles à diverses fins de recherche si nécessaire ».

pic.twitter.com/ensnwpkZsh

— Ivan Kutil (@ivankutil) October 12, 2021

Le fin mot de l’histoire se trouve sur Twitter, dans les messages d’Ivan Kutil, cofondateur et PDG de la startup AppSatori, promu Champion Innovator par Google pour son expertise des produits Workspace. Ivan Kutil partage un slide de Google contenant un détail important. Avec Meet, ce ne sont pas des Data Encryption Key qui sont enveloppées par des KEK, mais des « Session Key », des clés de session.

Expliquons ce point. Meet est motorisé par WebRTC. Ce framework attribue des clés uniques aux participants et à la « salle » qui les accueille, ce sont les Session Keys. Ces clés sont détruites à la fin d’une visioconférence.

Cela permet le chiffrement des données en transit entre le navigateur Web, les applications Meet et les serveurs de Google. Le géant du cloud utilise le standard DLTS (Datagram Transport Layer Security) et le protocole SRTP (Secure Real Time Transport Protocol). Par défaut, sans CSE, les enregistrements vidéo et les fichiers partagés sont chiffrés au repos sur Google Drive.

Or WebRTC et l’architecture employée par Google rendent difficile un chiffrement bout en bout à large échelle. C’est pour cette raison que Google est l’un des principaux promoteurs du projet Insertable Stream, qui permet de masquer le signal vidéo et audio en cas d’intrusion dans une session. Pour autant, CSE pour Meet doit bien offrir un chiffrement bout en bout des visioconférences, mais avec les clés de chiffrement fournies par les entreprises. Cependant, il faut s’attendre à des limitations d’usage.

Des clients aux fichiers sensibles

Reste à savoir à qui s’adresse cette option de chiffrement dans Workspace. Google explique que CSE est idéale pour les entreprises qui emploient des fichiers « extrêmement sensibles », comme des documents relatifs à des propriétés intellectuelles ou des organisations en provenance de secteurs hautement réglementés « comme l’aérospatial, la défense, les services financiers ou les gouvernements », indique la FAQ de Google.

Dès l’annonce de Client-Side Encryption en juin, GCP avait mentionné un premier client de taille : Airbus.

« Chez Airbus, nous utilisons déjà Client-side Encryption dans Workspace pour protéger les données les plus critiques de notre entreprise », déclare Andrew Plankett, Head of Digital Workplace chez Airbus dans un communiqué de presse de Google.

Avec cette approche, l’entreprise cliente et son fournisseur de solutions de chiffrement et d’identités partagent davantage de responsabilités. De même, ce mode de chiffrement est plus coûteux et réclame une surveillance accrue.

Le géant du cloud prévoit d’étendre les capacités de CSE pour Gmail et Agenda.