Product Documentation

    Adding a new normal user to the SAKA internal database requires creating a unique username for the user, assigning a password to them, and assigning either the encryption, decryption, deletion, search or a combination of these privileges to the user. When creating the pinguser, you must assign it only the decryption privilege.

    Adding a Domain Administrator requires creating a unique username for the DA, assigning a password to the DA, assigning them the SAKA DA privilege and specifying the digital certificate of the new DA so their digital signature can be verified for authentication and administrative actions.

    NOTE: It is recommended for security reasons, that with the exception of the first Domain Administrator—which is created as part of the SAKA setup—that DAs not be assigned any cryptographic privileges to encrypt, decrypt or delete sensitive data. This allows separate administrative privileges from cryptographic privileges for control purposes.

    After additional DAs have been created, the first DA's credential may be locked up and maintained—with its PIN in a sealed, tamper-evident envelope—as a safety measure in a remote location: either a bank safe or in the custody of a non-technical custodian.

    To add a new user to SAKA, click Add New User on the side-panel or Users → Add User on the menu. The following panel displays, allowing addition of a new user—DA or Normal—to the internal SAKA database.

    Currently connected to SAKA

    The SAKA URL to which DACTool is currently connected.

    Domain Identifier (DID)

    The unique identifier of the encryption domain to which DACTool is currently connected.

    Username

    The username of the new user who is being granted privileges to this SED. While the system can use any username, it is better to use some standard convention to make management easier. Here are a few suggestions:

    • If the user is a new DA, then use the username administrator followed by a numeral indicating the number of the DA within this SED. The first DA for an SED always has the username administrator1, so the next one should be called administrator2, and so on.

    • If the user is the ping user, the username must be pinguser.

    • If the username is for an application, then it is recommended to use the terms encryptonly-, decryptonly-, or encryptdecrypt- as prefixes to the application's abbreviation to identify the authorization of the username. For example, if the application is a point-of-sale application, a username with only encryption privileges might be called encryptonly-pos01 for the first such username.

    If a username already exists in the SAKA database, an error message will be returned indicating a duplicate value already exists.

    Password

    A password for the new user. The password must be a minimum of 8 characters with a combination of alphabet, numerals, and at least one special character.

    Again

    A field for repeating the new user's password to verify it.

    Encryption Authorized

    These radio buttons determine whether the new user is authorized to request encryption web services. By default it is set to Yes. However, it can be changed to No, if desired.

    Decryption Authorized

    This radio button group determines whether the new user is authorized to request decryption web services. By default it is No. However, it can be changed to Yes, if desired.

    Deletion Authorized

    This radio button group determines whether the new user is authorized to request deletion web services. By default it is set to No. However, it can be changed to Yes, if desired.

    Search Authorized

    This radio button group determines whether the new user is authorized to request search web services. By default it is set to No. However, it can be changed to Yes, if desired.

    Relay Authorized

    This radio button group determines whether the new user is authorized to request relay web services. By default it is set to No. However, it can be changed to Yes, if desired.

    SAKA Domain Administrator?

    This radio button group determines whether the new user is to be designated as a DA for this SED. By default, it is No. If the choice is set to Yes, three other radio buttons become enabled.

    Generate Keystore

    This radio button indicates that DACTool must generate a new EC cryptographic key pair for the new DA, and also must create a digital certificate signed by the Signing Key of this SED. If this radio button is selected, the Keystore field becomes enabled to specify the location of the BCFKS keystore.

    Paste CSR

    This radio button indicates that DACTool must accept a Certificate Signing Request (CSR) generated elsewhere for the new DA, and also must create a digital certificate signed by the Signing Key of this SED. No cryptographic keys are generated by DACTool for this option. If this radio button is selected, the Certificate Signing Request field is enabled to accept the CSR text.

    Paste Signing Certificate

    This radio button indicates that DACTool must accept a digital certificate issued elsewhere for the new DA. No keys are generated and no certificate is issued out of DACTool for this option. If this radio button is selected, the Signing Certificate (PEM) field becomes enabled to accept the digital certificate text.

    Keystore

    If the Generate Keystore radio button is selected for a new DA's credential, this field must specify the location where the BCFKS keystore will be created by DACTool with the new DA's cryptographic key pair and digital certificate. Only the directory of the keystore must be provided. DACTool automatically creates a unique B filename for the new DA. The Browse button may be used to locate the directory where the new keystore must be created.

    Certificate Signing Request

    If the Paste CSR radio button is selected for a new DA's credential, this field must specify the Privacy Enhanced Mail (PEM)-encoded certificate signing request for the new DA.

    Signing Certificate (PEM)

    If the Signing Certificate (PEM) radio button is chosen for a new DA credential, this field must specify the PEM-encoded digital certificate for the new DA.

    Cancel

    Cancels the operation and returns to the Home panel.

    Reset

    Resets the form to default values.

    Save

    Disabled by default. If all appropriate fields are filled in on the form, the button becomes enabled. Selecting it writes the new credential to the internal database.

    Adding a new user is as simple as supplying the parameters to the fields in the form and selecting the Save button. DACTool determines if the two passwords typed in are identical and match the rules for passwords—use the Enter key on your keyboard to activate the logic—it doesn't work when you use the Tab key or the mouse pointer to move from field to field.

    The following screen shows a successfully added new user:

    When adding a new DA to SAKA, select the Yes radio button to the SAKA Domain Administrator? Option. When you do so, the grayed-out radio buttons on the right side of the form become active.

    Unless you are familiar with public key cryptography or have a Public Key Infrastructure (PKI) in your environment, select Generate Keystore. This option allows creation of a new 256-bit EC key pair and digital certificate (issued by SAKA), and save them in a Java Keystore file at a custom location.

    When the Generate Keystore radio button is selected, the Keystore text field and the Browse button become active. Either specify the full path and filename of the new keystore in the text field or, using the Browse button, select a location and then specify the keystore filename. Use a format that identifies the DID and the DA's username in the filename, such as 1-administrator2.bcfks or 3-johndoe.bcfks, where the numeral represents the DID, and the name represents the DA's username. The .bcfks file extension indicates that this is a BCFKS file containing the new credentials of the DA.

    It is also recommended that, for security reasons, DAs should NOT have any privileges to perform any cryptographic functions such as encrypt, decrypt, etc. They should only be permitted to perform administrative functions such as adding/removing users, changing passwords, configuring the appliance, etc.