CLOUD DATA SECURITY

Exploring Cloud Service Providers' Crypto and Key Managment 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 the 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 complex and geographically-diverse
hybrid IT ecosystems. The terms pseudonymization and anonymization are now common in the
context of these privacy regulations when it comes to data protection and privacy. While
pseudonymization of data still allows for some form of re-identification (even indirect and
remote), while anonymization of data cannot be re-identified. CISOs look to the CSPs for data
security solutions to address these privacy requirements but struggle with the confusing array of
security models and services they offer.

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.

In this article, we describe the various data-centric security offerings of the “Big Three”
CSPs—Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. We
make an attempt to objectively reflect on what their data security services entail, based on the
published documentation made publicly available by the CSPs. It also outlines what enterprises
should be aware of prior to consuming these services in the context of their belated yet
increasing capabilities in the data-centric security space. It also needs to be noted that the
information captured is a point-in-time assessment and is subject to change as the CSPs continue
to enhance and expand their services. This article is intended towards any and all audience who
deal with data security and cloud security, executives, hands-on IT and Security professionals,
and anyone with a passion or interest in cybersecurity in general, across enterprises and service
providers.

Cloud Service Provider Crypto and Key Management Services

As enterprises transition from being just compliant to being secure, they must 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.
CSPs offer two kinds of cloud cryptographic (crypto) services to enable the implementation of
data-centric security:

• key broker and key management services (KMS), such as AWS KMS, GCP KMS, and
  Azure KeyVault; and
  
• cloud hardware security modules (HSMs), such as AWS CloudHSM.
  
  

This whitepaper also touches upon the Google Cloud DLP service, which is a composite service
that detects sensitive data and applies policies on the detected data.

CSP Key Management Services

Key broker and key management services 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:

• Customer-managed Master Key: Customer can view key metadata and manage the key
• CSP-managed Master Key: Customer can view key metadata but cannot manage the key
• CSP-owned Master Key: Customer cannot view key metadata nor manage the key

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.

Envelope Encryption

While these KMSs are used to generate, store, protect, and retrieve encryption keys, it is
important to understand the mechanism of application-level data encryption implemented and
supported at these CSPs. CSPs implement envelope encryption, which is the practice of
encrypting plaintext data with a working key (a DEK), and then encrypting the DEK with a
master key (the CMK). CSPs typically offer software development kits (SDKs) that are used by
the application to perform envelope encryption.

The encryption process works like this:

• An application makes a request (using the SDK) to the KMS to generate a DEK, under a
  specific pre-provisioned CMK. Note: With certain CSPs, KMS requests go through the
  internet by default.
  
• Across the 3 CSPs, the process for generation of the DEK varies. For AWS, the KMS
  uses the CMK to generate and encrypt a DEK when an application calls a specific
  method (GenerateDataKey) in KMS. Each key request results in the creation of a unique
  DEK that is created and protected under the same or multiple CMKs. However, in the
  cases of Azure and GCP, the DEK is generated locally but is protected by the KEK that is
  stored in their respective KMS services.
  Note: One best practice that is common across these services is the use of unique DEKs
  for each data during a write operation, and hence negating the need for DEK rotation.
  
• In case of AWS, the KMS returns both the plaintext and encrypted versions of the DEK
  to the application. However, there are options such as obtaining just the encrypted DEK
  by specifying a separate method (GenerateDataKeyWithoutPlaintext).
  
• The application uses the plaintext DEK to encrypt the sensitive data, and then typically
  deletes the plaintext DEK from memory.
  
• The encrypted DEK and the encrypted data are stored together.
  Note: For CSPs that offer only asymmetric key pairs for DEK encryption, the
  application/SDK uses the public key of the pair to encrypt the DEK during
  storage.
  

The decryption process works like this:

• An application parses the envelope-encrypted message (via the SDK) to obtain the
  encrypted DEK and makes a request to the KMS to decrypt the DEK.
  
• The KMS uses the CMK/KEK to decrypt the DEK.
  Note: For CSPs that offer only asymmetric key pairs for DEK encryption, the
  application/SDK sends the public key encrypted DEK to the KMS, where it is decrypted
  using the private key of the pair, and the cleartext DEK is returned to the
  application/SDK.
  
• The KMS returns the plaintext version of the DEK to the application.
• The application/SDK uses the plaintext DEK to decrypt the encrypted data.

Bring Your Own Key

CSPs also allow customers to 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 keys generated by the customer are
encrypted using the public key that is 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.

Google Cloud DlP

Google Cloud Data Loss Prevention (DLP) provides APIs for sensitive data inspection,
classification, and de-identification. It includes a number of built-in information type detectors,
and allows definition of custom detectors. It offers de-identification techniques including
redaction, masking, format-preserving encryption, and date-shifting as optional actions to be
taken on detected sensitive data within streams of data, structured text, files in storage
repositories such as Google Cloud Storage and BigQuery, and even within images. The keys for
data redaction are either:

• generated by the application and embedded in the API request header in the clear;
• wrapped by a master key within the Google KMS; or
• generated by the Cloud DLP system once the API call is made.

Issues and Challenges with CSP Crypto Services

A number of issues and challenges around scale, availability, portability, performance, and
security of these CSP crypto services should be considered.

• CSP lock-in – Each CSP offers services that are available and functional within the
  confines of their cloud services. Enterprises typically use more than one CSP to
  implement their workloads, along with on-premises legacy implementations. The
  biggest challenge and concern for enterprises is that they cannot implement a single
  CSP-agnostic enterprise solution or service that can be applied across both
  on-premises and multi-cloud hosted workloads. Enterprises will face an immense
  challenge if they want to shift cloud workloads from one CSP to the other, often
  involving decryption and re-encryption of all of their data. Realizing that customers
  do not want to get locked into its KMS, Google has recently integrated with third
  parties like Fortanix (SDKMS) and Equinix (SmartKey) via its External Key
  Manager services. It refers to these capabilities as BYOKMS (Bring Your Own Key
  Management Service). Such third-party KMS integrations are still coupled with, and
  hence rely on, the CSPs’ systems and services, however.
  
• Lack of total control over keys – As previously described, CSPs either own or
  manage the master keys, which provide the root of trust used within the confines of
  their KMS or cloud HSMs even if the customer provides the key material. These keys
  and data encrypted by these keys are likely liable to subpoena, or other disclosure, or
  abuse. As discussed below, BYOK as a practice in the industry has created a false
  perception that customer ownership and control of keys is established when the fact is
  that, even if a customer generates and imports the keys into a CSP KMS or cloud
  HSM, it is the CSP that has direct or indirect control of the keys. There is no hard
  isolation when it comes to cloud infrastructure.
  
• Lack of homogeneity – With enterprises going global through mergers and
  acquisitions, they cannot afford to have regional services and silos. Even though
  CSPs have a global footprint, their crypto services are not global. Not all regions have
  the KMS and cloud HSM services available, which forces enterprises to deploy and
  migrate their applications and data to specific CSP regions. In addition, the CSPs’
  integrated crypto services are also fragmented, as crypto clients and SDKs built for
  one application may not be interoperable with other applications running within the
  CSP, even if they are using the same KMS under the same identity. The result is that
  customers encrypting data on one platform or in one CSP region cannot necessarily
  expect to be able to decrypt on another platform or in a different CSP region.
  
• Lack of key management abstraction level – Abstraction of key management is
  critical to ensuring developers do not spend too much time handling keys and needing
  to understand key management. Through these CSP crypto services, developers have
  access to the encryption keys and can use them as needed within their applications.
  CSPs offer developer SDKs to enable their application to handle crypto operations
  and key management, although a significant amount of metadata usage (such as key
  usage, key specification, encryption context, grant tokens) is required to create,
  request, encrypt, and decrypt keys. The lack of abstraction and giving developers
  access to physical keys, and providing them with the ability to manage those keys at
  the application code level, creates opportunities for exposure and breach.
  
• Lack of encryption format choices and other data obfuscation options – CSP
  crypto services SDKs all support 256-bit GCM-mode AES. As of early 2020, only
  Google Cloud DLP offers other encryption formats such as Format-Preserving
  Encryption (FPE) to enable business processes, retain application business rules and
  database schema, and allow secure analytics to be performed even after encryption of
  data. They also do not offer capabilities to partially expose certain data elements to
  enable business functions without the need to decrypt the data. CSPs also do not have
  a defined tokenization service offering, vault-based or vaultless, to meet PCI-DSS
  requirements.
  While Google Cloud DLP offers FPE, it does not clarify whether this is FF1-mode
  AES; FF3-mode AES, which is both vulnerable and has limitations; or a
  non-standard form of FPE not validated by NIST. It also makes no reference to
  supporting partial FPE or Unicode.
  
• Envelope encryption and Google Cloud DLP risks – As explained above, envelope
  encryption involves the generation and protection of unique DEKs for each
  encryption operation, under the same or multiple Master Keys. Decryption involves
  decryption of the encrypted DEKs with the Master Keys prior to actual ciphertext
  decryption. Typical of distributed computing fallacies such as The Network is
  Reliable, The Network is Secure, and Latency is Zero, this CSP Encryption/DLP
  model introduces two key risks:
  
  • Availability – Each crypto or redaction operation at the application level
    depends on connectivity between the applications and KMS or Google Cloud
    DLP. Network glitches or service unavailability will introduce failures
    (protect/write, or decrypt/read).
    
  • Performance – Every crypto or redaction operation requires a round trip to
    the KMS for DEK generation, encryption, and decryption. This introduces
    additional overhead and is subject to network latency, KMS or cloud HSM or
    Google Cloud DLP efficiency, and the overhead of multiple encryption
    operations (especially when asymmetric cryptography is used for DEK
    encryption/decryption). This does not scale for high-performance cloud
    workloads, bulk data processing, and delay-sensitive transactions.
    Note: When data needs to be decrypted, the application sends the encrypted
    DEKs to KMS for decryption and plaintext DEKs are returned to the application.
    CSPs do not state whether, once the KMS decrypts the DEKs and returns them to
    the application, those plaintext DEKs are deleted automatically or the application
    has to explicitly delete them.
    
    
  Google Cloud DLP also has APIs that applications can invoke to detect sensitive data
  using pre-defined rules, and then redact that data. The same risks with availability and
  performance lie with this model.