Gmail client-side encryption: A deep dive

Nicolas Lidzborski, Principal Engineer and Jaishankar Sundararaman, Sr. Director of Engineering, Google Workspace

In February, we expanded Google Workspace client-side encryption (CSE) capabilities to include Gmail and Calendar in addition to Drive, Docs, Slides, Sheets, and Meet.

CSE in Gmail was designed to provide commercial and public sector organizations an additional layer of confidentiality and data integrity protection beyond the existing encryption offered by default in Workspace. When CSE is enabled, email messages are protected using encryption keys that are fully under the customer’s control. The data is encrypted on the client device before it’s sent to Google servers that do not have access to the encryption keys, which means the data is indecipherable to us–we have no technical ability to access it. The entire process happens in the browser on the client device, without the need to install desktop applications or browser extensions, which means that users get the same intuitive productivity and collaboration experiences that they enjoy with Gmail today. Let’s take a deeper look into how it works.

How we built Client-side Encryption for Workspace

We invented and designed a new service called, Key Access Control List Service (KACLS), that is used across all essential Workspace applications. Then, we worked directly with customers and partners to make it secure, reliable, and simple to deploy. KACLS performs cryptographic operations with encryption keys after validating end-user authentication and authorization. It runs in a customer's controlled environment and provides the key management API called by the CSE-enabled Workspace clients. We have multiple partners providing software implementations of the KACLS API that can be used by our customers. 

At a high level, Workspace client code takes advantage of envelope encryption to encrypt and decrypt the user content on the client with a Data Encryption Key (DEK) and leverage the KACLS to encrypt and decrypt the DEK. In order to provide separation of duty, we use the customer's OpenID Connect (OIDC) IdP to authenticate end-users and provide a JSON Web Token assertion with a claim identifying the user (3P_JWT). For every encryption/decryption request sent to KACLS, the application (e.g. Gmail) provides a JSON Web Token assertion with a claim authorizing the current end-user operation (G_JWT). KACLS validates these authentication and authorization tokens before returning, for example, a decrypted DEK to the user’s client device.

More details on KACLS are available in Google Workspace Encryption Whitepaper and CSE reference API.

How we built CSE into Gmail

Google Workspace Engineering teams have been hard at work over multiple years to deliver to our customers the ability to have their data protected with client-side encryption. This journey required us to work closely with customers and partners to provide a capability that was secure, easy to use, intuitive and easily deployable. It was also important for CSE to work seamlessly across the Workspace products: you can create a Meet CSE scheduled meeting in Calendar CSE and follow-up with Gmail CSE emails containing links to Drive CSE files.

Client-side encryption in Gmail was built with openness and interoperability in mind. The underlying technology being used is S/MIME, an open standard for sending encrypted messages over email. S/MIME is already supported in most enterprise email clients, so users are able to communicate securely, outside of their domain, regardless of what provider the recipient is using to read their mail, without forcing the recipients to log into a proprietary portal. S/MIME uses asymmetric encryption. The public key and the email of each user are included in the user's S/MIME certificate. Similarly to TLS used for HTTPS, each certificate is digitally signed by a chain of certificate authorities up to a broadly trusted root certificate authority. The certificate acts as a virtual business card, enabling anyone getting it to encrypt emails for that user. The user's private keys are kept secure under customer control and are used by users for decryption of incoming emails and digital signature of outgoing emails.

We decided to leverage the CSE paradigm used for Drive CSE and not keep the private key on the device, to keep them as safe as possible. Instead, we extended our KACLS API to support asymmetric encryption and signature operations. This enables our customers to centrally provision and enable S/MIME, on the KACLS, for all their users without having to deploy certificates individually to each user device.

CSE in Gmail uses the end-user's client existing cryptographic functionalities (Web Crypto API for web browsers for instance) to perform local encryption operations and run client-side code to perform all S/MIME message generation.

Now let's cover the detailed user flows:

When sending an email, the Gmail client generates a MIME message, encrypts the message with a random Data Encryption Key (DEK) then uses the recipients' public keys to encrypt the DEK, calls KACLS (with the user authenticated by customer's IdP and authorized by Google) to digitally sign content and finally sends the authenticated and encrypted S/MIME message, which contains both the encrypted email and the encrypted DEK, to Google servers for delivery to the recipients. Below is an animated screenshot showing the user interface of Gmail when using CSE.

                                              

When receiving an email, Gmail will verify that the digital signature of the email is valid and matches the sender's identity, which protects the email against tampering. Gmail will trust digital identities signed by Root CA PKI as well as custom domain configurations. The Gmail client will call KACLS (with the authentication and authorization JWT) to decrypt the email encryption key, then can decrypt the email and render it to the end-user.

How we protect the application

Workspace already uses the latest cryptographic standards to encrypt all data at rest and in transit between its facilities for all services. Additionally, Gmail uses Transport Layer Security (TLS) by default for communication with other email service providers. CSE in Gmail, however, provides an additional layer of protection for sensitive content. The security of Gmail CSE is paramount to us, and we developed new additional mechanisms to ensure CSE content would be locked into a secure container. On the web, we have been leveraging iframe origin isolation, strict postMessage API, and Content Security Policy to protect the user's sensitive data. Those security controls provide multiple layers of safety to ensure that CSE content stays isolated from the rest of the application. See this simplified diagram covering the isolation protecting CSE emails during composition or display.

What’s next for Client-side encryption and why it’s important 

CSE in Gmail uses S/MIME to encrypt and digitally sign emails using public keys supplied by customers, which add an additional level of confidentiality and integrity to emails. This is done with extensive security controls to protect user data confidentiality, but also transparently integrated in Gmail UI to delight our users. However our work is not done, and we are actively partnering with Google Research to further develop client-side capabilities. You can see some of our progress in this field with our presentation at the RSA Security Conference last year where we provided insight into the challenges and the practical strategies to provide advanced capabilities, such as AI-driven phishing protection for CSE.