CLOUD DATA SECURITY
BYOK Option in Cloud Crypto and Key & Management Services


Introduction

Enterprises across industry segments are moving IT workloads and functions to the cloud, frequently
ahead of any strategy or consistent capability to secure sensitive data. The advantages of cloud
migration, such as scale, agility, and consumption-based pricing, are compelling and seem to outweigh
the risks in the short term.

Most enterprise IT today is hybrid, with some workloads in the cloud and some hosted within the
enterprise datacenter. Many are adopting a “cloud-first” or “cloud-only” approach for all new IT
functions and business. Due to a combination of decentralized IT functions, frequent mergers and
acquisitions, and shadow IT, most enterprises are multi-cloud, leveraging more than one cloud service
provider (CSP).

Data security is rarely the first consideration for selection of a CSP. The emergence of strict new data
privacy regulations such as GDPR and CCPA is driving the need for CISOs to more effectively address data
protection and data governance in these very complex hybrid IT ecosystems across geographies. CISOs
are looking to the CSPs for data security solutions but struggling with the confusing array of security
models and services offered by CSPs.

CSPs offer native key management, encryption, and Hardware Security Module (HSM) services. These
security services have typically been added as a layer on top of their existing stacks; after-thoughts from
a late recognition of their customers’ increasing data security concerns, and are not enterprise-grade. As
most enterprises are also multi-cloud, the challenges inherent in CSP security offerings include
deficiencies in uniformity, homogeneity, coverage, customer control and ownership, functionality,
scalability, performance, visibility, and more. On top of these, there are broader challenges with key
management, and vendor lock-in.

As enterprises transition from being just compliant to being secure, they will focus on data-centric
security services that keep their sensitive data protected persistently—while at rest, in transit, and in
use—rather than server-side or transparent encryption services across storage and databases, which
offer very little actual security. The good news is that even the CSPs have realized the increasing need for
data-centric security, and have started to offer new capabilities in this space.

The “Big Three” CSPs—Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure
offer key broker/key management services (KMS), such as AWS KMS, GCP KMS, and Microsoft Azure Key
Vault.

CSP Key Management Services

KMSs typically expose an API for managing keys and secrets. The premise of key management or
brokerage across all of the big three CSPs is the use of the Master Key and Working Key model. The
Master Key, usually referred to as the Customer Master Key (CMK), never leaves the KMS application,
and is not used to protect sensitive data in bulk. It is typically used to generate Working Keys and/or to
encrypt Working Keys or other secrets, and thus serves as a Key Encryption Key (KEK). Working Keys are
Data Encryption Keys (DEKs), and are used by applications to encrypt/decrypt actual sensitive data. AWS
and GCP use symmetric (AES-256) CMKs, but Azure uses only asymmetric (RSA-2048, -3072, -4096) key
pairs, storing the private keys in their KMS.

CMKs may either be software-managed or stored inside a FIPS-compliant HSM controlled by the CSP.
There are different models of Master Key management in terms of customer control and visibility:

Cloud HSM

Cloud HSM is a service through which keys are generated by, and stored within, FIPS 140-2-compliant
HSMs that are hosted and managed by the CSP. This model allows higher throughput than the
KMS-based model of encryption. These HSMs offer a subset of the PKCS#11 standard API specifications,
which are exposed either directly or through the KMS interface to take advantage of the other cloud
services integrations existing with the KMS.

An important caveat is that these CSP crypto services are available in specific physical locations, referred
to Regions. Even when these services are available, cross-region integrations and availability of keys
across CSP regions are also not guaranteed. Some CSPs do not specify their level of FIPS 140-2
compliance.

Bring You Own Key

CSPs also allow customers to optionally import their own key material. This “Bring Your Own Key” (BYOK)
model lets customers generate the keys themselves (typically using on-premises HSMs) and upload them
to the CSP KMS. Customers are usually required to download a certificate from the CSP, along with an
import token. The symmetric key(s) generated by the customer are encrypted using the public key bound
to the downloaded certificate. The encrypted symmetric key(s) plus the CSP token or a hash of the key
material are then uploaded to the CSP KMS. The tokens/hashes are used for authentication and integrity
purposes. In some BYOK implementations, the CSP requires padding and Base64-encoding encrypted
key(s) prior to upload.

What is “Bring Your Own Key” really buying you?

When CSPs offer the “Bring Your Own Key” option, it creates a perception of increased security and
control. But digging deeper into the BYOK model reveals that it is applied at varying tiers of the key
hierarchy across CSPs, and that customers are not necessarily in control of the keys that actually protect
data. In other words, BYOK is applied to Master Keys or Key Encryption Keys (KEKs), and customers
almost never get to import Data Encryption Keys (DEKs) actually used for data encryption. Some CSPs
have a key hierarchy where DEKs are at the lowest tier, with one or more KEKs layered above. One of the
CSPs even offers BYOK only at the fourth tier of this hierarchy, meaning that the other three keys—the
second-level KEK, first-level KEK, and the DEK—are owned by the CSP.

Regardless of the key hierarchy tier where BYOK is offered, CSPs still have control over all keys below: the
perception created by CSPs and sold to enterprises is that the option to bring in their encryption keys
provides control, when in fact it does not. BYOK can address concerns around key types and strengths
(AES-256 vs. AES-128 or 3DES), key generation sources (HSM vs. software), and can be handy for
enterprise audit processes. But when the keys are uploaded into the CSP KMS, there should be no
perception that customers have total control of and exclusive access to those keys.

From a key rotation perspective, BYOK addresses enterprise policy requirements. Since enterprises
cannot rotate CSP-owned DEKs and KEKs, BYOK-KEKs are allowed to be rotated, and this satisfies audit
and compliance requirements. For SaaS offerings such as Office 365, where Microsoft leverages Azure
Key Vault-based keys, the BYOK option is applied to the topmost key in the vault key hierarchy, and that
is what gets rotated.

For customer-developed applications deployed across the CSPs’ IaaS & PaaS offerings, CSPs provide
some common best practices around DEK usage. They encourage use of unique keys for each data
element, whether it’s generated by the KMS or Cloud HSM—whether every application request
(GenerateDataKey) for DEKs will generate a new/unique key, which is the case with AWS; or if it’s locally
generated by the application, as in Azure and GCP. In either of these cases, it is also advised to encrypt
the DEK with a KEK, stored securely in the KMS or Cloud HSM, and the encrypted DEK is stored with the
encrypted data during a write operation. This is called the Envelope Encryption model, and the premise
of this best practice is that this means there is no need for DEKs to be rotated.

However, generating unique keys for each data element, even for a specific data type, could result in a
huge number of keys, and generating a key each time to perform a data encryption also adds additional
overhead to the process, which impacts performance. Having developers generate and manage DEKs
(itself a risk) at the application layer frequently means they use the same or shared keys across data
types and environments. In such scenarios, the DEKs tend to persist, and thus are subject to
compromise, necessitating rotation. With typical implementation of symmetric cryptographic services, a
DEK rotation every n years could result in a burdensome requirement to re-encrypt all data. A periodic
rotation at the KEK level avoids this situation and is easy to execute. However, this approach offers no
assistance for enterprises with compromised DEKs.

To handle key rotation at the DEK level, enterprises should consider use of available, alternative crypto
and key management solutions that simplify DEK rotation without involving bulk re-encryption of data.

Consider CSP Crypto Services and BYOK for appropriate use cases only

When enterprises consume software as a service (SaaS) to store or process sensitive data, they face
unique challenges. SaaS providers offer limited or no scope for custom development, so enterprises are
typically restricted to very few options for data security.

One option would be to leverage an encryption gateway solution, which acts as a web proxy to intercept
and protect sensitive data prior to storing it in the SaaS cloud. The other option is to leverage the SaaS
provider’s encryption capabilities, if available. Some of these SaaS providers also offer BYOK. In those
cases, adopting the BYOK model makes sense. Most SaaS providers implement platform-level
encryption (database, storage) by default, and typically also offer field-level encryption services at
additional cost. These allow selection of fields to protect, encryption algorithm, and key strength to be
used, as well as whether to use provider-generated keys or BYOK. Opting for such SaaS providers’
data-centric crypto services certainly provides added security. One way to exercise some control in the
key management space is by adding BYOK to the mix, which helps in meeting some compliance and audit
requirements, even though the challenges discussed above continue to apply. In a nutshell, if you can’t
Bring Your Own Encryption (BYOE) to the cloud, at least Bring Your Own Key (BYOK).


Articles

Home

Key and Secrets Management

Bring Your Own Key

Exploring Cloud Service Providers' Crypto and Key Management Services

Importance and Advantages of Format Preserving Data Protection

Recommendations for Implementing the Right Cloud Crypto and Key Management Solution

Online Shopping Security in the Age of COVID-19

Published Articles and Press Releases

Videos