Bet Noire / Getty Images IBM, Intel, AMD take different routes to hardware-based encryption So-called confidential computing approaches allo...
 |
| Bet Noire / Getty Images |
We have encryption for data in motion. We have encryption for data at rest. But one type of data is difficult to keep encrypted — data that is being used. For an application to do something with data, such as checking a document for spelling mistakes, it must be able to see the data.
Software-based solutions include tokenization and format-preserving, searchable, homomorphic (which allows for mathematical operations), and multi-party encryption. These are slow, cumbersome, and don't work for all use cases. What works is hardware-based protections. Smartphones already use them — secure enclaves that allow for the processing of identity and payment data in a way that's not visible to the rest of the device.
On enterprise servers, this is called confidential computing and two main flavors of this technology are in use. The best known is Intel's SGX, a secure enclave within Intel chips that protects applications and data while in use. These enclaves are relatively small, and applications typically must be rearchitected or rewritten to take advantage of them. By keeping it small, however, the potential risk due to flawed application logic is also minimized.
The other approach is used by IBM on the S390 chips in its Z System mainframes and LinuxOne servers, and by AMD in their EPYC chips. Here, the protected enclave is quite a bit larger and can hold not just an application, but the entire virtual machine it's in. That means that applications don't have to be rearchitected or rewritten to work inside the enclave. Cloud providers are getting on board. While Amazon hasn't come out with a hardware-based solution yet, Microsoft has opted to go with Intel SGX and Google Cloud with AMD Epyc.
IBM S390 chosen for highest security needs
Confidential computing is still relatively new, and early adopters tend to be financial services companies and other enterprises with high-security requirements. Take, for example, Hex Trust, a Hong Kong-based company that offers bank-grade custody for digital assets like cryptocurrencies. "We need the same infrastructure in the crypto markets as we have today in the financial markets," says Rafal Czerniawski, CTO at Hex Trust. Czerniawski previously worked in the financial services industry.
The cryptocurrency space has been beset by a wave of high-profile and embarrassing breaches and losses in recent years. "If the big institutions are going to adopt it, we'll need the same infrastructure, especially in custody," Czerniawski says. "But you hear stories all the time about people losing their keys, or disappearing with the keys, or faking their own death."
It's not enough just to figure out how to securely store a few crypto keys, Czerniawski says. In the enterprise, in large institutional environments, clients might have hundreds or thousands of assets and different blockchains. Even if a key management application was rewritten so that it would fit inside an Intel SGX enclave, that doesn't give you the infrastructure capability to manage the keys. "How do you scale that?" he adds. "How do you have many services running concurrently using the same keys? If my machine goes down, how do I resume processing on another server? We need to run transaction processing at scale."
There are also cryptographic authentication layers and cryptographically enforced security policies such as whitelisting the addresses of where transactions can be sent. "Running all of that inside the secure enclave gives us a lot of flexibility," Czerniawski says.
IBM is all about operating at scale, Czerniawski says. Plus, the technology is available both on premises and in the cloud. "Maybe initially our clients want to start small, with a proof of concept in the IBM cloud," he says. "As their business grows, and the risk exposure grows, they can transition to an on-prem solution. That gives a lot of flexibility to our clients."
IBM Z's secure enclave can go up to 16 terabytes in size. "You don't have to pick and choose what parts of our workload you are seeking to protect," says Rebecca Gott, IBM Z and LinuxOne distinguished engineer, and the person who leads blockchain development and Z-as-a-service via the IBM cloud. "You can protect everything at once." No code changes are required, she adds.
The way that the technology works is that each secure enclave has its own set of encryption keys used to encrypt communications into or out of the enclave. The enterprise customer sends the application, bundled up inside a virtual machine, together with its encrypted data and the keys used to unlock it, into the enclave, via a secure encrypted channel.
The application does its work inside the enclave, safe from the prying eyes of anyone else, including the cloud provider's own system administrators. "That's a key part of our value proposition," says Gott. "Anyone with elevated system credentials — infrastructure admins, hypervisor admins, cloud admins, any of those players — cannot see the user's data or software."
Sending in an entire virtual machine creates additional exposure, and IBM addresses that by having each enclave go through a secure boot process to make sure that the initial image is not tampered with, and the enclave's encryption keys are established at manufacturing time for each machine. "The root key material never leaves the hardware security module," Gott says. "The underlying architecture has the highest federal security certification available for a commercial processor. It means if there's any physical tampering with the device, the tampering is detected and the root material is zeroed out within 100 nanoseconds."
Then, to ensure that the virtual machine and application aren't compromised, there's a process in place for enterprise clients to load their code into a private GitHub repository where it can be verified and signed, Gott says. "So, you can be sure there's no tampering anywhere in the pipeline. You know the provenance of the code and you have a whole audit trail and protections along the whole process."
IBM Z's hardware-based confidential computing has been on the market the longest, says Charles King, principal analyst at Pund-IT, having been first introduced in 2016, and it offers a higher level of performance than the competitors. Like other Z mainframe technologies, he says, the secure enclaves "are clearly designed to meet the most rigorous security needs of the company's large enterprise customers."
AMD targets secure computing in the cloud
Like the IBM approach, AMD also encrypts the entire main memory space of a virtual machine. AMD is aiming at the public cloud market with its EPYC chips, says King. That makes it attractive to cloud-native companies like France’s iExec, which provides the infrastructure to allow enterprises to run cloud-based blockchain applications. "We rent space from Google Cloud, repackage it as blockchain and off-blockchain, and rent it out to enterprises," says Lei Zhang, head of security at iExec,
Google Cloud was the first public cloud provider to offer AMD EPYC-based confidential computing as a public beta in mid-July. For example, one of iExec's customers is a hospital that wants to share its medical data with research companies. "Medical data is high sensitivity, so we need to guarantee data privacy and ownership," says Zhang. Another customer is using the platform for 3D rendering for films. "You don't want a scene leaked," he says.
The AMD EPYC secure enclave is large enough that the entire rendering process can run within it. The blockchain networks are a trusted way to handle data and a few other use cases, says Zhang. "Smart contracts and some business logic run directly on the blockchain, but there is a problem with scalability."
That's where the secure enclaves come in. "You can't run sophisticated algorithms like AI directly on blockchain networks," Zhang says. "It's costly and not efficient. That's why we want to offload such applications to off-blockchain networks, but we must guarantee a similar level of trust."
Confidential computing allows the company to do just that, Zhang says. "Even the administrators of the Google Cloud service cannot penetrate this secure virtual machine to inspect my data." Intel SGX would not have been able to run a full virtual machine, he says. "It was developed to preserve highly sensitive but small workloads, microservices. The AMD technology is designed for cloud infrastructure services."
As with the IBM Z platform, applications can be run, Zhang adds. "You don't need to modify the source code. If you develop SGX applications based on the Intel SDK, you have to do a lot of modifications to the code of the application. It's extremely painful."
The Google Cloud secure enclave isn't quite as big as IBM's, up to 896 gigabytes. But, like with IBM, the enclave has its own encryption keys, generated by a combination of hardware and software, that enables enterprise customers to send their workloads into the enclave.
"Customers can keep it encrypted using their own keys or use cloud HSM [hardware security module] technology to encrypt the data when they bring it to the cloud," says Nelly Porter, senior product manager at Google Cloud. "The application — this is very critical for us — doesn't need to change."
Google had tried using Intel SGX secure enclaves and looked at ways to make the process easier for customers, but in the end forcing enterprises to rearchitect their applications was too cumbersome. The source code may not be available, and even with open source code, there may be dependencies or other reasons why the application can't be changed.
Instead, with AMD's approach, only the hypervisor code needs to be changed to work with the secure enclave. "There's only a handful of those," says Greg Gibby, senior product marketing manager for EPYC at Advanced Micro Devices. "For Linux, for all the major distributions, that's done, and the code has been upstreamed and accepted by the community.” He adds that VMware has committed to enabling this technology with its next release, and AMD is working with other firms that have their own hypervisors.
Allowing hypervisors and virtual machines access to the enclave expands the potential attack surface, critics say. "The hypervisor does have access," says Gibby. "If you had a malicious hypervisor, there are potential ways you could get into the virtual machine."
That doesn't mean that the attack surface increases, he says. "The entire memory space is encrypted," he says, "and uses an encryption key that the hypervisor does not have access to. So it actually reduces the attack surface, not expands it."
Other security solutions in the production environment would protect against this kind of attack, but currently, AMD's own platform doesn't protect against malicious hypervisors, he admits. Protections are in the EPYC roadmap, he says, “but we didn't want to wait. We didn't want to let the perfect be the enemy of the good."
Microsoft bets on Intel SGX
Not everyone is on board with AMD’s approach. Microsoft has decided to go with Intel SGX and its smaller enclaves. According to Mark Russinovich, CTO for Microsoft Azure, the Intel SGX enclaves only go up to 256 kilobytes — a tiny fraction of what either AMD EPYC or IBM Z can offer.
The benefit for customers is that they have full protection against both logical and physical access — the only things in their enclaves are what they put in there. "A customer can install software and process data with no dependency on anything from Microsoft," Russinovich says. "It provides for extreme levels of protection and assurance."
While Intel SGX typically runs on smaller workstations, not multi-socket datacenter-class servers, Microsoft has worked with Intel to get SGX into its cloud centers with single-socket servers. "There's no question that it's easier if you can launch a whole virtual machine, but that creates a tremendous amount of surface area that exposes you to side channel attacks," Russinovich says.
Microsoft looked closely at the AMD approach, "but decided to pass because of some of the limitations," Russinovich says. Customers do have to write code that is aware that it's running inside Intel SGX, he says. "But we're working on technologies and SDKs and tooling to make it easier to get software into those enclaves."
Microsoft is also working with the Confidential Computing Consortium — AMD, Google, Intel, Red Hat and Oracle are also members — and contributed the Open Enclave SDK, which abstracts the differences between trusted computing environments. The SQL database supports Intel SGX, he adds, so if an application uses SQL for its most sensitive work, then the rest of the application doesn't have to be rewritten to take advantage of the enclave.
Gartner analyst Steve Riley confirms that Intel SGX requires code to be rewritten, and AMD's EPYC does not. Azure SQL databases can place information in enclaves without modification, he says, "but any other application that runs on ordinary compute instances will require modification."
Microsoft's Open Enclave framework isn't the only one that's trying to solve this problem, Riley says. Google has its own approach, called Asylo. "None is a declared standard," he says, "and it's unlikely that one will ever emerge as a de facto standard."