(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

June 20, 2018 Comments closed

New Runtime Encryption solutions emerging to fill “Encryption Gaps”

in Everything Encryption

New hardware and software runtime encryption solutions will address encryption gaps

A few years ago, before “Blockchain” and “Quantum” became business’ favorite buzzwords, the Cloud was all the rage. Today we’re well past the point of hype, cloud environments are ubiquitous. And while conventional wisdom used to hold that you should run apps client-side and only use the cloud for storage, that’s archaic nowadays with cloud-based applications becoming more and more prevalent.

Unfortunately, that opens up an attack vector. More and more companies are realizing they need to encrypt data at rest. And starting in July it will be mandatory for everyone to encrypt data in transit. But even if you do both, there are still exploitable encryption gaps.

For a cloud-based application to work it has to be able to read data in plaintext. This represents an encryption gap. Traditionally you would run the app on the client side, which at least gives you a degree of control over its security. But with cloud-based apps, if an attacker or a rogue employee can gain access to the app’s environment they can read the data. If you’ll recall the recent Spectre and Meltdown vulnerabilities – they both exploited similar attack vectors.

How do you fill in the Encryption Gaps?

There has been a lot of work put into fixing these gaps on both the hardware and software side. So far Google, Microsoft and IBM have runtime encryption solutions in varying stages of completion and a slew of start-ups are also working to address the issue in a more specific scope.

Let’s take a look at some of the different solutions that are being proposed.

---

Hardware: Secure Enclaves

Let’s start with a quick definition of Secure Enclave. Probably the most popular example of a Secure Enclave is what Apple uses on its mobile devices. It’s a co-processor of the device’s ARM CPU and it’s responsible for storing critical authentication and payment information. Most importantly, it remains secure even if the iOS kernel has been hacked.

“The enclave is not available to the operating system,” says Ambuj Kumar, co-founder and CEO at Fortanix. “If you find a zero-day bug in the operating system, the enclave is secure. If you have a malicious insider with access to the system, the enclave is secure. If you have a physical attacker who is able to get into all my memory, that still does not break runtime encryption because the enclaves are embedded in the CPU.”

With a Secure Enclave, encrypted data goes into the enclave where it’s decrypted and processed before being encrypted again on the way out. Again, everything is happening on the hardware, specifically on the chip, so the encryption is faster and more reliable than if it were software-based.

There are also solutions being made for the chips that facilitate cloud computing. Intel calls its solution “Software Guardian Extensions” or “Intel SGX.” ARM’s is TrustZone and AMD calls it Secure Execution Environment.

There are a few drawbacks though. For one, space is limited in a Secure Enclave so there’s a possibility for processing delays. Additionally, not every Secure Enclave is compatible with every environment. This form of the technology is still in its early phase with multiple parties vying for supremacy. It may take a little bit of time for a leader to emerge and then most other platforms will adapt.

There is also research that has found a Spectre-like exploit with Intel SGX, that can make unencrypted data in the enclave readable. Suffice it to say the industry is still working out some kinks.

---

Software: Homomorphic Encryption

The aim of most software-based solutions is to do as much work as possible without having to decrypt anything. One way to do that is with Homomorphic Encryption. Using homomorphic encryption allows calculations and searches to be made without decrypting the data. The downside is it comes at the expense of speed.

Homomorphic encryption is actually very old. Well, in internet years that is. You can date it all the way back to 1978. It’s made a comeback because some security experts see a use case in securing cloud apps. In 2009, IBM’s Craig Gentry created the first fully-homomorphic encryption scheme. Prior to that the best anyone could do was to create partially homomorphic schemes that allowed for limited computing of encrypted data.

Gentry described the new system as “one of those boxes with the gloves that are used to handle toxic chemicals…All the manipulation happens inside the box, and the chemicals are never exposed to the outside world.”

[For the record, that contraption has cleverly been named a “glovebox.”]

Using homomorphic encryption, the system will compute and process the data while it’s encrypted and then spit back an encrypted answer. At the time Gentry created his Homomorphic Encryption scheme, he predicted it would be another decade before it became practical. That was on account of the fact that the process was literally a million times slower than it would be if you were working with unencrypted data. While there is work being done to address that issue, it’s still too much of a hinderance for most companies.

There might be hope though, one company, Enveil, claims to have found a way to make Homomorphic encryption fast enough for practical use. Following a breakthrough by the federal government, Enveil CEO Ellison Anne Williams says a viable homomorphic option should hit the market soon.

“We’re really bringing practical homomorphic encryption to bear. And we’ve made it really easy to plug and play with all types of applications, so you don’t have to change your user experience, or how you store your data, or even how you encrypt the data.”

---

Software: Multi-party Computation

Rather than doing the calculation all at once on one server, Multi-party Computation splits the work up across multiple servers. No one server ever has all of the encrypted data at once. This is, at least on its face, not so different from the groups of bitcoin miners that pool their resources to try and solve blocks.

Multi-party Computation isn’t new, either. It was first introduced as two-party computation back in 1982. It was expanded in 1986. Computation is based on the secret sharing of all inputs along with zero-knowledge proofs to help prevent malicious activity. The idea is that with enough “honest players” any bad behavior from a malicious actor would be quickly detected and eliminated.

Multi-party computation ensures:

• Input privacy: No information about the private data held by the parties can be inferred from the messages sent during the execution of the protocol. The only information that can be inferred about the private data is whatever could be inferred from seeing the output of the function alone.

• Correctness: Any proper subset of adversarial colluding parties willing to share information or deviate from the instructions during the protocol execution should not be able to force honest parties to output an incorrect result. This correctness goal comes in two flavours: either the honest parties are guaranteed to compute the correct output (a “robust” protocol), or they abort if they find an error (an MPC protocol “with abort”).

Multi-party computation is much faster than homomorphic encryption, but still slower than hardware-based solutions owing to the extra communication that’s required.

Problems with Software-based Encryption Solutions

For starters, both software-based solutions, Homomorphic Encryption and Multi-Party Computation, may need new application logic before implementation. These are not yet turn-key solutions, largely owing to the fact that this is a fairly new industry. Sometime these solutions can break applications or functionaliy. Not every program can easily be converted to make these kinds of computations, either. For instance, if an application pulls data from a database and then processes it using its own internal logic, then converting it to either solution will be difficult.

As Nigel Smart, the founder of Unbound Tech puts it:

“All the technologies in the world aren’t going to take a C program and just run it. It needs to be converted to the cryptographic protocol.”

As a result, many of the start-ups positioned in this space are focusing on specific use cases, offering products that sit between a user’s application and a database. So far startsup have introduced a range of specialized products such as software-based key managers and solutions for securing database access.

There’s also some discussion over who is best equipped to provide runtime encryption. Should it be a product offered by cybersecurity vendors or should it be a feature offered by large cloud platforms?

There’s a lot of uncertainty surround runtime encryption, and many IT professionals would argue there are bigger issues to worry about.

Still, these products should evolve tremendously over the next few years. They’re worth keeping an eye on.

As always, leave any questions or comments below.

• #Runtime Encryption