Cryptographic keys Archives

Google Cloud Security- Key Management Services

by Anish Bhattacharya

Posted on October 31, 2020Last updated on August 18, 2022

In this article, we will take a closer look at Google’s Cloud Key Management Services. When users store data into Google Cloud, the data is automatically encrypted at rest. We use Google’s Cloud Key Management service to gain better control over managing the encrypted data-at-rest and encryption keys.

Source and Control of cryptographic keys

Cloud KMS lets users manage cryptographic keys in a central cloud service for direct use or use with other resources and applications. The keys that have to be used must be from one of these sources:

Cloud KMS’s software backed key gives users the ability to encrypt data with either a symmetric or asymmetric key that the users control.
CloudHSM provides hardware keys. Symmetric and asymmetric keys are only used in FIPS 140-2 Level 3 validated Hardware Security Modules(HSMs).
Bring Your Own Key(BYOK) is also available for users to import their cryptographic keys into Cloud KMS.
Cloud External Key Manager (Cloud EKM), which uses external Key Managers such as Thales or Fortanix can also be used.

Figure: Cloud EKM providing bridge between KMS and External Key Manager

Cryptographic keys in Cloud KMS

This section describes keys, key versions, and the grouping of keys into keyrings. The following diagram illustrates key groupings.

Key: A named object which represents a cryptographic key. It is a pointer to a key, and the actual bits or the key may change as we rotate the keys or create newer versions of the keys.

CloudKMS supports both asymmetric keys and symmetric keys. A symmetric key is used for symmetric encryption to protect some corpus of data, such as using AES-256 in GCM mode to encrypt a block of plaintext. An asymmetric key can be used for asymmetric encryption or for creating digital signatures.

Keyring: Keys are grouped into one keyring to organize the keys better. A keyring belongs to a specific Google Cloud project and resides in a particular location. Key inherit IAM policies from the keyrings that contains them.Grouping keys with related permissions in a keyring lets you grant, revoke, or modify permissions to those keys at the keyring level, without needing to act on each key individually. Keyrings provide convenience and categorization, but if the grouping of keyrings is not useful to you, you can manage permissions directly on keys.Key metadata: Resource names, properties of KMS resources such as IAM policies, key type, key size, key state, and any data derived from the above. Key metadata can be managed differently than the key material.

CloudKMS components

In this section, we discuss a few points about additional parameters associated to Google CloudKMS resources such as keys and keyrings.

ProjectGoogle Cloud KMS resources belong to Google Cloud Project, like all other Google Cloud Resources. Users can host data in a project that is different from the project in which Cloud KMS keys reside. This capability supports the best practice of separation of duties between the key administrators and data administrators.
LocationsWithin a project, Cloud KMS resources are created in one location.

Key Hierarchy

The following diagram illustrates the key hierarchy of Google’s internal Key Management Service. Cloud KMS leverages Google’s internal KMS in that Cloud KMS-encrypted keys are wrapped by Google KMS. Cloud KMS uses the same root of trust as Google KMS.

Data encryption key (DEK): A key used to encrypt data.
Key encryption key (KEK): A key used to encrypt, or wrap, a data encryption key. All Cloud KMS platform options (software, hardware, and external backends) let you control the key encryption key.
KMS Master Key: The key used to encrypt the key encryption keys (KEK). This key is distributed in memory. The KMS Master Key is backed up on hardware devices. This key is responsible for encrypting your keys.
Root KMS: Google’s internal key management service.

CloudKMS platform overview

The Cloud KMS platform supports multiple cryptographic algorithms and provides methods to encrypt and digitally sign using both hardware and software-backed keys.

The diagram shows the main components of the Cloud KMS platform.Administrators access key management services by using the Google Cloud Console, the gcloud command-line tool, or through applications implementing the REST or gRPC APIs.Applications access key management services using a REST API or gRPC.

Applications can use Google services that are enabled to use customer-managed encryption keys (CMEK). CMEK, in turn, uses the Cloud KMS API. The Cloud KMS API lets users use either software (Cloud KMS) or hardware (Cloud HSM) keys. Both software and hardware-based keys leverage Google’s redundant backup protections.

With the Cloud KMS platform, users can choose a protection level when creating a key to determine which key backend creates the key and performs all future cryptographic operations on that key.

The Cloud KMS platform provides two backends (excluding Cloud EKM), which are exposed in the Cloud KMS API as

Software Protection Level The protection level software applies to keys that may be unwrapped by a software security module to perform cryptographic operations.
HSM protection Level The protection level HSM applies to keys that can only be unwrapped by Hardware Security Modules that perform all cryptographic operations with the keys.

Google Cloud supports CMEK for several services, including

Cloud Storage
BigQuery
Compute Engine.

CMEK lets users use the Cloud KMS platform to manage the encryption keys that these services use to help protect their data.Cloud KMS cryptographic operations are performed by FIPS 140-2 validated modules.

Keys with protection level software, and the cryptographic operations performed with them, comply with FIPS 140-2 Level 1.
Keys with protection level HSM, and the cryptographic operations performed with them, comply with FIPS 140-2 Level 3.

References

www.cloud.google.com/kms/docs

www.cloud.google.com/security-key-management

www.cloud.google.com/sdk/gcloud/reference/kms

www.googleapis.dev/python/cloudkms/latest/UPGRADING.html

Tags:

About the Author

Anish Bhattacharya

Anish Bhattacharya is a Consultant at Encryption Consulting, working with PKIs, HSMs, creating Google Cloud applications, and working as a consultant with high-profile clients.

Cloud Key Management

Key Management – Recommendations and Best Practices

by Riley Dickens

Posted on September 26, 2020Last updated on August 16, 2022

Cryptographic keys are a vital part of any security system. They do everything from data encryption and decryption to user authentication. The compromise of any cryptographic key could lead to the collapse of an organization’s entire security infrastructure, allowing the attacker to decrypt sensitive data, authenticate themselves as privileged users, or give themselves access to other sources of classified information. Luckily, proper management of keys and their related components can ensure the safety of confidential information.

Key Management is the process of putting certain standards in place to ensure the security of cryptographic keys in an organization. Key Management deals with the creation, exchange, storage, deletion, and refreshing of keys, as well as the access members of an organization have to keys.

Primarily, symmetric keys are used to encrypt and decrypt data-at-rest, while data-in-motion is encrypted and decrypted with asymmetric keys. Symmetric keys are used for data-at-rest since symmetric encryption is quick and easy to use, which is helpful for clients accessing a database, but is less secure.

Since a more complicated and secure encryption is needed for data-in-motion, asymmetric keys are used.

The way symmetric key systems work and steps listed below.

A user contacts the storage system, a database, storage, etc, and requests encrypted data
The storage system requests the data encryption key (DEK) from the key manager API, which then verifies the validity of the certificates of the key manager API and the key manager
A secure TLS connection is then created, and the key manager uses a key encryption key (KEK) to decrypt the DEK which is sent to the storage systems through the key manager API
The data is then decrypted and sent as plaintext to the user

Asymmetric key systems work differently, due to their use of key pairs. The steps follow below:

The sender and recipient validate each other’s certificates via either their private certificate authority (CA) or an outside validation authority (VA)
The recipient then sends their public key to the sender, who encrypts the data to be sent with a one-time use symmetric key which is encrypted by the recipient’s public key and sent to the recipient along with the encrypted plaintext
The recipient decrypts the one-time use symmetric key with their own private key, and proceeds to decrypt the data with the unencrypted one-time use key

While these key systems do keep data secure, that makes the cryptographic keys the biggest sources of security concerns for an organization, which is where key management comes in.

To ensure strong security and uniformity across all government organizations, the National Institute of Standards and Technology (NIST) has created Federal Information Processing Standards (FIPS) and NIST Recommendations, referred to as NIST Standards, for sensitive and unclassified information in government organizations. These standards have security methods approved for all government data that is unclassified and sensitive.

Since these standards are approved for all of the government’s sensitive and unclassified data, this means they are best-practice methods for cryptographic key protection for non-governmental companies.

NIST Standards

The first security issue the NIST Standards review are cryptographic algorithms which are used for the encryption of data. Previously in this blog, symmetric and asymmetric cryptographic algorithms were discussed, but the NIST Standards only approve of a few specific types of these algorithms.

For symmetric algorithms, block cipher-based algorithms, such as AES, and hash function-based algorithms, like SHA-1 or SHA-256, are approved. Block cipher based algorithms iterate through a series of bits called blocks and uses different operations, such as XOR, to permutate the blocks over a series of rounds, leading to the creation of a ciphertext.

Hash function-based algorithms use hashes, which are one-way functions, to generate hash data. Asymmetric algorithms are all accepted, NIST says that “the private key should be under the sole control of the entity that “owns” the key pair,” however.Cryptographic hash functions, which do not use cryptographic keys, and Random Bit Generators (RBGs), which are used for key material generation, are also approved by NIST Standards. A list of all algorithms approved by NIST Standards can be found in FIPS 180 and SP 800-90 for hash functions and RBG respectively.
Also discussed by NIST Standards is how cryptographic keys should be used. The most important recommendation is that a unique key should be created at every key creation. A key should not be used for both authentication and decryption, a user should have a separate key for each use. NIST Standards gives advice on what a cryptoperiod should be set to. A cryptoperiod is the time span that a key can be used for its given purpose before it must be renewed or, preferably, replaced with a new key. For asymmetric-key pairs, each key has its own cryptoperiod. The cryptoperiod of the key used to create a digital signature is called the originator-usage period, while the other cryptoperiod is called the recipient-usage period. NIST Standards suggests that the two cryptoperiods begin at the same time, but the recipient-usage period can extend beyond the originator-usage period, not vice versa.

Conclusion

Key Management is one of the essential portions of cybersecurity, and therefore should be executed with all the best-practices in mind. Luckily, the government publishes the NIST Standards which recommend the best ways to minimize security risks related to cryptographic keys.

The NIST Standards discuss how keys should be used, what cryptographic algorithms are approved for government work, and what cryptoperiods for keys should be set to. As NIST Standards are updated, it is worth keeping track of to ensure your security system is always up to date.

About the Author

Riley Dickens

Riley Dickens is a Consultant at Encryption Consulting, working with PKIs, creating Google Cloud applications, and working as a consultant with high-profile clients.

Encryption

Cloud-Based VS On-Premises HSMs

by Puneet

Posted on January 22, 2020Last updated on August 22, 2022

Introduction

The adoption of Public Key Infrastructure (PKI) has been going up steadily in enterprises across industry sectors and has been described in earlier articles¹ . PKI mechanisms such as certificate-based authentication, encrypted communication, certificate management, code signing, and others all combine to ensure a secure enterprise. However, all the security benefits offered by PKI can come to naught if the private keys used for various purposes, are compromised. Therefore, the critical success factor (and biggest vulnerability) in PKI and any cryptography system is the safe storage and management of private keys. This is where a Hardware Security Module (HSM) comes in.

HSM Overview

An HSM is a specialized, dedicated, physical cryptographic device or ‘appliance’ designed and built for key lifecycle management – generation, storage, management and exchange of cryptographic keys. HSMs are also used for offloading of cryptographic functionality from application servers – examples being authentication, encryption, decryption, and digital signing. HSMs offer certified mechanisms for physical and logical security, tamper resistance, intrusion prevention and detection, event logging, and secure APIs to access the HSM. HSMs allow for the segregation of the cryptographic tasks from application business logic, with unparalleled performance for any cryptographic function. For example, while software running on the best hardware might achieve a few thousand digital signatures per second, an HSM can achieve millions.

Traditionally, HSMs were set up “on-premise” or within the enterprise data center. The prevalence of cloud computing, especially over the last few years, has seen the emergence of “Cloud based HSMs” or “HSM as a Service”. Regardless of the type whether on-premise or cloud based, enterprises need to keep some of the following features in mind while selecting an HSM.

Security:

Any HSM needs to be certified to international security standards such as Common Criteria and FIPS (Federal Information Processing Standards ). Certification provides the assurance that the design and build of the device meets certain basic criteria. While certification is necessary, it is not enough, and other criteria need to be considered while selecting an HSM.

User Interface (UI):

The UI for HSM administration is often command-line based. Some providers may have a centralized management portal with a graphical user interface (GUI) and dashboard, which can ease some of the administration tasks.

Algorithms:

Any HSM should provide a number of cryptographic algorithms (both symmetric and asymmetric) that can be used for multiple functions such as authentication, encryption, decryption, signing, timestamping, and others. A related factor can be future readiness such as support for new technologies like quantum cryptography.

Automation:

Once the HSM is deployed, ongoing maintenance and management tasks take up most of the administration work. Any automation features provided by the HSM vendor can be an advantage to reduce ongoing administration efforts and costs.

Earlier articles on PKI are available at https://www.encryptionconsulting.com/blog/

Key backup:

Backup of keys needs to be done to an environment that has similar security levels as provided by the HSM. Remote backup management and key replication are additional factors to be considered.

Integration:

The HSM is not a standalone entity and needs to work in conjunction with other applications. An important feature to evaluate therefore is the integration capabilities. Over time, since the HSM will need to support multiple applications, out-of-the box and proven integration interfaces with multiple applications can be a significant advantage.

Total Cost of Ownership (TCO):

On-premise HSMs will have a higher upfront investment or Capital Expenditure (Capex) and possibly lower annual costs. Cloud HSMs will have much lower or no Capex but may have higher annual costs or Operational Expenditure (Opex). The decision factor therefore typically is the TCO over a period of time, say five years. The cost factors to compute TCO include hardware, tools needed, network and security infrastructure, data center, operational model, payment model, software licenses, support, service levels, training, compliance, and personnel (staffing) costs.

Random Number Generation:

It is important that the HSM vendor uses an approved or certified process for Random Number Generation, since this could be a critical factor from a regulatory and compliance perspective.

Once the basic features are evaluated, the next step is to decide whether to invest in an on-premise or cloud based HSM. Some of the scenarios that can help enterprises make this decision are indicated below.

On-premise HSM

HSMs originated decades ago as physical devices that were built grounds up especially for cryptographic operations and deployed on-premise. The hardware, firmware, operating system, network access and overall functionality of an HSM were all designed to ensure that the devices were tamper-resistant and intrusion proof.

An on-premise HSM is a good option for enterprises with one or more of the following scenarios:

Large organizations which require complete and isolated control over their key management mechanisms, and who have a clear business case for the high investments needed in an on-premise HSM.
Applications which require very low latency, where an HSM being in the same data center as the application can make a big difference.
Applications with intensive cryptographic operations and a need for high performance, where offloading the cryptographic functions from an application server to a local HSM can result in a significant performance improvement for the application.
Organizations which operate in countries with strict requirements on data localization, and where cloud providers may not have a local data center in that geographic location.
Organizations with predictable workloads, where it is unlikely that the business requirements and transaction volumes will exceed the capacity of the HSM in the near future.

Cloud based HSM

A recent research report from Flexera indicates that around 94% of organizations today leverage some form of cloud services. As workloads of all types move to the cloud, HSMs are no exception. The simplicity, flexibility and agility offered by Cloud based HSMs make them an attractive value proposition, especially when enterprises face one or more of the following scenarios:

Small and medium organizations who already use a lot of cloud services and the high investments for on-premise HSMs may not be feasible.
Organizations who want to test or pilot multiple HSM services with minimal upfront investments, before committing to a vendor.
Organizations where the workloads are less and application performance and latency requirements may not require a dedicated, on-premise HSM.
Organizations with highly variable workloads which might require elasticity i.e. scaling up and scaling down of the HSM infrastructure.
Organizations who prefer a predictable, operational expenditure (Opex) based financial model offered by the cloud rather than high upfront capital investments needed by an on-premise HSM.

There are two types of cloud based HSMs: public cloud based, and third party. Both types offer the HSM-as-a-Service model. Depending on the vendor, both types may also offer single tenant as well as multi-tenant solutions, and additional key management services apart from HSMs. The main difference between the two cloud based HSMs is vendor lock-in. Public cloud based HSMs are typically tied to that public cloud provider such as AWS or Azure and are therefore suitable for enterprises which leverage only one public cloud provider. Third party cloud based HSMs usually work across multiple public cloud providers and therefore are a good choice for enterprises which have multi-cloud scenarios². Third party cloud HSMs, being specialized offerings, may also have more sophisticated features such as automation, scaling, back-ups, and better administration. In general, the choice of a cloud based HSM is closely linked with the enterprise cloud strategy.

Key Takeaways

The question “Which is a better option: an on-premise HSM or a cloud based HSM?” has no single answer. Enterprises will need to choose the best option depending on their use cases and business scenarios. One thing however remains clear: the benefits offered by Public Key Infrastructure (PKI) can be completely undermined if private keys are compromised. Protecting and managing those keys is therefore a critical requirement to ensure enterprise security. HSMs, whether on-premise or cloud based, are the best options today to fulfil that requirement.

A recent research report on cloud trends from Flexera indicates that more than 80% of organizations are moving to multi-cloud environments

Tags:

Cryptographic keys hardware security module HSM key lifecycle management

About the Author

Puneet

President at Encryption Consulting LLC focusing on providing consulting to customers in the Applied Cryptography space.

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Tag: Cryptographic keys

Google Cloud Security- Key Management Services

Source and Control of cryptographic keys

Cryptographic keys in Cloud KMS

CloudKMS components

Key Hierarchy