We have been stressing the fact that we all need to consider the time, effort and risk involved in a change of cryptographic families on the whole of our IT and OT stacks. And we must note that cryptography is the foundation for digital trust when it comes to these IT and OT stacks; without digital trust, these stacks cannot and should not store or process critical business data. So, we need to trust and verify. This change is especially needed to prepare for the onset of quantum processing.

Our second theme is that in undertaking this change, the cryptographic processing engines everywhere, will need to be respun, reformatted and reinstalled. Literally everywhere.

Zero-Trust in Cloud and Multi-Cloud Settings

the fact that regardless of the above two issues, the old adage of ‘trust but verify’ (or ‘zero- trust’) is proving hard to do with today’s HSMs, particularly in cloud and multi-cloud settings.

This difficulty stems from two main vectors – the first is that the architecture of the initial digital root of trust foundation (the HSM) was designed some 30 years ago for what is now described as the ‘inside’ or ‘inside the club’ use cases. Imagine trying to do your job with a laptop, or mobile device from 30 years ago; do you think you could keep up with demands, or even complete basic digital tasks in 2022? The answer is obvious, no; so we need to evolve the 30 year old HSM architecture to account for this next decade and beyond.

Most HSMs today show their deficiencies when it comes to modern digital requirements. These HSMs lack modern tools to create flexible and programmable architectures for federated, connected external facing IT environments. Which ‘external’ environment we note, are now encompassing 5G, smart cities, AI/ML, IoT and quantum based cloud insights – amongst other advances coming next week, next month, next year or next decade.

The second vector of difficulty stems from the missing HSM functionalities (see above paragraph) required to accommodate the new and evolving, ‘trust but verify’, dynamics of a secure, robust connected economy.

Marketing refers to ‘trust but verify’ as ‘zero -trust’ – a regrettable but generally accurate turn of phrase. But zero-trust needs a reliable evolving framework for creating trust and verify each time. Remember, the focus is not on trusting anything; how then will digital business function? You need digital trust in humans and machines in order to get anything of value done. As such, security and IT leaders have an obligation to verify, establish and maintain trust with any and all entities they or their organizations interact with.

In the old ‘trust but verify’ days, the inside use case coupled with logical and physical access controls worked well as they were tolerated as appropriate – and they also benefited from the actual physical presence of the identity.

But in an ‘always on /always immediate’ connected economy with emergent digital identities, no real time lags and straight through processing needs, ‘trust but verify’ needs to change to ‘trust and verify’. Each time.

New Architectures, Functionalities and Processing Engines

In order to accommodate new architectures, new functionalities and new processing engines for a zero- trust (and verify) enabled economy, a weighing of two considerations may be instructive.

The first consideration is whether the useful life of the HSM can be extended further to capture, with its traditional levels of assurance, the dynamics for zero-trust for these new processing environments and use cases.

The second consideration is whether the limits of the HSM in its architecture and primitives processing are just upon us – like an old house foundation that is now cracking and leaking – because the water table has shifted the foundation. Do we also wait until one of the windows crack and the connecting pipes break too, to provide further evidence that it’s time to redo it?

New HSM Architecture for Zero-Trust

After careful consideration (our founders were ‘key’ to the design and build of the market leading HSM) we came to the conclusion that the HSM needed to be re-architected for zero-trust and the hybrid-multi cloud world. All with a focus on bringing new modern needs back ‘inside’ for best protection, assurance and processing power, and to reverse the relationship of the HSM to the applications it supports.

We will talk about our specific approaches to these modern needs, and our responding features in coming blogs.

While designing the ‘new’ HSM (btw – we call it a Hybrid Security Platform (HSP) given that it will be in deployment during the era of ‘quantum concern’, you should also update the cryptographic processing engine at the same time to be crypto-agile for quantum and for its own updates. Having this capability ready in advance is just prudent risk mitigation. We have talked about that at length in prior blogs already.

Crypto updates in the zero-trust quantum-enabled world may need to happen with greater frequencies than in prior times, as attack vectors and computational powers evolve. Think about how slow it would be to go to each provider of software, hardware and services to update or patch that crypto or key management processes and processing engines because for example, someone found another algorithm to create the outcomes of a Shor’s algorithm. And think about that process having to repeat itself each time for each trading partner in the demand and supply side of your business.

We know that foundations should rarely be touched – but we came to the view that half-measures were just that – half measures. We wanted a forward, cost effective and prudent approach to creating long lived digital trust – a ‘like for like’ replacement approach will be too slow, too expensive and will place severe burdens on scarce skill sets. And such an approach will in any event miss the mark on required functionalities needed for ‘zero-trust’.

Digital trust would then move at the speed of the slowest and least capable participant in your ecosystem. Their security is your security is your customers’ security.