|
Home > |
|---|
Depending on the SafeNet HSM and its configuration, the HSM can have three, or more, logical partitions.
•One for the Security Officer (SO)
•One for the Auditor, and
•One (or more) for applications and Clients.
In rare circumstance, the Security Officer might create and keep cryptographic objects, Normally it is not used for "production" cryptographic operations - the SO space is intended for overall HSM-level administration.
The Auditor partition is used to enable and manage secure audit logging activities, and generally has no other function in the HSM.
The application partition (or partitions, depending upon HSM type and configuration) is enabled (Activated) and managed by the partition User Owner in some regimes), and is then used by client applications to create and use cryptographic objects, and to perform cryptographic operations.
The ordinary partition User entity can be further sub-divided into Crypto Officer and Crypto-User in cryptographic security regimes that require this distinction. Legacy partitions are under the administrative control of the HSM SO, and do not have their own separate SO. The User or the Crypto Officer entity is created by the HSM SO.
Either type (legacy or PPSO) can be created on an HSM with firmware 6.22.0 or newer and with the PPSO capability update installed. On HSMs that support multiple application partitions it is possible to create both types on the same HSM. A PPSO partition has its own SO. The Partition SO manages what happens inside its partition. The HSM SO creates the PPSO partition, and deletes it when necessary, but has no other oversight or control of the PPSO partition. This distinction is particularly important in cloud scenarios, but is a significant element in separation of roles for any use of an HSM.
Crypto operations are normally performed from a logged-in session on the HSM. It is possible to create objects without logging in, so long as the CKA_PRIVATE attribute is set to 0 - that is, public objects. You can also delete any object that has CKA_PRIVATE=0. This is as defined in PKCS#11, and is not a security issue.
The restrictions that you expect come into play for objects that are created with CKA_PRIVATE=1, where only the owner is able to delete (or the SO could delete the entire partition containing the objects).
These distinctions can be demonstrated with CKDEMO commands 1) Open Session, and 3) Login.
The "Open Session" prompt has three options, to choose the partition that you wish to use:
Enter your choice (99 or 'FULL' for full help): 1
SO[0], normal user[1], or audit user[2]?
If you select "normal user [1]", when opening a session, you are telling the library that you choose to use the user partition which is owned by the partition User (or is shared by the Crypto-Officer and Crypto-User if the partition User has been separated into those two sub-entities).
The session is started, but you have not yet authenticated, and so cannot perform most operations in the session.
The Login prompt has four options, to perform the needed authentication (log into the session that you started above):
Enter your choice (99 or 'FULL' for full help): 3
Security Officer[0]
Crypto-Officer [1]
Crypto-User [2]:
Audit-User [3]:
Enter PIN :
If you have chosen the "normal user [1]" partition, when opening the session, then the valid login authentication options are:
•Crypto-Officer (which is the same as partition User (the black PED Key for PED-authenticated HSMs) if the Crypto-Officer/Crypto-User distinction is not in force) or
•Crypto User (which is the limited user when the Crypto-Officer/Crypto-User distinction has been invoked).
If you attempt one of the other two authentications, "Security Officer [0]" or "Audit-User [3]", an error message is returned because those are not applicable to the session type (therefore, the partition type) that you selected earlier.
If certificates are created as private objects (CKA_PRIVATE=1), the Crypto User cannot delete them. Also, the Crypto User cannot create fake private objects with CKA_PRIVATE=1. The Crypto User limitations are focused on restricting access to sensitive and/or private keys and objects.
LUNA_CREATE_OBJECT:
LUNA_COPY_OBJECT:
LUNA_DESTROY_OBJECT:
LUNA_MODIFY_OBJECT:
LUNA_DESTROY_MULTIPLE_OBJECTS:
LUNA_GENERATE_KEY:
LUNA_GENERATE_KEY_W_VALUE:
LUNA_GENERATE_KEY_PAIR:
LUNA_WRAP_KEY:
LUNA_UNWRAP_KEY:
LUNA_UNWRAP_KEY_W_VALUE:
LUNA_DERIVE_KEY:
LUNA_DERIVE_KEY_W_VALUE:
LUNA_MODIFY_USAGE_COUNT:
LUNA_ENCRYPT_INIT:
LUNA_ENCRYPT:
LUNA_ENCRYPT_END:
LUNA_ENCRYPT_SINGLEPART:
LUNA_DECRYPT_INIT:
LUNA_DECRYPT:
LUNA_DECRYPT_END:
LUNA_DECRYPT_RAW_RSA:
LUNA_DECRYPT_SINGLEPART:
LUNA_DIGEST_INIT:
LUNA_DIGEST:
LUNA_DIGEST_KEY:
LUNA_DIGEST_END:
LUNA_SIGN_INIT:
LUNA_SIGN:
LUNA_SIGN_END:
LUNA_SIGN_SINGLEPART:
LUNA_VERIFY_INIT:
LUNA_VERIFY:
LUNA_VERIFY_END:
LUNA_VERIFY_SINGLEPART:
LUNA_GET_OBJECT_SIZE:
LUNA_SEED_RANDOM:
LUNA_GET:
LUNA_GET_CONTAINER_LIST:
LUNA_GET_CONTAINER_NAME:
LUNA_LOGIN:
LUNA_OPEN_SESSION:
LUNA_PARTITION_SERNUM_GET:
LUNA_FIND_OBJECTS:
LUNA_GET_RANDOM:
LUNA_OPEN_ACCESS:
LUNA_GET_MECH_LIST:
LUNA_GET_MECH_INFO:
LUNA_SELF_TEST:
LUNA_GET_HSM_CAPABILITY_SET:
LUNA_GET_HSM_POLICY_SET:
LUNA_GET_CONTAINER_CAPABILITY_SET:
LUNA_GET_CONTAINER_POLICY_SET:
LUNA_GET_CONFIGURATION_ELEMENT_DESCRIPTION:
LUNA_RETRIEVE_LICENSE_LIST:
LUNA_QUERY_LICENSE:
LUNA_GET_CONTAINER_STATUS:
LUNA_GET_OUID:
LUNA_GET_CONTAINER_STORAGE_INFO:
LUNA_GET_ATTRIBUTE_VALUE:
LUNA_GET_ATTRIBUTE_SIZE:
LUNA_GET_HANDLE:
LUNA_INIT_TOKEN:
LUNA_PARTITION_INIT:
LUNA_CLOSE_ACCESS:
LUNA_DEACTIVATE:
LUNA_MTK_GET_STATE:
LUNA_MTK_RESPLIT:
LUNA_MTK_RESTORE:
LUNA_MTK_UNLOCK_CHALLENGE:
LUNA_MTK_UNLOCK_RESPONSE:
LUNA_MTK_ZEROIZE:
LUNA_CLEAN_ACCESS:
LUNA_PED_GET_SET_RAW_DATA:
LUNA_ZEROIZE:
LUNA_FACTORY_RESET:
LUNA_HA_LOGIN:
LUNA_CONFIGURE_SP:
LUNA_LOG_POLL_HOST:
LUNA_LOG_EXTERNAL:
LUNA_ROLE_STATE_GET:
LUNA_LOGOUT:
LUNA_CLOSE_ALL_SESSIONS:
LUNA_CLOSE_SESSION:
LUNA_GET_SESSION_INFO: