Google unveils end-to-end messages for Gmail. Only thing is: It’s not true E2EE.
Yes, encryption/decryption occurs on end-user devices, but there’s a catch.
When Google announced Tuesday that end-to-end encrypted messages were coming to Gmail for business users, some people balked, noting it wasn’t true E2EE as the term is known in privacy and security circles. Others wondered precisely how it works under the hood. Here’s a description of what the new service does and doesn’t do, as well as some of the basic security that underpins it.
When Google uses the term E2EE in this context, it means that an email is encrypted inside Chrome, Firefox, or just about any other browser the sender chooses. As the message makes its way to its destination, it remains encrypted and can’t be decrypted until it arrives at its final destination, when it’s decrypted in the recipient’s browser.
Giving S/MIME the heave-ho
The chief selling point of this new service is that it allows government agencies and the businesses that work with them to comply with a raft of security and privacy regulations and at the same time eliminates the massive headaches that have traditionally plagued anyone deploying such regulation-compliant email systems. Up to now, the most common means has been S/MIME, a standard so complex and painful that only the bravest and most well-resourced organizations tend to implement it.
S/MIME requires each sender and receiver to have an X.509 certificate that’s been issued by a certificate authority. Obtaining, distributing, and managing these certificates in a secure manner takes time, money, and coordination. That means that if Bob and Alice have never worked together before and an urgent or unexpected need arises for him to send Alice an encrypted message promptly, they’re out of luck until an admin applies for a certificate and sees that it’s installed on Alice’s machine—so much for flexibility and agility.
Google says that E2EE Gmail abstracts away this complexity. Instead, Bob drafts an email to Alice, clicks a button that turns on the feature, and hits send. Bob’s browser encrypts the message, and sends it to Alice. The message decrypts only after it arrives in Alice’s browser and she authenticates herself.
To make this happen, Bob’s organization deploys what Google says is a lightweight key server, known as a KACL, short for a key access control list. This server, which can be hosted on premises or most cloud services, is where keys are generated and stored. When Bob sends an encrypted message, his browser connects to the key server and obtains an ephemeral symmetric encryption key. Bob’s browser encrypts the message and sends it to Alice, along with a reference key. Alice’s browser uses the reference key to download the symmetric key from the KACL and decrypts the message. The key is then deleted.
To prevent Mallory or another adversary-in-the-middle from obtaining the key, Alice must first authenticate herself through Okta, Ping, or whatever other identity provider, or IDP, Bob’s organization uses. If this is the first time Alice has received a message from Bob’s organization, she will first have to prove to the IDP that she has control of her email address. If Alice plans to receive encrypted emails from Bob’s organization in the future, Alice sets up an account that can be used going forward.
Bob’s organization can add an additional layer of protection by requiring Alice to already have an account on the IDP and authenticate herself through it.
“The idea is that no matter what, at no time and in no way does Gmail ever have the real key. Never,” Julien Duplant, a Google Workspace product manager, told Ars. “And we never have the decrypted content. It’s only happening on that user’s device.”
Now, as to whether this constitutes true E2EE, it likely doesn’t, at least under stricter definitions that are commonly used. To purists, E2EE means that only the sender and the recipient have the means necessary to encrypt and decrypt the message. That’s not the case here, since the people inside Bob’s organization who deployed and manage the KACL have true custody of the key.
In other words, the actual encryption and decryption process occurs on the end-user devices, not on the organization’s server or anywhere else in between. That’s the part that Google says is E2EE. The keys, however, are managed by Bob’s organization. Admins with full access can snoop on the communications at any time.
The mechanism making all of this possible is what Google calls CSE, short for client-side encryption. It provides a simple programming interface that streamlines the process. Until now, CSE worked only with S/MIME. What’s new here is a mechanism for securely sharing a symmetric key between Bob’s organization and Alice or anyone else Bob wants to email.
The new feature is of potential value to organizations that must comply with onerous regulations mandating end-to-end encryption. It most definitely isn’t suitable for consumers or anyone who wants sole control over the messages they send. Privacy advocates, take note.
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82.
