What are the similarities and differences between Google's recently announced client-side encryption and Tresorit's end-to-end encryption?

These days, Google announced the integration of new encryption controls, which “will put data encryption in customers’ hands and will be rolled out for beta testing by customers in the coming weeks”. What sounds like a regular product update, represents a big step towards aiming to give companies more control over their data from Google’s side – a big step towards data security!

But is this control enough for highly confidential data of enterprises, though? Let’s take a closer look at what Google has just announced, and what it means for organizations looking for ultimate data protection.

Little more than 1,5 half years ago, when Google announced their new data security mechanisms for customer-managed and customer-supplied encryption keys, we did an analysis on the actual level of security they guarantee. With the introduction of client-side encryption yesterday, they have addressed many of the shortcomings of those solutions.

First of all, there are no universally accepted definitions of client-side encryption, nor end-to-end encryption, so we're going to focus on what Google calls client-side encryption and what Tresorit considers as true end-to-end encryption.

Google states in their “Google Workspaces admin guide”:
"With end-to-end encryption (e2e), encryption and decryption always occur on the source and destination devices (such as on mobile phones for instant messaging). Encryption keys are generated on the client, so as an administrator, you don't have control over the keys on the clients and who can use them. In addition, you don't have visibility into which documents users have encrypted.

With client-side encryption (CSE), encryption and decryption also always occur on the source and destination devices, which in this case are the clients' browsers. However, clients use encryption keys that are generated and stored in a cloud-based key management service, so you can control the keys and who has access to them. For example, you can revoke a user's access to keys, even if that user generated them. Also, with CSE, you can monitor users' encrypted files."

As many details of Google's implementation are unclear at this point (such as where the encryption keys are generated and transferred), we can only take for granted some elements that are documented.

Similarities between the technologies:

• Encryption and decryption of file contents are done on the client-side, in the case of Google within the web browser. Only already encrypted documents are transferred to Google Workspace for storage. This is a great step towards ensuring privacy!
• The encryption keys for the actual documents are stored in an encrypted format, they are inaccessible for the cloud storage provider.
• The privacy takes its toll on some of the convenience features, such as full-text search, spell check, simultaneous co-editing, document previews, etc. as these features are implemented with heavy server-side support.

In contrary what Google states, administrator control of the keys and insights into the encrypted contents of the users are also possible with end-to-end encryption (that's what Tresorit's Advanced Control feature is all about), although it's a bit more complicated.

Differences between the technologies:

• In the case of true end-to-end encryption, encryption keys are generated, derived, manipulated, encrypted, and decrypted entirely on the client-side. Encryption keys are never leaving the user's device in an intelligible form.

  With client-side encryption, the encryption keys of the documents are sent   over the internet to a third party Key Management Service that will encrypt   or decrypt them before they are used on the client-side. This transfer of keys   introduces new weaknesses and poses further security risks.

• With end-to-end encryption you can safely rely on the same cloud storage provider to store your encrypted keys and data as they are completely opaque to the provider.

  In order to prevent the isolation of data from encryption keys at the cloud   storage provider, you need to use a separate service for key management (the   providers used by Google are named in their announcement). Even if you will   be able to implement your own in-house key management service in the    future, this introduces extra hassles, compliance issues, and extra costs.

• Although the difference between these technologies does not imply this directly, we think that file names are just as an important part of the customers' private documents as their contents. Therefore, we also protect them with end-to-end encryption, while this is not the case with Google's CSE.
• How the introduction of CSE changes the way of file sharing, especially via links, and how it works in Google Workspace is not covered in any documentation. Sharing options with anonymous access most probably won't work, as authentication towards the KMS is needed. However, it is possible with E2EE. [It's worth mentioning that all Tresorit’s content security measures such as expiration date, watermarking, print and download prevention, expiration and detailed access logs are all available in Tresorit - although this is in fact unrelated to the encryption technology.]

It is what it is: the more people who can access your file content, the higher the risk that it will be compromised – whether accidentally or deliberately.

Tresorit, for example, employs end-to-end encryption which means that the entire transmission route is protected, which removes the possibilities for any weak points or backdoors. Coupled with our zero-knowledge principle, our solution guarantees that nobody can access your data, not even Tresorit's developers. Client-side encryption ensures that no file can leave the user’s device in unencrypted format and that they are only decrypted after reaching the user's device. This is at least the first leap towards greater data privacy.

Additional Q&As

Are the new client-side encryption features different from what Google has already had on their Cloud platform?

As we explained in our blog, Google has already had some options for third-party key management for enterprise customers, but it basically meant that Google let customers/third-parties encrypt their data on the client-side, however, customers still had to hand over their keys to Google without knowing how Google handles them. We cannot see completely clear at this point how the keys are generated and managed with CSE. From what we already know, there are similarities, and we assume it indeed originates from that technology. The encryption keys are wrapped and coming from a different entity to where the data is stored. The keys are only decrypted when in use.

On the other hand, their previous solution was not employing client-side encryption, the keys were used on the server-side. Client-side encryption is a huge step forward to protecting the user's privacy. The other difference is that now higher level of security is added to user-facing products like Docs, and not just for vendors and developers of Google Cloud.

Will Google still be able to access customer content stored in Workspace apps with client-side encryption?

As we explained above, the announced new options do not give you full control over the confidentiality of your data. They only give a certain level of control over your encryption keys. The ultimate problem with them is that in each case, decryption of your data happens on Google’s servers, and in the moment you hand over your key to Google, they can access your data. But: this is not 100% clear yet. If we rely on their announcement and documentation, we must assume that they will not be able to access customer content anymore. The processing of content has moved from the server-side to the client-side, thus, the keys can bypass Google's storage servers. However, they cannot bypass the key management service. This is the reason why Google relies on partners on this regards. It’s going to be really interesting later in the year when Google publishes more details on their API that will allow enterprise customers build their own in-house key service, allowing workplaces to retain direct control of their encryption keys.

Learn more about Tresorit Content Shield, our comprehensive security offering for enterprises.