Hop-by-hop vs. end-to-end encryption
An important property of any collaboration platform is confidentiality. Collaboration systems transport and store large volumes of personal communications, most of which bear critical expectations of privacy and are a high-value target for bad actors. If a collaboration platform fails to protect the confidentiality of these communications, the consequences for users and organizations that rely on that platform can be significant.
In this blog I’ll present and compare two general strategies for implementing confidentiality assurances in a collaboration platform:
- Hop-by-hop encryption describes a class of solutions composed of discrete data-path hops, each of which is secured through either encryption at-rest, or encryption in-transit.
- End-to-end encryption describes a class of solutions characterized by the encryption of data by its producer, decryption by its intended consumer, and the practical impossibility of decrypting that data at any point along the path from one to the other.
I’ll highlight the intrinsic advantages of an end-to-end encryption based solution.
Hop-by-hop encryption
Hop-by-hop encryption combines the common practices of encryption in-transit and encryption at-rest. The former guards against data exposure on the network, and the latter secures data from attacks on storage media. Industry standards and broadly validated implementations of these are publicly available and generally straightforward to leverage (e.g. TLS is a ubiquitous example of encryption in-transit). Below we illustrate how encryption in-transit and encryption at-rest can be used together to secure user data in a simplified example of a fictional messaging platform, example.com.
Fig. 1: hop-by-hop encryption
In fig. 1 we show a user, Alice, sending a message to another user, Bob, via the example.com service. The transmission of this message is composed of three hops: two that are secured by encryption in-transit and one that is secured by encryption at-rest.
In the first hop, Alice’s message “Hi Bob” is delivered over the internet from her client to server A. We illustrate this as a message within a blue circle and lock to show that it is encrypted over the network path of hop one. This is an example of encryption in-transit because data is encrypted by the client before it is delivered to the network, and decrypted by server when it is received from the network.
We will assume that example.com offers persistent messaging, and that server A stores Alice’s message to a database of some sort. To protect Alice’s message from exposure in the event of a storage media attack, the message is encrypted by server A before it is written to disk and decrypted by server B after it is read from disk. This is represented in the figure as a message within an orange circle and lock to show that it is being stored in an encrypted form. This second hop is an example of encryption at-rest.
In the third and final hop, Alice’s message is delivered over the internet from server B to Bob’s client. This is another example of encryption in-transit since the message is encrypted by server B before it is written to the network, and decrypted by Bob’s client upon receiving it from the network. Note that, although we represent this again as a message within a blue circle and lock, the actual encryption key is different than that used in the first hop.
In summary, when a strategy for protecting the confidentiality of user data is based on common mechanisms for encryption in-transit and encryption at-rest, the result is a series of independently secured hops. Different keys are used to secure each hop, and each server along the path holds a key for each of its adjacent hops. In general, this sort of strategy provides substantial protections from a wide variety of attack vectors.
But there remains a gap.
Mind the Gap
A fundamental limitation of the hop-by-hop encryption strategy described above is that every server involved in transmitting messages must bridge a confidentiality gap. That is, every server in a message’s path through example.com will engage in decrypting, then re-encrypting, that message. For instance, if we take a closer look at what is happening inside server A of the previous example, we see it is doing something like fig. 2.
Fig. 2: The Privacy Gap of hop-by-hop encryption
Here server A is receiving a message that is encrypted with the in-transit key of the first hop. The message must first be decrypted with that key before it can then be re-encrypted using the at-rest key of the second hop. This means that server A must hold in memory, at least for a short time, the cleartext content of Alice’s message. An attacker with sufficient privileges on this server can therefore read Alice’s message.
One can see that although hop-by-hop encryption can be effective in securing messages from network and storage attacks, it is insufficient in the context of an attack on the compute resources through which messages pass. To be fair, it is common to regard this sort of attack as an acceptable risk since there are normally other safeguards to prevent such unauthorized access from occurring. Bear in mind, though, that a collaboration platform of any meaningful scale will have compute resources in the thousands, and that an attacker need only breach one of these in order to compromise the confidentiality of any number of that platform’s users.
Fig. 3: hop-to-hop encryption gaps are pervasive
For example, lets assume a more realistic deployment, where a given message might traverse many hops across a large system. While the ten hops of the path illustrated in fig. 3 may seem contrived, when you take into account all of the application servers, load-balancers, firewalls, reverse-proxies, database servers, NASes, message brokers, replication services, and other compute resources that can be found in the path of a message transiting a large collaboration platform, it is actually not far from practice.
With the above in mind, consider that every compute node along the path of a given message presents a confidentiality risk for that message, and any single compromised node in the system can potentially expose every message that traverses it. Despite the fact that messages are well secured as they transit each network arc, and are encrypted while stored to persistent media, they remain vulnerable to attacks that leverage even a very limited compromise of the overall system compute resources.
End-to-end encryption
End-to-end encryption addresses the gaps that emerge from the hop-by-hop encryption strategy by establishing a private channel that extends the full path from sender to intended recipients. There are a variety of ways to accomplish end-to-end encryption. One strategy is to build an end-to-end secure channel over the top of a hop-by-hop encryption foundation.
Fig. 4: End-to-end encryption
For example, as illustrated in fig. 4, Alice’s client may first encrypt her message end-to-end (green lock) before encrypting it a second time in-transit (blue lock). Unlike the key (blue) used for in-transit encryption, however, the end-to-end key (green) is known only to Alice and her intended recipient, Bob. As shown above, The end-to-end encrypted message makes its way through the collaboration platform just as an ordinary message would in a hop-by-hop encryption flow, being variously encrypted in-transit and at-rest as it goes.
Fig. 5: Gap-less privacy
However, if we look inside server A this time, we see something different from before. When server A receives Alice’s message, it decrypts the message with the in-transit key (blue), but the message remains encrypted with Alice’s end-to-end key as it is then re-encrypted with the at-rest key (orange). Unlike what we saw with purely hop-by-hop encryption, the original message is not, and actually cannot be, exposed as cleartext within server A. An attacker with even full root and physical access to this server and its database will have no practical means to compromise the confidentiality of this message.
Fig. 6: hop-to-hop encryption gaps are mitigated
Stepping back to consider the implications at a system level, we can see that, regardless of the scale and complexity of the service, end-to-end encryption provides seamless confidentiality throughout. At every transition between in-transit and at-rest encryption, the original message remains encrypted with at least the end-to-end key.
Closing the gap
From the above, we may draw some general conclusions on the relative merits of hop-by-hop and end-to-end encryption strategies for securing user data. On the one hand, hop-by-hop encryption is relatively straightforward and easy to employ. It doesn’t require much more than the adoption of well-established existing mechanisms for securing data over networks and in storage. The almost trivial effort required to provide these protections belie their value, though, as encryption in-transit and at-rest guard against many of the most common attack vectors.
Fig. 7: End-to-end encryption vs hop-by-hop encryption
End-to-end encryption on the other hand, provides all the protections of hop-by-hop encryption but with significant additional safeguards. First and foremost, it closes the pervasive confidentiality gap of hop-by-hop encryption by securing user data from attacks on compute resources. Second, it exemplifies the Principle of Least Privilege (POLP) by providing a cryptographic means for limiting user data access to only those with explicit authorization. Finally, the combination of hop-by-hop encryption, and end-to-end encryption, provides Defense in Depth (DiD) where a successful attack at one layer may be mitigated by the other.
Up Next
For the sake of clarity, we have eschewed discussion of several technical considerations in order to highlight fundamental distinctions between the general approaches of hop-by-hop and end-to-end encryption. Among these considerations are the means by which clients create and exchange end-to-end encryption keys securely, and how server-side cleartext processing functions (such as search or transcoding) may be supported as fully visible opt-in features of an end-to-end encrypted service. These are great topics for further discussion. Posts dedicated to these subjects are soon to come.
Related resources:
To learn more about Cisco collaboration and security APIs and platforms visit:
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
Great article Andrew! Thanks for sharing this information.