Google Cloud KMS Key Management Service

Google Cloud KMS Key Management Service

  • Google Cloud KMS – Key Management Service provides a centralized, scalable, fast cloud key management service to manage encryption keys
  • KMS helps apply hardware security modules (HSMs) effortlessly to the most sensitive data by just a toggle between software- and hardware-protected encryption keys with the press of a button.
  • KMS provides support for external keys using Cloud External Key Manager to protect the data in Google Cloud and separate the data from the key

Cloud KMS Keys, Keys Versions, and Key Rings

  • A Cloud KMS key is a named object containing one or more key versions, along with metadata for the key.
  • A key exists on exactly one key ring tied to a specific location.
  • After creation, a key cannot be moved to another location or exported.

Google Cloud KMS Keys, Key Rings, and Key VersionsKey

  • A named object representing a cryptographic key that is used for a specific purpose. The key material – the actual bits used for cryptographic operations – can change over time as new key versions are created
  • Key is the most important object for understanding KMS usage.
  • Key purpose and other attributes of the key are connected with and managed using the key.
  • IAM permissions and roles can be used to allow and deny access to keys
  • Cloud KMS supports both asymmetric keys and symmetric keys.
    • Symmetric key
      • is used for symmetric encryption to protect some corpus of data for e.g., using AES-256 to encrypt a block of plaintext.
    • Asymmetric key
      • consists of a public and private key.
      • can be used for asymmetric encryption, or for creating digital signatures.
  • Key’s type (symmetric or asymmetric) can’t be changed after key creation

Key Ring

  • A grouping of keys for organizational purposes.
  • Key ring belongs to Google Cloud project and resides in a specific location
  • Keys inherit IAM policies from the Key Ring that contains them.
  • Grouping keys with related permissions in a key ring allows you to grant, revoke, or modify permissions to those keys at the key ring level without needing to act on each key individually.
  • Key rings provide convenience and categorization
  • To prevent resource name collisions, a key ring cannot be deleted.
  • Key rings and keys do not have billable costs or quota limitations, so their continued existence does not affect costs or production limits.

Key Metadata

  • Includes resource names, properties of KMS resources such as IAM policies, key type, key size, key state, and any other derived data
  • Key metadata can be managed differently than the key material.

Key Version

  • Represents the key material associated with a key at some point in time.
  • Key version is the resource that contains the actual key material.
  • Granting access to a key also grants access to all of its enabled versions. Access to a key version cannot be managed.
  • A key version can be disabled or destroyed without affecting other versions
  • Disabling or destroying a key also disables or destroys each key version.
  • Versions are numbered sequentially, beginning with version 1.
  • When a key is rotated, a new key version is created with new key material.
  • The same logical key can have multiple versions over time, thus limiting the use of any single version.
  • Symmetric keys will always have a primary version. This version is used for encrypting by default, if not version is specified
  • Asymmetric keys do not have primary versions, and a version must be specified when using the key.
  • When Cloud KMS performs decryption using symmetric keys, it identifies automatically which key version is needed to perform the decryption.

Key States

  • A key version’s state is always one of the following:
    • Pending generation (PENDING_GENERATION)
      • Applies to asymmetric keys only
      • is still being generated and can’t be used, enabled, disabled, or destroyed yet.
      • KMS will automatically change the state to enabled as soon as the version is ready.
    • Enabled (ENABLED)
      • is ready for use.
    • Disabled (DISABLED)
      • may not be used, but the key material is still available, and the version can be placed back into the enabled state.
    • Scheduled for destruction (DESTROY_SCHEDULED):
      • is scheduled for destruction, and will be destroyed soon.
      • can be placed back into the disabled state.
    • Destroyed (DESTROYED)
      • is destroyed, and the key material is no longer stored in Cloud KMS.
      • If the key version was used
        • for asymmetric or symmetric encryption, any ciphertext encrypted with this version is not recoverable.
        • for digital signing, new signatures cannot be created.
      • may not leave the destroyed state once entered.
  • A key version can only be used when it is enabled.

Google Cloud KMS Key States

Key Rotation

  • For symmetric encryption, periodically and automatically rotating keys is a recommended security practice
  • Cloud MS does not support automatic rotation of asymmetric keys and has to be done manually
  • With key rotation, data encrypted with previous key versions is not automatically re-encrypted with the new key version.
  • Rotating keys provides several benefits:
    • Limiting the number of messages encrypted with the same key version helps prevent brute-force attacks enabled by cryptanalysis.
    • In the event that a key is compromised, regular rotation limits the number of actual messages vulnerable to compromise.
    • If you suspect that a key version is compromised, disable it and revoke access to it as soon as possible.
    • Regular key rotation helps validate the key rotation procedures before a real-life security incident occurs.
    • Regular key rotation ensures that the system is resilient to manual rotation, whether due to a security breach or the need to migrate your application to a stronger cryptographic algorithm.

Key Hierarchy

Google Cloud KMS Key Hierarchy

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

Cloud KMS Locations

  • Within a project, Cloud KMS resources can be created in one of many locations.
  • A key’s location impacts the performance of applications using the key
  • Regional
    • data centers exist in a specific geographical place
  • Dual-regional
    • data centers exist in two specific geographical places.
  • Multi-regional
    • data centers are spread across a general geographical area
  • Global
    • special multi-region with its data centers spread throughout the world
  • Reading and writing resources or associated metadata in dual-regional or multi-regional locations, including the global location may be slower than reading or writing from a single region.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

References

Google_Cloud_Key_Management_Service_KMS

AWS Key Management Service – KMS

AWS Key Management Service – KMS

  • AWS Key Management Service – KMS is a managed encryption service that allows the creation and control of encryption keys to enable data encryption.
  • KMS provides a highly available key storage, management, and auditing solution to encrypt the data across AWS services & within applications.
  • KMS uses hardware security modules (HSMs) to protect and validate the KMS keys by the FIPS 140-2 Cryptographic Module Validation Program.
  • KMS seamlessly integrates with several AWS services to make encrypting data in those services easy.
  • KMS is also integrated with AWS CloudTrail to provide encryption key usage logs to help meet auditing, regulatory and compliance needs.
  • KMS Keys are only stored and used in the region in which they are created. They cannot be transferred to another region.
  • KMS enforces usage and management policies, to control which IAM user, role from the account or other accounts can manage and use keys.
  • KMS can create and manage AWS KMS keys by
    • Create, edit, and view symmetric and asymmetric KMS keys, including HMAC keys.
    • Control access to the KMS keys by using key policies, IAM policies, and grants. AWS KMS supports attribute-based access control (ABAC). You can also refine policies by using condition keys.
    • Create, delete, list, and update aliases for the KMS keys.
    • Tag the KMS keys for identification, automation, and cost tracking.
    • Enable and disable KMS keys.
    • Enable and disable automatic rotation of the cryptographic material in KMS keys.
    • Delete KMS keys to complete the key lifecycle.
  • KMS supports the following cryptographic operations
    • Encrypt, decrypt, and re-encrypt data with symmetric or asymmetric KMS keys.
    • Sign and verify messages with asymmetric KMS keys.
    • Generate exportable symmetric data keys and asymmetric data key pairs.
    • Generate and verify HMAC codes. 
    • Generate random numbers suitable for cryptographic applications

Envelope encryption

  • AWS cloud services integrated with AWS KMS use a method called envelope encryption to protect the data.
  • Envelope encryption is an optimized method for encrypting data that uses two different keys (Master key and Data key)
  • With Envelop encryption
    • A data key is generated and used by the AWS service to encrypt each piece of data or resource.
    • Data key is encrypted under a master key defined in AWS KMS.
    • Encrypted data key is then stored by the AWS service.
    • For data decryption by the AWS service, the encrypted data key is passed to AWS KMS and decrypted under the master key that was originally encrypted so the service can then decrypt the data.
  • KMS does support sending data less than 4 KB to be encrypted, envelope encryption can offer significant performance benefits
  • When the data is encrypted directly with KMS it must be transferred over the network.
  • Envelope encryption reduces the network load for the application or AWS cloud service as Only the request and fulfilment of the data key through KMS must go over the network

KMS Service Concepts

KMS Usage
  • KMS Keys OR Customer Master Keys (CMKs)
    • AWS KMS key is a logical representation of a cryptographic key.
    • KMS Keys can be used to create and use symmetric or asymmetric KMS keys for encryption or signing OR HMAC KMS keys to generate and verify HMAC tags.
    • Symmetric KMS keys and the private keys of asymmetric KMS key never leave AWS KMS unencrypted.
    • A KMS key contains metadata, such as the key ID, key spec, key usage, creation date, description, key state and a reference to the key material that is used to run cryptographic operations with the KMS key.
    • Symmetric KMS keys are 256-bit AES keys that are not exportable.
    • KMS keys to encrypt and decrypt up to 4 KB (4096 bytes) of data
    • KMS keys can be used to generate, encrypt, and decrypt the data keys, used outside of AWS KMS to encrypt the data [Envelope Encryption]
  • Customer Keys and AWS Keys
    • AWS managed keys
      • KMS keys that AWS services create in your AWS account
      • keys are automatically rotated every 3 years 1 year (~365 days).
      • cannot manage these keys, rotate them, change their key policies or use them in cryptographic operations directly; the service that creates them uses them on your behalf.
    • Customer managed keys
      • KMS keys are created by you to encrypt your service resources in your account.
      • Automatic rotation is Optional and if enabled, keys are automatically rotated every year.
      • provides full control over these KMS keys, including establishing and maintaining their key policies, IAM policies, and grants, enabling and disabling them, rotating their cryptographic material, adding tags, creating aliases that refer to the KMS keys, and scheduling the KMS keys for deletion.
    • AWS Owned Keys
      • AWS owned keys are a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts.
      • AWS owned keys are not in your AWS account, however, an AWS service can use the associated AWS owned keys to protect the resources in your account.
      • cannot view, use, track, or audit them
  • Key Material
    • KMS keys contain a reference to the key material used to encrypt and decrypt data.
    • By default, AWS KMS generates the key material for a newly created KMS key.
    • KMS key can be created without key material and then import your own key material into that KMS key or created in the AWS CloudHSM cluster associated with an AWS KMS custom key store.
    • Key material cannot be extracted, exported, viewed, or managed.
    • Key material cannot be deleted; you must delete the KMS key.
  • Key Material Origin
    • Key material origin is a KMS key property that identifies the source of the key material in the KMS key.
    • Symmetric encryption KMS keys can have one of the following key material origin values.
      • AWS_KMS
        • AWS KMS creates and manages the key material for the KMS key in AWS KMS.
      • EXTERNAL
        • The KMS key has imported key material. 
        • Management and security of the key is the customer’s responsibility.
        • Only symmetric keys are supported.
        • Automatic rotation is not supported and needs to be manually rotated.
      • AWS_CLOUDHSM
        • AWS KMS created the key material for the KMS key in the AWS CloudHSM cluster associated with the custom key store.
  • Data Keys
    • Data keys are encryption keys that you can use to encrypt data, including large amounts of data and other data encryption keys.
    • AWS KMS does not store, manage, or track your data keys.
    • Data keys must be used by services outside of AWS KMS.
  • Encryption & Decryption Process
    • Use KMS to get encrypted and plaintext data key using CMK
    • Use the plaintext data key to encrypt the data and store the encrypted data key with the data.
    • Use KMS decrypt to get the plaintext data key and decrypt the data
    • Remove the plaintext data key from memory, once the operation is completed.
  • Key Policies
    • help determine who can use and manage those KMS keys.
    • can add, remove, or change permissions at any time for a customer managed key.
    • cannot edit the key policy for AWS managed keys.
  • Grants
    • provides permissions, an alternative to the key policy and IAM policy, that allows AWS principals to use the KMS keys.
    • are often used for temporary permissions because you can create one, use its permissions, and delete it without changing the key policies or IAM policies.
    • permissions specified in the grant might not take effect immediately due to eventual consistency
  • Grant Tokens
    • help mitigate the potential delay with grant.
    • use the grant token received in the response to CreateGrant API request to make the permissions in the grant take effect immediately.

KMS Working

  • KMS centrally manages and securely stores the keys
  • Keys can be generated or imported from the key management infrastructure (KMI).
  • Keys can be used from within the applications and supported AWS services to protect the data, but the key never leaves KMS AWS.
  • Data is submitted to AWS KMS to be encrypted, or decrypted, under keys that you control.
  • Usage policies on these keys can be set that determine which users can use them to encrypt and decrypt data.

KMS Access Control

  • Primary way to manage access to AWS KMS CMKs is with policies.
  • AWS KMS requires you to attach resource-based policies to the customer master keys (CMKs), called key policies
  • All KMS CMKs have a key policy.
  • KMS CMKs access can be controlled using
    • Use the key policy – use the key policy to control access to a CMK.
    • Use IAM policies with the key policy – use IAM policies in combination with the key policy to control access to a CMK. Controlling access this way enables you to manage all of the permissions for your IAM identities in IAM.
    • Use grants in combination with the key policy – use grants in combination with the key policy to allow access to a CMK. Controlling access this way enables you to allow access to the CMK in the key policy, and to allow users to delegate their access to others.
  • To allow access to a KMS CMK, a key policy MUST be used, either alone or in combination with IAM policies or grants. IAM policies by themselves are not sufficient to allow access to a CMK, though they can be used in combination with a CMK’s key policy.

Rotating Customer Master Keys

  • AWS KMS managed CMK
    • automatically rotated every 3 years 1 year.
  • CMKs with generated key material
    • supports automatic key rotation
    • keys are rotated every year
  • CMKs with imported key material or keys generated in a CloudHSM cluster using the KMS custom key store feature
    • do not support automatic key rotation
    • provides flexibility to manual rotate keys as required
  • for keys rotated automatically by KMS, data is not re-encrypted. KMS keeps previous versions of keys to use for decryption of data encrypted under an old version of a key. All new encryption requests against a key in AWS KMS are encrypted under the newest version of the key.
  • For manually rotated keys, data has to be re-encrypted depending on the application’s configuration
AWS Managed Key vs Customer Managed CMK

KMS Multi-Region Keys

  • AWS KMS supports multi-region keys, which are AWS KMS keys in different AWS Regions that can be used interchangeably – as though you had the same key in multiple Regions.
  • Multi-Region keys have the same key material and key ID, so data can be encrypted in one AWS Region and decrypted in a different AWS Region without re-encrypting or making a cross-Region call to AWS KMS.
  • Multi-Region keys never leave AWS KMS unencrypted.
  • Multi-Region keys are not global and each multi-region key needs to be replicated and managed independently.

KMS Features

  • Create keys with a unique alias and description
  • Import your own keys
  • Control which IAM users and roles can manage keys
  • Control which IAM users and roles can use keys to encrypt & decrypt data
  • Choose to have AWS KMS automatically rotate keys on an annual basis
  • Temporarily disable keys so they cannot be used by anyone
  • Re-enable disabled keys
  • Delete keys that you no longer use
  • Audit use of keys by inspecting logs in AWS CloudTrail

KMS vs CloudHSM

AWS KMS vs CloudHSM

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are designing a personal document-archiving solution for your global enterprise with thousands of employee. Each employee has potentially gigabytes of data to be backed up in this archiving solution. The solution will be exposed to he employees as an application, where they can just drag and drop their files to the archiving system. Employees can retrieve their archives through a web interface. The corporate network has high bandwidth AWS DirectConnect connectivity to AWS. You have regulatory requirements that all data needs to be encrypted before being uploaded to the cloud. How do you implement this in a highly available and cost efficient way?
    1. Manage encryption keys on-premise in an encrypted relational database. Set up an on-premises server with sufficient storage to temporarily store files and then upload them to Amazon S3, providing a client-side master key. (Storing temporary increases cost and not a high availability option)
    2. Manage encryption keys in a Hardware Security Module (HSM) appliance on-premise server with sufficient storage to temporarily store, encrypt, and upload files directly into amazon Glacier. (Not cost effective)
    3. Manage encryption keys in amazon Key Management Service (KMS), upload to amazon simple storage service (s3) with client-side encryption using a KMS customer master key ID and configure Amazon S3 lifecycle policies to store each object using the amazon glacier storage tier. (With CSE-KMS the encryption happens at client side before the object is upload to S3 and KMS is cost effective as well)
    4. Manage encryption keys in an AWS CloudHSM appliance. Encrypt files prior to uploading on the employee desktop and then upload directly into amazon glacier (Not cost effective)
  2. An AWS customer is deploying an application that is composed of an Auto Scaling group of EC2 Instances. The customers security policy requires that every outbound connection from these instances to any other service within the customers Virtual Private Cloud must be authenticated using a unique x 509 certificate that contains the specific instance-id. In addition an x 509 certificates must be designed by the customer’s Key management service in order to be trusted for authentication.
    Which of the following configurations will support these requirements?
    1. Configure an IAM Role that grants access to an Amazon S3 object containing a signed certificate and configure the Auto Scaling group to launch instances with this role. Have the instances bootstrap get the certificate from Amazon S3 upon first boot.
    2. Embed a certificate into the Amazon Machine Image that is used by the Auto Scaling group Have the launched instances generate a certificate signature request with the instance’s assigned instance-id to the Key management service for signature.
    3. Configure the Auto Scaling group to send an SNS notification of the launch of a new instance to the trusted key management service. Have the Key management service generate a signed certificate and send it directly to the newly launched instance.
    4. Configure the launched instances to generate a new certificate upon first boot. Have the Key management service poll the AutoScaling group for associated instances and send new instances a certificate signature that contains the specific instance-id.
  3. A company has a customer master key (CMK) with imported key materials. Company policy requires that all encryption keys must be rotated every year. What can be done to implement the above policy?
    1. Enable automatic key rotation annually for the CMK.
    2. Use AWS Command Line interface to create an AWS Lambda function to rotate the existing CMK annually.
    3. Import new key material to the existing CMK and manually rotate the CMK.
    4. Create a new CMK, import new key material to it, and point the key alias to the new CMK.
  4. An organization policy states that all encryption keys must be automatically rotated every 12 months. Which AWS Key Management Service (KMS) key type should be used to meet this requirement?
    1. AWS managed Customer Master Key (CMK)
    2. Customer managed CMK with AWS generated key material
    3. Customer managed CMK with imported key material
    4. AWS managed data key

References

AWS_Key_Management_Service