Before the cryptographic service calls are presented, it is desirable to address the necessary databases in support of cryptographic functions. To perform cryptographic functions securely, the Cryptographic Module (CM) must exercise proper access control. Users requesting cryptographic services must be authenticated before their secret keys can be retrieved from secure storage. Users' access and usage of data must also be authorized. To support these controls, the following databases must exist.
Each element in the user authentication database should contain at least four fields: user id, user authenticator, user type, and user authorization vector. The user id is simply the user's name. The user authenticator can be a password, a biometrics template, or anything else that can be used to authenticate a user. It may be desirable to control access to the CM through different access privileges. The user having the highest authorization privilege is the cryptographic officer (CO). The field ``user type'' is used to indicate whether a user is a CO or a regular user. The CO assigns specific cryptographic service calls that a user can access in the user authorization vector. When a CM is used for the first time, a CO should initialize the CM and the UDATABASE would then contain an entry for the CO.
For the operation of cryptographic functions, keys must be loaded into the proper registers of the CM before cryptographic functions can take place. These registers are CM-dependent and are not to be confused with the generic secure key database (SKEYDB). The retrieval of keys from SKEYDB and the subsequent loading of the keys into the CM registers is handled by the cryptographic module rather than by the application programs, therefore, no cryptographic service call is defined for key retrieval for the CM. For easy referencing, let the registers of a CM be called CMKEYREG. Depending on the type of CM used, the storage of keys in CMKEYREG may be temporary whereas the storage of keys in SKEYDB is more permanent, that is until a key is specifically removed. Keys can be loaded to or removed from SKEYDB by cryptographic service calls.