Beyond the Basics: Protect your code and business logic with Runtime Encryption Plugins

Motivation

In conversations with customers, we find a strong demand to be able to run sensitive application logic and custom cryptographic schemes inside an HSM-grade trust boundary. This was reinforced during an active beta phase of Equinix SmartKey and continues with early adopters. For those that may not have heard, Equinix recently launched Equinix SmartKey, powered by Fortanix and Intel® SGX, the industry’s first global SaaS-based HSM and Key Management Service.

It is often not possible to protect sensitive business logic at all with legacy HSM. When supported, we find that it is difficult, cumbersome, and expensive, requiring users to learn complex, low-level, vendor-specific APIs; write low-level code in C (where users are vulnerable to various memory bugs); and set up complex, customized build environments for testing.

Thus, users are often left to run sensitive application logic in an abstraction layer outside the HSM, where it is vulnerable to a variety of attacks.

Runtime Encryption Plugins

To address this demand, Fortanix developed a Runtime Encryption Plugin capability for Fortanix Self-Defending Key Management Service™ (SDKMS) and in partnership with Equinix for Equinix SmartKey™. The underlying Fortanix solution provides unified HSM and Key Management capabilities secured with Intel® Software Guard Extensions (Intel® SGX). Fortanix further extends the trusted execution benefits of Intel® SGX to Plugins.

Runtime Encryption Plugins allow users to rapidly develop, test, and run arbitrary code using a high level, memory safe language. The user’s code runs entirely inside the HSM-grade trust boundary, where it is able to use all of SDKMS’s native cryptographic, key management, and access control functionality through a simple, high-level API. This enables customization for unique requirements and business process as well as extensibility and crypto-agility.

This system has been used in practice to address for wide variety of use cases including

Plugin diagram

Easy to Configure and Manage with UI

Basic plugins may be developed entirely from within the user interface (UI). Our UI provides basic syntax highlighting and the ability to test plugins with mock inputs. Tracebacks are available on runtime errors.

Runtime Encryption Plugins leverage existing access controls designed from client applications. Like client applications, plugins may be in multiple groups. The plugin may only use the keys in these groups, and it may only be invoked by applications in these groups.

Additionally, a plugin has access to information about the entity that invoked it. This allows plugins to enforce arbitrarily complex access controls on client applications.

Plugin view in SDKMS UI

Easy to Develop

We currently support writing plugins in Lua 5.3, a small, dynamic, interpreted language designed for embedding. We chose Lua for its simplicity, its relatively small, modular implementation (which weighs in at under 25K lines of C), and its strong runtime performance and memory footprint (relative to similar languages).

The small, simple interpreter keeps the trusted compute base (TCB) to a minimum, and the small memory footprint and embedded design works well in an Intel SGX enclave.

Plugins are run inside a strict, sandboxed, resource-limited environment. The sandbox communicates with the rest of SDKMS by serializing data over a single, multiplexed channel to minimize API surface.

Support for other languages, including Python, is planned.

Easy to Consume with High-level, intuitive APIs

SDKMS plugins may use all our cryptography and key management functionality through Lua APIs that mirror the REST APIs available to client applications.

This allows users who are familiar with our REST APIs to quickly utilize cryptography and key management functionality from plugins.

For example, encrypting data using our REST API looks like this: REST API code
Using a Lua plugin, encrypting data looks like this:

Lua plugin code

Similarly, plugins are invoked from client applications via a POST REST API call, mirroring how client applications use native SDKMS functionality. POSTed JSON data from client applications are automatically deserialized into a Lua object for use by the plugin.

Share this post:

Get our blog updates in your inbox: