Google veut simplifier le chiffrement de bout en bout dans Gmail
Google dévoile cette semaine une version améliorée du chiffrement côté client (CSE) pour son service Gmail. Le géant du cloud espère ainsi rendre obsolète, une fois pour toutes, la norme Secure/Multipurpose Internet Mail Extensions (S/MIME) pour le courrier électronique chiffré de bout en bout (E2EE).
S/MIME est utilisé pour le chiffrement et la signature de clé publique des données MIME et a été développé à l’origine par RSA en 2002. Aujourd’hui, bien que la fonctionnalité S/MIME soit largement utilisée, elle n’est pas toujours activée par défaut dans la plupart des services de courrier électronique et ne fonctionne que lorsque les parties qui envoient et reçoivent le courrier répondent à la norme.
En effet, les deux équipes informatiques des employés engagés dans un échange doivent acquérir et gérer les certificats nécessaires et les déployer auprès de chaque utilisateur. Sans compter que les utilisateurs doivent ensuite déterminer si le destinataire et eux-mêmes ont configuré S/MIME, puis échanger des certificats avant de pouvoir échanger des courriels chiffrés.
Pour Google, S/MIME a fait son temps
Bien qu’il existe des solutions alternatives, telles que les fonctions intégrées des éditeurs de messagerie ou les solutions ponctuelles, elles présentent les mêmes inconvénients.
Selon Google, cela limite l’utilisation de l’E2EE aux organisations qui disposent de ressources informatiques importantes et de cas d’usage solides pour l’envoi de courriers chiffrés. Même dans ce cas, elles ne peuvent souvent le faire qu’en utilisant des solutions de contournement qui créent des expériences fragmentées, limitées et sous-optimales pour toutes les personnes impliquées.
« Si vous parlez à des administrateurs, ils vous diront plusieurs choses sur le chiffrement », explique Neil Kumaran, chef de produit pour la sécurité de Gmail chez Google. « Tout d’abord, ils vous diront probablement que pour un certain sous-ensemble de leurs données, elles doivent être entièrement chiffrées d’une manière ou d’une autre – généralement en raison d’une obligation réglementaire et peut-être d’une obligation contractuelle ».
« La deuxième chose qu’ils vous diront, c’est que l’état actuel du chiffrement est très difficile à mettre en œuvre dans l’écosystème de la messagerie électronique », poursuit-il. « Et même s’ils mettent en œuvre certaines de ces solutions en dehors des cas d’usage idéaux, il y a généralement des failles dans leur dispositif de chiffrement. En résumé, cette situation est largement ressentie par l’ensemble de nos clients ».
Google assure que sa solution démocratise effectivement le chiffrement tout en exigeant un minimum d’effort de la part des équipes informatiques et des utilisateurs. Et ce, tout en « améliorant le contrôle, la confidentialité et la souveraineté des données ». Une promesse qu’il faisait déjà en 2021 lors des premières intégrations de CSE (Client Side Encryption) dans la suite Workspace.
Simplifier l’utilisation de CSE
« L’idée est de créer une sorte de bulle protectrice pour les courriels, qui semble automatique au point de ressembler à un courriel normal. »
Julian DuplantResponsable du produit de sécurité de Gmail, Google
La solution de Google consiste en un modèle de chiffrement qui, selon l’entreprise, supprime les exigences complexes en matière de certificats ou de droits d’administration et permet aux utilisateurs d’envoyer des messages entièrement chiffrés à n’importe quel utilisateur sur n’importe quelle plateforme.
« L’idée est de créer une sorte de bulle protectrice pour les courriels, qui semble automatique au point de ressembler à un courriel normal », décrit Julian Duplant, responsable du produit de sécurité de Gmail, auprès de Computer Weekly, une publication sœur du MagIT. « Nous avons créé un service qui permet aux organisations utilisant cette fonctionnalité de devenir les gardiens de ces données ».
Avec cette bulle, Google assure qu’il confie d’abord à ses clients le contrôle des certificats, ou clés, nécessaires pour chiffrer ou déchiffrer les messages, en renonçant définitivement à sa propre capacité d’accès aux messages.
Plutôt, le fournisseur laisse le choix aux clients d’utiliser les services de chiffrement tiers du marché, KMS ou HSM. GCP recommande en premier lieu les services de FlowCrypt, Fortanix, FutureX, Stormshield, Ultimaco, SixScape, Hitachi et Thales. Les administrateurs peuvent bâtir leur propre service de gestion de clés. Il n’est pas possible d’utiliser les services de chiffrement de Google.
Deuxièmement, le fournisseur donne aux entreprises le contrôle de l’annuaire des utilisateurs qui décide qui a accès aux clés.
Troisièmement, il a créé une nouvelle fonctionnalité pour les invités, qui permet aux clients de créer automatiquement des comptes temporaires dans leur organisation, pour que des destinataires externes puissent accéder au message et le déchiffrer selon les règles du client.
« Tout l’échange de certificats qui aurait eu lieu auparavant n’a plus lieu d’être. C’est automatique et cela permet aux clients d’avoir leur propre espace de sécurité et de contrôle de ces données. »
Julian DuplantResponsable du produit de sécurité de Gmail, Google
« Si vous envoyez un message à un destinataire qui possède Gmail, qu’il s’agisse d’un espace de travail ou d’un consommateur, il pourra automatiquement déchiffrer ce message sur la base des règles de l’organisation », raconte M. Duplant. « [Si le contact utilise] n’importe quel autre fournisseur de courrier électronique dans le monde, il recevra une notification par courrier électronique indiquant que “Julian vous a envoyé un message chiffré, cliquez ici pour le lire” », explique-t-il.
Lorsque l’utilisateur clique sur ce message, le navigateur s’ouvre et il voit une interface Gmail sécurisée où il peut déchiffrer le message et rédiger sa propre réponse. « Le plus intéressant, c’est que S/MIME n’est pas nécessaire. Tout l’échange de certificats qui aurait eu lieu auparavant n’a plus lieu d’être », avance Julian Duplant. « C’est automatique et cela permet aux clients d’avoir leur propre espace de sécurité et de contrôle de ces données. »
Il est également important de noter que si le destinataire a configuré S/MIME, Gmail continuera d’envoyer le courrier électronique via S/MIME, comme il le fait déjà.
Google estime que cette approche offre une solution de chiffrement plus complète à ses clients, ce qui réduirait les frictions et abaisserait les obstacles à une cybersécurité efficace.
Un contrôle supplémentaire pour les entreprises
Un autre effet secondaire de cette approche du chiffrement côté client, selon Google, est qu’en faisant de ses clients les arbitres ultimes de l’accès à leurs données de messagerie, elle peut les aider à se protéger contre, par exemple, les intrusions injustifiées de gouvernements exigeant que le fournisseur de services leur remette les données.
Google a déclaré qu’il espérait ainsi améliorer la conformité de ses clients avec les réglementations sur la souveraineté des données, les contrôles à l’exportation et d’autres exigences telles que l’HIPAA aux États-Unis.
La technique de chiffrement CSE présente toutefois plusieurs limites. Les clés de chiffrement des messages sont traitées dans le client, ici Chrome, avant son envoi vers les services cloud de Google. La couche de chiffrement additionnel ne s’applique pas aux métadonnées des mails : son titre, son heure d’envoi ne sont pas protégés par cette méthode. Certaines fonctionnalités, dont la signature, l’impression, l’envoi de rendez-vous sur calendrier sont désactivés. Les fichiers en pièces jointes ne peuvent pas dépasser 5 Mo. Si certaines extensions de fichiers sont bloquées, les mails chiffrés ne peuvent pas être scannés à la recherche de virus.
La nouvelle technologie est disponible aujourd’hui en version bêta pour les clients éditions Enterprise Plus, Education Standard et Plus, mais dans les semaines à venir, les utilisateurs pourront envoyer des courriels E2EE à n’importe quelle boîte de réception Gmail et à n’importe quelle boîte de réception dans le courant de l’année.
Pour approfondir sur Gestion des accès (MFA, FIDO, SSO, SAML, IDaaS, CIAM)
