FAQs: Security and compliance
Read to get answers for questions about data security in IBM Cloud® Hyper Protect Crypto Services.
How can I manage user access to my service instances? Does IBM have access to my instances?
IBM or any third-party users do not have access to your service instances or your keys. By loading the master key to your service instance, you take the ownership of the cloud HSM and you have the exclusive control of your resources that are managed by Hyper Protect Crypto Services.
Hyper Protect Crypto Services follows the IBM Cloud Identity and Access Management (IAM) standard. You can manage user access by assigning different IAM roles and grant access to specific keys to enable more granular access control.
How does IBM offer a unique and secure process for service initialization (key ceremony)?
Hyper Protect Crypto Services sets up signature keys for crypto unit administrators during the service initialization process to ensure that the master key parts are loaded to the HSM with no interception.
A master key is composed of two or three master key parts. Each master key custodian owns one encrypted master key part. In most cases, a master key custodian can also be a crypto unit administrator. In order to load the master key to the service instance, master key custodians need to load their key parts separately by using their own administrator signature keys.
A signature key is composed of an asymmetric key pair. The private part of the signature key is owned by the crypto unit administrator, while the public part is placed in a certificate that is used to define an administrator and never leaves the crypto unit.
This design ensures that no one can get full access of the master key, even the crypto unit administrators.
What is a 140-2 FIPS Level 4 Certification and how can I validate it?
The Federal Information Processing Standard (FIPS) Publication 140-2 is a US government computer security standard that is used to approve cryptographic modules.
- Security Requirements for Cryptographic Modules.
- Cryptographic Module Validation Program.
- FIPS 140-2 defines four levels of security, including FIPS 140-2 Level 1, 2, 3, and Level 4.
What is the difference between FIPS 140-2 Level 1, 2, 3, and Level 4?
-
Level 1: The lowest level of security. No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components.
-
Level 2: Improves the physical security mechanisms of a Level 1 cryptographic module by requiring features that show evidence of tampering including tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module, or pick-resistant locks on covers or doors to protect against unauthorized physical access. Security Level 2 requires, at minimum, role-based authentication in which a cryptographic module authenticates the authorization of an operator to assume a specific role and perform a corresponding set of services.
-
Level 3: Provides a high probability of detecting and responding to attempts at physical access, use, or modification of the cryptographic module. The physical security mechanisms can include the use of strong enclosures and tamper-detection and response circuitry that zeroizes all plain text CSPs when the removable covers or doors of the cryptographic module are opened. Security Level 3 requires identity-based authentication mechanisms, enhancing the security provided by the role-based authentication mechanisms specified for Security Level 2.
-
Level 4: The highest level of security. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access. Penetration of the cryptographic module enclosure from any direction has a high probability of being detected, resulting in the immediate zeroization of all plain text CSPs.
Security Level 4 cryptographic modules are useful for operation in physically unprotected environments. Security Level 4 also protects a cryptographic module against a security compromise because of environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and temperature. Intentional excursions beyond the normal operating ranges can be used by an attacker to prevent a cryptographic module's defenses.
A cryptographic module is required to either include special environmental protection features designed to detect fluctuations and delete CSPs, or to undergo environmental failure testing to ensure that the module will not be affected by fluctuations outside of the normal operating range in a manner that can compromise the security of the module. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.
Hyper Protect Crypto Services is the only cloud HSM in the public cloud market that is built on an HSM designed to meet FIPS 140-2 Level 4 certification requirements. The certification is listed on the Cryptographic Module Validation Program (CVMP) Validated Modules List.
How to understand the key hierarchy for Hyper Protect Crypto Services KYOK?
The following table lists the keys that are needed for Hyper Protect Crypto Services Keep Your Own Key (KYOK) functionality.
| Key types | Algorithms | Functions |
|---|---|---|
| Signature key | P521 Elliptic Curve (EC) | When you initialize your Hyper Protect Crypto Services instance to load the master key, you need to use signature keys to issue commands to the crypto units. The private part of the signature key is used to create signatures and is stored on the customer side. The public part is placed in a certificate that is stored in the target crypto unit to define a crypto unit administrator. |
| Master key | 256-bit AES | You need to load your master key to the crypto units to take the ownership of the cloud HSM and own the root of trust that encrypts the entire hierarchy of encryption keys, including root keys and standard keys in the key management keystore and Enterprise PKCS #11 (EP11) keys in the EP11 keystore. Depending on the method that you use to load the master key, the master key is stored in different locations. |
| Root key | 256-bit AES | Root keys are primary resources in Hyper Protect Crypto Services and are protected by the master key. They are symmetric key-wrapping keys that are used as roots of trust for wrapping (encrypting) and unwrapping (decrypting) other data encryption keys (DEKs) that are stored in a data service. This practice of root key encryption is also called envelope encryption. For more information, see Protecting your data with envelope encryption. |
| Data encryption key (DEK) | Controlled by the data service | Data encryption keys are used to encrypt data that is stored and managed by other customer-owned applications or data services. Root keys that you manage in Hyper Protect Crypto Services serve as wrapping keys to protect DEKs. For services that support the integration of Hyper Protect Crypto Services for envelope encryption, see Integrating IBM Cloud services with Hyper Protect Crypto Services. |
How does EP11 differ from PKCS #11?
Enterprise PKCS #11 (EP11) is aligned with PKCS #11 in terms of concepts and functions. An experienced PKCS #11 developer can easily start using EP11 functions. However, they have the following major differences:
- EP11 is built to allow high availability and scalability by design.
- EP11 is a stateless protocol, whereas PKCS #11 is stateful. The stateless design of EP11 allows for the use of external keystores as well as scaling to multiple backends.
- EP11 over gRPC (GREP11) defines a network protocol that can be directly used in cloud applications.
For more information, see Comparing the PKCS #11 API with the GREP11 API.
What EP11 mechanisms are supported by the GREP11 functions?
Mechanisms can vary depending on the level of firmware in the crypto card, see Supported mechanisms. For more information about the EP11 mechanisms, see the IBM 4768 Enterprise PKCS #11 (EP11) Library structure guide and IBM 4769 Enterprise PKCS #11 (EP11) Library structure guide.
What compliance standards does Hyper Protect Crypto Services meet?
Hyper Protect Crypto Services meets controls for global, industry, and regional compliance standards, such as GDPR, HIPAA, and ISO. As the HSM used by Hyper Protect Crypto Services, the IBM 4768 or IBM 4769 crypto card is also certified with Common Criteria EAL4 and FIPS 140-2 Level 4. For more information, see Security and compliance.
Can I monitor my service instance?
Yes, you can monitor the status of your service instance through IBM Cloud Activity Tracker.