IronCore CMK Explainer
Customer Managed Keys, or CMK, is a cloud architecture pattern that gives customers control and ownership of the encryption keys that protect some or all of their data stored in SaaS applications. It also provides customers with an independent audit of data access.
IronCore Customer Managed Keys is a turnkey CMK implementation. It has four architectural components:
- Java SDK
- IronCore Encryption Service
- IronCore Configuration Broker
- Customer Key Management System (or Hardware Security Module)
Each component is discussed below.
Your application’s data access layer encrypts data by making calls to the Java SDK. The SDK encrypts application data locally with a Data Encryption Key or DEK.
The SDK also makes calls to the Encryption Service REST API. The Encryption Service generates and encrypts the DEK either on its own or in conjunction with your customer's Key Management System (KMS). Both a DEK and an Encrypted Data Encryption Key, or EDEK, are returned to your application’s data access layer to be persisted alongside encrypted application data.
The pattern of encrypting a data payload with a DEK, then encrypting the DEK with a per-tenant master key to create an EDEK is called envelope encryption. Envelope encryption is highly performant as the content to encrypt is not transferred to the service and the inner encryption is done locally.
The cardinal rule for a CMK implementation is that an unencrypted DEK must never be persisted. You store the encrypted EDEK alongside encrypted application data. Since only the customer can unlock the EDEK, this pattern gives your customers independent access control and an independent audit log.
IronCore Encryption Service
The IronCore Encryption Service (ES) encrypts and decrypts data encryption keys (DEKs and EDEKs). It communicates with your customer’s KMS or Hardware Security Module (HSM) to provide customer control and auditing. CMK is a trust but verify model. Your customers trust that you will encrypt their data and never persist an unencrypted data encryption key. They verify your access and access patterns by integrating encryption and decryption of the DEK into their Key Management infrastructure (i.e., KMS or HSM).
The Encryption Service is an adapter pattern between the ES REST API and the wide variety of potential customer KMS choices. This makes it practical for SaaS applications to implement CMK without the integration complexity and ongoing technical debt associated with supporting, testing and auditing new and updated customer key management infrastructure.
The Encryption Service runs locally in your infrastructure. It is highly secure, stateless and never persists a DEK. It configures itself by “calling home” to the Configuration Broker once per tenant. Self-configuration allows the ES to remain stateless and secure, and to easily scale horizontally. The Encryption Service is packaged as a Docker container.
The Encryption Service generates audit events. These events are integrated with your customer's Security and Incident Event Management (SIEM) system. IronCore audit events are in addition to the logs generated directly from your customer's KMS
The Encryption Service is multi-tenant and encryption calls require a unique tenant identifier in their call signatures. There are two mode of operation for the Encryption Service which are configured on a per-tenant basis:
- Remote Key
- Key Leasing
Remote Key refers to classic CMK in which calls are made to the customer KMS for each and every DEK encryption and decryption operation.
Key leasing refers to an approach where the customer KMS leases keys to the local encryption service, which caches them in memory for a lease period. Audit events are still provided to the customer infrastructure as asynchronous message events. Key leasing is beneficial because it minimizes latency and maximizes availability.
The encryption service can support master keys that are symmetric or asymmetric (public / private key pair). Asymmetric keys allow encryption to a public key, which eliminates the need to call the customer KMS when encrypting DEKs (the ES will still generate audit events).
IronCore Configuration Broker
The IronCore configuration broker lets your customer configure the many settings and “knobs” that are part of their security policy, key management infrastructure, and SIEM system. It is branded with your logo as a SaaS provider, but can run in your customer’s infrastructure, in IronCore’s infrastructure, or within your own infrastructure. IronCore cannot read the sensitive information it brokers, such as KMS access credentials. These can only be read by authorized keys used to initialize encryption service instances.
IronCore provides two pre-configured tenant IDs for testing purposes:
AWS-KMS: Using this tenant ID will cause all content to be encrypted with a key provisioned by a pre-configured Amazon KMS. Keys for this instance are still using AES-256 keys.
GCP-KMS: Using this tenant ID will cause all content to be encrypted with a key provisioned by a pre-configured Google Cloud KMS. Keys for this instance are still using AES-256 keys.
Using any other tenant ID will auto-create a per-tenant key (if one doesn't exist) and store it in the end-to-end encrypted IronCore KMS. The tenant will operate in key leasing mode.
All communications between the configuration broker user interface, the configuration broker service and the encryption service are end-to-end encrypted. IronCore cannot view sensitive information such as KMS access credentials and the configuration can only be decrypted by the keys from authorized encryption service servers.
End-to-end encryption is a minimal-trust model (sometimes called zero-trust in marketing literature, but technically zero-trust is a higher standard that includes protected memory, immutable audited code, etc.). One benefit of implementing IronCore CMK is that this same end-to-end encryption is also available to your application. This allows you to first adopt the CMK trust-but-verify model, then iteratively move to the minimal-trust model that end-to-end (aka client-side) encryption offers. These trust models can be mixed and matched. For example, it is common for SaaS vendors to provide end-to-end protection of opaque file attachments while providing CMK protection for records and fields.
The combination of the third party nature of the configuration broker and the encryption service also strengthen the trust model. Enterprise-security professionals often rely on the concept that critical aspects of the security architecture are managed by independent entities. This split-knowledge concept is familiar to anyone who has watched an apocalyptic movie where nuclear weapons can only be launched with keys or passcodes controlled by two or more individuals for example.
Customer Key Management System
Architects and developers new to the CMK pattern sometimes ask, “what key management system should I use?” This is a common misconception. You do not host your own KMS or HSM in a CMK architecture. Instead, you call into your customer’s key management infrastructure, giving them independent control over access and audit.
Unfortunately, there are multiple product KMS/HSM product lines. These include Gemalto, Thales, AWS, GCP, Azure and a long tail of off-brand vendors. Each product line has multiple product offerings. And each product offering has numerous configuration settings. The IronCore Customer Managed Keys module abstracts this complexity to provide you with a single point of integration via the SDK (or REST API).
Having said all that, we will immediately contradict ourselves. For some mid-market customers, it can be useful to provide a packaged KMS as part of your SaaS offering, even though this is not technically a CMK architecture. The self-hosted KMS can be used to increase per-seat revenue either by encouraging purchase at a higher tier or as an ala-carte add-on. To support this pricing model, IronCore provides the IronCore Key Management System as part of the CMK module.
The choice of customer KMS (or IronCore KMS) is completely transparent to your CMK implementation.