Key Generation and Storage

The nShield CSP generates public/private key pairs (RSA, DSA, and Diffie-Hellman keys) in the module. The keys are stored in the Security World as protected by key blobs. (For details of the Security World, see the User Guide). Natively generated keys have mscapi as the appname and the hash of the key as the ident.

As in the Microsoft CSP, up to two keys are allowed for each container. Containers themselves are stored as opaque data in the Security World. Containers contain no key information but serve to associate NFKM keys with CSP containers, as well as storing other miscellaneous information. They have mscapi as the appname and container-`containerID as the `ident, where containerID is calculated from a combination of the CSP name, the user’s unique SID and the container name.

The default permissions on new containers created by the nShield CSP have changed in order to solve a problem with IIS version 6: in this version of IIS it was possible to create containers with an empty ACL, such that they were completely inaccessible.

The previous default container permissions came from the inherited permissions on the NFAST_KMLOCAL directory, and had no non-inherited permissions. The default Security World Software installation gives everyone full control of the NFAST_KMLOCAL directory.

The current software sets an explicit ACL on new containers created by the CSP but does not alter permissions on previously created containers. The new permissions are as follows:

  • READ access for EVERYONE.

  • FULL access for BUILTIN\Administrators.

  • For user containers: FULL access for the current user.

  • For machine containers: FULL access for LOCALSYSTEM.

No action is required on the user’s part to invoke the new behavior.

Symmetric keys in the nShield CSP are generated and stored entirely in software. These keys are not hardware protected and are no more secure than the corresponding keys in the Microsoft CSP.

The values of the KP_PERMISSIONS flags for hardware protected keys are enforced in software, except for CRYPT_EXPORTABLE which is ignored.

All CSP-generated, hardware-protected keys have ACLs that allow both signing and encryption. Hardware-protected keys that have been generated by the CSP are never exportable by the CSP; CryptExportKey always fails with a permissions error when called on such a key.

Container files and their associated key files can be moved freely between machines, as long as the user’s SID is also valid on the destination machine. This is the case if the user in question is a domain user and both machines are on that domain. If the user’s SID is not valid on the destination machine and keys are required to be shared between multiple machines, then the cspimport utility must be used to reassociate the Security World key file with the required destination container.