The Bring Your Own Encryption (BYOE) concept is the desired trust model for organizations that require full control over access to their data regardless of where it is stored or processed.
Regulated industries, such as financial services and healthcare, require keys to be segregated from the cloud Data Warehouse compute and storage infrastructure. BYOE enables organizations to comply with this requirement with encryption applied to the most sensitive columns, and dynamic masking or filtering access to other sensitive columns – achieving the optimal balance between data protection, compliance, analytics and usability of the data.
Without exposing encryption keys or sensitive data to the cloud, BYOE enhances the security of data within all cloud services such as Database as a Service (DBaaS) environments, as data is always encrypted before being sent to the cloud.
There is an increased latency problem as any data element has to go through repeated cycles of encryption and decryption for utilization in cloud environments, thereby inducing latency related issues.
As there are limited interfaces available, there is a requirement to build Custom API’s for integration with multiple cloud service providers, which might not be feasible for a small/medium sized organizations.
As the organizations adopt a move to cloud approach, this approach puts increasing pressure on the on-premises infrastructure with respect to scaling, performance, etc.
Bring Your Own Key-Cloud HSM
No Key exposure outside the HSM.
FIPS advanced level (FIPS 140-2 Level 3 and above) complaint hardware-based devices meeting all regulatory requirements.
Can perform all core functions of an on-premises HSM: key generation, key storage, key rotation, and APIs to orchestrate encryption in the cloud.
Designed for security.
Dedicated hardware and software for security functions.
Need specialized, in-house resources to manage key and crypto lifecycle activities.
HSM-based approaches are more cost intensive due to the use of a dedicated hardware appliance.
Bring Your Own Key-Cloud KMS
No specialized skilled resources are required.
Enables existing products that need keys to use cryptography.
Provides a centralized point to manage keys across heterogeneous products.
Native integration with other services such as system administration, databases, storage and application development tools offered by the cloud provider.
Key exposure outside HSM.
FIPS 140-2 Level 3 and above devices not available.
Software Key Manage-ment
With this approach, service accounts, generic administrative accounts which may be assumed by one or more users, can access these secrets, but no one else.
Not compliant with regulatory requirements which specify FIPS-certified hardware.
Run the organizations own key management application in the cloud.
Lower cost than HSMs and full control of key services, rather than delegating them to your cloud provider.
Can perform all core functions of an HSM: key generation, key storage, key rotation, and APIs to orchestrate encryption in the cloud.
Encryption key management software is used to handle the administration, distribution, and storage of encryption keys. Proper management will ensure encryption keys, and therefore the encryption and decryption of their sensitive information, are only accessible for approved parties. IT and security professionals use these solutions to ensure access to sensitive data remains secure.
Encryption key management software also provides tools to protect the keys in storage and backup functionality to prevent data loss. Additionally, encryption key management software includes functionality to securely distribute keys to approved parties and enforce key sharing policies.
Certain general encryption software provides key management capabilities. Still, those solutions will only offer limited features for key management, distribution, and policy enforcement.
To qualify for inclusion in the Encryption Key Management category, a product must:
Provide compliance management capabilities for encryption keys
Include key storage and backup functionality
Enforce security policies related to key storage and distribution
A software key management approach can be used instead of an HSM based SaaS approach or a cloud KMS approach. Also, secrets management is an efficient approach to manage secrets, passphrases, etc.
For organizations who do not use advanced hardware for key management on-premises but want to ensure their cloud providers do not own and cannot be compelled to turn over keys to decrypt their data, software-based key management is suitable.
Run the organization’s key management application in the cloud.
Lower cost than HSMs and full control of key services, rather than delegating them to your cloud provider
Can perform all core functions of an HSM -key generation, key storage, key rotation, and API interfaces to orchestrate encryption in the cloud
Need to handle failover and replication yourself
Not compliant with regulatory requirements that specify FIPS-certified hardware
The approach is only suitable for IaaS, as there is a need to install and configure your servers to perform key management
Multi-Cloud Key Management is the process of using a vendor solution to provide a centralized and secure key management system across multiple cloud environments. It does not much matter whether the customer’s application architecture uses a private cloud, a public cloud, a hybrid cloud, or is distributed across multiple clouds — the framework remains the same. They can choose to move ahead with a single CSP or multiple CSP depending on its cloud strategy.
Multi-cloud key management utilizes a single solution that can provide a secure and centralized approach to manage keys in multiple cloud environments. The solution provided by the vendors can achieve higher FIPS levels.
In terms of resources, multi-cloud key management tends to use fewer resources as all crypto key lifecycle management activities are centralized to one key location. This centralized location relieves the user from logging into multiple cloud environments instead of only focusing on a centralized location. It also removes any custom API to be built for the solution as everything will be provided by the vendor for the solution.
Multi-Cloud Key Management is best suited for environments that need to talk to each other to work flawlessly. If the organization has contracted with a single cloud service provider, then the native KMS encryption approach may be the best choice. However, the majority of enterprises contract with multiple cloud service providers. In a multi-cloud environment, the technical and economic benefits of the Cloud are diminished by the complexity of requiring a different encryption key management method for each cloud environment. A strategy to simplify key management without adding administrative complexity and a consistent, centralized, and secure means to manage encryption keys-ideally. One specifically designed for multi-cloud environments is the suggested choice – Hence the hybrid key management approach.
The following diagram depicts the Multi-Cloud key management solution. There is the centralized management of accounts across all leading CSPs with custom API for integration and managing all encryption key lifecycle management activities from the central console. This eliminates the requirement of separate logins for different cloud vendor solutions.
Organizations are leveraging third-party providers who offer multi-cloud solutions, enabling organizations to “Bring” your key and “manage” your keys.
Separate encryption keys from data encryption and decryption operations for compliance, thereby ensuring best security practices and control of your data.
Utilizes BYOK services to deliver key generation, separation of duties, reporting, and key lifecycle management that fulfill internal and industry data protection mandates, all with FIPS 140-2-certified secure key storage.
Keys are marked for automated key rotation on a per-cloud schedule.
Each cloud service login is authenticated and authorized by the service provider.
Choice of HSM depending on the requirement, i.e., using FIPS 140 level 4 vs. level 1 instead of using a standard native HSM, which does not provide a choice.
Cryptographic keys are a vital part of any security system. They do everything from data encryption and decryption to user authentication. The compromise of any cryptographic key could lead to the collapse of an organization’s entire security infrastructure, allowing the attacker to decrypt sensitive data, authenticate themselves as privileged users, or give themselves access to other sources of classified information. Luckily, proper management of keys and their related components can ensure the safety of confidential information. Key Management is the process of putting certain standards in place to ensure the security of cryptographic keys in an organization. Key Management deal with the creation, exchange, storage, deletion, and refreshing of keys. They also deal with the members access of the keys.
Why is Key Management Important
Key management forms the basis of all data security. Data is encrypted and decrypted via the use of encryption keys, which means the loss or compromise of any encryption key would invalidate the data security measures put into place. Keys also ensure the safe transmission of data across an Internet connection. With authentication methods, like code signing, attackers could pretend to be a trusted service like Microsoft, while giving victim’s computers malware, if they steal a poorly protected key. Keys provide compliance with certain standards and regulations to ensure companies are using best practices when protecting cryptographic keys. Well protected keys are only accessible by users who need them.
Types of Keys
There are two types of cryptographic keys, symmetric and asymmetric keys. Symmetric keys deal with data-at-rest, which is data stored in a static location, such as a database. Symmetric key encryption uses the same key for both encryption and decryption. Using data in a database as an example, while the data is stored in the database, it is encrypted with the symmetric key. Once an authorized user attempts to access the data, the information is decrypted with the same symmetric key and made accessible to the user. The other type of cryptographic key is an asymmetric key.
Encryption using asymmetric keys is a little more complicated than symmetric key encryption. Instead of using the same key for both encryption and decryption, two separate keys called a public and private key, are used for the encryption and decryption of data. These keys are created as a pair, so that they relate to each other. The public key of a pair of asymmetric keys is mainly used to encrypt data. This key can be shared with anyone since it encrypts, not decrypts, data. The private key is used for the decryption of data encrypted by its public key counterpart, so it must stay secure.
Asymmetric keys focus on encrypting data-in-motion. Data-in-motion is data sent across a network connection, whether it be a public or private connection. When transporting sensitive data, most encryption processes use both symmetric and asymmetric keys to encrypt data.
The data is first encrypted-at-rest by a symmetric encryption key.
The symmetric key is now encrypted by the public key of the person who the data is being sent to. That encrypted symmetric key and the ciphertext are sent to the recipient of the data.
Once the ciphertext and key reach the recipient, the symmetric key is decrypted by that user’s private key, and the ciphertext is decrypted.
How Key Management Works
Key management follows a lifecycle of operations which are needed to ensure the key is created, stored, used, and rotated securely. Most cryptographic keys follow a lifecycle which involves key
The generation of a key is the first step in ensuring that key is secure. If the key in question is generated with a weak encryption algorithm, then any attacker could easily discover the value of the encryption key. Also, if the key is generated in an insecure location, the key could be compromised as soon as it is created, resulting in a key that cannot be safely used for encryption. Key generators, AES encryption algorithms, or random number generators tend to be used for secure key generation.
The next step of the key lifecycle is ensuring the safe distribution of the keys. Keys should be distributed to the required user via a secure TLS or SSL connection, to maintain the security of the keys being distributed. If an insecure connection is used to distribute the cryptographic keys, then the security of any data encrypted by these keys is in question, as an attacker could execute a man-in-the-middle attack and steal the keys.
After distribution of the key, it is used for cryptographic operations. As previously noted, the key should only be used by authorized users, to make certain the key is not misused, copied, etc. When the key is used to encrypt data, it must then be stored for later decryption. The most secure method is via a Hardware Security Module (HSM) or CloudHSM. If an HSM is not used, then the keys can either be securely stored on the client’s side, or, if the keys are used on the Cloud, then the Cloud Service Provider’s Key Management Service can be used.
Once a key’s cryptoperiod, or time period the key is usable, passes, the key must be rotated. When the key of an encrypted set of data expires, the key is retired and replaced with a new key. First the data is decrypted by the old key or key pair and then encrypted by the new key or key pair. Rotation is necessary because the longer a key is in rotation, the more chance there is for someone to steal or find out the key. Rotation of keys can happen before the cryptoperiod expires in cases where the key is suspected to be compromised.
Two other ways of dealing with a compromised key are revoking or destroying the key in question. Revoking a key means the key can no longer be used to encrypt or decrypt data, even if its cryptoperiod is still valid. Destroying a key, whether that is due to compromise or due to it no longer being used, deletes the key permanently from any key manager database or other storage method. This makes it impossible to recreate the key, unless a backup image is used. NIST standards require that deactivated keys be kept in an archive, to allow for reconstruction of the keys if data encrypted in the past must now be decrypted by that key or key pair.
Compliance and Best Practices
Compliance standards and regulations ask a lot of key management practices. Standards, created by the NIST, and regulations, like PCI DSS, FIPS, and HIPAA, expect users to follow certain best practices to maintain the security of cryptographic keys used to protect sensitive data. The following are important practices to follow to ensure compliance with government regulations and standards.
Avoid hard-coding keys: The most important practice with cryptographic keys is never hard-coding key values anywhere. Hard-coding a key into open-source code, or code of any kind, instantly compromises the key. Anyone with access to that code now has access to the key value of one of your encryption keys, resulting in an insecure key.
Least privilege: The principle of least privilege is the idea that users should only have access to keys that are absolutely necessary for their work. This assures only authorized users can access important cryptographic keys, while providing better tracking of key usage. If a key is misused or compromised, only a handful of people have access to the key, so the suspect pool is narrowed down if the breach was within the organization.
HSMs: HSMs are a physical device which stores cryptographic keys and performs cryptographic operations on-premises. For an attacker to steal the keys from an HSM, they would need to physically remove the device from the premises, steal a quorum of access cards needed to access the HSM, and bypass the encryption algorithm used to keep the keys secure. HSMs on the Cloud are also a viable key management storage method, but there is always the chance that the Cloud Service Provider’s security fails, allowing an attacker to access the keys stored therein.
Automation: Automation is widely practiced method of ensuring keys do not go past their cryptoperiod and become over used. Other portions of the key lifecycle can be automated as well, like creating new keys, backing up keys regularly, distributing keys, revoking keys, and destroying keys.
Create and Enforce Policies: Creating and enforcing security policies relating to encryption keys is another way many organizations ensure the safety and compliance of their key management system. Security policies provide the methods everyone within an organization follows, and creates another method of tracking who can and has accessed certain keys.
Separate Duties: Separating duties related to key management is another important practice for any organization. An example of separation of duties is that one person is assigned to authorize new user’s access to keys, while another distributes the keys, and a third person creates the keys. With this method, the first person cannot steal the key during the distribution phase, or learn the value of the key during the generation phase of the key lifecycle.
Split Keys: One final practice to ensure the strength of any key management system is by splitting the keys into multiple portions. In this way, no one person knows the full key, rather multiple people must come together to use the key. This assures that others can be held responsible by their peers, if their portion of the key is compromised.
Encryption Consulting Training and Blogs
Encryption Consulting provides a variety of methods to create your own successful system for encryption key management. We host monthly webinars relating to key management, public key infrastructure (PKI), and more. We also provide assessments and training for HSMs, PKIs, and more. We can ensure your system is meeting compliance standards, and protecting data with the best methods possible. We also write weekly blogs that can help you find the best practices to use for your key management needs and learn more about the different aspects of data security.
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).
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.
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
Once overlooked, key management in the cloud is becoming a high priority for CISOs as multi-cloud environments become the next step in the continual goal of reducing downtime. Each major cloud provider has its own internal key manager. Amazon Web Services (AWS) has the AWS Key Management Service tucked away inside of the Identity and Access Management (IAM). Azure has the Key Vault to store keys used within its environment. Google has the Cloud Key Management Service. All of them have very different interfaces and offer little control over key sovereignty.
External Key Management services have been slow to answer the problem with their focus on the internal data center. Cloud key managers have not been keen to adopt standards such as the Key Management Interoperability Protocol (KMIP). The latest generation of Key Managers, however, is starting to close the gap. By leveraging the REST interfaces provided by cloud providers, Key Managers can enable Bring Your Own-Key (BYOK) functionality at multi-cloud and enterprise scales. Functionally, most Key Managers can support these new use-cases through APIs and clients. Migrating to a secure cloud infrastructure requires some research as BYOK integrations are still emerging.
How to Decide on a Key Management Partner
There are several questions you should consider before deciding on your key management partner:
Where should your organization be using encryption but not due to complexity?
How many cryptographic objects will the Key Manager support? Will it be able to scale with the continued growth of your company?
Does the Key Manager support automation of workloads? With the heavy automation already in your DevOps environment, why introduce a manual bottleneck?
Does the Key Manager have the integrations for the tools you use?
Is the Key Manager from a company that can be a trusted partner? Managing your keys is only part of the equation. Encryption keys and certificates manage all of your stored data. You need to ensure your organizational data integrity.
By working with experts, you greatly increase your chances of having a platform that performs and provides the security your organization needs to thrive while still protecting vital data. With the right strategy, encryption of your multi-cloud infrastructure can be integrated into your existing DevOps platforms with ease.
Jon Mentzell is a cyber security expert with two decades of systems administration and DevOps experience including security for a cabinet-level government agency. He is currently the Product Security Manager at Fornetix.