Enabling HSM Cryptography as an Integrated Service

An updated version of this article is available under this link.

Managing Hardware Cryptography in the Enterprise since the Millennium

There has been a substantial increase in the use of cryptographic techniques and Hardware Security Modules (HSM's) in larger commercial enterprises, and banks in particular, since the upsurge of online services in the late 1990's. Invariably this has been undertaken on a project basis, with each project having its own goals and initial budget.

The enhanced security provided by project based HSM implementations results in complex integration environments that can restrict the ability to securely share HSM resources across systems that use cryptography, thereby requiring security projects to 'duplicate' existing HSM infrastructure for each project's production deployment. For a large organisation, e.g. banks, the consequences of this model are unnecessarily large cryptographic infrastructures - which are becoming increasingly costly and ultimately unsustainable to manage.

CSG HSMs

Figure 1: Selection of Hardware Security Modules

The Project Dimension

Project timescales to implementation were for these new online services projects typically several months or up to two years, depending on project scale and complexity. Many of these early implementations are still in production today, some, and in a cryptographic sense may well have remained functionally unchanged during a decade's worth of production use.

The crucial point is that the initial project considerations cover only a small percentage of the overall business life cycle of an application using cryptography, often less than 10%. Yet, it's highly likely, that it's only during this "project period" that the use and deployment of cryptography receives attention. Often in 'Business-As-Usual' the easy option is to leave it alone because "If it's not broken don't touch it" and "Fred left two years ago and he was the only one who truly understood all the details".
Does any of this resonate?

Recent HSM Trends - the last ten years

The rapid deployment of mid-range server based business applications in the early part of the last decade used in-server "Crypto Cards". In the middle of the last decade an additional option was the advent of the "Networked HSM" becoming more widely available.

In many production online transactional systems where resilience is essential, the HSM technical utilisation can be 10% or less for a device which is on line 24/7. In batch processing systems utilisation can be intense but only for very short periods in a processing day with significant periods of idle time.

It is also not unusual for an HSM to cost twice its original purchase cost over an elapsed period of 5 to 6 years when support and maintenance costs are factored in. The costs of commercially available Crypto Cards through to high-end Networked HSM's typically range from £2,000 to as much as £40,000 per unit.

In the early part of the last decade the production lifespan of an HSM was implicitly accepted by default as being approaching ten years. At the end of the decade this production life had reduced to about half the former figure. Within this production life there is also the likelihood that an HSM will require a number of firmware upgrades every year or so, as the HSM manufacturers improve their firmware products including issuing security patches.

The newest HSM products invariably have several times the technical performance and throughput of their predecessors. It can be considered realistic to consolidate five existing HSM devices with one of its successors. Whilst this may facilitate HSM consolidation, actual HSM utilisation can still be very low and adding additional incremental HSM capacity or for that matter rationalising and upgrading HSM's is not that straightforward to achieve, when meeting enterprise change management and governance requirements.

In certain high performance payment systems, where HSM utilisation was high ( 60% +) it was not unusual, in the middle of the last decade, to have over a dozen HSM's deployed on a production system, and comparable numbers on the business continuity or DR configuration. Using the latest HSM products this can be reduced to no more than 4 or 5 units. Losing one HSM due to technical failure used to cost you circa 10% of total capacity now it can cost you 20 - 25%, bringing with it different operational challenges.

Now it also needs to be recognised that it is a reality that HSM's will require production replacement during the normal life of a business system(s). This is not commonly acknowledged or accepted yet, and whilst it's a good thing that you will need fewer new HSM's compared to their predecessors, nothing significant has been done to improve the operational management of the HSM's. In organisations that have multiple secure systems utilising HSM's, the limitations for securely sharing HSM's across applications results in a much higher volume of HSM's being deployed than are actually ever needed for peak performance - Each project / application requiring a minimum of 2 devices for resilient production, 2 for test/DR if appropriate, and at least 1 for development, making a requirement for at least 5, all used at low levels.

HSM config

Figure 2: Traditional / Conservative Approach for Deploying HSM's

Within many large organisations, maintaining balanced overall technical systems configurations, inclusive of all HSM considerations, is more challenging and complex than was ever envisaged - at that original project inception workshop.

Changing the HSM Management Model

With much of the direct costs of cryptography management stemming from the procurement and maintenance of HSM's, organisations are increasingly looking for innovative ways to meet these challenges by:

sharing the common cryptographic resources in a secure manner to enable new business applications to utilise existing managed HSM's
reducing the number of HSM's in use to a level that your business is comfortable with, yet provide improved technical resilience for existing business applications
allowing the re-use or redeployment of existing HSMs that can be regarded as a surplus
to performance requirements and avoiding
HSM vendor 'lock-in'
providing HSM specific regression testing (of new firmware etc.) that doesn't have to be repeated for every project implementation of cryptography
provision for the selection of both hardware and software encryption, as the business and technical circumstances dictate.

Figure 2 illustrates how integrating cryptography as a centralised service model can readily enable all of the above points, thereby providing significant savings for organisations with large cryptographic infrastructures. Please see Crypto Service Gateway for more information on how to proactively manage cryptography across business units.

CSG HSM config

Figure 3: Cryptomathic's Approach for Sharing Cryptographic Resources

Reducing the direct costs attributed to HSM's should not be looked at in isolation as it's their actual interaction within your enterprise that is the crucial factor. In the next section, the emphasis switches from what may be viewed as the passive aspects of deploying cryptography within an organisation to the more dynamic aspects in new and changing business circumstances.

Continue with: