FM Deployment Constraints
This section describes important considerations and constraints associated with deploying your Functionality Modules (FMs). Your Luna Network HSM must meet all the criteria described in Preparing the Luna Network HSM to Use FMs.
Introducing FMs into your Luna Network HSM deployment will change the functionality of certain HSM features. Please take the following constraints into consideration before using FMs:
>FMs and High-Availability (HA)
>FMs and Backup/Restore/Cloning
>FMs and Secure Trusted Channel (STC)
>FMs and HSM Firmware Rollback
>FM Configuration and Remote PED
>FM-Enabled HSM Cannot be Verified With CMU
>No EDDSA or EC_MONTGOMERY Private Keys with C_CreateObject
>FM Sample Applications Dependent on General Cryptoki Samples
CAUTION! Enabling FMs (HSM policy 50) introduces changes to Luna HSM functionality, some of which are permanent; they cannot be removed by disabling the policy. FM-enabled status is not reversible by Factory Reset.
If you are using Crypto Command Center, ensure that your CCC version supports FM-enabled HSMs before you enable HSM policy 50. Refer to the CCC CRN for details.
FMs and FIPS Mode
FMs change the abilities of the HSM firmware, adding new cryptographic algorithms or other functions. Since the new functionality is not certified by NIST, be sure that your FM does not preclude FIPS compliance.
To be certain that your organization is meeting FIPS requirements, ensure that you are using a FIPS-certified version of the Luna HSM firmware, and that your Luna Network HSM has the following HSM policy settings:
>HSM policy 12: Allow non-FIPS algorithms: 0
>HSM policy 50: Allow Functionality Modules: 0
If FIPS 140 compliance is not a requirement of your use-case, then enabling FMs does not present an issue for you. Enabling the Functionality Modules Policy (setting Policy 50 to "1") is not reversible. For more information about HSM policies, see HSM Capabilities and Policies.
FMs and High-Availability (HA)
FM-specific functions must specify the exact HSM that will handle the operations. Therefore, the Luna HSM Client's HA implementation currently cannot accommodate FM functionality. If you want your FM-specific operations to be load-balanced across multiple HSMs, you must program this functionality into your applications yourself.
HA will still work with standard Luna operations.
For HA to function with Functionality Modules, all HSMs with application partitions in the HA group must have the same algorithms and functionality available. If one member partition does not have a required algorithm available in HSM firmware, cryptographic objects using that algorithm cannot be cloned to that partition, and this will disrupt HA functions.
Therefore, all HSMs containing HA group members must have FMs enabled (as described in Preparing the Luna Network HSM to Use FMs), and they must all have the same FM(s) loaded. HA login requires two FM-enabled HSMs.
For more information about HA, see High-Availability Groups.
FMs and Backup/Restore/Cloning
To back up and restore objects on FM-enabled partitions, you require the following minimum Luna Backup HSM firmware versions:
> Luna Backup HSM (G7) requires minimum firmware version 7.7.1
> Luna Backup HSM (G5) requires minimum firmware version 6.28.0
As a general rule, cryptographic objects can be cloned from a partition with less-secure settings to one with identical or more secure settings. Therefore, it is not possible to clone objects from a standard partition to an FM-enabled partition, unless the FM-enabled partition uses a stronger cloning protocol. This rule applies to backup/restore operations as well. For example:
>cloning from a pre-7.7.0 standard partition to a V0 or V1 FM partition is allowed
>cloning from a V0 standard partition to a V1 FM partition is allowed
This is to ensure that you can migrate objects to a Luna HSM with firmware 7.7.0 or newer, whether you have enabled FMs or not. These are considered migration scenarios only, and Thales does not recommend them for production environments.
To back up keys stored in the SMFS, your application must provide all the functions to back up and restore these keys.
FMs and Secure Trusted Channel (STC)
To use Functionality Modules (FMs) with STC client connections, you require Luna HSM firmware 7.7.0 or newer. To use FMs with earlier firmware versions, you must use NTLS connections.
FMs and Appliance Re-imaging
The FM-ready configuration required to make FMs work makes it impossible to re-image the appliance to the baseline version. This restriction comes into effect once HSM policy 50: Enable Functionality Modules is set to 1, and it continues to apply even if the policy is set back to 0. Attempting to re-image the appliance software once HSM policy 50 has been enabled will return the following:
lunash:>sysconf reimage start
The HSM Administrator is logged in. Proceeding...
The HSM Functionality Module policy (policy 50) has
previously been enabled.
Enabling this policy at any time causes the Appliance Re-image feature
to become unavailable.
ERROR, Not all required pre-conditions to re-image the appliance were satisfied
Command Result : 65535 (Luna Shell execution)
FMs and HSM Firmware Rollback
Enabling HSM Policy 50 permanently disables the ability to roll back the HSM firmware to a version lower than 7.4.0. Attempting to roll back the firmware once HSM policy 50 has been enabled will return the following error:
ERROR, failed to roll back HSM F/W!!!
Command Result : 65535 (Luna Shell execution)
FM Configuration and Remote PED
Various FM functions require HSM resets (for example, creating a partition or enabling an FM).
If you are configuring FMs while authenticating with Remote PED, the Remote PED connection is broken with each reset. LunaCM continues to show an active Remote PED connection until you restart LunaCM. You must close that apparent connection with
This might be required several times during Luna Network HSM setup for FMs. To prevent this, enable HSM Policy 51: Allow SMFS Auto Activation. If SMFS is not auto-activated, then the SMFS will require further individual PED prompts during the configuration process (SMFS is deactivated upon HSM reset if SMFS auto-activation is off).
NOTE Thales recommends that first time configuration of FM's be done locally, to minimize the issues mentioned above.
FM-Enabled HSM Cannot be Verified With CMU
The FM-enabled Luna Network HSM does not currently support confirming the HSM's authenticity using cmu verifyhsm, as described in Verifying the HSM's Authenticity, or retrieving and confirming a Public Key Confirmation from the HSM using cmu getpkc and cmu verifypkc.
Key Attributes
On an HSM with FMs enabled, keys that are derived or generated have the "always-sensitive" and the "never-extractable" attributes set to "false".
No EDDSA or EC_MONTGOMERY Private Keys with C_CreateObject
This release of the Luna Network HSM firmware does not allow FMs to use C_CreateObject to create EDDSA or EC_MONTGOMERY private keys. Use C_GenerateKeyPair to create these types of key.
FM Sample Applications Dependent on General Cryptoki Samples
When you install the FM SDK, the installation script ensures that the general Luna (PKCS) SDK and samples are also installed (first). This satisfies source dependencies for the FM samples. If you later delete or remove the Luna SDK, you might break those dependencies, and the FM samples will not build. You can manually correct this by performing a manual rpm -i of the cksample package.
Memory for FMs
Multiple FMs can be loaded into the FM space of the HSM, with a total memory limit of:
>8 megabytes for FMs
>4 megabytes of SMFS
Unused FMs can be deleted, to free some memory space.
