Kasten K10 and End-to-End Security

End-to-End Encryption, huh, yeah!
What is it good for?
Absolutely everything!
Say it again y’all!
Sung to the tune of War (What Is It Good For). Apologies to Edwin Starr.

The current COVID-19 climate we all find ourselves in has led to an explosive growth of video conferencing services like Zoom, that I have to admit has outpaced cloud-native growth (well, at least in the short term). However, this growth has also brought greater visibility and has placed Zoom’s privacy and security practices under increased scrutiny. They have recently found themselves in hot water due to advertising but not really implementing “end-to-end encryption.” 

The term End-to-End Encryption (E2EE) is often misused by marketing departments as people often conflate it with “transport encryption.” It is important for us to understand what these terms truly mean. In the context of what we are doing at Kasten for secure cloud-native backup and recovery, this post will dig into why transport encryption (e.g., using TLS) isn’t always enough and how we actually meet the technical definition of “end-to-end” to ensure that our customers' data is always protected.

End-to-End Encryption

End-to-end encryption, when implemented correctly, allows for secure communication where only the sender and receiver can read messages. Senders and receivers could be people, phones, computers, or basically any other communication device. What this means is that your data will be safe from prying and modification from Internet providers, cellular companies, or anyone in the middle that might be acting as a carrier for your messages. Even if there is an intermediary that stores this message for asynchronous transmission, they will not be able to read the contents of your message.

In contrast, with transport encryption (such as you sending a message on a chat network), your messages are usually only encrypted between hops. So, the message will be encrypted from your phone or computer to the messaging server but it can, and often will be, decrypted there before it is received by the intended recipient. This practice has clear risk as  any messaging server that is compromised will reveal sensitive information, and may obligate compliance for governments to subpoena your messages and records.

So, what did Zoom do wrong? In essence, they advertised end-to-end encryption support but really only provided transport encryption. The Internet connection established between Zoom running on your computer and their servers used the same encryption your browser uses to connect to your favorite shopping sites. If Zoom wants to, your video stream can be viewed, recorded, or even modified at this stage before it is sent over to whoever you are on a Zoom call with.

Kasten K10 and End-to-End Encryption

As some of you are already aware, the K10 Data Management Platform, our flagship product, is purpose-built for Kubernetes. Given that we provide enterprise operations teams an easy-to-use, scalable, and secure system for backup/restore, mobility, and disaster recovery of Kubernetes applications, encryption whenever backup data is stored outside of the Kubernetes cluster fault domain is a very big deal for us. There are multiple levels of encryption to ensure that our customer’s data is always encrypted, at rest and in-flight.

First, K10 does use transport security to ensure that data in-flight is always encrypted. The most traversed data path outside of Kubernetes for K10 is moving data and metadata to an object store for backup storage. TLS certificate verification is performed to ensure that man-in-the-middle attacks are not possible. The data being transferred is itself encrypted using AES-256-GCM before it hits the wire. While not absolutely required, K10 also does not use a single master key for all data but instead has a separate encryption key per application.

More concretely, we will examine how K10 uses encryption for our three major use cases: Backup, Application Mobility, and Disaster Recovery.

Backup and Disaster Recovery: For backup and disaster recovery within the cluster, K10 is both the sender and, later during a restore operation, the receiver. Encryption keys are always stored within the Kubernetes cluster and never shared or stored with the object storage location. This secure transfer process meets the definition of “end-to-end encryption”: data is encrypted both during transit and at rest, and the intermediate object storage system will never be able to view the data.

Application Mobility: When moving applications across clusters, there are two separate instances of K10 that act as the sender or receiver of application data and metadata. An object store is used as an intermediary to store application restore points and, like the backup and restore scenario, it only sees encrypted data and never plaintext. When the receiving cluster needs to read this data in, there is an out-of-band exchange mechanism used where a top-level encryption key that is only valid for this application (called the migration key) is used to decrypt the required data. This secure transfer process again meets the definition of “end-to-end encryption”: data is encrypted both during transit and at rest, and the intermediate  object storage system will never be able to view the data.

Conclusion

The above article shows the importance of end-to-end encryption and its particular relevance to data protection workflows. However, encryption is just one of the components of Kasten K10’s security features. To secure your data, we also provide a number of features for authentication (OIDC, Token-based authentication, etc.), fine-grained Role Based Access Control (RBAC), IAM support, cloud KMS integration, support for Customer Managed Encryption Keys (CMEKs), API use auditing, and much more!

We encourage you to give the product a try for FREE no sign-up needed, and let us know how we can help. We look forward to hearing from you!