|
Home > |
|---|
This section describes the compatibility of small form factor (SFF) backup with HSM-to-HSM cloning in various configurations.
Note: SFF backup requires firmware 6.21.0 or greater. HSMs with older firmware do not support SFF backup.
The SFF backup feature can be added only to PED-authenticated cloning HSMs. Cloning and SFF backup are two different HSM features that provide copying or archiving of partition objects in different ways, for different purposes. They can co-exist, but with limitations.
Changes to cloning behavior were necessary in order to implement the SFF backup feature on a cloning HSM. These changes come into effect only when an HSM has the SFF backup capability update file (CUF) installed, and the SFF backup feature is turned on in the HSM policies.
An HSM that is factory-configured for cloning supports secure HSM-to-HSM copying of objects. That cloning ability remains part of the HSM throughout its life. An HSM that was configured for cloning before the addition of SFF backup is still capable of cloning, but now additionally can archive objects to off-board storage by means of SFF backup.
A cloning-only HSM (without the SFF capability enabled) can accept cloning only of objects that have never been stored off the HSM (except keys clearly marked as extractable). Therefore, when SFF backup is installed and enabled on a cloning HSM (cloning plus SFF), the operation of cloning to or from that HSM becomes restricted to HSMs that also have SFF backup installed and enabled. This is particularly important in HA implementations. If SFF backup is enabled on an HA group member, it must also be enabled for all other members of the HA group. See Effect on HAfor more information.
The following table sets out the compatibility constraints for HSMs with and without the SFF backup capability.
| Source HSM | Target HSM | ||||||
|---|---|---|---|---|---|---|---|
| Firmware Version |
Has CUF? |
Has HSM- [See Note 1] |
Firmware Version |
Has CUF? |
Has HSM- level policy set? [See Note 1] |
Cloning Outcome | SFF backup? |
| F/w prior to version 6.21.0 | N/A | N/A | F/w prior to version 6.21.0 | N/A | N/A | No change. Cloning from one HSM to another is possible if the two HSMs share the same cloning domain. This was always the case. | None |
| F/w prior to version 6.21.0 | N/A | N/A | F/w version 6.21.0 or newer |
No | No | No change. Cloning from one HSM to another is possible if the two HSMs share the same cloning domain. | None |
| F/w version 6.21.0 or newer |
No | No | F/w prior to version 6.21.0 | N/A | N/A | No change. Cloning from one HSM to another is possible if the two HSMs share the same cloning domain. | None |
| F/w version 6.21.0 or newer |
Yes | Yes | F/w prior to version 6.21.0 | N/A | N/A | Cloning is NOT possible. Cloning from one HSM to the other is prevented when mismatch of settings is detected. | Source can use SFF backup, Target cannot |
| F/w version 6.21.0 or newer |
Yes | Yes | F/w version 6.21.0 or newer |
No | No | Cloning is NOT possible. Cloning from one HSM to the other is prevented when mismatch of settings is detected. | Source can use SFF backup, Target cannot |
| F/w version 6.21.0 or newer |
Yes | Yes | F/w version 6.21.0 or newer |
Yes | Yes | Cloning from one HSM to another is possible if the two HSMs share the same cloning domain. | Source and Target can both use SFF backup. Can interchange provided the same Scalable Key Storage secret is on both HSMs |
|
Note 1: The partition SFF backup policy does not have an effect at this level. The HSM-level policy governs. Note 2: In addition to the requirement for minimum firmware level, the Capability Update must be present and the appropriate policy must be set for the feature to work. The above table has separate columns for each condition to highlight them, but does not include possible instances where the CUF is installed but the policy is off. If any of the three (firmware, CUF, policy) is not correct, the SFF backup feature cannot work. |
|||||||
The following rules apply to the SFF backup feature:
•If your HSM is not factory configured for cloning, you cannot apply the SFF backup capability.
•If your HSM has firmware lower than 6.21.0, you cannot apply the SFF backup capability.
•If your HSM has version 6.21.0 (or higher) firmware, and is a cloning version HSM, you can apply the SFF backup capability.
– If you do not apply the capability then the HSM can clone as it always did.
– If you do apply the capability, but do not switch on the policy, cloning is still not affected.
– If you do apply the capability, and switch on the policy, you can archive partition objects to an SFF backup eToken. Your ability to clone, however, is restricted to other HSMs that also have the SFF capability applied and the policy switched on.
This section might seem repetitive, given the previous section, but readers might come to this page from a perspective of wishing to clone, or of wishing to use the SFF feature. Viewed from the cloning perspective, the simple statement regarding SFF is that, in the case where either HSM has the SFF policy enabled, the other must also have it enabled for cloning to function. Otherwise, if you wish to clone between the HSMs, then you must disable the policy on the HSM with the SFF CUF. Without that preparation, a cloning attempt results in an error CKR_DATA_INVALID.
Firmware 6.21.0 was the dividing line, the first firmware that supports the SFF feature; if firmware is earlier, then the SFF capability update cannot be installed. In this table, we show several examples of both pre-6.21 and 6.21-or-newer, in both the Source and Destination positions, to indicate that our testing has covered a variety of situations.
| Source | Destination | Cloning Result |
|---|---|---|
| Pre-6.21.0 (FW6.2.1) | FW6.22.0 with SFF Off | No error |
| FW6.22.0 with SFF Off | Pre-6.21.0 (FW 6.0.8) | No error |
| Pre-6.21.0 (FW6.2.1) | FW6.22.0 with SFF On | CKR_DATA_INVALID error |
| FW6.22.0 with SFF On | Pre-6.21.0 (FW 6.0.8) | CKR_DATA_INVALID error |
| FW6.22.0 with SFF Off | FW6.22.0 with SFF Off | No error |
| FW6.22.0 with SFF On | FW6.22.0 with SFF On | No error |
| FW6.22.0 with SFF Off | FW6.22.0 with SFF On | CKR_DATA_INVALID error |
| FW6.22.0 with SFF On | FW6.22.0 with SFF Off | CKR_DATA_INVALID error |
The takeaway message, where all involved HSMs are cloning type, is:
•If both the intended cloning source and cloning target/destination have older firmware, which does not allow the SFF capability to be installed, then cloning proceeds with no difficulty, as was always the case.
•If either the source or the destination has older firmware, and the other has newer firmware, but with SFF not turned on, then cloning proceeds with no difficulty.
•If either the source or the destination has older firmware, and the other has newer firmware where SFF is installed and ON, then cloning fails.
•If both the source and the destination have newer firmware but SFF is OFF for both, then cloning proceeds with no difficulty.
•If both the source and the destination have newer firmware and SFF is ON for both, then cloning proceeds with no difficulty.
•If both the source and the destination have newer firmware but SFF is ON for one, but OFF for the other, then cloning fails.
HSMs that do not have SFF backup enabled, and have previously been able to participate in an HA group, continue to function in HA, even when updated to a firmware version that can support SFF backup. This remains true as long as the other members of the HA group have the previous firmware, or have the newer firmware, but with SFF backup not enabled.
HSMs that have the SFF backup capability applied, and the feature policy switched on, can share an HA group only with other HSMs that have the capability applied and the policy switched on.
The above general rules apply at the HSM-wide level. It is not possible to have different settings, affecting the above-described compatibilities, at the partition level. The only partition-level option is to forbid SFF backup for a particular partition while the HSM, as a whole, supports and permits it.