Data encryption Archives

Deep Dive on AWS-Key Management Service

by Dipanshu Bhatnagar

Posted on November 21, 2020Last updated on September 5, 2022

Read Time: 08 min

Data encryption on the cloud is the most prominent thought every security professional has in their mind these days. While performing data encryption, Security keys are of the utmost importance. When it comes to managing a single security key manually, it is relatively easy, however, if the number of security keys in use are huge, the task of managing those keys becomes cumbersome. Thus, the need arises for automated key management services for data encryption.

AWS KMS (Key Management Service) provides an easy to use WebUI to deal with the management of security keys to protect data-at-rest and data-in-use. AWS KMS is a placeholder for CMK (Customer Master Key) resources containing key metadata to encrypt & decrypt the data. Also, AWS KMS can be integrated with various other AWS services, such as Redshift, EBS, EFS, S3, and Secret Manager, to name a few.

In today’s post, we will discuss the key concepts of AWS KMS and its various features and integration with other AWS services.

Key Types

AWS Managed CMKsThese CMKs are created, managed and used by an AWS service integrated with KMS on behalf of the customer in theirs AWS account. For example, “aws/s3” is the default key in S3 and is used only for your account to encrypt your S3 buckets.
Customer Managed CMKsThese CMKs are created, managed and used by the customer in the AWS account. This is the most widely used method while using KMS, as it provides complete granular level access control over the security keys in an AWS account.
AWS Owned CMKsThese CMKs are owned and managed by AWS service/s for use in multiple AWS accounts. The key for these CMKs is not visible to users. For example, if you choose S3 default encryption, S3 uses its own KMS CMKs that are shared across multiple AWS accounts.

Data Keys

Data keys are encryption keys that the user can use to encrypt large amounts of data and other data encryption keys. Users can use AWS CMKs to generate, encrypt, and decrypt data keys. However, AWS KMS does not store, manage, or track the data keys or perform cryptographic operations with data keys. Users must use and manage data keys outside of AWS KMS’ scope.

Access Control to KMS CMKs

The primary way to control the access to your AWS KMS CMKs is with IAM & Key policies. Policy is a combination of declarative statements that describe who has access to what.

IAM PoliciesPolicies attached to an IAM identity are called identity-based policies.
Key PoliciesPolicies attached to resources are called resource-based policies.

In AWS KMS, you must attach resource-based policies to your CMKs i.e. key policies. IAM policies alone cannot permit access to CMKs to IAM users or roles.

Type of CMK	CMK management via IAM Policy	CMK management via Key Policy	Can view **CMK Metadata	Used only for specific user account	Automatic Rotation
Customer Managed	Yes	Yes	Yes	Yes	Optional*
AWS Managed	No	No	Yes	Yes	Every 3 Years
AWS Owned	No	No	No	No	Varies

* Be default “Automatic Rotation” is disabled, however, user can enable it upto 1 year.

** CMK Metadata is information about the CMK such as Key identifiers, Origin, KeyUsage, KeyState etc.

For example, the metadata type “Origin” signifies the source of the CMK’s key material. When this value is AWS_KMS, AWS KMS created the key material. When this value is EXTERNAL, the key material was imported from external key management infrastructure. When this value is AWS_CLOUDHSM, the key material was created in the AWS CloudHSM cluster associated with a custom key store.

Symmetric and Asymmetric CMKs:

AWS KMS protects the CMK that you use to protect your data and data keys. The CMKs are generated and used only in hardware security modules designed so that no one can access the plaintext key material.

AWS KMS supports symmetric and asymmetric CMKs:

Symmetric CMK: This represents a single 256-bit secret encryption key that never leaves AWS KMS unencrypted.
Asymmetric CMK: This represents a mathematically related public key and private key pair that you can use for encryption and decryption or signing and verification, but not both. The private key never leaves AWS KMS unencrypted. You can use the public key within AWS KMS by calling the AWS KMS API operations, or download the public key and use it outside of AWS KMS.

AWS KMS also provides symmetric data keys and asymmetric data key pairs that are designed to be used for client-side cryptography outside of AWS KMS. The symmetric data key and the private key in an asymmetric data key pair are protected by a symmetric CMK in AWS KMS.

KMS Custom Key store

A key store is a secure location for storing cryptographic keys. By default, the customer master keys (CMKs) that you create in AWS KMS are generated in and protected by hardware security modules (HSMs) that are FIPS 140-2 Level 2 compliant cryptographic modules. The CMKs never leave the modules unencrypted.

A custom key store is an AWS KMS resource that is associated with an AWS CloudHSM cluster backed by FIPS 140-2 Level 3 HSMs that are owned and managed by user.

When a user creates an AWS KMS CMK in their custom key store, AWS KMS generates a 256-bit, persistent, non-exportable Advanced Encryption Standard (AES) symmetric key in the associated AWS CloudHSM cluster. This key material never leaves your HSM unencrypted. When you use a CMK in a custom key store, the cryptographic operations are performed in the HSMs in the cluster.

What is Bring Your Own Key (BYOK):

A CMK is a logical representation of a master key in which the key material is generated and owned by the AWS. However, users can create a CMK without any key material, and then import external key material into that CMK. This is known as BYOK i.e. Bring Your Own Key

Imported key material is supported for symmetric CMK in AWS KMS key stores; however, this is not supported for asymmetric CMK and Custom Key stores as well.

When imported key material is used, the users remain responsible for the key material while allowing AWS KMS to use a copy of it. This is a common use case where the user wants to have complete control over the key material for regulatory/business/compliance/legal purpose.

Conclusion

AWS KMS is a widely used KMS service among all the KMS as-a-service options available from Cloud vendors. Since AWS KMS provides multiple options for CMKs, it becomes difficult to decide at times which option one should choose under different scenarios. Considering the functionality and feature set available in each CMK, if a user wants to use a key available to all IAM entities in its AWS account, AWS Managed CMK is better choice as the CMK is available for all the IAM users in the same account. However, if user wants to have a granular access control over keys then Customer Managed CMK or BYOK appears to be a better option.

Tags:

About the Author

Dipanshu Bhatnagar

Dipanshu Bhatnagar is a Principal Consultant Cloud Security Specialty at Encryption Consulting working with PKIs, AWS Cloud Cryptographic services and tools, Google Cloud Cryptographic Services, and helping high profile clients towards their cloud journey with complete data privacy assurance.

Cloud Key Management

Google Cloud Security – Data Encryption

by Parnashree Saha

Posted on November 7, 2020Last updated on September 9, 2022

Read time: 5 mins

Encryption is a process that takes plaintext as input and transforms it into an output (ciphertext) that reveals no information about the plaintext. Encryption adds a layer of defense for protecting data and ensures that if the data accidentally falls into an attacker’s hands, they cannot access the data without having access to the encryption keys. Even if an attacker obtains the storage devices containing your data, they will not be able to understand or decrypt it.

Data Encryption Options

Cloud storage encrypts data on the server-side before it is written to disk, at no additional charge. Besides this standard, there are additional ways to encrypt the data while using Cloud Storage.

Below are the available encryption options for Google Cloud:

Server-side encryption

Google Cloud Storage performs server-side encryption by default on all uploaded objects. All data is broken into chunks which can be up to several GB in size. Using envelope encryption, each chunk of data is encrypted with a unique Data Encryption Key (DEK) that is also encrypted with a Key Encryption Key (KEK). The encrypted version of the DEK is then stored alongside the encrypted data, and the encrypted chunks of data are distributed across Google’s storage systems

Google Cloud Storage supports server-side encryption with two key options:

Customer-supplied encryption keys

With the customer-supplied encryption key (CSEK) option, users must generate their own AES 256
symmetric key and provide it to google cloud storage for encryption/decryption operations. The CSEK is only stored in storage system memory and never persisted on any Google Cloud device

Cloud storage does not permanently store user’s key on Google’s servers or otherwise manage user’s key. Instead, the user provide key for each cloud storage operation, and the key is purged from Google’s server after completion of the operation. The customer-supplied encryption key is hashed and then purged from the storage system. The cryptographic hash is used to validate (future requests) but cannot be used to decrypt data or to reconstruct a key When the customer supplies the encryption key, cloud storage uses the key while encrypting

the object data
the object’s checksum
the object’s hash

Cloud Storage uses standard server-side keys to encrypt the remaining metadata for the object, including the object’s name.Encryption and Decryption workflow mentioned below:

The CSEK is provided to Google Cloud Storage along with the data upload
Data is broken into sub-file chunks
A Google Cloud Storage system calls a common cryptographic library that Google maintains, called CrunchyCrypt, to generate a unique, one-time key called DEK
Each data chunk is encrypted using a DEK
The storage system then uses the CSEK as the KEK and encrypts the DEK
The encrypted DEK is stored alongside the ciphertext chunk it encrypted in Google Cloud Storage while the plaintext version of the DEK is deleted from memory
The customer-supplied encryption key is hashed and then purged from the storage system. The cryptographic hash is used to validate future requests but cannot be used to decrypt data or reconstruct the key
The client or application requests data from Google Cloud Storage while supplying the CSEK
Google Cloud Storage identifies the chunks in which the data is stored and where the chunks reside and retrieves the chunks
For each data chunk, the storage system retrieves the encrypted DEK and decrypts it using the CSEK
Once the decryption is done using DEK, the storage system discards the DEK and sends the decrypted data to the client or application that requested the data

Customer-managed encryption keys:

Customer-managed encryption keys are keys generated for users by Cloud Key Management Service (KMS), that the user manages themselves. These keys act as an additional encryption layer on top of the standard Cloud Storage encryption.The encryption and decryption workflow:

Data is broken into sub-file chunks after being uploaded to Google Cloud
A Google Cloud Storage system calls a common cryptographic library that Google maintains, called CrunchyCrypt, to generate a unique one-time use DEK
Each data chunk is encrypted using a DEK
The storage system then sends the DEK to Google’s Key Management Service (KMS) to be encrypted using that storage system’s associated Key Encryption Key (KEK)
The encrypted DEK is stored alongside the ciphertext chunk it encrypted in Google Cloud Storage while the plaintext version of the DEK is deleted from memory
When data is requested, Google Cloud Storage identifies the chunks in which the data is stored and where the chunks reside and retrieves the chunks
For each data chunk, the storage system retrieves the encrypted DEK and sends it to Google’s KMS for decryption
KMS sends the decrypted DEK to the storage system where it is used to decrypt the data
The storage system discards the DEK and sends the decrypted data to the client that requested the data

Client-side encryption:

With this option, Users create and manages its own encryption keys. Users must encrypt the data before sending it to cloud storage. The encrypted data on the client side arrives at cloud storage in an encrypted state. When cloud storage receives the data, one more time the data will be encrypted. This second encryption is called server-side encryption, which Cloud Storage manages. While retrieving the data, cloud storage removes the server-side layer of encryption, but user must decrypt the client-side layer by themselves.

Benefits

Customer-managed keys provide the following benefits:

More Control over Data Access:
- Customer-managed keys provide an extra level of security for customers with sensitive data.
- When the customer decides to disable access, data can no longer be decrypted
Stop Data Breaches:
- In this case, disabling customer-managed keys will allows customers to stop ongoing exfiltration of their data
More Control over Data Lifecycle:
- Using customer-managed keys, sensitive data is encrypted with the customer’s key. Without customer’s/users consent no one can decrypt the data
- The customer has full control over the data’s lifecycle
Secure
- Compute assets are encrypted using the industry-leading AES-256 standard, and Google never retains users’ keys, meaning Google cannot decrypt user’s data at rest.
Comprehensive
- Customer-Supplied Encryption Keys cover all forms of data at rest for Compute Engine, including boot and data persistent disks.
Fast
- Google Compute Engine is already encrypting user’s data at rest, and Customer-Supplied Encryption Keys gives user greater control, without additional overhead.

Tags:

Data encryption data security google cloud google cloud platform

About the Author

Parnashree Saha

Parnashree Saha is a data protection senior consultant at Encryption Consulting LLC working with PKI, AWS cryptographic services, GCP cryptographic services, and other data protection solutions such as Vormetric, Voltage etc.

Cloud Key Management

Format Preserving Encryption with NIST recommendations

by Anish Bhattacharya

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

In 2014, JPMorgan Chase was under a massive cyber- attack in which the data of 76 million private customers and 7 million business customers was leaked. The attacker was able to get administrative rights due to non-functional two-factor authentication and was able to access user data. The webserver and the web application were secured, but the database remained unencrypted where the data was copied from.

If Format Preserving Encryption had been used, this situation could have been mitigated. With FPE, there would not have been any change to the database schema, and the encryption could be integrated on the fly.

What is Format Preserving Encryption?

For basic information in regard to FPE, please refer to this link

To give you some context, Format Preserving Encryption or FPE is an encryption algorithm used to preserve the format of the clear text while it remains encrypted. However, the strength of FPE is lower compared to AES. FPE is, however, an important mechanism for encrypting data whilst preserving the data length. FPE ensures that while data remains encrypted, all programs, applications and databases continue to be functional.

Why use Format Preserving Encryption?

Implementing a perfectly secure network is harder than just encrypting your data. Encrypting data is cheaper, easier, more secure, and thus better in every way imaginable.There are many organizations with a legacy infrastructure which may not be as secure. Thus, protecting all of the data in the legacy network protects the data even if the network gets compromised. This change can be made with almost no impact to existing infrastructure.Even if the organization has a robust infrastructure, it may face issues while the data is under audit. No one wants to reveal raw customer data which may put their reputation under seize. Thus FPE can be used to de- identify all data, remove all PII (Personal Identifiable Information) of customers and would serve as an extra defence mechanism when data is breached. –

As per NIST 800-38G:

Format-preserving encryption (FPE) is designed for data that is not necessarily binary. In particular, given any finite set of symbols, like the decimal numerals, a method for FPE transforms data that is formatted as a sequence of the symbols in such a way that the encrypted form of the data has the same format, including the length, as the original data. Thus, an FPE encrypted SSN would be a sequence of nine decimal digits.

So, if we convert a 16-digit credit-card number it will return another 16-digit value. A 9-digit Social Security Number would return another 9-digit value.This cannot be achieved with other modes of encryption, such as AES where if we encrypt a credit card it will look like 0B6X8rMr058Ow+z3Ju5wimxYERpomz402++zNozLhv w= which is greater than 16 digits and has not just numbers inside it.This kind of output would not work in most systems or databases where we must follow strict data types. Thus if it expects 16 digit numbers, this type of output would not suffice and may even result in a system-wide crash.

NIST SP 800-38G recommends ways through which we can encrypt this sensitive data in the databases. These solutions would also follow FIPS 140-2. So if someone wishes to use FPE, they can rest assured that they would be following almost all regulations and standards which would be enough to satisfy regulatory requirements of HIPAA, PCI DSS etc.

Now, since we talked about why to use FPE regardless of using a legacy network, let us talk about FPE provided by Google Cloud Platform, and what benefit it provides over other platforms.

FPE By Google Cloud

Firstly, Google is the only cloud provider currently who is providing FPE through their DLP APIs. Now, most of the organizations are currently transitioning to the cloud, but to make that transition happen securely, data should stay encrypted while in transit.

To do that, Google provides FPE under Cloud Data Loss Prevention. Using DLP API, customers can encrypt their data using FPE and de-identify information using predefined info types such as Credit card numbers, phone numbers, etc.This would encrypt the data, and make it safer to transition to the cloud. The transfer of data from a datacenter to a database on the cloud would also maintain their referential integrity as well as their format.

Conclusion

FPE is an encryption mechanism that keeps data encrypted while databases and applications remain functional. FPE preserves the format of the data which allows legacy systems and networks to remain functional while data is encrypted. GCP provides a DLP API which offers FPE through their platform. This helps in making all types of systems and programs functional/available and also improves data auditability by removing all PII data within it.

Sources:

https://www.bbc.com/news/business-29470381

Tags:

Data encryption format preserving encryption fpe NIST

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.

Education Center, Encryption Basics

What is an HSM? What are the benefits of using an HSM?

by Puneet

Posted on September 23, 2020Last updated on December 16, 2022

Table of Contents

What is an HSM?
Types of HSMs
Compliance
Advantages to HSMs

Today more than ever, organizations have a need for high level security of their data and the keys that protect that data. The lifecycle of cryptographic keys also requires a high degree of management, thus automation of key lifecycle management is ideal for the majority of companies. This is where Hardware Security Modules, or HSMs, come in. HSMs provide a dedicated, secure, tamper-resistant environment to protect cryptographic keys and data, and to automate the lifecycle of those same keys. But what is an HSM, and how does an HSM work?

What is an HSM?

A Hardware Security Module is a specialized, highly trusted physical device which performs all major cryptographic operations, including encryption, decryption, authentication, key management, key exchange, and more. HSMs are specialized security devices, with the sole objective of hiding and protecting cryptographic materials. They have a robust OS and restricted network access protected via a firewall. HSMs are also tamper-resistant and tamper-evident devices. One of the reasons HSMs are so secure is because they have strictly controlled access, and are virtually impossible to compromise.

For these reasons and more, HSMs are considered the Root of Trust in many organizations. The Root of Trust is a source in a cryptographic system that can be relied upon at all times. The strict security measures used within an HSM allow it to be the perfect Root of Trust in any organization’s security infrastructure. Hardware Security Modules can generate, rotate, and protect keys, and those keys generated by the HSM are always random. HSMs contain a piece of hardware that makes it possible for its computer to generate truly random keys, as opposed to a regular computer which cannot create a truly random key. HSMs are also generally kept off the organization’s computer network, to further defend against breach. This means an attacker would need physical access to the HSM to even view the protected data.

Types of HSMs

There are two main types of Hardware Security Module:

General Purpose: General Purpose HSMs can utilize the most common encryption algorithms, such as PKCS#11, CAPI, CNG, and more, and are primarily used with Public Key Infrastructures, cryptowallets, and other basic sensitive data.
Payment and Transaction: The other type of HSM is a payment and transaction HSM. These types of HSM are created with the protection of payment card information and other types of sensitive transaction information in mind. These types of Hardware Security Module are narrower in the types of organizations they can work within, but they are ideal to help comply with Payment Card Industry Data Security Standards (PCI DSS).

Compliance

As HSMs are used so often for security, many standards and regulations have been put in place to ensure Hardware Security Modules are properly protecting sensitive data. The first of these regulations is the Federal Information Processing Standard (FIPS) 140-2. This a standard that validates the effectiveness of hardware performing cryptographic operations. FIPS 140-2 is a federal standard in both the USA and Canada, is recognized around the world in both the public and private sectors, and has 4 different levels of compliance.

Level 1, the lowest level, focuses on ensuring the device has basic security methods, such as one cryptographic algorithm, and it allows the use of a general purpose model with any operating system. The requirements for FIPS 140-2 level 1 are extremely limited, just enough to provide some amount of security for sensitive data.
Level 2 builds off of level 1 by also requiring a tamper-evident device, role-based authentication, and an operating system that is Common Criteria EAL2 approved.
Level 3 requires everything that level 2 does along with tamper-resistance, tamper-response, and identity-based authentication. Private keys can only be imported or exported in their encrypted form, and a logical separation of interfaces where critical security parameters leave and enter the system. FIPS 140-2 level 3 is the most commonly sought compliance level, as it ensures the strength of the device, while not being as restrictive as FIPS 140-2 .
Level 4 is the most restrictive FIPS level, advanced intrusion protection hardware and is designed for products operating in physically unprotected environments. Another standard used to test the security of HSMs is Common Criteria (ISO/IEC 15408). Common Criteria is a certification standard for IT products and system security. It is recognized all around the world, and come in 7 levels. Like FIPS 140-2, level 1 is the lowest level, and level 7 is the highest level.
The final standard is the Payment Card Industry PTS HSM Security Requirements. This is a more in-depth standard, focusing on the management, shipment, creation, usage, and destruction of HSMs used with sensitive financial data and transactions.

The final standard is the Payment Card Industry PTS HSM Security Requirements. This is a more in-depth standard, focusing on the management, shipment, creation, usage, and destruction of HSMs used with sensitive financial data and transactions.

Advantages to HSMs

Hardware Security Modules have a number of benefits including:

Meeting security standards and regulations
High levels of trust and authentication
Tamper-resistant, tamper-evident, and tamper-proof systems to provide extremely secure physical systems
Providing the highest level of security for sensitive data and cryptographic keys on the market
Quick and efficient automated lifecycle tasks for cryptographic keys
Storage of cryptokeys in one place, as opposed to several different locations

Tags:

Data encryption data security FIPS hardware security module HSM key management PCI-DSS

About the Author

Puneet

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

Cloud Key Management

Format Preserving Encryption (FPE) – Usage on GCP

by Riley Dickens

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

Online data security has always been important, but never more so than now. With more and more of our data being stored on the cloud, users need to look for the best security solutions to ensure their confidential information is secure. While all parts of online data security are necessary to secure data, arguably the most important portion is data encryption.

This is why more and more cloud services are using a type of encryption called Format-Preserving Encryption.

What is Format-Preserving Encryption?

If your company has multiple 16-digit credit card numbers stored in a database, but the encrypted ciphertext needs to be 16-digits as well after encryption, this is where Format-Preserving Encryption [FPE] comes in.FPE encrypts plaintext that is a certain length and produces a ciphertext that is the same length as the plaintext and uses the same set of values as the plaintext. Using the previous example of a 16-digit credit card number with a plaintext of 1483920193402918, the ciphertext created with FPE could produce an output of 1483666666662918.

By using FPE, you can see that the ciphertext and plaintext are the same length and only use numerical values for encryption. One cloud provider that lets users implement FPE in their encryption is Google Cloud.

Format-Preserving Encryption in Google Cloud

Google Cloud gives users access to a de-identification technique called pseudonymization. Pseudonymization is a technique that replaces sensitive data with cryptographically generated tokens. Google Cloud supports three different pseudonymization techniques:

Deterministic encryption using AES-SIV
Format-Preserving Encryption
Cryptographic hashing

All three techniques use cryptographic keys for data transformation, but we will focus on the Format-Preserving Encryption.
Google Cloud uses a type of FPE called FPE-FFX. FFX focuses on two different FPE methods,FF1 and FF3, to encrypt data.At the time of writing this, FF1 is the only method currently supported for encryption. FF2 did not make it to publication at the time of FFX’s creation. FF2 and FF3 derivations are being resubmitted, but after a cryptanalytic attack in 2017, FF3 was considered to be too insecure.FFX uses multiple rounds of a Feistel function on the plaintext, along with the use of a key, to create the ciphertext. A Feistel function splits the plaintext into two parts and does a permutation each round on each half of the plaintext, and then swaps the left half of text to the right and vice versa. The FF1 method uses 10 rounds of the Feistel function, and FF3 uses 8 rounds of the Feistel function. FPE-FFX has several steps necessary to encrypt data.To begin encryption, the alphabet being used to de-identify the data must be specified in one of three ways:

Using one of four values that represent the most common character sets/alphabets
Using a radix value specifying the size of the alphabet. Specifying 2 gives an alphabet consisting of the numbers 0 and 1, while specifying 95 gives an alphabet with all numeric, upper-case alpha, lower-case alpha, and symbol characters
By building an alphabet containing the exact characters to be used

When using FPE-FFX in Google Cloud, the data is encrypted as previously described, but can also be prepended with a surrogate annotation, resulting in a final token. The token takes the following form when a surrogate annotation is included: surrogate_infotype(surrogate_length): surrogate_value. The surrogate annotation is surrogate_infotype(surrogate_length). The infotype is defined by the user and the surrogate value is the resulting ciphertext. If no surrogate annotation is specified, then the final token is just the surrogate value. To re-identify unstructured data, the full token, including a surrogate annotation, is necessary, while structured data only needs the surrogate value.

Conclusion

Format preserving encryption is extremely important for users who wish to keep the ciphertext after encryption as the same length as the plaintext. Of the several different FPE-FFX methods used on Google Cloud, FF1 is the best practice method to use, due to the extra rounds of the Feistel function it goes through.

Structured data requires a surrogate annotation be prepended on the ciphertext to allow for re-identification of data. Google Cloud has a strong implementation of FPE in place for customer use. For those in need of same length plaintext and ciphertext, Google Cloud’s FPE-FFX is their best choice.

Tags:

Data encryption data security format preserving encryption fpe GCP google cloud platform

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.

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.

Key Types

Data Keys

Access Control to KMS CMKs

AWS KMS supports symmetric and asymmetric CMKs:

KMS Custom Key store

What is Bring Your Own Key (BYOK):

Conclusion

Tags:

Datasheet of Encryption Consulting Services

About the Author

You might also be interested in

Subscribe to our newsletter

Explore More Topics

Data Encryption Options

Below are the available encryption options for Google Cloud:

Server-side encryption

Google Cloud Storage supports server-side encryption with two key options:

Customer-supplied encryption keys

Customer-managed encryption keys:

Client-side encryption:

Benefits

Tags:

Datasheet of Encryption Consulting Services

About the Author

You might also be interested in

Subscribe to our newsletter

Explore More Topics

What is Format Preserving Encryption?

Why use Format Preserving Encryption?

FPE By Google Cloud

Conclusion

Sources:

Tags:

Datasheet of Encryption Consulting Services

About the Author

You might also be interested in

Subscribe to our newsletter

Explore More Topics

What is an HSM?

Types of HSMs

Compliance

Advantages to HSMs

Tags:

Datasheet of Encryption Consulting Services

About the Author

You might also be interested in

Subscribe to our newsletter

Explore More Topics

What is Format-Preserving Encryption?

Format-Preserving Encryption in Google Cloud

Conclusion

Tags:

Datasheet of Encryption Consulting Services

About the Author

You might also be interested in

Subscribe to our newsletter

Explore More Topics

Ready to get started?