ADSS CA Server & Mass Key Generation | Ascertia | Blog

In this blog, we discuss how Ascertia's ADSS CA Server protects mass key generation using Hardware Security Modules (HSMs). HSMs are a vital part of any digital security solution. Understanding how this impacts your high-trust business is vital.

What are Hardware Security Modules?

HSMs offer fast, secure processing of private keys. They ensure that cannot be created, copied, changed or deleted without appropriate permission or stolen without being noticed. They also off-load the processing cost of digital signatures for high performance systems such as time stamping servers or certificate validation servers.

What are HSMs used for?

Traditionally, HSMs have been used for central server keys and certificates. High-trust user certificates are typically deployed on Smartcards or USB crypto-tokens.

When issuing high trust certificates to large populations of end-users, the costs spiral rapidly. For example, one million smart cards would cost € 20 million. However, the cost of deploying one million keys and certificates centrally in two or more load balanced HSMs would be a very small fraction of this.

HSM challenges

Some HSMs struggle with internal limits to store more than a few hundred or a few thousand keys.

The answer to this problem is to export the private keys encrypted under a key encrypting key (KEK) that is securely held within the HSM and copied to other HSMs in the same KEK group.

These keys must be held in a high availability database. In high trust solutions the KEK ensures that the only point at which a key can be unwrapped and used is within a Common Criteria EAL4+ or FIPS 140-2 Level 3 HSM that already knows the KEK. The KEK is never exposed outside of the HSM and is transported to other HSMs via the HSM Master Key.

Older versions of ADSS Server only support storing end-user keys inside the HSM or its security environment. ADSS Server v4.8 offers a new feature that requests an HSM to generate a private signing key and wrap this using a strong KEK and export this back to ADSS Server. This is supported by some of the common HSMs, but not supported by all. Careful checking is required and ADSS Server includes a simple HSM test utility for this purpose.

The advantage of ADSS Server-wrapped key management

• ADSS Key Manager manages all the HSMs that are part of the same KEK group. The management of the Master Key and the KEKs is under the separate control of the HSM software. ADSS Server is able to fall back to use another alternate HSM in the same group if the primary HSM fails and thus ensure high availability even when the HSM drivers don’t natively support this.
  
  
• The ADSS Server Certification Service is able to receive an application or RA based request for a user key to be generated. The private key is generated and wrapped under the KEK Key. Certificates can be generated by first creating a certificate signing request (CSR/PKCS#10) which is signed by the relevant private key which has been decrypted using the KEK.
  
  
• All wrapped user keys are kept in the ADSS Server database which can uses highly available configurations of Oracle 11gR2 and 12c, plus SQL Server Enterprise Edition and PostgreSQL and My SQL are also supported as usual.
  
  
• After certificate creation, ADSS Server deletes the end-user private key from HSM. ADSS Server is in charge of user key management within its trustworthy system framework using role based access controls, dual controls where appropriate and detailed secure logging of all activity. All HSMs that have a group KEK need to be registered so that failover processing works seamlessly.
  
  
• When signing data with an end-user key the relevant protected end-user private key is retrieved from the ADSS Server database, passed to the HSM and decrypted using the KEK. The “data to be signed” is then passed to the HSM and signed with the unwrapped end-user private key. The signed data is passed back as usual.
  
  
• The end-user key is deleted from the HSM automatically after a configurable time.

Any number of KEKs can be created and linked with the HSMs. KEKs are also linked to the ADSS Server certification profiles hence different KEKs can be used for different types of certificates, or groups of users or organisations.

The life cycle of the KEK is managed using HSM vendor provided utilities and this can also be under dual control if supported by the HSM utilities.

Protecting mass key generation with Ascertia's ADSS CA Server

In summary, ADSS Server answers the requirement of managing thousands and indeed millions of end-user keys in a sophisticated and secure way unmatched by other approaches.

Within ADSS Server users’ private keys are always known to exist (or known to have been deleted). They are always held within a professional relational database structure. They are available immediately after generation and certification for signing operations, should an HSM fail then another within the same KEK group can be immediately used without operator intervention and crucially the cost of the HSMs required is low. PCIe or network HSMs can be used as required within physical or virtual systems.

Above all, ADSS Server offer the choice of when to use this approach to opt to keep all keys, or just certain keys in the HSM. The feature is license controlled and so can be enabled or disabled.

This is a specialist area so contact us to discuss your requirements for key wrapping with our expert staff.