Why Cisco Joined the Confidential Computing Consortium

Building a Networked Mesh of Hacker-Resistant Software

The world’s digital devices are based on layered software stacks.  Each of these layers has its own security vulnerabilities. A successful attack made into one of the layers of software is typically leveraged to exploit another layer.

Some digital devices embed internal protections to limit potential damage. These protections are constructed using shared keys, certificates, or even passwords. Unfortunately, these shared secrets also can be compromised. Additionally, application software layer must implicitly trust underlying layers such as the Operating System or hypervisor manager. And, for these applications, there is little that can be done when the most fundamental layers of a device are actively being exploited.

Over the years, a variety of security technologies have been implemented to protect digital devices. From anti-virus to firewalls to intrusion detection systems, entire industries have been born. But hackers continue to overcome these protections. As long as developers continue to build traditional layers of software, and as long as our protections depend on software-based shared secrets, security exploits will continue.

Confidential Computing offers a new paradigm. Built upon secrets which never leave the specific computing chips, one layer of software can now be protected from exploits originating in another layer. Additionally, a hacker who has gained administrative privileges for a device’s Operating System will be unable to read or change an application’s data or code.

There are two foundational Confidential Computing technologies that enable this new paradigm. The first is the hardware-based Trusted Execution Environment (TEE). There is a class of TEE which allows application code to be compiled, signed, and encrypted by a software developer. That code can only be decrypted and executed within a compliant TEE. Subsequent memory or disk exchanges with the CPU are fully encrypted. Even a root hacker cannot look into the memory.

But using a TEE to run a verifiably genuine application is only part of the solution. This is where the second foundational technology plays a role. This technology is known as Remote Attestation. With Remote Attestation, an application within a TEE can externally assert the secure context in which it is running. Consequently, the TEE’s remote peer can verify that it is interfacing with a known, secured instance of untampered software.

Once two peers have verified each other’s identity, it becomes possible to integrate multiple sets of trustworthy peers together. The result is a mesh of directly connected trusted software. This eliminates entire classes of Operating System and hypervisor manager compromises from the list of attack surfaces that a hacker might exploit.

Getting to these trustworthy meshes will require agreements on the inter-device protocols needed for Remote Attestation. Some of these protocols will not be a surprise. For example, we can assume technologies like Transport Layer Security (TLS) might be used to connect the TEE. But within TLS, we will still need an industry-accepted language for communicating Remote Attestation claims about a TEE. Such standardization of these protocols will take time and work.

The good news is progress is being made. One place to look is the IETF’s Remote Attestation Working Group. In this venue, architectures for such specifications are nearing completion. But neither the IETF nor other traditional standards bodies have yet to float specific protocol proposals. Implementers only have access to a set of vendor-driven proposals. And each of these proposals has been framed upon the assumptions underlying a vendor’s specific TEE chipset.

This is where the Confidential Computing Consortium (CCC) is well positioned to play a role. Within the CCC, there are projects for acquiring attestable information out of TEEs. One of these projects is Open Enclave SDK for Intel SGX. Other venues exist for parallel efforts such as OP-TEE for Arm TrustZone. But these projects just scratch the surface of what can be Remotely Attested. Only now is the industry in a position to attempt to generalize and agree upon:

◉ The definitions of specific attestable TEE claims

◉ The level of trust that can be associated with a type of TEE or even on a specific TEE instance

◉ Acceptable stacks of network transport protocols and encodings

◉ How the initiator of a request can verify only approved TEEs have been used to deliver an end-to-end function

Accomplishing any of these objectives will require effort. Simultaneously allowing protocol extensibility and vendor neutrality will be non-trivial. The CCC can influence these discussions.

At Cisco, we care a great deal about the trustworthiness of networking peers. Our reasons for joining the CCC are simple. We are going to advocate for Remote Attestation interoperability. And we are going to integrate Remote Attestation into our Network Admission Control portfolio. We believe both have significant potential to reduce the risks that come from today’s layered software stacks.