User Roles
As part of the ProtectToolkit-C configuration process, different user roles are assigned to those responsible for application administration and use.
For ProtectToolkit-C, there are four defined roles available. These are:
>Administration Security Officer (ASO)
For public access roles, see Unauthenticated Users.
Standard PKCS #11 defines the Security Officer (SO) and the Token Owner or User roles. Each slot and its associated token will have an SO and a User, each with their own respective PINs. A Security Officer grants and revokes access to a token and assists with key backups. A Token Owner uses the token for the application.
Two additional roles are only available on the Admin token. The holders of these roles handle HSM-level administration and management. These are the Administration Security Officer (ASO) and the Administrator. These roles effectively mirror their standard PKCS #11 counterparts.
It should be noted that the services available to the various roles are highly dependent upon the security policy set for the HSM. The following sections give a complete description of these roles and the services available to each of them.
Administration Security Officer (ASO)
This user knows and can present the Admin Token SO PIN. The ASO’s main role is to introduce the Administrator to the module. The following services are available to the ASO:
>Set the initial Administrator PIN value (ASO cannot change it later)
>Set the CKA_TRUSTED attribute on a Public object
>Set the CKA_EXPORT attribute on a Public object
>Exercise cryptographic services with Public objects
>Create, destroy, import, export, generate and derive Public objects
>Can change his/her own PIN
Administrator
This user knows and can present the Admin Token User PIN. The following services are available to the Administrator:
>Set or change the real-time clock (RTC) value
>Read the System Event Log
>Purge a full System Event Log
>Configure the Transport Mode feature
>Specify the security policy of the HSM
>Create new ProtectToolkit-C slots/tokens and specify their labels, SO PINs, and minimum PIN Length
>Initialize smart cards and specify their labels and SO PINs
>Destroy individual ProtectToolkit-C slots/tokens
>Erase all HSM secure memory, including all PINs and User Keys
>Perform firmware upgrade operations
>Manage Host Interface Master Keys
>Exercise cryptographic services with Public objects on the Admin Token
>Exercise cryptographic services with Private objects on the Admin Token
>Create, destroy, import, export, generate and derive Public objects on the Admin Token
>Create, destroy, import, export, generate and derive Private objects on the Admin Token
>May change his/her own PIN
Security Officer (SO)
Many users may be assigned this role. There will be one per user slot. The SO has the following abilities:
>Set the initial User PIN value (SO cannot change it later)
>Reset (re-initialize) the Token (destroys all keys and the User PIN on the Token) and set a new label
>Set the CKA_TRUSTED attribute on a Public object
>Set the CKA_EXPORT attribute on a Public object
>Exercise cryptographic services with Public objects
>Create, destroy, import, export, generate and derive Public objects
>May change his/her own PIN
Token Owner (User)
Many users may be assigned this role. There will be one per user slot. The user has these abilities:
>Exercise cryptographic services with Public objects
>Exercise cryptographic services with Private objects
>Create, destroy, import, export, generate and derive Public objects
>Create, destroy, import, export, generate and derive Private objects
>May change his/her own PIN
Unauthenticated Users
Public (unauthenticated) access to HSMs is allowed. Because authentication applies to tokens, a user may be simultaneously authenticated to one token while accessing another token without authentication.
NOTE The services available to unauthenticated users are heavily dependent on the active security policy.
Unauthenticated users have these abilities:
>Exercise status querying services
>Authenticate to a token
>If ‘No Clear PINs’ is not set, they may initialize User or Smart Card Tokens and specify their labels and SO PINs
>If token flag CKF_LOGIN_REQUIRED is FALSE, they can create, destroy, import, export, generate, derive and use Public objects on the token
>If token flag CKF_LOGIN_REQUIRED is FALSE, they can exercise cryptographic services with Public objects
>If ‘Authentication Protection’ is not set, they can exercise the digesting services
>Force session terminate, restart HSM by running the hsmreset utility.
