Object handles and labels

Objects in an HSM application partition are assigned unique handles when a session is initialized. A handle generally persists for the duration of the session, or until an object is deleted from a session.

From the PKCS#11 standard:

"When an object is created or found on a token by an application, Cryptoki assigns it an object handle for that application’s sessions to use to access it. A particular object on a token does not necessarily have a handle which is fixed for the lifetime of the object; however, if a particular session can use a particular handle to access a particular object, then that session will continue to be able to use that handle to access that object as long as the session continues to exist, the object continues to exist, and the object continues to be accessible to the session."

Where this association might not be applicable is when multiple Luna application partitions are gathered in an HA group. The same object on two different partitions can have different object handles. The HA functionality of the Luna HSM Client maps member partitions and their in-common contained objects in a virtual partition that is the exclusive application access point for the group. See High-Availability Groups. We recommend that, when deploying an HA group, you set hagroup haonly, which hides HA-group member partitions, and displays only the virtual partition in the slot list. Addressing member partitions directly, to make changes, can disrupt HA function. The ephemeral list of objects used by the virtual partition is recreated with each new session, and updated during the session. Within a session, that list is a cache of those objects requested during the session, making for faster look-up of objects that are used repeatedly.

Labels can be applied to objects to assist in identifying them across separate sessions and across multiple partitions; a label persists for the life of the object, and is therefore a more reliable method of identifying objects in those situations.