Compare Behavior of Pre-Firmware 7.7, and V0, and V1 Partitions

Luna HSM Firmware 7.7.0 and newer preserve the traditional keys-in-hardware mode of operation and improve on it with fixes and security updates, while also adding the option to securely store more keys than will fit inside a crypto module. Traditional support of Luna features is retained in what we call version zero (V0) partitions, to distinguish from version one (V1) partitions that do the following:

>Implement Scalable Key Storage to securely externally store and manage keys in vastly greater quantities than can fit inside a crypto module.

>Conform with FIPS SP 800-131A (revised).

>Comply with current and anticipated Common Criteria and eIDAS requirements (including Per-Key Authorization).

         Partition type ==>
Firmware 7.7.0 and newer
V0 V1

Description ==>

>Continues the Luna tradition of "keys always in hardware", for ongoing compatibility with existing applications and use-cases

>Adds the ability to store large numbers of keys safely within the security perimeter of the HSM in a database or file system,

>Adds Per-Key Authorization capability,

>... both for RSS and other applications.

After updating to Luna HSM Firmware 7.7.0 or newer, any pre-existing partition becomes a V0 partition. If you create new partitions after the firmware update, the default is V0 with a further option to convert to V1 if there is ever a need. V0 partitions preserve your content, allow your applications to continue functioning with those partitions as they always did, and leverage the benefits of new fixes and security updates introduced with the newer firmware. To access the new features mentioned above, V0 partitions must be converted to V1 partitions after the update to Luna HSM Firmware 7.7.0 or newer. A summary of the origin of each partition type is provided in The Origin of Each Partition Type. For more information about converting V0 partitions to V1, refer to Converting Partitions from V0 to V1 or V1 to V0.

NOTE   V0 partitions have been designed to preserve as much compatibility as possible with your existing applications, while setting some necessary infrastructure for Luna HSM Firmware 7.7.0 features and future developments. However, the conversion of pre-existing partitions to V0 has implications for the firmware update process that must be considered before updating to Luna HSM Firmware 7.7.0 or newer. If you have not updated your Luna HSM to Luna HSM Firmware 7.7.0 or newer but plan to do so, Thales recommends reading Special Considerations for Luna HSM Firmware 7.7.0 and Newer before updating and reading the information in this section.

This section is of interest

>to customers who already have HSMs in operation and are looking to upgrade to Luna HSM Firmware 7.7.0 or newer, where possible, or

>to anyone wanting to know what differences in behavior to expect if you elect to change from the default V0 partition type to V1.

Version 7.x hardware can accept upgraded firmware, discussed in this section, and works best in conjunction with

>Luna HSM Client 10.3.0 or newer

>Luna Appliance Software 7.7.0 or newer

You might be looking to migrate existing keys and objects from their application partitions to updated partitions, both for older HSM generations being supplanted, and for current hardware being updated.

The ability to migrate keys and objects from pre-firmware 7.7 to new partitions is preserved. Some new administrative commands, and new options to pre-existing commands, have been added. Any API changes are as transparent as possible to maintain the function of existing customer and partner applications.

TIP   Luna Appliance Software 7.8.0 (or newer) and Luna HSM Client 10.5.0 (or newer), added cloning protocol 4 (CPv4) and Extended Domain Management, improving the process of migrations and HA and generally working with mixed groups of HSMs. The former barrier is removed:

>between on-premises password-authenticated and multifactor quorum-authenticated partitions, or

>between on-premises multifactor quorum-authenticated partitions and Luna Cloud HSM services (password authenticated).

As long as you can authenticate to each of the parties, and the on-premises partition is Luna HSM Firmware 7.8.0 (allowing multiple domains to a partition) you can clone between them, in either direction, subject only to restrictions regarding repositories of greater vs lesser security.

The Origin of Each Partition Type

This section describes the origin of pre-firmware 7.7.0, V0, and V1 partitions.

Pre-Firmware 7.7.0 Partition

This is any partition on a Luna HSM from Luna 5.x and 6.x, and including Luna 7.x from firmware version 7.0 up to (but not including) version 7.7.0.

NOTE   When older Luna models like 5.x and 6.x are involved in migration of key material to Luna 7.x, there might be additional restrictions on the older units, such that firmware update paths must be followed before interaction with Luna 7.x HSMs is possible.

Be aware also that applications making use of older HSMs might have created and used outdated key-types and cryptographic mechanisms that are not accepted (or are allowed only restricted use) by newer HSM versions, especially in FIPS-compliant operation.

V0 Partition

Any pre-existing partition, when HSM firmware is updated to version 7.7.0 or newer, becomes a V0 partition.

Any new partition, created using the default partition type (-version option) of the command partition create (in lunash).

Any partition created on a firmware-7.7.0 (or newer) HSM, by an older client that does not know about the V0 / V1 distinction, is always V0.

The V0 status is a partition policy (#41).

V1 Partition

Any partition created with the [non-default] V1 option selected in the command partition create (in lunash) becomes a V1 partition.

A V0 partition (whether created as V0 or a pre-existing partition that got upgraded with 7.7.0 firmware) can be converted to a V1 partition, without losing any contained objects. Do this by changing Policy 41 to value 1.

The Effects of Each Partition Type on HSM and Partition Functionality

The following sections describe how various aspects of HSM and application-partition functionality are affected by upgrading and by creating new partitions with the relevant creation-time options.

Partition Policy Considerations

Pre-firmware 7.7.0 Partition

There are no special considerations for pre-existing partitions, created with earlier firmware. Behavior with respect to Partition Policies is unchanged.

V0 Partition and V1 Partition

Partition policy 41 - Partition version

>Defaults to version zero (partition V0)

when a new partition is created on a firmware 7.7.0 (or newer) HSM

when a partition already exists on a pre-7.7.0 HSM that is then updated to firmware 7.7.0 (or newer)

>Becomes version one (partition V1)

when -version 1 is specified as a new partition is created on a firmware 7.7.0 (or newer) HSM

when lunacm command partition changepolicy -policy 41 -value 1 is issued

>V0 partition contents are preserved if/when policy 41 is set to version 1 (convert V0 partition to V1)

>The V1 status persists for the life of the partition unless command partition changepolicy -policy 41 -value 0 is issued

which reverts the partition to V0, and

all partition contents are erased, and

Scalable Key Storage and Per-Key Authorization are disabled.

>Some other policies are also interdependent with the partition version status. See Partition Capabilities and Policies 3, 7, 31, 32, and 40.

General HSM Behavior

Pre-firmware 7.7.0 Partition

There are no special considerations for pre-existing partitions, created with earlier firmware. Behavior with respect to cloning, backup, etc. is unchanged.

V0 Partition

Behavior defaults to V0 behavior, where keys reside in hardware.

Keys can be archived to a Backup HSM or shared for purposes of redundancy and load-balancing in an HA environment, but only when securely cloned among HSMs within the same encryption domain.

Your historic applications and integrations are supported.

V1 Partition

V1 option adds key export capability when you need to support larger numbers of keys than will fit inside an HSM, yet they must remain within the secure cryptographic boundary (Scalable Key Storage)

The exported keys are always encrypted by a master key (SMK) that remains within an HSM and can be securely copied only to another HSM that shares the same cryptographic domain.

Admin Partition Behavior with Pre-7.7.0 HSM / Pre-10.3.0 Client

Older client software (example 7.4 or 10.2.0) cannot create a V1 partition on an HSM with firmware 7.7.0 or newer.

Similarly, if a V1 partition is created on a 7.7.0 (or newer) Network HSM appliance and linked to an older Client, the client can see the remote partition, but cannot initialize or use the V1 partition. (Expect error CKR_ACCESS_ID_INVALID)

Client must be version 10.3.0 or newer to create and work with V1 partitions (see ** at the bottom of this page).

 

Cloning

Pre-firmware 7.7.0 Partition

There are no special considerations for pre-existing partitions, created with earlier firmware. Behavior with respect to cloning, Key Export etc. is unchanged.

V0 Partition

When an HSM's firmware is updated to version 7.7.0 or newer, any existing partitions become V0, and all contents are updated.

Keys/objects that have newer attributes, unknown to the older firmware, can be cloned if the newer attributes are at default value (unset), allowing them to be dropped by the older, receiving HSM. If a newer security-related attribute has been set, then the object is not cloned to an older HSM that is not aware of the attribute.

Keys can be imported from a pre-7.x HSM (5.x or 6.x) into a V0 partition on the firmware 7.7.0 (or newer) HSM, just as you would any object.

When cloning objects from HSM firmware earlier than 7.7.0 into V0 partition, the size of the object increases. As such, synchronization from partition in pre-7.7.0-firmware HSM to V0 partition may fail due to storage limitation.

V1 Partition

When a new V1 partition is created, or when a V0 partition is converted to V1,

>Objects cannot be cloned from a V0 partition or from a pre-7.7.0 partition into a V1 partition, and

>objects cannot be cloned from a V1 partition to a non-V1 partition.

NOTE   For older Luna versions, or situations where only cloning protocol version one (CPv1) is available, the library attempts to perform the individual actions of a cloning operation in sequence on the respective partitions, opening and closing a separate session for each object to be copied. If the policies and partition types on the source and target partitions are incompatible, the partition clone command (or an attempted HA synchronization) can fail with a message like CKR_DATA_LEN_RANGE while trying to clone. This can occur if a key object from the source partition is a different size than an equivalent object expected by the target.

UPDATE: Using Luna HSM Firmware 7.8.0 and newer, when a cloning negotiation agrees on the use of CPv4, a call to clone multiple keys/objects launches a single session for all the requested objects, rather than opening and closing individual sessions for each object. The above portion of this note about mismatched sizes remains valid.

Objects can be cloned, unwrapped, or legacy-SKS-inserted, directly to a V1 partition (i.e., SIMinsert) - note that cloning in such case is a one-way operation; V1 partitions perform outbound cloning only for SMKs.

SMK (SKS Master Key)

Pre-firmware 7.7.0 Partition

This is not applicable before firmware 7.7.0, because SKS and therefore the SMK do not exist in Luna HSM version 7 prior to firmware 7.7.0.

V0 Partition

Each V0 partition has a unique Primary SMK generated when the Crypto Officer role logs in for the first time, but it cannot be seen or used while the partition is in V0 state. However, that SMK is in place, in case you ever change partition policy 41 to make the current partition a V1 partition.

V1 Partition

Each V1 partition has a unique Primary SMK generated when the Crypto Officer role logs in for the first time, but it can also accept a replacement Primary SMK via cloning (such as when joining a partition to an existing HA group)

Each V1 partition also has additional SMK slots or holding areas for:

>Rollover SMK,

>SMKs from earlier-model HSMs,

>FM SMK for partitions with Functionality Modules enabled.

The Primary SMK secret is used to extract and to insert keys/objects; all other SMK secrets can be used only to insert keys/objects.

Behavior at Partition Level

Pre-firmware 7.7.0 Partition

There are no special considerations for pre-existing partitions, created with earlier firmware. Behavior with respect to cloning, backup, HA, etc., is unchanged.

V0 Partition

Whether pre-existing and updated, or newly created, V0 partitions should be generally indistinguishable from previous-firmware partitions -- continuing to work with your applications -- with provisos mentioned below. Cloning or Export/Import function as expected:

>from older versions (pre-firmware 7.7),

>to-or-from V0 partitions (firmware 7.7.0 or newer),

>but not back to older-version partitions.

Client versions earlier than 10.3 do not support expression of V0/V1 partition types (policy 41) for Partition Policy Template (PPT)

>partition showPolicies -exportTemplate does not report V0/V1 partition policy.

>partition init -label <somelabel> -applytemplate <template file> supports management of V0/V1 partition template correctly.

>Partition initialization without V0/V1 partition policy succeeds with correct default value (V0).

V1 Partition

Only the SKS Master Key (the SMK) is cloned from partition to partition, or from HSM to HSM for HA or for Backup/Restore. All other objects are encrypted with the SMK and Extracted for external storage or retrieved from external storage and inserted for use within the HSM.

Structure of Partition

Pre-firmware 7.7.0 Partition

There are no special considerations for pre-existing partitions, created with earlier firmware. Structure is unchanged until you update firmware to version 7.7.0 or newer.

V0 Partition

Partition structure is generally as for pre-7.7.0 partition, but with some updated overhead taking up some space; a completely filled pre-7.7.0 partition would need more room for objects after migration/firmware-update, but this is taken care of by partition size increases, as needed, during firmware update. The increase is enabled by an increase in available memory that is also part of the update process (see below).

V1 Partition

When a new partition is created at V1 or a V0 partition is converted to V1, the new structural overhead applies, including the space allotted for Primary and other SMKs.

Also, some keys can have new/additional attributes necessary to satisfy newer crypto and security standards.

Objects in a Partition

Pre-firmware 7.7.0 Partition

Object characteristics and behavior are unchanged until you update firmware to version 7.7.0 or newer.

V0 Partition

Memory allotment is increased (from pre-7.7) to allow increased partition size, all pre-existing keys and all new keys receive new attributes (if applicable to key type) but those attributes are not used for anything in V0 partitions (see * at the bottom of this page).

NOTE   The doubling of the memory allotted to partitions does not double the key capacity of partitions. It increases headroom to allow for increases in the data space required by keys, to accommodate new features and abilities, and does not alter published baselines for key capacity.  

V1 Partition

Memory allotment is increased (from pre-7.7) to allow increased partition size. There are no pre-existing keys in new V1 partitions, and all new keys receive the new attributes.

NOTE   The doubling of the memory allotted to partitions does not double the key capacity of partitions. It increases headroom to allow for increases in the data space required by keys, to accommodate new features and abilities, and does not alter published baselines for key capacity.  

Memory

Pre-firmware 7.7.0 Partition

Memory availability and usage are unchanged until you update firmware to version 7.7.0 or newer.

V0 Partition and V1 Partition

Size limit with FW version< 7.7.0 New size limit after upgrading to FW version >= 7.7
2 MB 4 MB
16 MB 32 MB
32 MB 64 MB

Example after mid-size update:

   Partition Storage:
			Total Storage Space:  3306327 
			Used Storage Space:   0 
			Free Storage Space:   3306327 
			Object Count:         0 
			Overhead:             15560  

NOTE   The doubling of the memory allotted to partitions does not double the key capacity of partitions. It increases headroom to allow for increases in the data space required by keys, to accommodate new features and abilities, and does not alter published baselines for key capacity.  

In summary, if you could store X-number of a given size of keys on your partition or HSM, then you can still store them all after 7.7.0 f/w update. The increase, at each allotment level was chosen to accommodate increased partition overhead and object size changes, plus some extra just in case (see * at the bottom of this page).

Behavior at Key Level

Pre-firmware 7.7.0 Partition

Key object characteristics and behavior are unchanged until you update firmware to version 7.7.0 or newer.

V0 Partition and V1 Partition

Some key types and algorithms might have constraints on the allowed uses of some older key and algorithm types and sizes, due to changes in the security and threat environments over time.

Check the latest mechanism summary tables in the SDK.

As with any firmware version update, some key types might be newly added, and some existing key types might have attributes that are used differently from previous. Where this might become apparent is when keys are replicated in an HA group with a mix of HSM firmware versions - for example, an existing application might attempt to make use of key sizes that are recognized as too small and of low security by group members with newer firmware, or a newer application might make use of newer attributes that are not recognized by older firmware (see Per-key Authorization, below, for example).

Partition Policy Template

Pre-firmware 7.7.0 Partition

partition showPolicies -exportTemplate generates a template file containing current policy settings

partition init -label <label> -applytemplate <template file> applies an existing template with the contained policy settings

V0 Partition

Both commands behave the same as in previous versions. V0 partitions have some policies that do not exist in pre-7.7.0 partitions. As long as none of the policies in your template conflict with the state of a new policy, your pre-existing templates should work correctly. Any policy that is not mentioned in a template is set to its default value when the template is applied.

If there is a mismatch between template policies and the default values of newer or dependent policies, then the attempt to apply the old policy would fail with CKR_FAILED_DEPENDENCIES.

You have the option to edit a policy file before applying it, to add newer policies.

V1 Partition

The default for new partition creation with firmware 7.7.0 (or newer) is a V0 partition. You could apply your PPT to creating a V1 partition only by pre-editing the policy template file to include setting policy 41 to a value of 1.

See also the lists of dependencies below the table at Partition Capabilities and Policies.

Per-Key Authorization

Pre-firmware 7.7.0 Partition

This is a new feature with firmware 7.7.0 and has no bearing on partitions at earlier firmware versions.

V0 Partition

Partition Policy 40 Enable Per-key Authorization Data defaults to 0 (zero, or off) for V0 partitions, and cannot be turned on. V0 partitions do not immediately provide per-key authentication data or attributes upon conversion to this partition version and key objects received from partitions on other HSMs (7.x-pre-7.7.0 HSMs, as well as 5.x and 6.x HSMs) come into the partition without auth data.

V1 Partition

Partition Policy 40 Enable Per-key Authorization Data defaults to 1 (one, or on) for V1 partitions, and can be turned off for performance.

Relevant keys have attributes, and are automatically assigned the CKA_AUTH_DATA attribute, that allow HSM owner to provide individual users access to specific keys for Sole Ownership and Control, such as in Remote Signing and Sealing applications.

Special considerations apply when importing key objects without per-key auth data into a Luna 7.7.0+ partition that enforces per-key authentication. For more information, refer to Migration Scenarios for Per-Key Auth.

Multifactor Quorum Authentication

Pre-firmware 7.7.0 Partition

Behavior of partitions at earlier firmware versions continues as-is (except see exceptions in next paragraph, if PEDs are updated).

V0 Partition and V1 Partition

>Luna PEDs with firmware 2.7.4 or 2.9.0 or newer can function with Luna HSM 7.7.0 and newer HSMs that have been updated for compliance with eIDAS/Common Criteria and NIST 800-56A standards.

>When an HSM is at firmware version 7.7.0 or newer, it verifies that any connecting PED is at PED firmware 2.7.4 or firmware 2.9.0, or the HSM refuses the connection and issues an error.

>The RPV of an orange PED key, created with PED firmware 2.7.4 or 2.9.0 against a firmware 7.7.0 HSM has additional features compared to previous RPV, necessary for current authentication standards.

>PEDs with firmware older than 2.7.4 or 2.9.0 can do the following:

Use a newer RPV, which was created with PED firmware 2.7.4 or 2.9.0 against a Luna HSM with firmware 7.7.0. However, the PED remains unaware of the newer security components.

Duplicate a newer RPV onto another orange key while only imprinting the older security components; that is, the newer security components are lost. The duplicated RPV can then be used with pre-firmware-7.7.0 HSMs, but since the newer security components are missing, the 'duplicate' orange key (and any copy of it) cannot be used with HSMs at version 7.7.0 or newer.

>For Remote PED operation,

any blank RPK must first be provisioned with new Critical Security Parameters (CSP) via a local PED connection;

the content of a previously provisioned orange Remote PED Key (RPK) with old CSP must be migrated to new CSP. The same is true for a newer-style RPV that had the newer security components stripped by copying with a non-updated PED, as described above. For more information, refer to Migrating Existing Orange Remote PED keys.

When the ped vector init’ command raises the PED prompt about "reuse an existing keyset?", this will lead to RPK migration (old to new).

>For Local PED, the local-connection handshake is now similar to that being used for updated, improved-security connections with Remote PED.

Client Software Interaction

Pre-firmware 7.7.0 Partition

Newer client software can include commands and options that are not applicable to partitions in older-firmware HSMs.

V0 Partition

Older client software (example 7.4) can create only a V0 partition on an HSM with firmware 7.7.0 or newer (see ** at the bottom of this page).

V1 Partition

Older client software (example 7.4 or 10.2.0) cannot create a V1 partition on an HSM with firmware 7.7.0 or newer.

Similarly, if a V1 partition is created on a 7.7.0 (or newer) Network HSM appliance and linked to an older Client, the client can see the remote partition, but cannot initialize or use the V1 partition. (Expect error CKR_ACCESS_ID_INVALID)

Client must be version 10.3.0 or newer to create and work with V1 partitions (see ** at the bottom of this page).

 

Client-Mediated High Availability

Pre-firmware 7.7.0 Partition

HA behaves as it always has, for pre-7.7.0 HSMs.

V0 Partition

Generally as-is (backward compatible) except for any provisos around permissibility of certain mechanisms and key sizes, such as in FIPS mode, and the usual considerations where an HA group should have all members at the same firmware .

Migration must be done via Luna Backup HSM while any application partitions on an HSM being updated to firmware 7.7.0 (or newer) must be removed from any HA group, at the time. The partitions can become members of HA groups after all are at the newer version.

Key/object replication among HA group members continues to use cloning.

V0 primary partitions in an HA group cannot synchronize with other members on a pre-7.7.0-firmware HSM.

A V0 partition on an appliance with HSM firmware 7.7.0 (or newer) can be added to an existing HA group that already has HA members made up of partitions from an HSM with pre-version-7.7.0 firmware.

V1 Partition

With V1 partitions, HA must function with SKS as the method of object / key replication among members, rather than cloning. Because this type of HA is client-mediated, you need Luna Client 10.3.0 or newer.

V1 partition can be added to an existing HA group that already has HA members made up of partitions from a pre-7.7.0-firmware HSM. However, when V1 partition becomes the primary member of the HA group, synchronization with remaining member of the HA group will no longer function.

An HA group with V1 partitions must have all members at V1 and all members sharing the same SMK.

A V1 partition cannot be a member of more than one HA group unless both groups have the same SMK. If a member of an existing HA group is added to a different HA group with a different SMK, the new member takes on the SMK of the new HA group and ceases to function properly in its original group (and should be removed).

High Availability Indirect Login

This type of HA is set up and managed by means of the HA Indirect Login API (a.k.a. "roll your own HA"), and does not rely on the Client.

Pre-firmware 7.7.0 Partition

HA behaves as it always has, for pre-7.7.0 HSMs (see High Availability Indirect Login Functions Prior to Luna HSM Firmware 7.7.0).

V0 Partition and V1 Partition

For adjustments to API and behavior, see High Availability Indirect Login For HSM Firmware 7.7.0 and Newer

Functionality Modules

Pre-firmware 7.7.0 Partition

FM behavior is as previously, for pre-7.7.0 HSMs.

V0 Partition and V1 Partition

Backup HSM (G5) at firmware 6.28 - FM-vs-non-FM support

  to HSM FW
<= 7.4 FM
to HSM FW
<= 7.4 non-FM
to HSM FW 7.7
V0 FM
to HSM FW 7.7
V0 non-FM
to HSM FW 7.7
V1 FM

to HSM FW 7.7

V1 non-FM

From HSM FW
7.4 FM
yes   no   yes   yes   yes   yes  
From HSM FW
7.4 non-FM
no   yes   no   yes   no   yes  

"yes" indicates a supported backup/restore path

Partition Roles

Pre-firmware 7.7.0 Partition

Roles and their behavior remain as-is for pre-7.7.0 HSMs.

V0 Partition

As in pre-7.7.0

V1 Partition

V1 partitions add the Limited Crypto Officer role for Per-Key Authorization operations see Partition Roles.

Backup/Restore

Pre-firmware 7.7.0 Partition

Backup and restore remain as-is for pre-7.7.0 HSMs.

V0 Partition and V1 Partition

Use of Luna Backup HSM G5 with V0 or V1 partitions implies Backup HSM firmware 6.28 and Luna Client 10.3 (or newer). Both the Client and the RBS server version must be aligned -- that is, the RBS server must be installed from the 10.3 Client or newer, replacing any previous RBS server.

A Luna Backup HSM G5 with firmware earlier than 6.28.0 can restore onto a partition in a firmware-7.7.0 (or newer) HSM, but the Luna Backup HSM G5 must be at firmware 6.28.0 in order to properly backup from a version 7.7.0 (or newer) application partition. In other words, if your Luna Backup HSM G5 is not updated, then its contents can be considered a backup for key-migration, but not a production backup for firmware 7.7.0 (and newer) HSM partitions.  

If there is a need to maintain an older version of client library for your main application and to use Luna Backup HSM G5 firmware 6.28.0 for backup/restore purposes, then you must have a separate workstation dedicated for running the RBS server from Luna Client 10.3.

Even if RBS service is not required, you would still need the separate workstation to run lunacm to take advantage of Luna Backup HSM G5 firmware 6.28.0.

Luna Backup HSM (G5) at firmware 6.28.0 used locally with Luna Network HSM appliance with software <=7.4

  to HSM FW
<= 7.4
to HSM FW
7.7 V0
to HSM FW
7.7 V1
From HSM
FW <= 7.4
 not
recommended
supported    supported

 

See also the functionality module-related Luna Backup HSM G5 concerns, above on this page.

NOTE   To perform backup operations on Luna HSM Firmware 7.7.0 or newer (V0 or V1 partitions) you require at minimum:

>Luna Backup HSM 7 Firmware 7.7.1

>Luna Backup HSM G5 Firmware 6.28.0

You can use a Luna Backup HSM with older firmware to restore objects to a V0 or V1 partition, but this is supported for purposes of getting your objects from the older partitions onto the newer V0 or V1 partitions only. V0 and V1 partitions are considered more secure than partitions at earlier firmware versions - any attempt to restore from a higher-security status to lower-security status fails gracefully.

When the Luna Backup HSM is connected directly to the Luna Network HSM 7 appliance, only the SMK can be backed up from or restored to a V1 partition.

 

The Limited Crypto Officer role does not do cloning, and therefore cannot transfer the current partition's SMK to a Backup HSM for SKS backup.  

Secure Trusted Channel

Pre-firmware 7.7.0 Partition

STC remains as-is for pre-7.7.0 HSMs.

V0 Partition and V1 Partition

>A newer version of STC is supported with cryptography that has been enhanced in the following ways:

New FIPS and Common Criteria compliant cipher suites added -- ECDH P-521 + AES-GCM and ECDH P-521 + AES-CTR + HMAC-SHA-512 -- for key derivation, encryption and authentication.

Key Derivation – Perfect forward secrecy

Each party provides an ephemeral key and a static key

Compromising the static key doesn’t compromise all past and future communications

Bilateral Key Confirmation and Unidirectional AES keys [NIST requirement]

Both parties ensure that the other party has derived the same keys

2 AES keys are derived: one for encryption and one for decryption

Prevents reverse replay attacks

For more information see Creating an STC Connection

>To use functionality modules (FMs) with STC client connections, you require the newer version of STC, which is used in Client-V0/V1 partition connections.

>To use the updated STC connections, you require Luna Appliance Software 7.7.0 or newer, Luna HSM Firmware 7.7.0 or newer, and Luna HSM Client 10.3.0 or newer.

>If you are using Luna HSM Firmware 7.4.2 or older, STC requires Luna HSM Client 10.2.0 or older.

------------

(* If you had thousands of very small keys, you would notice a definite increase in the partition space taken by those keys after update.
If you had 100 big keys or fewer in the partition, you would barely notice a change in required space, as the overhead [new attributes] per key is proportionately much smaller against an individual large key. )

(** Luna Cloud HSM software has historically been named/numbered for the associated HSM version. The Client numbering has been restarted at 10.x to decouple from specific firmware and software versions. )