Per-Key Authorization
Per-key authorization or authentication (PKA) is a feature introduced with Luna HSM Firmware 7.7.0 to support the eIDAS use case of Remote Signing and Sealing (RSS) and the relevant Protection Profile (PP 419-221.5). PKA introduces data structures to keys that are created and manipulated in the HSM such that keys can be handled in the ways that applications normally handle key material, but under the sole ownership and control of an end-user natural person or legal entity. The attributes are applied to keys that are created with Luna HSM Firmware 7.7.0 (or newer). In V0 partitions those attributes are simply ignored. In V1 partitions the attributes are actively used. See more at V0 and V1 Partitions.
Keys for use in eIDAS schemas:
>have authentication data structures that allow the possibility for an entity to have sole ownership and control
>can be unassigned, waiting for distribution to eventual owners/Users, or
>can be assigned to the control of a specific owner/User.
When a key has auth code data attached, then by definition anyone who holds the auth code is a/the key owner. But before it is assigned, the key does not have an owner/User, and might be part of a pool of unassigned keys, waiting for distribution to users. Keys do take some time to generate, so in times of high demand, it could be practical and convenient to have some ready-to-go.
Keys are intended to be used, but they must also be administered. That is, an individual natural person (or a non-natural legal entity) authorizes cryptographic usage of a key, perhaps to sign forms or documents. At the same time, the HSM has roles that perform actions within the HSM, either:
>generally - the eIDAS Administrator role represented by the Crypto Officer (CO) role in the HSM) or
>specifically/individually - the eIDAS User role represented by the Limited Crypto Officer (LCO) role in the HSM.
So, a citizen might log into a service and perform an action that directs the application to retrieve their existing personal key from a database/repository and insert/decrypt the key into an HSM partition, where the citizen authorizes a signing or other operation, and then the copy of the key is deleted from the HSM partition, but the archived, encrypted copy resides safely in the database for future retrieval and use. Alternatively, a citizen might request a single-use key, that is generated 'on-the-spot' in the HSM partition (by the LCO role) and is authorized by that citizen to perform one action (like signing) and then the key is permanently deleted, with no copy existing anywhere.
Generally, these and other operations related to keys are not performed by administrative commands (tools like LunaCM); rather, they are performed via the PKA API or REST, while the performing application is logged in as one or the other of the partition roles.
Example Use Case
For example, an application might be instructed to retrieve a certain key and use it to sign a document on behalf of a citizen. The application acquires the key from a database (in the form of an encrypted blob) and inserts it into an HSM where it is decrypted to reveal the key that is to be used. But the application is able to actually use that key only when the owner/citizen presents her/his unique authentication data, which is part of the key attributes.
New Role and Handling
In order to manage this service, the individual application partition's Crypto Officer role and a new role called Limited Crypto User handle the actions of creating, modifying, and using keys containing auth data.
A key can be created in an assigned state, where it is immediately associated with an entity, or a key can be created in unassigned state and only later assigned to an owner, when convenient.
No New Administrative Commands
Because the operations around PKA and RSS are handled programmatically, no particular administrative commands are introduced - only a new -version option for partition creation and a new partition policy 40, which is off for V0 partitions, and which defaults to on for V1 partitions, but can be turned off if desired. Everything else about PKA is handled by the Per-Key Authorization API.
Dependencies and Interactions with Other Features
The feature is ignored by older clients and applications that do not know how to make use of it. Active use of PKA requires a V1 partition, which means that cloning is used for:
>incoming keys and objects from older firmware, but not outgoing (that is, on V1 partitions, cloning of keys is inbound migration, only)
>copying (such as for HA), or backing-up/restoring, of the SMK
All other objects are stored, encrypted by the SMK, in external storage using the Scalable Key Storage (SKS) feature.
Stored Data Integrity (SDI) is also mandated by eIDAS and is therefore applied by Luna HSM Firmware 7.7.0 and newer.
HA Indirect Login support is constrained differently for V0 and V1 partitions - see section "V0 Partitions" in Per-Key Authorization API.
