For cryptographic services to be available on SAKA, the cryptographic hardware module on the appliance must be activated. The cryptographic module—either the Trusted Platform Module (on the Model-T) or the Hardware Security Module (on the Model-H)—holds the “root” key of the key hierarchy that protects all cryptographic keys on the appliance. However, the hardware module can only be activated by Key Custodians (KCs) with their Personal Identification Numbers (PINs)—which they established during the installation of the appliances. Only when the hardware module is activated, does the “root” key become available, which in turn, enables cryptographic services to become available to business applications.

NOTE: SAKA security is entirely predicated on the “root” key. However, on the Model-T, the Storage Root Key (SRK) cannot leave the hardware module—this is part of the design specification for the TPM, as specified by the Trusted Computing Group (TCG). Once created upon initialization, the SRK can only be activated for use or destroyed during re-initialization. On the Model-H, the “root” key is generated inside the HSM, and can leave the HSM only under the protection of another encryption key in a controlled process.

In the event of a restart of the SAKA, since it is unfeasible for KCs to be available in remote server-rooms where the SAKA is typically deployed, SAKA includes a client application—the Key Custodian SetPIN Tool (KCSPTool)—that allows KCs to activate the hardware module from remote locations. All that is required is for the KCs to have a connection to SAKA from their computers and the USB flash drive that contains their credential (which was created when SAKA was initially set up).

While it is recommended that KC connections be controlled through an access-control list of a router or switch to prevent denial-of-service (DoS) attacks, the connection need not be secured for confidentiality since SAKA accepts KC commands and responses only over a secure transport protocol—Transport Layer Security.

The installation process of SAKA instances would have resulted in the KCs being given the KCSPTool on some media they would use to install on their computers. Since the KCSPTool is a Java application, it can run on any platform where a Java Virtual Machine (JVM) is available. It is necessary for the KCs to have a supported version of the JVM on their computer to use the tool. See 3—Architecture for the supported version of the JVM for your appliance.

On a Windows PC, the KCs would use a Command Tool script (a batch file) to start the KCSPTool. On a Linux computer, this would be shell script. The script file can be associated with an icon on the KC's desktop to make it convenient for the KC to use the tool.

NOTE: It is strongly recommended that KCs never copy their credential file from the USB flash drive to their computer for convenience. While it might be tempting, leaving the file on the computer could leave the file vulnerable as it might be copied off by an attacker, who might then try to determine the KC's PIN by subjecting the file to a dictionary attack or a rainbow table attack. Sites may not only want to enforce this through a company policy, but also through automated tools that delete such credential files when found on the hard disk of a KC's computer. Ultimately, the site must rely on the responsibility of the KC to preserve the security of their credential—policies and automated tools can only go so far.

When the KCSPTool starts it displays the following screen: