Users talking to one another in an end-to-end encrypted system should be the only ones that know what they are talking about and that is exactly how it is often portrayed. Time and time again this understanding or principle is stretched thin and our rights are ignored or deemed "not relevant". People have the right to data privacy as defined in international human rights law, and within the right to free expression and to hold opinions is inferred the right to whisper, whether or not they are using digital communications or walking through a field.
Very often, people state that states or providers are trustworthy, and yet, while "trustworthy" can be defined in law, practice,, and understanding it is my opinion that to be "completely trustworthy" if and only if it is: completely resilient, reliable, accountable, and secure in a way that consistently meets users' expectations.
A Systems Design Perspective
An end-to-end encrypted communication system
is when the provider of the set of functions needed by two or more parties to communicate among each other in a confidential, authenticated, and integrity-preserving fashion without any other or third party having access to the content (including relevant metadata) of that communication where the functions that offer the confidentiality, authenticity, and integrity-preservation are providing these services to only the participants whom all know who are in the conversation.
Intentional compromises of end-to-end encryption are usually referred to as "backdoors" but are often presented as additional "design features" under terms like "key escrow" or facilitation of key management like "Customer Managed Encryption Key" ("CMEK") or "Bring Your Own Key" ("BYOK") for the ease of service. Users of end-to-end encryption would not expect a front, back, or side door entrance into their confidential conversations. For the purpose of this writing let us introduce an additional set of definitions: "Hold Your Own Key" ("HYOK") and "Share Your Own Key" ("SYOK") or "Trust Your Provider Encryption Key" ("TYPEK"). For the avoidance of doubt, let us sum them up: (I am currently finishing my thesis which I started many years ago depicting and explaining these. I will be posting excerpts of this later.)
| Term | Abbrev. | Description | Privacy |
|---|---|---|---|
| Trust Your Provider Encryption Key | TYPEK | The platform provided and created key often used as "tenant-isolation" for means of data-at-rest protection of other resources. Such resources can include key material, data, and others. Sometimes called tenant or default key. | None/ Low |
| Customer Managed Encryption Key | CMEK | Consuming parties' or vendors' usage of platform services where the platform provides the key generation, key protection, etc, and the CryptoPeriod responsibilities for you. This is required in every "last-scope" processing perspective of your slice. Otherwise, it defaults back to "TYPEK"-scenario and strength. | Medium |
| Share Your Own Key | SYOK | You create your own key and share it with the provider and or platform. Usually doing this for the sake of ensuring the quality and entropy of the Customer Managed Encryption Key protecting any Data-Encryption-Keys (DEK's). By definition, this means that the provider or platform will use this key, and is no-longer a secret. | Medium |
| Bring Your Own Key | BYOK | You create your own key and make choices about how to use it. The second the key is unprotected within the provider's platform, you should consider it as "shared" or "compromised" or "designed security level". | Low/ Medium |
| Hold Your Own Key | HYOK | You have created and hold your own key. The key is and never has been in the possession of the provider. This is cost and operation-heavy and relies on manual interaction, especially in the case of SaaS and other means. | High |
The strength is relying on the nature of implemented processes and functionality chosen. When using designed platform services, one is to verify the security and legal frameworks of the capabilities and responsibilities. For most use-cases, using platform services will result in higher security strength but not from a compliance and regulatory perspective in the cases where the law is questionable. EDPB has a good resource explaining such criteria here.
End-to-end encryption, irrespective of the content or the specific methods employed, relies on two important and rigorous technical concepts:
- The end-to-end principle and encryption, an application of cryptographic mechanisms to secure internet protocols and maintain the privacy of content delivered via these internet protocols.
- That end-to-end encryption is comprised of these necessary constituent parts, and a systems approach also defines their interplay.
In any of the situations, when anyone shares their Private Key and no longer "Holds their own key" or transmits their Data-Encryption-Key (DEK) unprotected using such, the system of End-to-End-Encryption is no longer. It can be better conveyed and construed as the recipient and sender are no longer "ultimately" protected and weaknesses are in play.
Legal Perspective
The most crucial factor and consideration in Data Protection Regulation and Data Protection By Design & By Default perspectives is the role and responsibilities of the service providers, the interaction with culture, regime, regulation, public authorities, local law enforcement, and other agencies. These weaknesses are sometimes required by law which completely destroys E2EE as a principle.
From a legal point of view, End-to-End encryption services offered are only viable and an effective measure if:
- The law prevents providers from infringing access to data held by that recipient for the given purpose, e.g. by virtue of a duty to professional secrecy applying to the provider,
- That exemption extends to all information in the possession of the provider that may be used to circumvent the protection of privileged information (cryptographic keys, passwords, other
- credentials, etc.).
- The provider does not employ the services in a way that allows the public authorities to access the data while held by them, nor do they forward the data to anyone else. (For example by means of adding additional recipients)
- The data is encrypted before it is transmitted with a method conforming to the state of the art guaranteeing that decryption will not be possible without knowledge of the decryption key
- (end-to-end encryption) for the whole length of time, the data needs to be protected,
- The decryption key is in the sole custody of the recipient, and appropriately secured against unauthorized use or disclosure by measures conforming to the state-of-the-art, and
- The provider has reliably established; that the sender's encryption key it relies on when it comes to the use, corresponds to the decryption key held by the recipient, ideally using a system relying on the principles of Perfect Forward Secrecy or Zero Knowledge-Proof.
It is important to note it is the end-users responsibility to protect their device and key material, however, if services are being offered in such a way, like software taking care of this on your behalf using your device's capabilities...
But when is it not ok then? Well let me sum up some of the aspects that would violate it by default:
- The law allows providers to alter the code or are able to alter the list of recipients
- The providers work together with public authorities and are capable of changing the list of recipients henceforth removing the integrity of such
- The provider is capable of downgrading strength, exporting key-material, or introducing other defects
- There is data that should be protected from an end-user perspective, being sent in the clear within provider services.
Final words
End-to-End Encryption E2EE, today, refers to End-user to End-user Encryption where the respective individuals have full control over their own keys in a "Hold-Your-Own-Key"-scenario or in a way where a process is protecting your key. However, any scenario where you "Bring-Your-Own-Key" and "Share-Your-Own-Key" that is not protected with the use of "Hold-Your-Own-Key" is ultimately flawed but for the sake of User-Experience and common onboarding could be a design that is acceptable.
In such UA/UX-design cases, there must be a legal framework ultimately protecting the users, but such frameworks are always flawed. If at any given time, the protected data or the key material, is processed or the process of such protection can be altered by the provider, the system is inherently flawed and should not receive the stamp of an E2EE-safe system. Data-Encryption-Keys (DEKs) should be using Perfect Forward Secrecy when it comes to messaging or similar which ensures that for the duration of a session whether online or offline, rely on the principle of "Hold-Your-Own-Key".