Over the past few years—and especially over the past few months—we have seen a rapid expansion of our Internet infrastructure, particularly in life quality enhancing businesses built upon the Internet. It’s encouraging that many of these organizations have also come a long way in the evolution from security ignorant to security conscious to security vigilant. As a result, we’ve witnessed the gradual but rapidly accelerated adoption of solutions that manage and protect machine identities such as TLS keys and certificates.
In today’s economy, machine identity management solutions must operate at scale with automation and intelligence across various environments, replacing previous approaches such as the use of spreadsheets to track the hundreds of thousands of certificates at use in larger enterprises and government agencies. This growth trend is not showing any signs of slowing as businesses grapple with ever more sophisticated attacks in the ever more digitized world.
One important challenge for many organizations has been to secure the private key that is used to prove the authenticity of the server identified by a certificate. Often, these private keys are protected in a suboptimal manner that incurs prohibitively expensive overhead or undesirably high risk.
Combined with machine identity management, Intel® Software Guard Extensions (Intel® SGX) offers a solution to the problem of securing private keys—an enclave-based solution that brings the cost and overhead down while elevating the security to a level that goes beyond the current status-quo.
In this blog, we will make the case that large organizations (and Venafi customers in particular) can benefit from the synergy between Venafi Trust Protection Platform and Intel SGX for end-to-end protection of machine identities throughout their lifecycles. We will share an example use case and overview of this new approach. Plus, we will touch on the Intel SGX that’s relevant to our solution.
Before we dive into Intel SGX and machine identity management, let’s set the stage for the importance of TLS certificates, which are the identities of web services. Our digital businesses and transactions heavily rely upon these certificates and the underlying PKI infrastructure and ecosystem behind the scenes. The fact that you can verify that you are talking to YourBank in your web browser is a result of the work has been put into making sure that YourBank and only YourBank has a trusted certificate issued to it. Each TLS certificate has a pairing private key which together form the identity of the owner of the pair. If a private key is compromised, then that machine identity can be misused by cybercriminals. Therefore, private keys have long been one of the most highly prized targets in cyberattacks. Such compromises often bring both financial and reputation damages to an organization.
Private keys can be compromised because they are vulnerable in two manners: at rest and in use.
A highly discouraged yet popular practice is to store private keys on the file system and rely on OS provided controls such as file permission for protections. Such a once-effective-but-outdated defense has little to no power in today’s hostile environment where attackers are more sophisticated than ever. A seemingly uncountable number of OS level vulnerabilities have been discovered, disclosed, and exploited to get secrets from restricted places in the file system.
Other approaches to storing keys offer higher protection through encryption and more advanced and stringent access controls to fend off attacks on secrets stored on hard disks. Yet one concern that has yet to be addressed is the lack of protection for sensitive data in use in memory, which is often at risk for memory targeting attacks such as memory-scraping. The problem becomes worse as businesses move workloads to third-party cloud infrastructures that rely on large numbers of humans to operate and manage the hardware and software. The fact that these humans hold the least stake in securing an enterprise customer’s business interest highlights the need for protections against errors caused by human nature in the public cloud.
Organizations who are especially active in the cloud will want to take extra care to safeguard their machine identities being used in memory. A machine identity management solution, such as the industry-leading Venafi Trust Protection Platform, solves the problems of lifecycle management for machine identities such as TLS certificates and key pairs. But there is still some work to be done when it comes to protecting the private keys that are constantly used in memory to prove ownership of machine identities.
The industry’s most popular approach to protecting private keys is using Hardware Security Modules (HSMs) which require a physical hardware appliance to be housed and operated in a controlled physical location. Extensive and special care needs to be given for integrating HSMs appropriately with other systems such as machine identity management. Cryptographic operations—such as generating public and private key pairs and proving ownership of the machine identity—can be performed on HSMs which are designed with technology that are not susceptible to memory attacks. PKCS11 is the standard programming interface exposed by most HSMs to applications. Applications that use the popular OpenSSL cryptographic library can also use HSMs thanks to the openssl/pkcs11 engine mechanism.
However, HSMs can be specialized and costly. Once you have the hardware, you still need to support it with specialized talent. Off the shelf, HSMs are only optimized for the most common use cases. So, it’s likely that you will need to build software to integrate it with other systems. In addition, deploying and managing multiple HSMs can also be challenging, especially in large and geographically distributed environments. They may also prove to be limiting for some organizations where the physical device is not always possible, especially in cloud and edge environments.
In the next section, we’ll look at an alternative for managing the last mile of machine identity lifecycles that helps elevate end-to-end protection with ease and sustainability.
Intel SGX is an implementation of the Trusted Execution Environment (TEE) paradigm. TEEs allow the isolation of data and its associated processing from the rest of the software on a machine. Abovementioned HSMs are an example of a TEE implementation, while others that we have seen in the market include Trusted Platform Modules (TPMs) that provide a trusted root and ARM TrustZone with use cases for mobile devices.
Intel SGX helps secure code and data in memory through the creation and management of Intel SGX enclaves. An enclave is a region of memory that is encrypted by a cryptographic key generated in the CPU package. Code and data in an enclave are decrypted by a key only known to the CPU when they reach the confines of the CPU package as shown in Figure 1. The net result is that code and data in an enclave is by design not exposed to any software on the server, including privileged software such as OS kernels, Virtual Machine Managers (VMMs), the BIOS, and the firmware through their lifetime. Figure 2 is an abstract illustration.
Intel SGX enclaves are deployed as shared libraries. The code and data segments in a library are not encrypted until the library is loaded, at which point they get encrypted by a CPU-generated key. Application developers identify the sensitive parts of their applications and define them as Intel SGX enclave-libraries. The Intel SGX SDK and Intel SGX runtime allow developers to create and deploy Intel SGX enclaves.
The protection of private keys using Intel SGX is achieved by implementing the PKCS11 standard in an Intel SGX enclave. From the application perspective, this enclave looks just like an HSM. This PKCS11 implementation in Intel SGX is provided by the Secure Key Caching (SKC) Library, part of Intel® Security Libraries for Data Center (Intel SecL-DC).
The Intel SKC Library is entirely software-based. Therefore, the configuration and deployment are performed the same way as for any other software. This allows organizations to have the benefits provided by HSMs without going through the trouble of purchasing, managing, and operating HSMs.
Figure 3, below, shows how all these TEE factors impact machine identity protection. When app servers run on Intel SGX enabled machines, an attacker is by design deprived the ability to capture the private keys even when they are used at runtime in memory.
The Intel SGX enabled server is not much different from a regular server equipped with Intel CPU in all other aspects of the computing. These servers are as general purposed as the computing machines we use for enterprise businesses in the data centers. They support the same operating systems such as RHEL, CentOS, and other flavors of Linux. You can also run Windows operating systems on Intel SGX-enabled machines.
While Intel SGX servers are designed for general computing purposed with added security enclave capability, Venafi’s collaboration with Intel SGX helps to eliminate any exposure of the private key through the full lifecycle of a machine identity with little to no management or operational overhead or cost.
Figure 4 shows a typical deployment of the solution. Venafi Trust Protection Platform deployment and configurations are unchanged. The Intel SKC service can be run on the same server that Trust Protection Platform runs on or it can be run on an independent server. Trust Protection Platform and the SKC service will be connected through standard authentication protocols.
From the perspective of the app server, a few lines of change to the app server configuration are the only modification required.
This solution can be conveniently deployed in the two most popular modes of application and system deployment: on the premises and in the cloud.
Many organizations and enterprises have not fully delegated the control of their workloads to public cloud providers. This will remain the case despite the aggressive progression of “cloud-ization”. To support this use case, Venafi Trust Protection Platform and Intel SGX can be deployed on an organization’s on-premises data center infrastructure.
As you can see, the notable difference is the use of an Intel SGX enabled server to replace a standard conventional server on which applications and services run in your data center. Because the difference is at the chip level and all other aspects of the CPU and the machine are unchanged, the performance impact is expected to be minimal.
From the perspective of the app server, a few lines of change to the app server configuration are the only modification required.
Due to Intel’s long history of technology partnership with public cloud providers, Intel SGX-enabled server virtual instances are already available in the cloud.
Understanding how Intel SGX can work with Venafi Trust Protection Platform to secure machine identities in memory is just the beginning. In future blogs, we will showcase additional use cases such as code signing identities and share plans for further solutions down the road.
We are running an Early Bird Access Program that is open to all existing Venafi customers and prospects who have an interest in trying the solution out and providing valuable feedback. The program provides necessary Intel SGX hardware sponsorship to participating customers on a first-come-first-serve basis. We will report on preliminary results that come from early bird customers using the solution.
Plus, we will delve deeper into the relevant technical components regarding the technical aspects of Intel SGX technology with a supplemental technical blog from Intel.
Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex. Results have been estimated or simulated. No product or component can be absolutely secure.
The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.
All product plans and roadmaps are subject to change without notice.
Intel technologies may require enabled hardware, software or service activation. Your costs and results may vary.
© Intel Corporation 2021. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others. Code names are used by Intel to identify products, technologies, or services that are in development and not publicly available. These are not
commercial names and not intended to function as trademarks.