Security World options
Decide what kind of Security World you need before you create it. Depending on the kind of Security World you need, you can choose different options at the time of creation. For convenience, Security World options can be divided into the following groups:
-
Basic options, which must be configured for all Security Worlds
-
Optionally enable Audit Logging for the Security World
-
-
Recovery and replacement options, which must be configured if the Security World, keys, or passphrases are to be recoverable or replaceable
-
SEE options, which only need be configured if you are using CodeSafe
-
Options relating to the replacement of an existing Security World with a new Security World.
Security World options are highly configurable at the time of creation but, so that they will remain secure, not afterwards. For this reason, we recommend that you familiarize yourself with Security World options, especially those required by your particular situation, before you begin to create a Security World.
Security World basic options
When you create a Security World, you must always configure the basic options described in this section.
Cipher suite
The following cipher suites are available:
| Cipher suite | Release version | Supported smart card types | Internal mechanisms |
|---|---|---|---|
|
v13.7 or higher |
Type 3 |
ECDSA signatures and ECC for key recovery |
|
v12.50 or higher |
Type 1, 2 and 3 |
DSA signatures and RSA for key recovery |
KML type selection
KML is the module signing key. The type of key used can be selected when a Security World is created and/or loaded using the --kml-type option with the new-world utility, otherwise the default KML type for the cipher suite is used. The KML types supported are listed in the following table:
| KML types | Description |
|---|---|
|
ECDSA KML on NIST P-521 |
|
ECDSA KML on NIST P-256 |
|
DSA KML with a 3072-bit modulus in a 256-bit order subgroup |
|
DSA KML with a 1024-bit modulus in a 160-bit order subgroup |
Note that the KML type selected when loading a Security World can be different from the KML type used when the Security World was created.
The KML type used when the Security World was created and the active KML type are both reported in the nfkminfo output, respectively in the World and Module information (see nfkminfo utility).
Acceptability rules
The following table lists the KML types acceptable for each cipher suites:
| Cipher suite | Default KML type | Acceptable KML types |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The KML type selection has an impact on performances and security, for more information see KML type and security strength. |
1 Legacy cipher suite.
2 In FIPS 140 Level 3 mode, ECDSA KML types are not supported with DSA Security Worlds.
3 It is not recommended to use the module file with legacy Security World software - i.e. prior to v13.7 - when a DSA Security World has been loaded with an ECDSA KML.
ACS quorum
You must decide the total number of cards (N) in a Security World’s ACS and must have that many blank cards available before you start to create the Security World. You must also decide how many cards from the ACS must be present (K) when performing administrative functions on the Security World.
| We recommend that you do not create ACSs for which K is equal to N, because you cannot replace such an ACS if even 1 card is lost or damaged. |
| In Common Criteria CMTS Security Worlds the minimum value of K for the ACS is 2. |
In many cases, it is desirable to make K greater than half the value of N (for example, if N is 7, to make K 4 or more). Such a policy makes it harder for a potential attacker to obtain enough cards to access the Security World. Choose values of K and N that are appropriate to your situation.
The total number of cards used in the ACS must be a value in the range 1 – 64.
FIPS 140 Level 3 compliance
By default, Security Worlds are created to comply with the roles and services, key management, and self-test sections of the FIPS 140 standard at Level 2. However, you can choose to enable compliance with the FIPS 140 standard at Level 3.
| This option provides compliance with the roles and services of the FIPS 140 Level 3 standard. It is included for those customers who have a regulatory requirement for compliance. |
If you enable compliance with FIPS 140 Level 3 roles and services, authorization is required for the following actions:
-
Generating a new OCS
-
Generating or importing a key, including session keys
-
Erasing or formatting smart cards (although you can obtain authorization from a card you are about to erase).
In addition, you cannot import or export private or symmetric keys in plain text.
FIPS 140 Level 3 approved configurations
In order to comply with FIPS 140 Level 3, the HSM must be initialized with a Security World in FIPS 140 Level 3 mode, and with the appropriate cipher suite as detailed in the following table:
| Product | Firmware version | FIPS standard | Security World cipher suite | Revisions |
|---|---|---|---|---|
nShield 5s |
v13.7.X (upcoming) |
FIPS 140-3 |
|
FIPS 186-5 revision |
v13.2, v13.4 |
|
NIST SP 800-131Ar1 transition |
||
nShield Solo XC |
v12.72.1 |
FIPS 140-2 |
||
nShield Edge |
v12.72.0 |
Common-Criteria-CMTS Support (nShield Solo XC only)
You can choose to enable support for EN 419 221-5 Protection profiles for TSP Cryptographic modules - Part 5 - Cryptographic Module for Trust Services using the common-criteria-cmts mode, see https://www.commoncriteriaportal.org/files/ppfiles/ANSSI-CC-PP-2016_05%20PP.pdf
If you enable support for the EN 419 221-5 Protection Profile the following constraints and facilities are enabled:
-
Constraints:
-
The minimum quorum for the ACS cardset is 2
-
You cannot import or export private or symmetric keys in plain text
-
Remote Operator feature is disabled.
-
-
Facilities:
-
generatekeyandmkaclxutilities support generating EN 419 221-5 Assigned Keys -
nfkmverifysupports the verification of EN 419 221-5 Assigned Keys.
-
In order to meet the requirements of this Protection Profile the HSM must be operated in accordance with the nShield Solo XC Common Criteria Evaluated Configuration Guide.
UseStrongPrimes Security World setting
From firmware version 12.70, the nShield HSM always targets FIPS 186-4 compliance when generating RSA keys of 1024 bits or more.
It typically does this using a "strong primes" strategy, however Entrust only guarantees this strategy if the UseStrongPrimes setting is enabled.
If your firmware is version 12.70 or higher, you do not need this setting enabled for FIPS 186-4 compliance.
If you are using an older version of firmware, meaning it has a version number lower than 12.70, then you need the UseStrongPrimes setting enabled to grant FIPS 186-2 compliance.
If your Security World is FIPS 140 Level 3, then this setting is on by default.
If your Security World is not FIPS 140 Level 3, then you can disable the UseStrongPrimes setting for faster RSA key generation, however this removes FIPS 186-2 compliance.
Remote Operator
To use a module without needing physical access to present Operator Cards, you must enable the Remote Operator feature on the module. For more information, see Optional features.
By default, modules are initialized into Security Worlds with remote card set reading enabled. If you add a module for which remote card reading is disabled to a Security World for which remote card reading is enabled, the module remains disabled.
OCS and softcard replacement
By default, Security Worlds are created with the ability to replace one OCS or softcard with another. This feature enables you to transfer keys from the protection of the old OCS of softcard to a new OCS or softcard.
| You can replace an OCS with another OCS, or a softcard with another softcard, but you cannot replace an OCS with a softcard or a softcard with an OCS. Likewise, you can transfer keys from an OCS to another OCS, or from a softcard to another softcard, but you cannot transfer keys from an OCS to a softcard or from a softcard to an OCS. |
You can choose to disable OCS and softcard replacement for a Security World when you create it. However, in a Security World without this feature, you can never replace lost or damaged OCSs; therefore, you could never recover the keys protected by lost or damaged OCSs, even if the keys themselves were generated as recoverable (which is the default for key generation).
| OCS and softcard replacement cannot be enabled after Security World creation without reinitializing the Security World and discarding all the existing keys within it. |
For an overview of Security World robustness and OCS or softcard replacement, see Robustness. For details about performing OCS and softcard replacement operations, see Replace OCS and softcards and Replace the ACS.
passphrase replacement
By default, Security Worlds are created so that you cannot replace the passphrase of a card or softcard without knowing the existing passphrase.
However, you can choose to enable passphrase replacement at the time you create a Security World. This option makes it possible to replace the passphrase of a card or softcard even if you do not know the existing passphrase. Performing such an operation requires authorization from the Security World’s ACS.
For details about performing passphrase replacement operations, see Changing unknown or lost passphrase.
Nonvolatile memory (NVRAM) options
Enabling nonvolatile memory (NVRAM) options allows keys to be stored in the module’s NVRAM instead of in the Key Management Data directory of the host computer. Files stored in the module’s non-volatile memory have Access Control Lists (ACLs) that control who can access the file and what changes can be made to the file. NVRAM options are relevant only if your module’s firmware supports them, and you can store keys in your module’s NVRAM only if there is sufficient space.
| When the amount of information to be stored in the NVRAM exceeds the available capacity, you can instead store this data in a blob encrypted with a much smaller key that is itself then stored in the NVRAM. This functionality allows the amount of secure storage to be limited only by the capacity of the host computer. |
Security World SEE options
You must configure SEE options if you are using the nShield Secure Execution Engine (SEE).
If you do not have SEE installed, the SEE options are irrelevant.
SEE debugging
SEE debugging is disabled by default, but you can choose whether to enable it for all users or whether to make it available only through use of an ACS. In many circumstances, it is useful to enable SEE debugging for all users in a development Security World but to disable SEE debugging in a production Security World. Choose the SEE debugging options that best suit your situation.
Real-time clock (RTC) options
Real-time clock (RTC) options are relevant only if you have purchased and installed the CodeSafe Developer kit. If so, by default, Security Worlds are created with access to RTC operations enabled. However, you can choose to control access to RTC operations by means of an ACS.
Security World replacement options
Options relating to Security World replacement are relevant only if you are replacing a Security World.
If you replace an existing Security World, its /opt/nfast/kmdata/local (Linux) or %NFAST_KMDATA%\local (Windows) directories are not overwritten but renamed to /opt/nfast/kmdata/local_N (Linux) or %NFAST_KMDATA%\local_N (Windows), (where N is an integer assigned depending on how many Security Worlds have been previously saved during overwrites).
A new Key Management Data directory is created for the new Security World.
If you do not wish to retain the /opt/nfast/kmdata/local_N (Linux) or %NFAST_KMDATA%\local_N (Windows) directory from the old Security World, you must delete it manually.