I am old enough to remember the huge cost of remediation of systems that was required to address the Y2K bug – not really a bug as much as lack or foresight exacerbated by the distribution of date processing logic throughout the business logic making a single point of rectification impossible.
An analogy to this that I see in our business activities is the implementation of cryptographic services across business applications, often bundled with COTS products, often implemented by well meaning but lay users of cryptography, and consequently more often than not sprinkled across the enterprises’ technology stacks.
What can go wrong here?— Ross Oakley
So, what can go wrong here?
Well just about everything. Cryptography, unlike date processing is a dynamic science and what protects us today will likely be vulnerable to attack in timeframes shorter than a typical application’s renewal cycle.
Cryptographic algorithms will be either broken or key lengths will become inadequate to fend off brute force attacks from resourced adversaries.
What were once considered suitable cryptographic key storage methods such as software vaults will be compromised and the integrity of relying applications and associated data or transactions will be lost.
With increasing volatility and pace of change in best practice around crypto, and a need to assess their organisation’s needs relating to cloud migration and security where “lift and shift” approaches don’t always translate well, we are seeing increasing attention to remodelled crypto services deployment as organisations seek to get their arms around this problem.
Implementing a crypto services layer with associated centralised monitoring and management is one such approach, hardened by the introduction of HSMs for key protection and completion of basic cryptographic functions within a certified hardware environment.
For some multi step functions however risks remain of exposure of clear text data or keys between steps – these functions might be for translation of encrypted data across two security domains, or something as simple as a secure password processing system that requires verification of a current password and setting of a new password within a secure environment whilst also enforcing password policies.
Or more simply, enforcement of an application’s rights to access a particular cryptographic key or function, where the access request and function are processed together within a certified environment.
Whilst these services could be implemented within a software services layer with intermediate calls to an HSM for various crypto services, we are seeing advanced organisations implementing these atomic multi step functions through embedded code running within an HSM which provides the full protection of a specialised and certified cryptographic processor guaranteeing no exposure of sensitive material outside the HSM.
In the Entrust nShield product line, the platform that supports this capability is termed CodeSafe, where CodeSafe applications are further protected through their operation exclusively within the FIPS 140-2 L3 certified boundary of the HSM, something not true of all HSM embedded code implementations.
So referring back to the Y2K bug analogy, there is a strong case to transition all cryptographic services to a services model to remove the need for application programmers to be too concerned about the underlying technologies, key and algorithm strengths etc , or the rules around our Gregorian calendar for that matter.
Having this in place, using HSMs to guarantee that sensitive material and cryptographic keys do not leak to the less controlled application space further protects the organisation. HSMs are continually updated to comply with industry security standards such as those from NIST.
And then moving the implementation of those critical or atomic functions to embedded code as supported by CodeSafe will ensure the highest protection against compromise and provide the highest level of confidence in the integrity of the application outcomes – no matter what day it is.
Adopting a crypto services transition model incorporating the above as part of any cloud architecture model seems to make sense to me.
Of course, this begs the question “what cloud HSM solution?”
I have some thoughts and results of some testing in regard to this which I will share later – Ross
