Hardware enclaves - the next frontier in enterprise application security

A fundamental maxim of IT security is that data must be protected at rest and in transit. The rule typically gets translated into security processes that require encrypted network connections, e.g TLS, VPN, and the encryption of storage volumes, files and objects.

Unfortunately, the bilateral principle has a small, but perilous blind spot: data in use. Although encrypted storage and network sessions protect data under most circumstances, the use of shared infrastructure and services like cloud instances and containers opens applications and data to attack while they are executing. Much like stealthy malware or a rogue app that extracts data from other applications on an infected PC, it's possible for nefarious code on a shared system to sniff data from another application's working memory while it is running. Furthermore, since the data must be unencrypted during code execution, it doesn't matter how securely it was treated during storage or transport. 

There have been many recent attempts to tighten the security fence around running applications including micro-VMs, application firewalls with role-based access security (RBAC) and curated application registries, however, none are foolproof. Instead, the only way to guarantee data security during application execution is by exploiting hardware features now included with modern processors. Sadly, using such trusted execution environments (TEE) is easier said than done, a problem that both startups and industry giants are fixing in hopes of making  so-called confidential computing a standard feature of cloud environments.

Hardware sandboxes - what started on phones comes to the cloud

A TEE is built on a hardware-defined secure enclave, which can be either part of a CPU or a separate chip, strengthening application security by encrypting data in use and enforcing access controls on different memory regions. Collectively, these create a so-called application sandbox that isolates an application's data from all other processes running on the system. Application sandboxing isn't a new concept, for example, virtual machines implement a form of sandboxing in software, however, enforcing sandbox protections in hardware was popularized by Apple in 2013 when it incorporated a Secure Enclave Processor (SEP) on the A7 SoC powering the iPhone 5S. 

Apple has since expanded Secure Enclaves to its entire product line by adding  SEP hardware into its A-series (iPhone, iPad, Apple TV, HomePod), S-series (Watch) and T-series (Mac security chip) silicon. Thus, a feature that was initially designed to protect the phone OS and a user's biometric security data has been extended to provide robust isolation between apps. Google followed suit in 2018 by adding the Titan M security chip first to the Pixel 3 and all subsequent phones and Chrome devices.

Apple has been vague in describing its SEP, whose design and features often change with new revisions of the A-series SOC, however, this Blackhat presentation summarizes the details, which represent a reasonable proxy for SEPs that have subsequently been introduced by Intel and AMD. 

• Built into hardware that the application processor cannot access.
• Modules for core security functions including a crypto engine and random number generator.
• Dedicated cryptographically signed and validated boot ROM and scratch RAM
• Provides application-specific key validation and AES encryption of external RAM.
• Enforces memory segmentation, aka a "filter," to prevent applications from accessing another apps' memory or SEP memory.

It might seem ironic that consumer devices pioneered hardware-based security since the stakes, i.e. risks and consequences of a breach, are far higher for businesses, particularly those using shared cloud services. Fortunately, the gap in hardware protection started to close when Intel released its Security Guard Extensions (SGX) secure enclave and SDK in 2015 with the Skylake micro-architecture.

Unlike some TEE implementations, SGX allows partitioning an application into protected and unprotected modules. 

An Intel product brief and blog from Quarkslab, a security consultancy and researcher, provide excellent summaries of the key features of SGX: 

• When an application creates an enclave, SGX creates protected memory. 
• Unprotected application code and data is distinct from secure code and data in the enclave.
• When the application calls an enclave function, only the code in the enclave can see protected data. External access is denied.
• When an executing enclave is stopped, the SEP removes any data from CPU registers to prevent snooping by other processes. 
• An application can use an SGX function to verify its authenticity and integrity and whether it is executing on an authentic Intel processor from a trusted third party (aka remote attestation).

AMD released a similar set of hardware security features in 2016 with Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV). ARM followed suit introducing a Platform Security Architecture (PSA) in 2017 that is currently embodied by the Cortex-M processors and IP blocks available to ARM licensees. 

Turning hardware features into secure applications

Although processor designers have provided the raw materials for building hardware-enforced secure applications, the available software tools are basic and hardware-specific. Thus, applications written for one security architecture (e.g. Intel SGX versus AMD SME) must be rewritten before migrating to another. What's needed is a platform-neutral abstraction layer to erase such architectural distinctions. It's a technology gap that has attracted the attention of several startups, notably Anjuna, Anglave and Fortanix, and sparked the creation of the Confidential Computing Consortium.

I recently talked with Ayal Yogev, CEO & Co-founder, Anjuna Security, about the company's first product, Anjuna Enterprise Enclaves, an architecture-agnostic platform that acts as an intermediary between hardware-specific SEP implementations and applications. As such, developers need not recompile applications for different types of servers or cloud services. The product currently works on either Intel or AMD servers or Azure services, with AWS Nitro support coming soon and is available through the Azure marketplace.

Azure has embraced the idea of hardware-enforced security via its Confidential Computing service and recently announced the general availability of VMs using SGX to protect data during runtime execution. Developers can build secure applications on the Azure DCsv2 instances have several options on the Azure marketplace besides Anjuna including:

• Anqlave Data vault, a FIPS 140-2 validated, key management system
• Fortanix Self-defending key management service (SDKMS), also FIPS 140-2 compliant
• Two open-source frameworks: The Open Enclave Software Development Kit (SDK) or The Confidential Consortium Framework (CCF).

IBM Cloud supports hardware-based security via the IBM Cloud Data Shield, a secure enclave available for its Kubernetes service hosts that adds Python and Java interfaces to the standard SGX C and C++ APIs, and includes pre-built SGX applications for MySQL and NGINX.

My take

Hardware secure enclaves aren't new, but extending the concept to enterprise applications and cloud infrastructure is a nascent development. While the Confidential Computing Consortium is only two years old, it now boasts more than two dozen members including all of the major cloud providers save AWS. 

Before confidential computing — what I call hardware-enforced security — can achieve broad adoption, developers need platform-agnostic tools that both speed adaptation of existing applications onto secure hardware and enable workloads to be migrated between server and cloud platforms without modification. Initial tools have focused on security niches like key management, however, Anjuna offers the promise of a general-purpose abstraction layer that can bolster the security of many application categories including data analytics, content management and DLP, blockchain and edge/IoT workloads. 

Improving application security by exploiting hardware features of modern processors will be a slow and painful process, however, it's worth remembering that it took Apple and iOS developers years to fully exploit the features of the A-series SEP. Thus, enterprise CISOs and developers have time to climb the confidential computing learning curve, but have no excuses for delay now that cloud services and supporting development platforms have come to market.