Hardware Security Modules (HSMs) are a fundamental part of a high trust solution. They offer fast, secure processing of private keys, which ensures that keys 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.
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 such smart cards would mean a cost of the order of € 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.
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 Advantages 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.
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 firstname.lastname@example.org to discuss your requirements for key wrapping with our expert staff.
You are not allowed to post comments.