Thales nShield Connect offers enterprise-class key management
One reason installation took that long was that the nShield had FIPS security enabled by default. This is a government standard for security that involves physical tokens (smart cards) that need to be inserted into the appliance's reader before most actions are taken. During initial configuration we set up nine smart cards, of which one needed to be inserted to continue with protected actions.
The number of cards and the number needed for a given action is flexible. This is to ensure that major actions, such as registering a new certificate with a provider (potentially a very expensive operation), has a consensus before the action is taken. One European institution requires that 55 out of 57 cards be inserted to request a new certificate, which given the 1 million Euro price tag, may be justified. On the other hand, many organizations may find this level of protection overkill, and turn off the FIPS security, with access allowed through normal passwords instead.
Setting up the nShield to work with a new application involves getting that application to work with one of the supported key management standards, PKCS#11, Microsoft CryptoAPI/CNG, Jave JCE or OpenSSL, or with one of the other supported security protocols. This can often be somewhat complex, as these are not necessarily the native methods for encryption. Even when they are, as with the Microsoft CryptoAPI, there can be numerous steps involved.
Thales has 22 published guides to integration with particular products, which even the technician sent to install the product used, because each involved lots of steps. Eight to 12 pages of guidance is typical. The tech was able to go through the steps relatively quickly once the basic configurations and permissions were set, and after he left, I completed a couple of other configurations using the guides, with no special problems.
Once applications are connected to the nShield, certificates and keys can be easily managed using policies, making it easy to issue new certificates and revoke or renew certificates. Policies can set how long a key is used before being renewed or revoked. Since all the keys are provided to the applications on demand over a secure, encrypted link, with the keys themselves stored securely in a hardened appliance, keys are not only centrally managed and protected from breaches, but visible to the administrator.
Reporting tools make it easy to find keys that are above or below a set number of bits, if an administrator is interested in upgrading the organization to a new recommendation for minimum bits in keys, for instance. Auditing tools also make it simple to trace which administrator has performed which function.
Since all the security eggs are in one basket, so to speak, it would be critical in large organizations to have redundant HSMs to ensure availability and resiliency against hardware failure. The process of setting up a failover unit is simple and easy to do, using an active passive system. Data is backed up using highly encrypted backups, and this data can be restored to the hot spare unit in case of disaster.
To ensure scalability of the system, Provisioning Servers can be created at different geographic sites to issue certificates or keys on demand. If this is done, the entire system is still easily managed from one console, and the management interface allows for administrative levels with very granular permissions, so that one type of admin might only have access to the information for one site, while another has oversight into the entire organization.
The Thales nShield provides a very high level of security, and works with a fairly broad range of operating systems and applications, albeit not as many as the Venafi system. If a high level of security is important, in addition to management of keys and certificates, the nShield is a good choice.
Pricing: Thales nShield Connect 6000 starts at $39,000. Pricing includes the first year of maintenance and support. Other HSMs start at $23,500.
Return to test