Release Notes

Sectorization allows LMS keys to be partitioned across a number of Remote Administrator ready smart cards. These cards can be used to provision one or more nShield hardware security modules with a block of one-time signature keys. When these signing keys are exhausted no more signatures may be created until additional provisioning is done.

Sectorization can be done from the command line using the example program pipsqueak (previously named pqsdk-test). To use pipsqueak, ensure that pqsdk.dll or libpqsdk.so are available, either in %path% or in the LD_LIBRARY_PATH environment variable.

Here is an example of how pipsqueak can be used to create an LMS key pair:

In this example the LMS key will have a Merkle tree height of 10 and therefore can create 1024 (2^10) signatures over its lifetime. LMS keys with a height of up to 25 are supported, but these will take many hours to generate.

Note that expcards is one and explease is two. The pipsqueak program will prompt the user to insert two smart cards if necessary. Remote Administrator allows configuration of dynamic slots. If there are enough blank cards in the physical and dynamic slots to write all necessary cards pipsqueak will do so without prompting.

When this command is complete there will be no nShield HSMs that can sign with this LMS key. All blocks of one-time signature keys are stored on smart cards. In this example, we provision an nShield HSM:

If there are more than one LMS card inserted into a slot of some nShield HSM this command will prompt the user to select one. To avoid prompting, specify the electronic serial number and slot using the "provesn" and "slot" options:

Once this is done there should be signatures available. To see how many signatures are available, use the showinfo option:

Notice that a single provision made 128 signatures available. That comes from the height (10) the card exponent (1) and lease exponent (2): subtracting the card and lease exponents from the height gives seven and 2^7 is 128.

A single nShield HSM can be provisioned up to twice. It is not necessary for the leases to be contiguous. In other words, a card with four provisions can be used on HSM A, then on HSM B and then on HSM A again. This is intended to help avoid running out of signatures. When one lease is running low the user can provision a second one without waiting for it to be exhausted. However, attempting to add a third lease will fail until the first lease has been used up.

In previous PQSDK releases, an LMS key pair was generated using a single call to the SEE machine. This is still possible if no sectorization is requested, but in this release key generation can be separated into many steps. This avoids problems with time outs for LMS keys with larger heights, such as 20 or 25. In addition, this allows client programs to display progress to users.

The new generateLMS command returns the number of chunks and cards remaining. It is necessary to call the continueLMS command until both of these are zero, at which point the LMS key will be saved to the Security World key management data directory. The number of chunks is determined by the chunk exponent argument to generateLMS. If that exponent is n, there will be 2^n + 1 chunks necessary.

In previous releases, the Merkle tree had to be completely reconstructed each time an LMS key was loaded after the SEE machine had been restarted. This was a problem for larger tree heights. To address this, PQSDK now caches the top portion of the tree in the Security World key management data directory. This means only a portion of the Merkle tree needs to be generated again when an existing key is loaded.

In previous releases, a command named see_getVersion was used to fetch the version number of a single SEE machine. This command is now internal and should not be used. Instead, use getSEEVersions which will respond with an array with version numbers for each SEE machine available.

The following are measurements of LMS signature sizes and key generation times. These are intended to assist in planning. Key generation times vary depending on many factors, including the chunk size used. They have been measured in laboratory conditions with no external load and in some cases (when marked with a ~ character) are estimated by extrapolation the timing of partial chunks of a key that was not completely generated.

This release is targeted at deployments with any combination of the following nShield HSMs:

This release has been tested for compatibility with the following operating systems:

The following tables show the supported configuration of firmware and software installations.

The Unrestricted SEE (SEE Activation (EU+10)) feature must be enabled on your HSM. Restricted SEE (SEE Activation (Restricted)) is not currently supported.