Strengthening cloud security with confidential computing

Cloud computing is here to stay, but even when companies opt for hybrid cloud to combine the flexibility of public cloud with the enhanced data protection of private cloud and on-premises infrastructure, security concerns remain.

This is where our research in confidential computing proves valuable, and we’re continuing to push the limits of this relatively new technology.

Our latest advance, memory-safety protection, can complement confidential computing. While confidential computing protects a program from external attacks so that an adversary outside a program cannot directly access or tamper with information inside the program, memory safety protection protects a program from internal attacks so an adversary cannot exploit a buffer overflow or other memory-safety vulnerability inside a program to steal information (as in the HeartBleed attack) or take control of the program (as in Return Oriented Programming attacks). 

This is important since memory-safety vulnerabilities are at the root of many cyber attacks. In fact, a recent study¹ showed that memory-safety vulnerabilities were the root cause of roughly 70% of the security vulnerabilities in one company’s production software.

And since AI systems often use specialized processors, we’re also working to extend confidential computing to systems that utilize different kinds of processing elements.

The past few years have seen lots of interest in confidential computing, with many tech giants betting on it, including Intel, AMD, Google, ARM, Microsoft, and others. IBM zSystems, widely used in the financial industry, has included highly reliable, secure, and scalable support for confidential computing since 2020 ².

Confidential computing protects a workload from external threats, ensuring that your data in rented cloud infrastructure is protected from system administrators and other software, even while your data is in use. The technology uses specialized hardware to protect the confidentiality and integrity of your workload. This hardware protects virtual machines (VMs) – secure virtual computer systems with their own CPU, memory, storage, and network interface that give customers access to their own virtual computers in the cloud.

A secure virtual machine is akin to a secure hotel room: A customer can enter the room with their key, while the hotel staff cannot. A secure virtual machine protects a user's workload from the cloud provider's personnel and software, and from other (potentially malicious) clients that may be running on the same infrastructure.

En route to more secure, general-purpose computers

IBM was one of the first companies to venture into confidential computing research. It started in the 1990s with the 4758 secure coprocessor, which protected code and data against physical snooping and tampering ³. This was the first hardware security module (HSM) to receive the Federal Information Processing Standards (FIPS) FIPS 140-1 was a FIPS that defined ‘Security Requirements for Cryptographic Modules’.  Level 4, the highest level of security in the standard, includes the notion of an “envelope of protection” around the cryptographic module.  Any attempt to penetrate the envelope must be detected and all critical security parameters zeroized.  As the document states, “Level 4 devices are particularly useful for operation in a physically unprotected environment where an intruder could possibly tamper with the device”.  FIPS 140-1 was superceded by FIPS 140-2 in May 2002.140-1 Level 4 certification, which at the time was the highest level of security in the standard for cryptographic modules. IBM continues to make HSMs available today and these provide the highest levels of security in the current version of the FIPS 140 standard – but these are not general-purpose computers.

To achieve a similar level of security on a general-purpose processor, our team began working in the early 2000s on securing IoT devices from physical attacks. We developed a CPU architecture called SecureBlue to protect the code and data on a system from physical snooping and tampering. In a SecureBlue-based system, information is in the clear when inside the CPU chip, and cryptographically protected when outside the chip. SecureBlue protects the confidentiality and integrity of code and data, which includes protection against so-called ‘replay’ attacks, where an adversary attempts to ‘replay’ data that was, but no longer is, valid.

The project was very successful, and within a few years IBM had shipped many tens of millions of SecureBlue-based CPU chips for applications where strong security against physical attacks was essential.

SecureBlue also paved the way to SecureBlue++ ^{4, 5}, which protects against physical attacks, but uses a “fine-grained” SecureBlue-like crypto protection mechanism. This also protects the confidentiality and integrity of an application from all the other software on a system including privileged software like an operating system that could be hijacked by an adversary. This was the first architectural proposal for what has come to be known as confidential computing.

In 2010, we built a SecureBlue++ prototype on a CPU simulator and demonstrated the architecture within IBM. We presented this work at Trust 2011, the Fourth International Conference on Trusted Computing in Pittsburgh and at the Second Annual NSA Trusted Computing Conference in Orlando. We also submitted a proposal to the U.S. Department of Homeland Security (DHS) to develop an end-to-end secure computer architecture (from small embedded systems to large servers) which led to a three-year DHS project on hardware support for malware defense and end-to-end trust ⁶ from embedded processors to high-end server and cloud architectures.

Enter Secure Virtual Machines

For embedded systems, secure boot solved a number of issues. On the server side, we decided to use our SecureBlue++ Secure CPU technology to support Secure Virtual Machines (SVMs) that are protected from the other software on the system, including privileged software such as the hypervisor. One advantage of the Secure Virtual Machine model is that it eliminates the need to make changes to an application – so applications that run today can be easily moved to the more secure SVM environment without change.

We extended the SecureBlue++ model to support Secure Virtual Machines and this became the basis for Secure Service Containers on z14, Secure Execution on z15 ² and z16 and Confidential Computing on OpenPOWER ⁷.

Other players join the game

We weren’t alone in this for long. In 2013, Intel presented several papers on its approach to confidential computing, called Software Guard Extensions (SGX), with papers referencing our work on SecureBlue++. Three years later, AMD, published its Secure Encrypted Virtualization (SEV) technology. Since then, confidential computing has been broadly embraced across many CPU architectures and clouds. The Linux Foundation’s Confidential Computing Consortium currently has 48 members.

As Vint Cerf, Google’s Chief Internet Evangelist, said in a 2020 blog post, "We believe the future of Cloud Computing will increasingly shift to private encrypted services where users can be confident that their data is not being exposed ... This is the future we want to bring about and Confidential Computing makes it possible."