End-to-end encryption (E2EE) is a type of communication system that allows two parties to send and receive information or messages privately, while preventing others from eavesdropping on the conversation – such as hackers, your internet service provider, telecom provider or communication service provider.
That is, only the two parties performing the communication can decipher each other’s messages.
When discussing this topic, there’s often a question asked, “But my information is secured using HTTPS, why do I need to consider advanced encryption systems?” It’s a good question, but not quite an apples-to-apples comparison. E2EE is an encryption system designed to provide privacy between two peers, while HTTPS is a protocol that helps to secure the link or transport communicating over a medium such as the Internet. HTTPS is an extension of HTTP that protects communication over a computer network (or the Internet) and is largely based on Transport Layer Security (TLS), or its predecessor, Secure Sockets Layer (SSL). When you sign on to your bank account or need to assure that your connection remains private, these encryption systems provide the privacy and integrity of the data while in transit.
But what happens when the data arrives at the other end? How do I know with any reasonable certainty that my information remains protected? In a few words – you don’t. Though HTTPS/TLS provide security on the actual link or transport, E2EE systems can provide further means to protect your information while “in flight” and at rest. In a world where hacker sophistication and ability continue to rise, we must take additional measures to protect our information. In the security business, we often ask our clients, “What type of secrets are you protecting? Are they one-hundred-dollar secrets? Are they one-million-dollar secrets?” When you frame the discussion in these terms, it’s not too hard to imagine what someone will do when the rewards are so high. Also, as many security experts indicate, many breaches start with low-tech means such as phishing exercises, or are inside jobs in the first place.
So, how does E2EE further protect my information? First and foremost, E2EE systems help assure that only the two parties communicating are capable of deciphering each other’s messages (information, documents, whatever that may be). However, encryption by itself is not enough. How do I assure the integrity of the information received is intact and free of tampering? This is where E2EE systems shine, and there are several standards that define methods for end-to-end encryption. In this article, I’ll refer to the Elliptic Curve Integrated Encryption Scheme (ECIES). Though this particular scheme is built on EC cryptography, the scheme itself defines methods to not only perform public key cryptography but also enables the intended recipient to validate the contents of the communication. Simply put, we’re not just “encrypting” a payload, but sending a message (or cryptogram) that contains a validation mechanism the receiving party can use to determine if a message has been tampered with. Systems such as Android Pay and others are based on this type of encryption.
How Does ECIES Work?
While the steps and components are outlined in the link above, we’ll provide a simple Alice and Bob example to further illustrate a simple communication between the two.
Alice wishes to send a private communication to Bob. Alice uses Bob’s public key to derive an encryption key (secret) and what’s known as a message authentication code or MAC. Alice encrypts the data using a symmetric cipher (such as AES) and also generates a message authentication code for the message. Alice then sends the derived secret, the encrypted payload, and the MAC to Bob. Bob then uses the derived secret to decrypt the encrypted payload, and uses the MAC to validate that the contents have not been tampered with.
Assuming Bob’s private key is kept private, ECIES is designed to function over an unsecured channel and only Bob can decipher the cryptogram. This means that at any point in between (internet service provider, telecom provider, service provider, ect.) the information cannot be deciphered.
Once the information arrives in Bob’s hands, he will use his private key to not only decrypt the information payload but he also validates the cryptogram in its entirety. If any of the information does not match, the cryptogram (message) is considered to be invalid.
Why ECIES Matters
While E2EE systems can provide a greater level of private communication, our job of ensuring security is not over simply knowing that Alice can lob an encrypted “softball” over to Bob. Though using such systems can help to assure privacy between two endpoints in a given system, what happens to the information that has arrived on the receiving end? Software makers must take additional precautions to protect their private keys and prevent tampering with local system resources once information is received and stored. For example, in a recent dialogue with a copier manufacturer, we were advised of security studies where random office equipment was pulled from a junkyard and copier hard drives were extracted. There, in full detail, sensitive medical documents were stored on the hard drive that were once printed.
It’s just another lesson that building privacy is not just about the encryption, but also the proper use of these cryptographic systems and handling sensitive information.
ABOUT THE AUTHOR
As CTO of etherFAX, Cichielo is responsible for the company’s technology road map, security and governance policies, patents, and intellectual property related matters. Cichielo holds many patents in the field of telecommunications, image recognition, and highly sophisticated encryption systems.