vania-janet/multiturn-rag-retrieval-data huggingface dataset:
IBM Cloud HPCS is backed by a FIPS 140-2 level 4 certified hardware security module (HSM). At a high level, the IBM HPCS consists of the following components.



* Crypto unit - a singular unit that represents a piece of hardware, the HSM, and the corresponding software stack, both are dedicated to a single tenant.
* Service instance - a cluster of crypto units, which operates as a single logical entity to provide redundancy and scalability. It is recommended to have at least two crypto units per instance of HPCS to provide high availability.



HPCS is a highly available solution owing to the multizone Region (MZR) architecture. Cross-regional high availability is available in some geographies with an expanding footprint.

The KMIP for VMware instance is authorized to Hyper Protect Crypto Services instance by using an IBM Cloud Identity and Access Management (IAM) service ID that has access to the instance. The service ID must have a minimum of platform Viewer access and service Manager access to the key manager instance. KMIP for VMware uses the customer root key (CRK) in the key manager instance, and stores all KEKs generated on behalf of VMware, in wrapped form, in the key manager instance.

To access KMIP for VMware over the private network, cloud service endpoints are used. During the setup, VMware vCenter and ESXi establish a trust with the deployed KMIP instance. VMware vCenter and ESXi authenticate with the KMIP adapter instance by using certificates in VMware vCenter when the connection to the key management server (KMS) is created. The public certificate is installed into KMIP to identify the vCenter client or clients that are allowed to connect. Each client is authorized to all keys stored in that KMIP for VMware instance.





 Hyper Protect Crypto Services for vSphere encryption - no third parties 

The following figure shows a typical vSphere encryption setup with HPCS/KMIP integration:

Zoom

!
Introducing EP11 over gRPC - Unified Key Orchestrator Plan 

Enterprise PKCS #11 (EP11) is designed for customers that are seeking support for open standards and enhanced security. The EP11 library provides a stateless interface, which is similar to the industry-standard

[Public-Key Cryptography Standards (PKCS) #11 API](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html). PKCS #11 API defines a platform-independent API to cryptographic tokens, such as hardware security modules (HSM) and smart cards. Existing applications that use PKCS #11 can benefit from enhanced security with secure key cryptography as well as a stateless interface, which makes the cryptographic operations much more efficient.

More information about the EP11 Library can be found in the

[Enterprise PKCS #11 (EP11) Library structure document](https://www.ibm.com/security/cryptocards/pciecc4/library). For more information about EP11 capabilities and extensions, see [EP11 introduction](https://www.ibm.com/security/cryptocards/pciecc3/ep11).

IBM Cloud® Hyper Protect Crypto Services provides a set of EP11 over gRPC (GREP11) API calls, with which all the cryptographic functions are executed in the cloud HSM of Hyper Protect Crypto Services. The GREP11 API is a stateless interface for cryptographic operations on cloud.

Hyper Protect Crypto Services leverages frameworks such as gRPC to enable remote application access. gRPC is a modern open source high-performance remote procedure call (RPC) framework that can connect services in and across data centers for load balancing, tracing, health checking, and authentication. Applications access Hyper Protect Crypto Services by calling the EP11 API remotely through gRPC. For more information about gRPC, see [the gRPC documentation](https://grpc.io/docs/guides/index.html).

With the GREP11 API, you can perform the following operations:



* Key generation.
Hyper Protect Crypto Services cloud TKE procedures 

The purpose of this document is to provide a template with procedures for the secure initialization and management of IBM Cloud® Hyper Protect Crypto Services Enterprise PKCS#11 Hardware Security Modules using Cloud Trusted Key Entry (TKE) and smart cards. The document is intended as a template to be tailored to fit the requirements of your organization.

The management of Hyper Protect Crypto Services can be subject to internal or external audits. For example, by using smart cards to initialize your service instance, the setup and procedures for initialization and management of Hyper Protect Crypto Services need to be documented, and evidence needs to be collected during execution of the procedures. Several decisions need to be taken by your Hyper Protect Crypto Services management team to establish a secure setup and make it operational for a production environment. You need to make most of these decisions beforehand and incorporate into this document.

Click the [link](https://cloud.ibm.com/media/docs/downloads/hs-crypto/IBM_Cloud_HyperProtectCryptoSevices_TKE_Procedures.pdf) to download the Hyper Protect Crypto Services cloud TKE procedures document.
KMIP for VMware provides an IBM-managed key management service that uses IBM Key Protect or Hyper Protect Crypto Services to give you full control over your keys. Other IBM Cloud services such as Cloud Object Storage also integrate with Key Protect and Hyper Protect Crypto Services, making them your central point of control for key management in the IBM Cloud.



 Keys within keys 

Key management systems commonly use a technique that is known as envelope encryption to wrap or protect keys with other keys. These keys are called root keys or key encrypting keys (KEKs). To access a key, you need to decrypt or unwrap the key by using its corresponding root key. Destroying the root key is an effective way of invalidating all the keys that were previously protected. These keys do not need to be stored close to the root key. Controlling access to the root key is important.

IBM Cloud Key Protect and Hyper Protect Crypto Services provide this service by using a customer root key (CRK). Key Protect stores CRKs exclusively in IBM Cloud CloudHSM hardware from which they cannot be extracted; Hyper Protect Crypto Services stores keys in IBM zSeries HSMs. These CRKs are then used to wrap more encryption keys such as the ones generated by KMIP for VMware for your VMware instance.

VMware implements this same concept for its keys. KMIP for VMware provides a key to VMware upon request. In turn, VMware uses this key as a KEK to wrap or encrypt the final keys that are used to encrypt your vSAN disk drives or VM disks. These final keys are called data encryption keys (DEKs).

So you end up with the following chain of encryption:



* Customer root key (CRK) stored permanently in IBM Key Protect or Hyper Protect Crypto Services.
* Key encrypting key (KEK) generated by KMIP for VMware and provided to vCenter Server and to the ESXi hosts in your instance.
* Data encrypting key (DEK) generated by VMware and stored alongside the vSAN disk or VM disk.



KMIP for VMware stores the wrapped form of the KEKs within IBM Key Protect or Hyper Protect Crypto Services.
Setting up BGP Message Digest 5 (MD5) authentication keys 

Border Gateway Protocol (BGP) authentication is an added layer of security that enables routers to share information only if they can verify that they are communicating with a trusted source, based on a key. TCP MD5 authentication between BGP peers verifies each transmitted message sent through the BGP session.



 BGP authentication requirements 

Make sure to adhere to the following BGP MD5 authentication requirements:



* BGP MD5 keys must be created as an imported, type-standard key (not a root key). The key material that you provide must be base64-encoded and the original string cannot exceed a maximum of 126 printable ASCII characters in length. For more information, see [Creating base64-encoded encryption keys](https://cloud.ibm.com/docs/dl?topic=dl-dl-md5create-encryption-keys).

The key material must be base-64-encoded and can be up to 7,500 bytes. The key name (different from the key material) is a unique, human-readable name for easy identification of your key.
* During an authenticated BGP session, BGP peers must be configured with the same key to establish a BGP neighbor relationship. Routers that are configured with a different key cannot maintain a BGP neighbor relationship.







 Setting up BGP MD5 authentication keys 

You can store your keys in either Key Protect or Hyper Protect Crypto Services (HPCS). To configure BGP MD5 authentication, follow these steps:



1. Set up a keystore instance with keys. For instructions, see [Key Protect: Getting started with encryption keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial) or [HPCS: Creating and importing encryption keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-import-keys).

If you use HPCS, it is important to note that the "extractable": <key_type> value is set to true for standard keys.
2.
C_CancelFunction N/A N/A Legacy function that always returns CKR_FUNCTION_NOT_PARALLEL. 







 Supported mechanisms 

A mechanism is referred to as a process to implement a cryptographic operation. It can vary depending on the level of firmware in the crypto card. The following table shows the mechanisms that are currently supported and how they relate to common GREP11 function categories.



Table 2. Describes the supported GREP11 mechanisms

 Function group Supported mechanisms 

 Encrypt and decrypt CKM_RSA_PKCS^1^, CKM_RSA_PKCS_OAEP^1^, CKM_AES_ECB, CKM_AES_CBC, CKM_AES_CBC_PAD, CKM_DES3_ECB, CKM_DES3_CBC, CKM_DES3_CBC_PAD
Google Cloud KMS is a centralized cloud service for you to create and manage cryptographic keys. You can perform cryptographic operations by using keys in Google Cloud KMS, or by integrating with other Google Cloud services such as Cloud HSM.











 What's next 



* To find out instructions on creating a managed key, check out [Creating managed keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-create-managed-keys).
* To find out instructions on adding a keystore, check out [Creating internal keystores](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-create-internal-keystores) or [Connecting to external keystores](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-connect-external-keystores).
* To find out how to grant access to vaults, see [Granting access to vaults](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-grant-access-vaults).
* To find out more about the Unified Key Orchestrator API, see [Unified Key Orchestrator API reference](https://cloud.ibm.com/apidocs/uko).
The service also helps your business meet regulatory compliance with the technology that provides exclusive controls on the external and privileged user access to data and keys.





 Why Unified Key Orchestrator? 

Many enterprises have the legal obligation to bring their own cryptographic keys when they move sensitive workloads to the cloud. Enterprises are adopting native encryption and key management offerings from cloud providers.

Dealing with multiple clouds means to deal with cryptographic keys in multiple key management services. This presents the following challenges:



* High manual effort and susceptibility to errors when enterprises operate different key management systems
* No control over themaster keyin external cloud key management systems
* Shortage of data centers and skilled staff to operatehardware security modules (HSMs)for KYOK or BYOK



Unified Key Orchestrator alleviates the complexity of maintaining encryption across hybrid environments. You can integrate all your key management use cases into one consistent approach, backed by a trusted IBM zSystems HSM. It provides you with the following features:



* Consistent user experience
* Seamless integration into the existing cloud framework
* One point of control for multiple keys in multiple clouds
* Secure backup of all keys and easy restoration across multiple clouds



For an architectural diagram of Hyper Protect Crypto Services, see [Service architecture](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-architecture-workload-isolation).





 Key features 

Hyper Protect Crypto Services provides the following features:



 Unified Key Orchestrator 



* Connection to external keystores

Unified Key Orchestrator, as part of Hyper Protect Crypto Services, provides key lifecycle management according to NIST recommendations and secure transfer of keys to internal keystores in the service instance or external keystores. With Unified Key Orchestrator, you can push your keys to third-party cloud keystores, such as Azure Key Vault, AWS Key Management Service (KMS), Google Cloud KMS, or IBM Key Protect for IBM Cloud, distribute keys across keystores, and manage keys and keystores through both the UI and REST API.
* Unified key backup and management system

Unified Key Orchestrator enables you to back up all keys in IBM Cloud with your Hyper Protect Crypto Services instance.
2. In the Instance ID field, enter your Hyper Protect Crypto Services instance ID. For example: d11a1a43-aa0a-40a3-aaa9-5aaa63147aaa.
3. In the Secret name field, enter the name of the secret that you created by using your Hyper Protect Crypto Services credentials. For example: ibm-hpcs-secret.
4. In the Base URL field, enter the public endpoint of your Hyper Protect Crypto Services instance. For example: https://api.eu-gb.hs-crypto.cloud.ibm.com:8389.
5. In the Token URL field, enter https://iam.cloud.ibm.com/identity/token.









 Step 16: Verify OpenShift Data Foundation is running 



1. List the pods in the openshift-storage namespace and verify they are running.

oc get pods -n openshift-storage
2. List the available storage classes.

oc get sc
Why can't I list crypto units? 

You get an error message when you list crypto units by using command ibmcloud tke cryptounits.

  What’s happening 

You might receive an error message similar to the following one:

> ibmcloud tke cryptounits API endpoint: [https://cloud.ibm.com](https://cloud.ibm.com) Region: XX-XX User: [john.doe@abc.com](mailto:john.doe@abc.com) Account: myaccount (GUID) Resource group: Default No service instances were found for the current resource group.

  Why it’s happening 

It might be caused by one of the following reasons:



*  You haven't logged in to the correct region or resource group where your service instance resides.
*  If you have multiple accounts, you are not using the correct account with which your service instance is created. Or, your account doesn't have the permission to view the service instance.



  How to fix it 

Try the following solutions:



*  Make sure that you are logged in to the correct region and resource group with the following command:

ibmcloud target -r <region> -g <resource_group>
*  Make sure that your account is assigned the Manager[service access role](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessservice-access-roles) to list the crypto units. The account with which you create the service instance is granted as the Administrator role by default and can assign various roles that correspond to the specific Hyper Protect Crypto Services permissions. For more information about roles and permissions, see [Managing user access](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-access).
master keyinitialization to help enable you to take ownership of the cloud HSM. You can also load the master key with the IBM Hyper Protect Crypto Services Management Utilities. The Management Utilities create and store your master key parts on smart cards and never exposes your secrets to the workstation and cloud, thus ensuring the highest level of protection to your secrets.

Hyper Protect Crypto Services can integrate with IBM Cloud data and storage services as well as VMware® vSphere® and VSAN, for providing data-at-rest encryption.

The managed cloud HSM supports the industry-standard cryptographic operations by using the Public-Key Cryptography Standards (PKCS) #11. You don't need to change your existing applications that use PKCS #11 standard to make it run in the Hyper Protect Crypto Services environment. The PKCS #11 library accepts the PKCS #11 API requests from your applications and remotely accesses the cloud HSM to execute the corresponding cryptographic functions, such as digital signing and validation.

Enterprise PKCS #11 over gRPC (GREP11) is also supported by Hyper Protect Crypto Services. The EP11 library provides an interface similar to the industry-standard

[PKCS #11 application programming interface (API)](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html).

With the built-in encryption of Hyper Protect Crypto Services, you can easily build cloud applications with sensitive data. Hyper Protect Crypto Services provides you with complete control of your data and encryption keys, including the master key. The service also helps your business meet regulatory compliance with the technology that provides exclusive controls on the external and privileged user access to data and keys.





 Why Unified Key Orchestrator? 

Many enterprises have the legal obligation to bring their own cryptographic keys when they move sensitive workloads to the cloud. Enterprises are adopting native encryption and key management offerings from cloud providers.

Dealing with multiple clouds means to deal with cryptographic keys in multiple key management services. This presents the following challenges:



* High manual effort and susceptibility to errors when enterprises operate different key management systems
When you enable service endpoints, you can connect to Hyper Protect Crypto Services by using a private IP that is accessible only through the private network of IBM Cloud. To find out more, see [Service endpoints for private connections](https://cloud.ibm.com/docs/account?topic=account-service-endpoints-overview).

After you enable service endpoints for your account, all existing and future Hyper Protect Crypto Services resources and service instances become available from both the public and private endpoint.







 Step 1: Configure the private network of IBM Cloud on your virtual server 

Prepare your VSI or test machine by configuring your routing table for the private network of IBM Cloud.



1. To route traffic to the private network of IBM Cloud, run the following command on your VSI:

route add -net 166.9.0.0/16 gw <gateway> dev <gateway_interface>

Replace <gateway> (for example, 10.x.x.x) and <gateway_interface> (for example, eth10) with the appropriate values.
2. Optional: Verify that the route was added successfully by displaying your new routing table.

route -n







 Step 2: Provision a service instance and select the network access 

When you [provision a service instance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-provision), you can choose between the private-only and public-and-private options using either the IBM Cloud console or CLI.

You can always [manage and update the network settings](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-managing-network-access-policies) after you provision and initialize the service instance. Use either the CLI or API to switch between a private-only network and a public-and-private network.





 Step 3: Target the Hyper Protect Crypto Services private endpoint for the TKE CLI plug-in 

To perform key management and cryptographic operations thought a private endpoint, you need to first target the private endpoint for the Trusted Key Entry (TKE) CLI plug-in.



1.
[PKCS #11 Cryptographic Token Interface Usage Guide](http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html_Toc406759989) for an in-depth look at sessions.





 Key object 

Key objects are stored in either the in-memory keystore that resides with the PKCS #11 application or in a database-backed keystore. If the CKA_TOKEN attribute is set to true for the key object, the key object is stored in the database-backed keystore. Otherwise, the key object is stored in the in-memory keystore.

Key objects in the in-memory keystore are not automatically rotated after the master key rotation. If PKCS #11 keystores are enabled in your service instance, you need to restart all active PKCS #11 applications to clear the in-memory keystore after the master key rotation is complete.

As shown in the following diagram, a PKCS #11 key object is an example of a PKCS #11 object class:



* Data: A data object is defined by an application.
* Certificates: A certificate object stores a certificate.
* Keys: A key object stores a cryptographic key. The key can be a public key, a private key, or a secret key. Each type of these keys has subtypes for use in specific mechanisms.



* Public key: The public component of a key pair that is used by anyone to encrypt messages intended for a particular recipient that has access to the private key of the key pair. The public key is also used to verify signatures created by the private key.
* Private key: The private component of a key pair that is used to decrypt messages. The private key is also used to create signatures.
* Secret key: A secret key is a generated stream of bits that is used to encrypt and decrypt messages symmetrically.





Zoom

!
However, it is suggested to assign a unique name to each key in the same keystore for easy identification. 
 Key type The type of the EP11 key that you want to manage in Hyper Protect Crypto Services. 
 Keystore The unique identifier of the keystore with the keystore type appended. Choose one that you want the key to be stored in from the list. For an asymmetric key pair, you need to specify the keystore separately to store the public key and the private key. You can find all available keystores by clicking the EP11 keystores tab in the side menu. 



By default, two key IDs are automatically generated. One is for the public key, and the other is for the private key. However, if you select a symmetric key type, such as an AES key, a DES key, or a Generic key, only one key ID is shown on the page.
2. Specify key attributes by following these steps:



* If you are creating an asymmetric key, specify key attributes on the Public key attributes and Private key attributes pages:



1. The required attributes are listed with the default values. To modify the attribute values, click the Edit icon ![Edit icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/edit-tagging.svg).
2. To add more attributes, click Add public attribute or Add private attribute depending on which page you are on. For a list of supported attributes, see [supported attributes table](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-pkcs11-api-refpkcs-attribute-list) and [supported curve names for Elliptic Curve keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-pkcs11-api-refsupported-pkcs11-ec-curve-name).

Add and set the CKA_MODIFIABLE attribute to true if you want to modify the added key later.