An updated version of this article is available under this link.
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.
Figure 1: Selection of Hardware Security Modules
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?
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.
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.
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.
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:
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.
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.