Page 64 – Encryption Consulting

Deep Dive on AWS-Key Management Service

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.

Google Cloud Platform’s Data Encryption Tools – KMS, HSMs, and PKIs

KMS, IAM, and DLP can also be integrated with Google Cloud Functions to encrypt data when uploaded to Google Cloud Storage automatically. Google Cloud Dataflow can use DLP and KMS to encrypt data automatically from several different storage locations. This shows how users can create their own, potentially more robust data encryption methods to assist in the storage of sensitive data on the Cloud.

Introduction

Data encryption, especially on the Cloud, is an extremely important part of any cybersecurity plan in today’s world. More companies migrate their data to the Cloud for its ease of use, reduced cost, and better security. The most prominent Cloud Service Providers (CSPs), like Google, Azure, and Amazon, all have different data encryption methods, but they are all secure and user-friendly.

How Data Encryption on the Cloud works

Cloud data resides in two places: in-transit and at-rest.

Data-in-transit encryption refers to using SSL or TLS to create a security “wrapper” around the data being moved. This ensures that it is more challenging to steal data-in-transit, but even if it were successfully stolen, it would be a confusing block of characters that would not make sense to the attacker. Most data-in-transit encryption is done through web browsers or FTP clients, so it does not need to be as managed as data-at-rest. Data-at-rest encryption is done when data is on a disk or another storage method. Similar to data-in-transit encryption, the data is jumbled into a random series of characters to stop attackers from stealing the plaintext.

GCP Provided Tools for Data Encryption

GCP uses AES-256 encryption by default when data is at-rest in Google Cloud Storage, and data-in-transit is encrypted with TLS by default. When encrypting data on the Cloud, GCP utilizes DEKs and KEKs, which are used and stored with Google’s Key Management Service (KMS) API. A DEK is a data encryption key, which is used to encrypt the data itself.

A KEK, or key-encryption key, is then used to encrypt the data encryption key to ensure an extra security layer. The KMS API works closely with other Google Cloud services, such as Cloud security services, Google Cloud Functions, etc, to store keys used for encryption and decryption on the Cloud. When other APIs attempt to access DEKs and KEKs, the user must first have the necessary permissions to access the keys. Services like IAM provide roles for users to be able to access KMS.

IAM, or Identity and Access Management, creates essential roles for services that they will need to work with different APIs within GCP. IAM offers another layer on top of KMS when protecting encrypted data. Administrators may create their roles for services and users, giving them more control in what they want access to certain users or services. IAM can also connect other GSuite applications, such as Gmail or Google Drive, to applications and services within a user’s Google Cloud account, further authenticating users.

Another example of a GCP API that assists in encrypting data is the Data Loss Prevention (DLP) API. This API can be used within or outside of Google Cloud and helps the user identify potentially sensitive data, such as Personally Identifiable Information, and mask that data from attackers. Google Cloud Platform users can integrate the KMS and DLP APIs to do encryption methods like Format Preserving Encryption, which encrypts data to be misunderstood while keeping the same formatting as the plaintext, allowing the PII data to be used with false values.

Conclusion

These methods and more allow users the freedom to manage their data encryption methods on the Google Cloud Platform. KMS, IAM, and DLP can also be integrated with Google Cloud Functions to encrypt data when uploaded to Google Cloud Storage automatically. Google Cloud Dataflow can use DLP and KMS to encrypt data automatically from several different storage locations. This shows how users can create their own, potentially more robust data encryption methods to assist in the storage of sensitive data on the Cloud.

Code Signing Architecture – What is Code Signing?

What is Code signing?

In the recent past, many technology firms are being targeted by hackers to tamper and corrupt the source code. These attacks heavily impact brand reputation and also leads to huge losses for firms victimized. To tackle this scenario, Code Signing technique can be used for safe guarding the code integrity and to provide authenticity of the author to the end user by providing digital signatures. Code Signing provides secure and trusted distribution of software preventing tampering, corruption and forgery. Code signing improves end-user confidence in software/code integrity and sender authenticity.

To explore the “Top 5 benefits of Code Signing“, please go through the blog article: www.encryptionconsulting.com/code-signing-top-5-benefits

Code Signing Architecture:

Code Signing Architecture provides a detailed explanation on how the Code Signing process works along with its components. Mentioned below are the four important differentiating components in the Code Signing Architecture.

Code Signing System (CSS)
Certificate Authority (CA)
Time Stamp Authority (TSA)
Verifier

These four components together will achieve the full cycle completion of the code signing process. Each component has a defined working process which is discussed in detailed below.

Code Signing System (CSS):

The Code Signing System (CSS) is the first and important component of Code Signing Architecture. Code signing system signs the submitted code using digital signature and authenticates the author. The digital signature is generated by CSS using private signing key and certificates. It is highly important to secure the private signing key and certificate from misuse and unauthorized access.

Certificate Authority (CA):

Developers or Source issuing code should use certificates from authentic certificate authorities (CA) as the certificate enables the process of authenticating the source. Certificates issued by authentic certificate authorities must comply with standard certificate policies such as NIST Interagency Report 7924 which specifies requirements to be followed by CAs while issuing certificates. Also, the developer requesting the certificate from authentic CAs has to provide supporting validation documents which would be verified before providing certificates. CA would follow guidelines mandated by standard agencies such as CA security council, CA/Browser Forum etc.

Time Stamp Authority (TSA)

An optional but important component in Code Signing Architecture is Time Stamp Authority (TSA). Time stamping preserves the source time when the code was signed and allows software to be accepted by the OS and other client device platforms even after the certificate expires. Signed software is validated with the source time when the certificate was signed rather than the current time. Hence, it is always advisable to use Time stamping technique while performing code signing. Digital signature signed code is sent to TSA for time stamping. TSA applies its own signature along with the valid source time stamp. TSA is independent from Code Signing System and synchronizes its clock with an authoritative time source.

Verifiers

End user using the code digitally signed by the publisher first initiates the process of verifying the signature. In general, verifiers are used to perform this step of validating the signatures and time stamp (if any). Verifiers leverage trust anchors to validate the signature on the signed code. Trust anchors are usually public keys of root certificate authorities (CA) installed securely on the verifying platform. In general, root CAs use standard architecture such as X.509 standard. If your organization is looking for implementation of Code signing, please consult [email protected] for further information

Code Signing – Best Practices

Introduction

Code Signing, as a technology, provides authenticity to the software codes, applications and/or files. This is done by signing the code using digital certificates and public key infrastructure. Hence, code signing provides assurance and trust to end users against code tampering or corruption. This is just one of the benefit of using code signing. To explore the “Top 5 benefits of Code Signing“, please go through the blog article: www.encryptionconsulting.com/code-signing-top-5-benefits

Every organization is expected to benefit a lot through code signing and this very reason makes this technology critical. One has to keep in mind the best practices to be followed while implementing code signing. Because when there is a breach of private keys of your company due to poorly implemented infrastructure, it not only impacts the customers but also the trust they have on your brand and its products.

Let’s take a look into the most critical best practices your company has to follow while implementing code signing technology:

Code Signing: Best Practices :

Separation of environments: Test signing and Release signing: One of the important code signing best practice is to set up a parallel environment for code signing infrastructure to sign test code with an internal test root Certificate Authority (CA). Internal test root CA would provide test certificates for signing the code. This benefits the firm in two ways, first benefit is limiting the exposure of actual private keys and code signing mechanisms to close group of users/developers and the other benefit is to opportunity to test the signed code for functionality bugs and vulnerabilities.
Test signing can be done in two ways:
- Test Certificate Signing Authority
- Self-signed certificates
Restricted access to Private keys through physical security: Systems with private keys have to have minimal access. As the saying goes, the most secure computer would be the one with minimum external connections. Hence, minimize the number of personnel having access to system with private keys used for code signing process.
Physical security is equally important for securing the sensitive data. In spite of all the virtual measures taken, if there is an employee or contractor who gains unwanted access can be a high threat. Physical measures such as cameras, fingerprint access, security guards etc. can be utilized for providing physical security.
Cryptographic hardware protection modules (HSMs): Cryptographic hardware protection modules restrict the export of private keys from these devices. Cryptographic modules are tamper proof and secure for storing keys that are used to sign digital certificates. There are three important types of cryptographic devices used for securing keys:
- Hardware Security Modules (HSMs)Smart cardsUSB tokens – Smart card device
Timestamp process: Public or Private: Time stamping process helps in verifying the authenticity of the publisher after the expiry of certificate. Public time stamping authority can be used for cost benefit but it is always suggested to use internal timestamp authority to avoid public network access.
Timestamp certificates can be issued for a maximum time period of 135 months. Strict measures has to be taken while you expose code signing process during external/public time stamping.
Scan the code for viruses: Code signing process helps in authenticating the code alone and cannot secure the code. Hence, it is always suggested to perform virus and malware scans before publishing the code and signing with digital certificates. Using virus/malware scan improves the quality of code as well.

If your organization is looking for implementation of Code signing, please consult [email protected] for further information

Code Signing- Potential Threats and Avenues of Attack

What is Code Signing?

If you are a CISO or holding an equivalent position for any organization, one of the biggest nightmares would be failure of line of defense for data security. One such important module relevant to data protection is “Code Signing”. Organizations have to be aware of threats posed to Code signing process and implement reasonable recommendations for tackling the issues.

According to a study conducted by Venafi, it is understood that out of 320 participants from USA, Europe and Canada more than 28% implement a defined code signing policy for protecting certificates used for signing code. There are high chances of forging and stealing of certificates by cyber hackers when proper policies are not enforced for code signing.

Let’s discuss few scenarios of threat landscape for “Code Signing” when appropriate code signing policy is not in place.

Potential Threats to Code Signing

Theft/Loss of Private Signing KeysPrivate signing keys have to be protected with utmost care. Many incidents are reported regularly due to theft of private signing keys. Cyber criminals with access to these signing keys might masquerade malware/malicious code as an authentic code or software. These incidents would cause huge financial loss as well as brand reputation loss. A single compromised private key can cause devastation to the entire firm’s business.
Real world incidents due to theft of private signing keys caused lot of damage for the affected firms. Governments also are affected by the loss of private keys and one of the classic examples is the attack on Malaysian Government during November 2011 where legitimate certificates stolen were used to sign malware.
Compromised Certificate AuthorityDirect attack launched on certificate authority (CA) issuing code signing certificates can cause severe damage to the firm using the certificates. Hence, it is always advisable to ensure the best practices are followed by CAs issuing certificates. Cyber attack incidents on CAs can even lead to the bankruptcy of the firm issuing certificates.
One such incident happened to a Dutch certificate authority – DigiNotar in 2011. Certificate Authority was compromised by hackers and issued fake certificates for many reputed websites which eventually resulted in bankruptcy of DigiNotar.

Best practice is to perform assessment on the vetting processes used by Certificate authority and data security measures in place before choosing the CA.
Use of insecure cryptography governance controls:Usage of weak and insecure cryptographic algorithms for code signing process would create vulnerabilities which can lead to cyber attacks such as brute force attack to hack keys used for code signing. Poor governance controls can cause intrusions into development and production systems. These security lapses can cause malicious code to be signed and authenticated.
CISOs should consider implementing proper governance controls to create secure environment. Also, performing appropriate assessment of code signing processes would avoid any unprecedented breach.

Venafi research survey on Code signing best practices and processes followed across US, Canada and Europe showed an astonishing picture about code signing landscape. More than 50% of the respondents across US, Canada and Europe either do not have code signing processes defined or implementing informal process with inconsistency. This is a huge alarming concern for CISOs.

35% of the respondents do not have clear owner for managing code signing private keys. In many cases, either development team or information security or both are managing private keys used for code signing.

It is the responsibility of CISOs to consider hiring an in-house team or a consulting firm who possess expertise in cryptography and code signing processes for better and secure implementation of “Code Signing”.

If your organization is looking for assessment and/or implementation of Code signing, please consult [email protected] for further information

Code Signing- Benefits and Basics

What is Code Signing?

Code signing is the process of authenticating software code/application/program/scripts to confirm the source of origin of the publisher and assure that the code has not been tampered or altered since it was signed.

Certificate Authorities (CA) confirm code signing source identity and bind their public key to a code signing certificate. This certificate enables validation of code sign with an authentic root certificate. Performing code sign will cater below three functions:

Provides authentication of code
Provides cryptographic protection
Software/code author validation

Top 5 benefits of “Code Signing”:

Let us take a look into the top 5 benefits users can enjoy by using “Code signing”:

Validates code integrity: Code signing provides integrity check of the code using hash function. Hash function is used at the source to sign the code and the same hash has to be matched at the destination. This provides proof of code integrity. If the hash is not matched, users would either receive a security warning or code will fail to download.
Verification can be performed using timestamp as well. Code signing certificates might include optional time stamp. Time stamp data strip is included along with signature during the time of signature. This process ensures the validity of certificate at the time of signature.
Issuing company reputation and authenticity:Using code signing process for authentication and validation of software, code and/or programs eliminates the risk of program corruption and tampering. This will safeguard the company’s reputation as well as intellectual property.
Enhancing trust on both sides of the transaction, companies can be more benefitted with customers trusting their software programs, files etc. for download. With increase in reputation one can expect considerable increase in customer loyalty.
Increase in revenue:Now a days, software publishers and network platform provides are increasingly mandating code signing process from a trusted source/certificate authority (CA) for distribution of software among users.
This is even more beneficial for small companies or individual developers to gain trust among customers through authenticity and increase their brand presence as well as revenue.
Safe and secure user experience:As already discussed in one of the points mentioned above, Code signing process builds mutual trust amongst both the parties i.e. vendor as well as consumer. On top of it, customers who use code signed software or files can be sure of security as the code is properly authenticated and validated which prevents code tampering.
Also, using code signing provides smooth user experience as there will be minimized security warnings and installation failures when code is signed by trusted certificate authority.
Seamless integration with multiple platforms:Code signing process is now available on multiple platforms such as Apple iOS, Windows, Linux, Android, JAVA, Adobe AIR etc. Many of these platforms highly recommend code signing process for code distribution.
Many browsers would require code signed using certificate from trusted certificate authority and reject any action commands provided through untrusted sources. One interesting fact is, Microsoft office macros and Firefox browser extensions also require code signing.

If your organization is looking for implementation of Code signing, please consult [email protected] for further information

Google Cloud Security – Data Encryption

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.

Introduction

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.

Google Cloud Security- Key Management Services

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.
Cloud HSM 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.

Cloud KMS 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.

Cloud KMS components

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

Project Google 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.

Cloud KMS 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

Cloud-based vs On-premises HSMs

As organizations step up their cloud journey as fast as possible to utilize the advantages of the cloud e.g. scalability, flexibility, cost-effectiveness, they have to parallelly think about data security in their IT landscape. This makes encryption, and subsequently HSMs, an inevitable component of an organization’s Cybersecurity strategy.Based on the use cases, we can classify HSMs into two categories: Cloud-based HSMs and On-Prem HSMsIn regards to the classification of HSMs (On-prem vs Cloud-based HSM), kindly be clear that the cryptographic technology is the same, but delivered via different methods.

Introduction

Encryption is one of the basic building blocks for any organization containing sensitive data/information. Sensitive data compliant with data privacy regulations creates a brand value for your organization as your organization becomes less prone to data breaches. As we all know the strength of the encryption depends upon two critical factors

Key length
Security of the Keys

Key length is quantifiable and could be determined using the various encryption algorithms such as AES-128 or AES-256. On the other hand, the Security of the key is a subjective matter. As we all know, the more secure the keys are, private keys in asymmetric and shared keys in symmetric encryption, the more powerful the encryption landscape is.

When it comes to the Security of Keys, the best bet is to use HSMs (Hardware Security Module) which are NIST compliant i.e. FIPS-140-2-Level3.

Cloud-based HSM vs. On-Premises HSM

In today’s article, we will compare Cloud-based HSM and On-prem HSM and try to Find an answer for what criteria a customer should choose as the appropriate option for their organization’s crypto security.

As organizations step up their cloud journey as fast as possible to utilize the advantages of the cloud e.g. scalability, flexibility, cost-effectiveness, they have to parallelly think about data security in their IT landscape. This makes encryption, and subsequently HSMs, an inevitable component of an organization’s Cybersecurity strategy. Based on the use cases, we can classify HSMs into two categories: Cloud-based HSMs and On-Prem HSMs in regards to the classification of HSMs (On-prem vs Cloud-based HSM), kindly be clear that the cryptographic technology is the same, but delivered via different methods.

On-prem HSMs are specifically useful for storing encryption keys when the organization wants complete control over their keys and policies without having any dependency on the Cloud Service Provider (CSPs). However, this comes at substantial upfront investment in terms of hardware, skilled resources, management software licenses managing the HSM cluster etc.

On-prem HSMs also make sense when an organization uses a secure application which is extremely sensitive to latency. The secure application uses an On-prem HSM only, thus avoiding the latency. Another important use case is where an application with intensive cryptographic operations is in use due to security best practices, technological designs, and/or performance requirements.

On-prem HSM is also beneficial to organizations which operate in countries with strict regulatory/compliance requirements on data localization, and where Cloud Service Providers (CSP) may not have a local datacenter in that geographic location. It also benefits organizations with foreseeable workloads, where it is highly unlikely that the business requirements and transaction volumes will exceed the capacity of the HSM in the near future.

On the other hand, Cloud-based HSMs offer out-and-out advantages of the cloud in addition to conventional features of HSMs. To dig deeper, we can further classify the Cloud-based HSM into two categories: Public Cloud HSM Services and Third- Party HSM Services.

Some Public Cloud HSM Services offer Single-tenant/dedicated or Multi-tenant services (e.g. AWS, Azure) whereas others offer only Multi-tenant services (e.g. GCP KMS, Oracle Key Vault) thus, these HSM Services are best suited for organizations which are dependent upon single Cloud Service Provider (CSP). In Third Party HSM Services, you can leverage multi-cloud platforms managed through the central management portal (e.g. DPoD) thus, these HSM Services are best suited for organizations with multi-cloud strategies.

These HSM Services also offer use-case-based modular services to lessen data protection cost. Some examples of these services are Key Vault, Oracle TDE (Transparent Data Encryption), Code/Digital Signing etc.

Comparison at a Glance

	Cloud-based HSM	On-Premises HSM
Hardware	No hardware required	# of hardware required including for resiliency, HA, Management Platform etc.
Payment Model	PAYG (pay-as-you-go)	Upfront Cost
Setup	Easy	Complex
Software	Included in the cost	Licenses may be required for each partition and Client Software
Client Deployment	Easy with CSP documentation	Complex and skill dependent
Compliance	Responsibility of CSP	Responsibility of the organization
Operational Overhead	Low as it’s a managed service from CSP	High as its managed by organization
SLA (Service Level Agreements)	Responsibility of CSP	Responsibility of organization
Operational Technical Knowledge	Medium with CSP’s documentation & vendor support	High as its managed by organization
Total Cost of Ownership	Low	High specifically for low # of partitions

*CSP: Cloud Service Provider

Conclusion

The HSM service is certainly a critical component while designing and deciding the data privacy measures for your organization’s PKI infrastructure. The decision between Cloud- based HSM or On-prem HSM is a function of TCO (total cost of ownership), number and complexity of the use cases, business, regulatory, legal compliances, foreseeable growth in the volume of the sensitive data, divergent data sources, and choice of business applications to name a few.

Although Cloud-based HSM Services are becoming more popular considering the fact that more and more organizations are jumping to the cloud for its numerous benefits. However, On-prem HSMs become critical in the case when Cloud Service Provider (CSPs) hit some limitations, although they are very few in the count.

To conclude, one thing remains consistently 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 data security. HSMs, whether On-prem or Cloud-based, are the best options today to fulfil that requirement.

Retain Control of your Encryption Keys on the Cloud

Want to centralize and simplify key management functions across multiple clouds, while retaining
control over your data and encryption keys?

What You Need to Know About Multi-Cloud Key Management

on Wednesday, October 28
at 11:00 a.m. CT.

What questions should you ask of your cloud provider?

What are critical architectural factors for
implementing cloud key management?

Public cloud vendors

Including AWS
Google Cloud Platform
Microsoft Azure

have their own solutions for encryption key management. While this establishes a high degree of security, organizations lose control over the keys.

Enter BYOK. The industry is trending toward giving customers more control over their cryptographic keys. All of the major cloud vendors now have support for Bring Your Own Key (BYOK), so that organizations can maintain control over the keys used for their data and applications, giving them greater data portability and flexibility. The ability to shift from one cloud provider to another — including multiple cloud providers at once — gives organizations options.

Especially when it comes to managing workloads, handling spikes and surges, and providing disaster recovery — not to mention satisfying audit requirements involving backup or redundancy capabilities.

How it works is keys are generated, escrowed, rotated, and retired in an on-premises or cloud hardware security module (HSM). A best practice is to use a FIPS 140-2 Level 3 HSM to more fully address compliance and reporting requirements.

While BYOK offers increased control, it also comes with additional key management responsibilities that are magnified in multi-cloud environments. Every cloud provider has its own set of APIs and its own cryptographic methods for transporting keys. Fundamentally, the processes, procedures and methods for managing keys are completely different across clouds, and not just from an API standpoint, but from architecture and process standpoints with each requiring different key management techniques.

What are best practices for multi-cloud ecosystems?

What are prerequisites for BYOK?

What You Need to Know About Multi-Cloud Key Management

to learn about key rotation best practices and how to manage the cryptographic key lifecycle.

Join us — Encryption Consulting and Futurex

on Wednesday, October 28
at 11:00 a.m. CT.

Code Signing Architecture – What is Code Signing?

What is Code signing?

Code Signing Architecture:

Code Signing System (CSS):

Certificate Authority (CA):

Enterprise Code-Signing Solution

Get One solution for all your software code-signing cryptographic needs with our code-signing solution.

Book A Demo

Time Stamp Authority (TSA)

Verifiers

Code Signing – Best Practices

Introduction

Code Signing: Best Practices :

Code Signing- Potential Threats and Avenues of Attack

What is Code Signing?

Potential Threats to Code Signing

Code Signing- Benefits and Basics

What is Code Signing?

Top 5 benefits of “Code Signing”: