What are "pre-firmware 7.7.0", and V0, and V1 partitions?

Luna HSM preserves traditional keys-in-hardware operation, and improves on it with fixes and security updates, while also adding the option to securely store more keys than will fit inside an HSM.

Traditional support of Luna features is retained in what we call version zero or V0 partitions, to distinguish from version one or V1 partitions, that:

>implement Scalable Key Storage (SKS) to securely externally store and manage keys in vastly greater quantities than can fit inside an HSM,

>conform with FIPS SP 800-131A (revised),

>comply with current and anticipated Common Criteria and eIDAS requirements (including Per-Key Authorization (PKA) ),

You can create either kind of application partition (the default is V0) or you can update firmware from pre-7.7.0 and have your existing partitions automatically become version zero with no loss of functionality, and with a further option to convert to version one if there is ever a need.

This section is of interest

>to customers who already have HSMs in operation and are looking to upgrade, 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 Client software 10.3.0 or newer and

•Luna Network HSM 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.0" 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.

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 outside the HSM, >Adds Per-Key Authorization capability, >... both for RSS and other applications.

The following sections go into greater, more explicit detail about how various aspects of HSM / application-Partition functionality are affected by upgrading and by creating new partitions with the relevant creation-time options.

What is the origin of each partition type

Pre-firmware 7.7.0 Partition

This is any partition on a Luna HSM from firmware version from 7.0 up to (but not including) version 7.7.0.

V0 Partition (Firmware 7.7.0 or newer)

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 lunacm) .

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 (Firmware 7.7.0 or newer)

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

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.

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 (Firmware 7.7.0 or newer) and V1 Partition (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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 (SKS))

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 (Firmware 7.7.0 or newer)

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

The cloning protocol becomes a newer, more secure version that can accept objects cloned from older versions, but that is not permitted to clone to an older version HSM.

V1 Partition (Firmware 7.7.0 or newer)

When a new V1 partition is created, or when a V0 partition is converted to V1, cloning is restricted to only the SMK. Replication or archiving of objects is done via SKS only.

>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.

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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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).

V1 Partition (Firmware 7.7.0 or newer)

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.

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 (Firmware 7.7.0 or newer) and V1 Partition (Firmware 7.7.0 or newer)

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  

 

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 (Firmware 7.7.0 or newer) and V1 Partition (Firmware 7.7.0 or newer)

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.

PPT (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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

Partition Policy 40 Enable Per-key Authorization Data defaults to 0 (zero, or off) for V0 partitions, and cannot be turned on.

V1 Partition (Firmware 7.7.0 or newer)

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 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.

Multi-factor authentication (PED-auth)

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 (Firmware 7.7.0 or newer) and V1 Partition (Firmware 7.7.0 or newer)

>Old-series PEDs (firmware 2.6.x through 2.7.2, PED powered by power block) have an upgrade path to PED version 2.7.4.

>New-series PEDs (firmware 2.8.x, PED is USB-powered) have an upgrade path to PED version 2.9.0.

>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, respectively, or the HSM refuses the connection and issues an error.

>When updating pre-7.7.0 PED-auth HSMs, at least one PED must be updated first, so that it remains possible to authenticate to roles on the HSM before/during/after the HSM update.

>An updated PED can function

•with older HSMs (HSM f/w 5.x and 6.x) that will not be updated with the new PED communication protocols, or

•with earlier f/w 7.x HSMs that have yet to be updated, or

•with f/w 7.7.0 and newer HSMs that have been updated for compliance with eIDAS/Common Criteria and NIST 800-56A standards.

>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.

••When the ped vector init’ command raises the PED prompt about "reuse an existing keyset?" 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 older-firmware. HSMs.

V0 Partition (Firmware 7.7.0 or newer)

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 (Firmware 7.7.0 or newer)

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).

 

HA (client mediated)

Pre-firmware 7.7.0 Partition

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

V0 Partition (Firmware 7.7.0 or newer)

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 G5 or G7 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.

V1 Partition (Firmware 7.7.0 or newer)

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.

HA 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 HSM Firmware 7.7 ).

V0 Partition (Firmware 7.7.0 or newer) and V1 Partition (Firmware 7.7.0 or newer)

For adjustments to API and behavior, see HA Indirect Login (firmware 7.7.0 and newer)

Functionality Modules (FMs)

Pre-firmware 7.7.0 Partition

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

V0 Partition (Firmware 7.7.0 or newer) and V1 Partition (Firmware 7.7.0 or newer)

 

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 (Firmware 7.7.0 or newer)

As in pre-7.7.0

V1 Partition (Firmware 7.7.0 or newer)

V1 partitions add the Limited Crypto Officer role for Per-Key Authorization operations see saw

Backup/Restore

Pre-firmware 7.7.0 Partition

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

V0 Partition (Firmware 7.7.0 or newer) and V1 Partition (Firmware 7.7.0 or newer)

 

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 G5 Backup concerns, above on this page.  

 

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.  

STC (Secure Trusted Channel)

Pre-firmware 7.7.0 Partition

STC remains as-is for pre-7.7.0 HSMs.

V0 Partition (Firmware 7.7.0 or newer) and V1 Partition (Firmware 7.7.0 or newer)

>7.7.0 (and newer) version of STC is supported "Creating an STC Connection" on page 1

>7.7.0 appliance software and HSM firmware (or newer) and 10.3.0 Client software are required

>previous version STC is not supported for 7.7.0-and-newer systems,

>if STC was configured on your system, it must be shut down before update to HSM appliance software and firmware 7.7.0 or Client 10.3.0 (or newer) - disabling policy 37 is a destructive action, so keys must be backed up first

>after the updates are completed, STC can be configured again.

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

(* If you had [say] thousands of very small keys, you would notice a definite increase in the partition space taken by those keys after update.
If you had [say] 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 Client 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. )