Supporting Cryptographic Databases

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.

1. A user authentication database (UDATABASE) must exist. A user's authentication must be verified before making any cryptographic service request. Once verified, a user is considered ``logged in'' to the CM and a connection is established between the user's host application process and the CM. If multiple users can log in to the CM simultaneously and share its resources, it is the host operating system's and CM's responsibility to maintain the separation of service calls among simultaneous connections. It is therefore assumed that the CM knows the identity of the user executing any CM service call until the user specifically logs out of the CM.

   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.

2. For the secret key cryptography, a secure secret key database (SKEYDB) must exist to store the secret keys. Facilities must also be provided to control the lifecycle of a key and ensure that replacement keys are brought into operation securely and old keys are safely destroyed. SKEYDB may contain these fields: user id, key id, key value, key type and/or key attributes, and key counter if applicable. Generally speaking, storage space is more limited in a CM than in a host computer. Therefore, SKEYDB is more likely to reside in the host, even though this is not a requirement. Keys stored outside the CM must be protected by encryption. It is possible and may be desirable to combine UDATABASE and SKEYDB into one single database, which is a design issue to be determined by the implementor.

   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.

3. For the public key cryptography, a separate database (PKEYDB) must exist to store a user's private key and public key certificates. A certificate is associated with a unique identifier (CERTID), which can be a function of the user identification (USERID), the certification authority's identification (CAID), and a certificate serial number
   (CASERIALNO).

• User Database Management Service Calls
• Secret Key Cryptography Service Calls
  • Encryption and Data Integrity Service Calls
  • Key Management Service Calls
• Public Key Cryptography Service Calls
  • Encryption and Digital Signature Service Calls
  • Key Management Service Calls
• Sample Implementation of rpc.rexd Client