The superuser of the operating system normally has unlimited control over everything on the computer system, but without the required PINs for authentication to the hardware module, even the root user is incapable of accessing keys on the module.

Because of the privileged status of the root user, he/she can assume the identity of any user on the Linux operating system. As a result, additional controls must be placed around this credential if the site security policy wishes to restrict individuals (with access to root) from accessing cryptographic keys on the hardware module. While the controls described in the Protecting PINs from root section of this document provides one method of restricting this access, sites must ultimately use methods that are in compliance to their internal security policies.

Indirectly

This operating system user ID owns the web service application software that makes up SAKA. Since the web service application uses this user ID within the Linux operating system, this account has access to the PINs for the hardware module (so it can authenticate to the module before performing cryptographic operations on data).

Care must be taken to secure this account and only provide its credential to trusted administrators.

Yes

This superuser account of the SAKA RDBMS has full control over everything inside all databases on the system. However, since data stored in the SAKA database only consists of ciphertext (data encrypted by the SAKA web application before it reaches the database) without any sensitive material that could decrypt them, this user cannot decrypt ciphertext despite their full control over database data.

No

The owner of database schemas and data in the SAKA internal database has unlimited control over everything inside this database schema and objects. However, as already indicated, since data stored in this internal database only consists of ciphertext without any sensitive material that could lead to its decryption, this user cannot decrypt ciphertext.

No

This administration account of the JEE Application Server has full control over the application server's configuration. However, since this is not an operating system account, this administrator cannot read or modify anything other than the application server configuration files. This credential only exists to facilitate the administration of the application server through a web interface.

No

This role in the hardware module provides the first of three authentication PINs required to access cryptographic keys inside a hardware module. Since the Key Custodian #1 only has part of the PIN to access the module, this individual cannot access any of the keys on the hardware module by themselves.

In HSM-based SAKA, this role also has one of the multi-card smart card backups of the HSM slot and its keys. The smart card and the PIN to the smart card do not provide this individual with access to any cryptographic keys—the key backup is split across three smart cards.

No

This role in the hardware module provides the second of three authentication PINs required to access cryptographic keys inside a hardware module. Since Key Custodian #2 only has part of the PIN to access the module, this individual cannot access any of the keys on the hardware module by themselves.

In HSM-based SAKA, this role also has one of the multi-card smart card backups of the HSM slot and its keys. The smart card and the PIN to the smart card do not provide this individual with access to any cryptographic keys—the key backup is split across three smart cards.

No

This role in the hardware module provides the third of three authentication PINs required to access cryptographic keys inside a hardware module. Since Key Custodian #3 only has part of the PIN to access the module, this individual cannot access any of the keys on the hardware module by themselves.

In HSM-based SAKA, this role also has one of the multi-card smart card backups of the HSM slot and its keys. The smart card and the PIN to the smart card do not provide this individual with access to any cryptographic keys—the key backup is split across three smart cards.

No

HSM role used to manage the HSM firmware and to facilitate backups of the HSM Root Key (HRK) and HSM database. This role cannot access cryptographic keys in the HSM—intrinsic to the HSM security design.

No

This credential is used by SAKA to authenticate a requester of web services. Depending on the SAKA configuration, this can be against the SAKA managed users or against an LDAP-based Directory Server. This credential is verified by the SAKA web service application before it performs the cryptographic operation. Since the credential has no operating system, RDBMS, Application Server, or hardware module privileges, this user cannot access cryptographic keys in the module.

If this credential has decryption privilege, it will have the ability to request decryption services from SAKA. As a consequence, the password to this credential must be protected by the applications that will include them in their web service request to SAKA; SAKA does not maintain this credential's password.

Indirectly