Is Your Crypto Due a Service?

Recent revelations in the press have caused industry experts to question just how much trust can be placed in existing cryptographic standards or even in certain methods of generating key material. Companies must be prepared to respond quickly and effectively to such changes in the security landscape, else they risk reputational damage and significant costs in the event of a breach.

To understand why this preparation is challenging, we should consider how cryptography is commonly deployed within a business.

Crypto the Painful Way

Each new project will be subjected to a threat analysis and a bespoke security design created to address the risks. In many cases, cryptographic resources known as hardware security modules (HSMs) are purchased to protect cryptographic keys from exposure; the choice of HSM will be driven by a combination of cost, familiarity and security requirements. Choices of key lengths, algorithms and cryptographic modes are made by the security architect, based on company policy or their best judgement at the time. After learning the idiosyncrasies and interfaces of the chosen brand of HSM, the developers will write software to conform to the security design, hopefully in a manner that allows some degree of flexibility later, but just as likely not.

There are several problems with this traditional approach to cryptography. Foremost is a lack of agility and flexibility. Imagine what would need to happen if RSA was broken or if SHA-256 was considered too weak for further usage - an urgent and painstaking review of each project and its use of cryptography, followed by a lengthy period of development work, testing and deployment. Not only would this be very expensive, but the business would remain at risk until the changes had been made. The pressure to fix the issue quickly would result in a higher number of bugs being introduced, while the distributed nature of the cryptography would make it likely that some occurrences were not spotted.

The second issue is the cost of deployment. Buying and maintaining HSMs on a per-project basis and requiring developers to understand the peculiarities of each different type of HSM is an expensive way to operate. Bear in mind that a typical deployment will require at least four devices: two for production, one for disaster recovery and one for testing/development. Trying to re-use HSMs from other projects can prove very challenging due to the difficulties of understanding capacity and a reluctance to change systems once they have been deployed.

Finally, the effort involved in demonstrating compliance with standards is compounded when the use of cryptography is spread across a business. Demonstrating this on a per-project basis is time-consuming, even if all projects stem from a company-wide policy. If any part of the audit fails, the resolution will be a series of point-fixes on each affected system, followed by a tedious re-audit of the solution.

The time has come for companies to rethink their use of cryptography and develop new approaches that meet the demands of the 21^st century.

Cryptography as a Service

Nowadays it would seem rather old-fashioned to buy new servers for each project and deploy them in their own rack. The world has moved on - servers now occupy dark datacentres and are allocated to projects with a few mouse-clicks in a virtual environment manager. Yet for some reason, few companies consider whether cryptography could operate in the same manner, despite the expense of purchasing and deploying HSMs on a per-project basis.

It would be much more efficient if all the HSMs lived in a rack together and were shared between all the projects that needed them. When demand exceeded available capacity, HSMs would be purchased and added to the farm. By exploiting the standardised interfaces supported by all brands of HSM, the farm could be designed in a vendor-agnostic fashion. Imagine explaining that in a purchasing meeting! Nothing drives down costs like announcing that you don't care which vendor you use because your solution works just as well with all of them.

Now we have a farm of HSMs, it would make sense to apply some policies centrally too. If security decisions are pushed out into the individual projects, they become brittle and hard to change in a crisis. Instead, projects should express what they want to do, not how they want to do it. A centralised policy can dictate which algorithm, key length or mode of operation is currently deemed secure enough for the task. If a weakness is found in a particular algorithm, it can be removed from an approved list and projects can immediately begin using its successor.

Centralised policies are easier to audit, which can dramatically reduce the cost of proving compliance with industry regulations.

By rethinking the way cryptography is deployed within a business, costs and risks can be reduced at the same time that the ability to respond to a crisis increases. Business leaders must start to consider cryptography as a strategic issue that deserves as much pre-planning as other infrastructure components. The need to adapt and the constant pressure to demonstrate compliance with standards are both excellent reasons for pursuing a service-based cryptographic deployment. To drive down both the cost and risk associated with deploying security projects, businesses must view cryptography as a strategic issue worthy of up-front investment.

See full Cryptomathic article in Connect World or download the Crypto Service Gateway product sheet for more information on how to implement a crypto service in an organisation.

References and further reading

• Selected articles on HSMs (2013-17), by Ashiq JA, Duncan Jones, Peter Landrock, Peter Smirnoff, Steva Marshall, Torben Pedersen and more