Cryptographic Coprocessors use role-based access control. In a role-based system, you define a set of roles, which correspond to the classes of Coprocessor users. You can enroll each user by defining an associated user profile to map the user to one of the available roles.
The capabilities of a role are dependent on the access control points or cryptographic hardware commands that are enabled for that role. You can then use your Cryptographic Coprocessor to create profiles that are based on the role you choose.
A role-based system is more efficient than one in which the authority is assigned individually for each user. In general, you can separate the users into just a few different categories of access rights. The use of roles allows you to define each of these categories just once, in the form of a role.
The role-based access control system and the grouping of permissible commands that you can use are designed to support a variety of security policies. In particular, you can set up Cryptographic Coprocessors to enforce a dual-control, split-knowledge policy. Under this policy no one person should be able to cause detrimental actions other than a denial-of-service attack, once the Cryptographic Coprocessor is fully activated. To implement this policy, and many other approaches, you need to limit your use of certain commands. As you design your application, consider the commands you must enable or restrict in the access-control system and the implications to your security policy.
Every Cryptographic Coprocessor must have a role called the default role. Any user that has not logged on to the Cryptographic Coprocessor will operate with the capabilities defined in the default role. Users who only need the capabilities defined in the default role do not need a profile. In most applications, the majority of the users will operate under the default role, and will not have user profiles. Typically, only security officers and other special users need profiles.
The default role is initially defined such that the functions permitted are those functions that are related to access control initialization. This guarantees that the Cryptographic Coprocessor will be initialized before you do any useful cryptographic work. The requirement prevents security "accidents" in which someone might accidentally leave authority intact when you put the Coprocessor into service.
The easiest and fastest way to define new roles (and redefine the default role) is to use the Cryptographic Coprocessor configuration web-based utility found off of the System Tasks page at http://server-name:2001. The utility includes the Basic configuration wizard that is used when the Coprocessor is in an un-initialized state. The Basic configuration wizard can define either 1 or 3 administrative roles along with redefining the default role. If the Coprocessor already has been initialized, then click on Manage configuration and then click on Roles to define new roles or change or delete existing ones.
If you would prefer to write your own application to manage roles, you can do so by using the Access_Control_Initialization (CSUAACI) and Access_Control_Maintenance (CSUAACM) API verbs. To change the default role in your Coprocessor, specify "DEFAULT" encoded in ASCII into the proper parameter. You must pad this with one ASCII space character. Otherwise, there are no restrictions on the characters that you may use for role IDs or profile IDs.
After you create and define a role for your Coprocessor, you can create a profile to use under this role. A profile allows users to access specific functions for your Coprocessor that may not be enabled for the default role.
The easiest and fastest way to define new profiles is to use the Cryptographic Coprocessor configuration web-based utility, located on the System Tasks page at http://server-name:2001. The utility includes the Basic configuration wizard that is used when the Coprocessor is in an un-initialized state. The Basic configuration wizard can define either one or three administrative profiles. If the Coprocessor has already been initialized, click to define new profiles or change or delete existing ones.
If you want to write your own application to manage profiles, you can use the Access_Control_Initialization (CSUAACI) and Access_Control_Maintenance (CSUAACM) API verbs.
The Basic configuration wizard in the Cryptographic Coprocessor configuration utility automatically redefines the default role such that it can be used for SSL without any changes.
For the most secure environment, consider locking the access-control system after initializing it. You can render the access-control system unchangeable by deleting any profile that would allow use of the Access Control Initialization or the Delete Role access control point. Without these access control points, further changes to any role are not possible. With authority to use either the Initialize Access Control or Delete Role access control points, one can delete the DEFAULT role.
Deleting the DEFAULT role will cause the automatic recreation of the initial DEFAULT role. The initial DEFAULT role permits setting up any capabilities. Users with access to these access control points have unlimited authority through manipulation of the access-control system. Before the Coprocessor is put into normal operation, the access-control setup can be audited through the use of the Access_Control_Maintenance (CSUAACM) and Cryptographic_Facility_Query (CSUACFQ) API verbs.
If for any reason the status response is not as anticipated, the Coprocessor should not be used for application purposes until it has been configured again to match your security policy. If a role contains permission to change a pass phrase, the pass phrase of any profile can be changed. You should consider if passphrase changing should be permitted and, if so, which role(s) should have this authority.
If any user reports an inability to log on, this should be reported to someone other than (or certainly in addition to) an individual with pass phrase changing permission. Consider defining roles so that dual-control is required for every security sensitive operation to protect against a malicious insider acting on his/her own. For example, consider splitting the following groups of access control points between two or more roles. It is recommended that one person should not be able to use all of the commands in the Master key group, because this could represent a security risk.
By the same token, one person should not be authorized to all of the commands in the Cloning key group.
The Cloning key group consists of these access control points:
After you create and define a profile for your Coprocessor, you must load a function control vector for your Coprocessor. Without the function control vector, your Coprocessor cannot perform any cryptographic functions.