Securing Data in Motion

In the past we’ve talked about how the security and privacy landscape have changed over the past few years. Today we’d like to talk about how data in motion is the next frontier, something that we’ve been working on across all the things we’ve built at INVISV.

Encryption is a solved problem

There are lots of security and privacy challenges that persist today not because there aren’t solutions to them but because those solutions aren’t implemented widely, following best practices, economically, and usably. Ubiquitous end-to-end encryption, encryption at rest, authenticated encryption, and related standard approaches for ensuring data confidentiality are widely known and increasingly used. So when we say that encryption is a solved problem, we mean that we’re nearing the point at which everyone has implemented best practices and a lack of encryption is no longer the cause of breach of confidentiality.

Encryption will of course continue to evolve: quantum computing will lead to changes in asymmetric cryptographic primitives that we depend upon for key agreement, new attacks against protocols and mechanisms will force algorithm adaptation and mitigation, and new implementations and hardware support will shift the balance to favor some techniques and algorithms over others. However, the need for and the use of encryption in the context of data at rest and for confidentiality is known and not likely to change: we know what we need to do, and we all just need to keep on doing it.

Enclaves secure data during computation

The frontier shifted a few years ago to securing the computation itself: what good does it do us if we can get our data securely to the cloud only to have it be insecure while we actually do anything with it while it’s there? Into this gap stepped the hardware companies, with several variations of trusted computing hardware that can perform more-or-less general-purpose computation on data in a manner that protects the data and computational results from the cloud provider itself. These secure enclaves or trusted execution environments (TEEs) are now widely available in all major clouds and are increasingly common on consumer-grade hardware (even phones). While making a TEE actually secure is an ongoing challenge for hardware manufacturers – with a constant trickle of side-channel attacks from security researchers leading to partial or even full breaks of popular TEEs – it’s now possible for most computation in the cloud to be partially secured using a TEE with minimal performance penalty.

Homomorphic encryption, secure multi-party computation, federated learning

In parallel with the hardware-security approach embodied in TEEs, researchers have been chasing a long-sought dream: secure computation via new cryptographic techniques such as homomorphic encryption and more esoteric ones such as indistinguishability obfuscation promise to place no trust in hardware or hardware vendors, relying upon only well-studied hardness results for their security. Related work has long proceeded on secure multi-party computation and federated learning, each aiming to secure specific types of computation between multiple mutually-distrustful parties that wish to compute a shared computational result over privately-held data.

These techniques are likely to prove valuable in narrow contexts where an efficient algorithm for a specific computation has been developed, and where there are standard implementations available. However, at least today, these are rare in practice, and difficult to plan around for general-purpose secure software development.

What’s next: data in motion

Our focus at INVISV for the last year has been showing how to secure data in motion. We used to exclusively describe this as a matter of privacy, but privacy and security are one and the same as we’ve discussed here in previous posts and there’s a need to think about them together.

Cloud providers are a breach risk

Securing data in motion means ensuring that data and metadata remain confidential while in transit and in use – all data and metadata. This is vastly more complex due to the proliferation of cloud services, which we all now use for everything we do, every system we build, and every device we touch. And because of this it’s not enough to just encrypt it – that doesn’t protect it from the cloud provider, just from ISPs in transit. Instead, we need to ensure that cloud providers can do their jobs without having sensitive data.

Another way to look at data in motion is to think: what would an organization’s or individual’s risk profile be if they were to run all their own services, on premises? Now, take that same risk profile, gain the benefits of the cloud, and introduce no new security and privacy risks from the cloud service. That’s what’s required when securing data in motion.

Today’s cloud providers are a breach risk for organizations and individuals. And it’s not a single cloud – most organizations have their data scattered across dozens of cloud providers, each of which has a window into their most sensitive inner workings.

Decoupling and securing data in motion

The data and metadata to be secured takes a huge number of forms: from something as mundane as Internet traffic – which we protect with INVISV Relay – to application data and metadata – which we protect in specific contexts, such as with Booth video conferencing – to authentication requests – which we protect with oblivious authentication (such as used in PGPP).

In each case, data and metadata that would have been revealed to the cloud provider (in these cases, us and other network providers) is architecturally decoupled so we as a service provider can deliver the high-performance service users expect without learning anything sensitive.

We think this is the way all cloud services should be built going forward, providing breach resistance and providing the security and privacy organizations and users deserve by securing data in motion.