You can have up to eight Cryptographic Coprocessors per partition. The maximum number of Cryptographic Coprocessors supported per server is dependent the system mode. Read this topic if you are using multiple coprocessors with SSL.
Spreading the work across multiple Cryptographic Coprocessors and multiple jobs gives you better performance provided that they are all configured the same. Only one Coprocessor (cryptographic device description) may be allocated to a job at one time. However, the job can switch between Coprocessors by deallocating the current Coprocessor and allocating a new one. For the i5/OS™ SSL user, the allocation and deallocation of the Coprocessors is managed by the system if the SSL configuration in DCM indicates that more than one Coprocessor is to be used for SSL session establishment.
If you configure all of the Coprocessors the same, then all operational keys will work identically on all of the Coprocessors. Any data encrypted on one Coprocessor can be decrypted on a different Coprocessor. All key store files will work interchangeably with any of the Coprocessors. The most important part of configuring the Coprocessors identically is the master keys. If you entered the master key in parts for one Coprocessor, you must enter the same master key parts for all of the other Coprocessors if you want them to work interchangeably. If a random master key was generated inside of the Coprocessor, then you must clone the master key to the other Coprocessors if you want all of the Coprocessors to work interchangeably.
There may be certain situations where you do not want all of the Coprocessors to be configured the same. They could all have different configurations or they could be set up in groups where the configuration within a group is the same but between groups is different. For these cases, all operational keys may not work identically on all of the Coprocessors. Data encrypted on one Coprocessor may not be able to be recovered on a different Coprocessor. Also, the keystore files may not work interchangeably among Coprocessors. For these situations, you must keep track of which keystore files and operational keys will work for a given Coprocessor. While configuring the Coprocessors differently may limit the scalability of cryptographic applications, it can provide more granularity in terms of security. For example, you can grant different object authorities to different cryptographic device descriptions.
If you use retained PKA keys then the Coprocessors are also not interchangeable. Retained keys can not be exported in any manner outside of the Coprocessor. Therefore, any cryptographic request that uses that retained key must be sent to the Coprocessor that stores the retained key.
The following material is only applicable if you are using i5/OS applications:
The Cryptographic_Resource_Allocate (CSUACRA) API verb is used to explicitly allocate a cryptographic device to your job so that the system can determine how to route all subsequent cryptographic requests. If you use any of the CCA API verbs without first explicitly using the Cryptographic_Resource_Allocate (CSUACRA) API verb, the system will attempt to allocate the default cryptographic device. The default device is the cryptographic device named CRP01. It must be created by either using the Basic Configuration wizard or the Create Device Crypto (CRTDEVCRP) CL command. You only need to use CSUACRA when you wish to use a device other than the default cryptographic device. A device allocated to a job, either explicitly or implicitly, remains allocated until either the job ends or the device is deallocated using the Cryptographic_Resource_Deallocate (CSUACRD) API verb.
When you have finished using a Cryptographic Coprocessor, you should deallocate the Cryptographic Coprocessor by using the Cryptographic_Resource_Deallocate (CSUACRD) API verb. A cryptographic device description can not be varied off until all jobs using the device have deallocated it.