Let’s talk end-to-end encryption…

Recently there is a heightened interest in End-to-End encryption (E2EE), owning to the fact that popular messaging service providers are racing to employ it. WhatsApp rolled it out in 2016, iMessage in 2019 and Android in 2020. Simply put, E2EE is a method where the communication between any two devices is secured by the devices and not by the service providers. Why is it important, you ask? Because now, even the service providers such as WhatsApp, cannot access user messages. The keys that encrypt each message, are generated and stored on the end device, outside of the control of the service providers. This not only provides users with the peace of mind, but also alleviates liability for the service providers. Remember the FBI-Apple encryption dispute? Service providers cannot be forced to reveal something that they do not know.

At first glance, E2EE may seem like an old wine in a new bottle, but it is so much more. It is a paradigm shift in how we understand and employ encryption to secure our communications. So much so that the widely used terminologies today are not sufficient to effectively discuss E2EE. Take a read through the several articles discussing E2EE by well-known authors. There is a vast inconsistency in how terms like encryption-at-rest and encryption-in-transit are used to describe E2EE. This post will underline why the standard security terminology lacks in richness to effectively describe new ideas, leading to such ambiguity.

Digital data have a life cycle through which it needs to be protected. This lifecycle is broadly classified under three stages: in-transit, at-rest and in-use.

• Encryption-in-transit is when the data are made unintelligible during transit between two services. This is to primarily protect data’s integrity and confidentiality.
• Encryption-at-rest is when the data is encrypted while it is stored. This protects the data against exfiltration.
• Encryption-in-use is when the data are encrypted while being used by a service. For instance, homomorphic encryption.

These terms work astonishingly well for discussing service providers that control all the encryption operations. However, their use quickly becomes ambiguous when point of encryption is moved further out towards the end user. Consider the following two scenarios,

• When WhatsApp backup service is used, users forgo E2EE. It is a natural choice. If a user device is lost and all encryption keys are lost with it, what good will the backup be if it is encrypted with those lost keys? To fully understand this scenario, we need to ask further questions:
  — Are the messages encrypted-in-transit? Yes. Both on the server and the client sides.
  — Are the messages encrypted-at-rest on server-side? Yes. WhatsApp uses iCloud which provides encryption-at-rest. The point to note is that WhatsApp owns and manages the keys used for encryption-at-rest during backup.
  — Are the messages encrypted-at-rest on the client-side? No.
  — Are the messages encrypted-in-use? No. Neither on the server, nor on the client side.
• Auto-download under WhatsApp settings, is disabled on an end device. A message is sent to this device, encrypted with the device’s key. Because the message is a GIF, it does not automatically download to the device. Instead, it is cached on the server until the user downloads it. Let’s reiterate through the questions above:
  — Are the messages encrypted-in-transit? Yes. Both on the server and the client sides.
  — Are the messages encrypted-at-rest on the server-side? Yes. But it is significantly better that the encryption-at-rest in the previous case. If the entire WhatsApp server is compromised (including all the keys on the server), the cached message will still be safe. In an alternate scenario, if the keys on the device are compromised, only the cached message is at risk.
  — Are the messages encrypted-at-rest on the client-side? No.
  — Are the messages encrypted-in-use? Yes, only on the server-side. WhatsApp in a sense is just using the data and is not actively managing it.

This is what leads to the confusion where the older terminology soon become inadequate to meaningfully communicate these intricate differences. When it comes to E2EE, every author chooses a vantage point (either the client or the server side) and uses the language that suits the view. Security experts often do a good job of describing these differences by combining or improving on these standard terms with lots of supplementary context. However, it is likely to become a constant source of confusion for those that work on the periphery of security domain.

What we need is a rethinking of standard security terminology in the light of this evolving landscape so important context is not lost in these nascent conversations.