V0 and V1 Partitions
Luna HSMs traditionally store sensitive cryptographic objects within the HSM only, except for cloning to another Luna HSM, or secure wrapping for export. The latest Luna USB HSM 7 firmware provides a third option, Scalable Key Storage (SKS), which allows you to securely store more keys than will fit in HSM storage. You can enable these different options using partition policies, to select one of the following partition types:
| Version 0 (V0) Partitions | Version 1 (V1) Partitions |
|---|---|
|
Cryptographic objects are securely stored in the HSM hardware. A partition can be configured to allow private and secret keys to leave the partition by only one of the following methods: >Cloning to another Luna HSM partition •Domain Planning and Key Cloning >Secure wrapping for export off the partition •Setting Key Export Mode on a Partition Refer to Cloning or Export of Private Keys to enable one of these modes on a V0 partition. |
On a V1 partition, one of the V0 modes (Cloning or Key Export) can be configured. V1 partitions also enable the following features: >Scalable Key Storage allows secure storage of cryptographic objects in a database outside the HSM. This lets you manage objects without the storage restrictions of an application partition. >Per-Key Authorization allows you to assign an authentication credential to individual keys, so they can only be accessed by authorized users. These features are introduced to conform to FIPS SP 800-131A (revised), and to comply with current and anticipated Common Criteria and eIDAS requirements. |
You can migrate existing keys and objects from a Luna application partition that was created before the introduction of V0 and V1 partitions. The following sections provide additional detail about differences between the partition types and implications of switching between them.
Setting V0 or V1 on an Application Partiton
The partition version is determined by partition policy 41 (see Partition Capabilities and Policies), set to V0 by default on a newly-created partition. There are three ways to set V1 on an application partition:
>The HSM SO can set V1 at the time of partition creation (see Creating the Application Partition)
>The Partition SO can set policy 41 to 1 during initialization, using a policy template (see Setting Partition Policies Using a Template)
>The Partition SO can convert the default V0 partition to V1 at any time after initializing the partition (see Setting Partition Policies Manually). Converting a partition from V0 to V1 is non-destructive; converting from V1 to V0 is destructive, resulting in the loss of all objects on the partition.
Special Characteristics of V0 Partitions
V0 partitions maintain all the same functionality and behavior as Luna HSM partitions using firmware prior to Luna HSM Firmware 7.7.0. Keys reside only within the secure HSM hardware and can be transferred to another Luna partition that is part of the same cloning domain (backup/restore, HA groups, slot-to-slot), or wrapped and exported off the partition, depending on the partition policy settings (see Cloning or Export of Private Keys).
V0 partitions use a new cloning protocol with enhanced security. Since Luna HSMs do not allow cloning objects from more-secure to less-secure environments, objects can be cloned from older firmware partitions to V0 partitions, but not from V0 partitions to partitions using older Luna HSM firmware. This has implications for various HSM functions:
>Partition storage overhead: V0 partitions require more space than older firmware partitions, mainly for new attributes (related to V1 functionality) that are added to cryptographic keys. These attributes become relevant only when a V0 partition is converted to a V1 partition.
The Luna USB HSM 7 provides more than enough HSM storage space to import all objects stored on an older Luna HSM.
>High-Availability Groups: V0 partitions can work in an HA group with other V0 partitions. You can create an HA group with a mix of V0 and older-firmware partitions only for the purposes of migrating keys to the V0 partition. Do not attempt to use V0 partitions in a production HA group including partitions with firmware older than Luna HSM Firmware 7.7.0.
>Backup/Restore: V0 partitions have the same Backup HSM firmware requirements as V1 partitions:
•Luna Backup HSM 7 Firmware 7.7.1
•Luna Backup HSM G5 Firmware 6.28.0
A Backup HSM with older firmware may be used to migrate objects from older Luna HSM firmware to a V0 partition, but this is a one-way operation only.
Special Characteristics of V1 Partitions
As described above, V1 partitions add new features that change the way objects are securely stored on the HSM (Scalable Key Storage) and the function of individual keys (Per-Key Authorization). In addition to these new features, the new cloning protocol has implications for various HSM functions:
>SKS Master Keys: Keys that are exported to a database using Scalable Key Storage are encrypted with an SKS Master Key (SMK) on the partition. The SMK is generated when the Crypto Officer logs in for the first time, but can be replaced with another primary SMK cloned from another partition. During cloning operations (HA, backup/restore, slot-to-slot cloning), only the SMK is cloned, and only to another V1 partition. Key objects remain in the secure database and they cannot be cloned to another partition. Replication or archiving of objects is done using SKS only.
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.
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.
>Partition storage overhead: V1 partitions require more space than older firmware partitions, for SMKs and new key attributes used for V1 features. This additional overhead also applies to V0 partitions, but the features only become active when the partition is converted to V1.
>Partition Policy 40: Enable Per-Key Authorization: This policy is enabled by default on V1 partitions. If you do not plan to use Per-Key Authorization, you can disable this policy to improve performance.
>High-Availability Groups: V1 partitions use SKS as the method of object replication among group members, rather than cloning.
>Limited Crypto Officer: V1 partitions have an additional Limited Crypto Officer role, which enables Per-Key Authorization (see Partition Roles).
>Backup/Restore: V1 partitions have the same Backup HSM firmware requirements as V0 partitions:
•Luna Backup HSM 7 Firmware 7.7.1
•Luna Backup HSM G5 Firmware 6.28.0
A Backup HSM with older firmware may be used to migrate objects from older Luna HSM firmware to a V0 partition, but this is a one-way operation only.
