Access Control

When creating a new Security World, for example using the new-world utility, one of the parameters that can be explicitly specified is the NSO-timeout. The NSO-timeout is the maximum time that can elapse between ACS quorum authorization, and reauthorization being required. This is only normally relevant when the last administrator card of the quorum is left in the card reader of a Module, as normal security practice is to remove the last administrator card as soon as the current administrative task has been completed.

The setting of this value will depend on the administrative tasks that the ACS quorum will authorize to be performed in the Security World, and the results of the threat analysis for the nShield administrators/ACS quorum.

The following is general guidance for NSO-timeout setting. Refer to your own security policy to determine what value is acceptable:

Each card set consists of a number of smart cards, N, of which a smaller number, K, is required to authorize an action. The required number K is known as the quorum. Each card in an ACS stores only a share of the ACS keys. You can only re-create these keys if you have access to enough of their shares. Because cards sometimes fail or are lost, the number of shares required to re-create the key (K) should be less than the total number of shares (N).

To make a robustly secure ACS, it is recommended that the value of K is relatively large and the value of N is less than twice that of K (for example, the values for K/N being 3/5 or 5/9). The customer security procedures should determine the values of K and N which should be based on a threat analysis of the protected data.

The customer security procedures should identify the role holders for the different cards. Roles should be assigned based on area of responsibility but also awareness of role holder’s availability as they may be required to recover a Security World at short notice in the case of a failure.

The customer’s security policy should determine whether the passphrases are required for the cards. passphrases provide an additional barrier to the attacker. This requirement may be necessary based on the value of the data protected and the security around the storage location of cards. A timing delay feature is applied to password retries to add further protection.

If an ACS quorum (K of N) is lost, the associated Security World becomes unmanageable as a quorum is needed to replace the old ACS card set. There is no possibility of recovering it.

If a card from an ACS is lost, you should replace the entire ACS as soon as possible.

Each card set consists of a number of smart cards, N, of which a smaller number, K, is required to authorize an action. The required number K is known as the quorum. Each card in an OCS stores only a fragment of the OCS keys. You can only re-create these keys if you have access to enough of their fragments. Because cards sometimes fail or are lost, the number of fragments required to re-create the key (K) should be less than the total number of fragments (N).

To make a robustly secure OCS, it is recommended that the value of K is relatively large and the value of N is less than twice that of K (for example, the values for K/N being 3/5 or 5/9). The customer security procedures should determine the values of K and N which should be based on a threat analysis of the protected data.

The customer security procedures should identify the role holders for the different cards. Roles should be assigned based on area of responsibility.

The customer’s security policy should determine whether the passphrases are required for the cards. passphrases provide an additional barrier to the attacker. This requirement may be necessary based on the value of the data protected and the security around the storage location of cards. A timing delay feature is applied to password retries to add further protection.

The customer’s security policy should determine whether persistent or non-persistent (default) mode is required and whether a time-out is required. See Persistence and non-persistence for OCS for guidance on this option. Once set at creation the mode cannot be changed.

The customer’s security procedures should determine whether OCS can be recovered if lost to a new OCS. This is enabled by default during Security World recreation.

The customer’s security procedures should determine whether OCS passphrases can be replaced if lost. This is disabled by default during Security World recreation.

Lost or damaged cards should be replaced as you discover the loss or damage to prevent a potential scenario where a quorum of cards are not available to authorize operations.

For further guidance on using an OCS to share keys across HSMs and share keys between users, see Creating and maintaining a quorum.

If you create a standard (non-persistent) OCS, the keys it protects can only be used while the last required card of the quorum remains loaded in the smart card reader of the nShield HSM. The keys protected by this card are removed from the memory of the HSM as soon as the card is removed from the smart card reader. This mode is more secure as the user directly controls key usage. If you want to be able to use the keys after you have removed the last card, you must make that OCS persistent. Keys protected by a persistent card set can be used for as long as the application that loaded the OCS remains connected to the HSM (unless that application removes the keys explicitly or any usage or time limit is reached). Persistent mode should only be used once a threat analysis of the environment has determined that it is safe for application keys to continue to be operationally usable once the last OCS card has been removed.

OCSs (both persistent and non-persistent) can also be created with a time-out, so that they can only be used for limited time after the OCS is loaded. Keys will be forcibly unloaded when the timeout expires. An OCS is loaded by most applications at start up or when the user supplies the final required passphrase. After an OCS has timed out, it is not loadable by another application unless it is removed and reinserted. Time-outs operate independently of OCS persistence.

You can manually remove all keys protected by persistent cards by clearing the HSM. For example, you could:

A persistent OCS with no timeout is suitable for a web server. However, using this option is dependent on the level of security of any running application. For example anyone that is able to gain unauthorized application access can use the key.

A non-persistent OCS with no or a short time-out would be suitable for a root Certificate Authority. It provides complete control over key availability – the key is unloaded when the card is removed from the card reader and becomes inactive after an assigned timeout, if it has been mistakenly left in the card reader.

A threat analysis should determine which configuration of persistence/non-persistence/time-out/no time-out is appropriate for the various sets of keys protected by OCSs.

Although keys belong to specific client applications performing different functions (with possibly different sensitivities), OCSs do not. You can protect keys for different applications using the same OCS. However, you must not use the same OCS to protect keys for many different applications as a compromise of the OCS could lead to a compromise of all application keys protected by it. Assigning different OCSs to different applications mitigates this threat. Additionally assigning more than one OCS to an application key helps maintain operation in the event of a compromise against an OCS.

Maintaining the integrity of your system against deliberate or accidental acts can be enhanced by appropriate use of (Operating System (OS)) user privileges. There are two levels of user in Windows:

Administrator access (an Administrator on Windows) is required for such tasks as:

Typically, normal users can only carry out read-only operations involving Security Worlds, card sets and keys. For example, encrypted copies of keys are held in Key Management Data (C:\ProgramData\nCipher\Key Management Data). The default permissions allow all users to read these files, enabling them to use keys but not create them. File permissions can be altered to restrict access to specific keys to specific users/groups.

Maintaining the integrity of your system against deliberate or accidental acts can be enhanced by appropriate use of (OS) user privileges. There are three levels of user:

Typically, normal users can carry out operations involving Security Worlds, cardsets and keys, but not create Security Worlds, keys and cardsets. nfast group users have enhanced access, enabling them to create Security Worlds, cardsets and keys. For example, encrypted copies of keys are held in kmdata (/opt/nfast/kmdata). Normal users only have read access to the files, whereas nfast group users have read and write access, enabling them to create and use keys. nfast group users can also change the mode of an HSM remotely.

Superuser access (e.g., root) is required for such tasks as software installation, starting and stopping the hardserver and SNMP.