  | Issue: | Asia-Pacific I 2014 |
| Article no.: | 8 | |
| Topic: | Is your Crypto due a service? | |
| Author: | Morten Landrock & Duncan Jones | |
| Title: | EVP EMEA & Senior Solutions Architect | |
| Organisation: | Cryptomathic | |
| PDF size: | 233KB |
About author
Morten Landrock is Managing Director of Cryptomathic Ltd and Executive Vice President of Cryptomathic’s EMEA (Europe / Middle East / Africa) operations, managing a team of people based in Denmark, France, Germany and the United Kingdom. He is also responsible for Cryptomathic’s corporate marketing activities.
Since joining Cryptomathic in 1999, Morten has worked extensively in business development, corporate strategy, management, marketing, and sales with a keen focus on international expansion – setting up offices in Denmark, France and the United Kingdom. During 2003-2005, Morten served as Vice Chair of the Marketing Centre for GlobalPlatform, an organisation responsible for the standardisation of smart card technology. Prior to joining Cryptomathic, he worked in marketing in the USA.
Morten Landrock holds a B.Sc in Business Administration of Aarhus and supplemented studies with graduate economics courses from the University of Leuven.
Duncan Jones is a Senior Solutions Architect and HSM (Hardware Security Module) expert. He designs security systems for customers across EMEA using Cryptomathic solutions, working closely with various large companies across the region, primarily in the financial services space. He also contributes to the innovation team, which develops new ideas and concepts, some of which are based on customers’ blue sky thinking and some initiated in-house. Duncan recently joined Cryptomathic, having spent the previous six years working for an HSM vendor, developing bespoke software solutions based around HSM products.
Duncan Jones holds a B.A. (Hons.) in Computer Science from the University of Cambridge.
Article abstract
The way cryptography is deployed affects the ability to respond to changing security requirements. Cryptography is often missing from the initial project phase, and is hard to be grafted on later. Re-using existing Security Modules is challenging and demonstrating standards compliance per project is costly. What is required is a centralized system that provides cryptography services to any project. This allows balancing demand across the business. It reduces efforts of proving compliance and enables deploying new algorithm and retiring old ones – all at a click of a button. Therefore, Cryptography as a Service now has much to offer!
Full Article
In early October 2013, it was announced that the RSA algorithm was no longer fit for purpose and businesses should immediately migrate their applications to stronger forms of encryption and signing. The revelations followed the publishing of a paper by a group of leading mathematicians, which described a new technique that dramatically reduces the time needed to factor large numbers. Four days ago, software appeared across the internet that could break a 2048-bit RSA private key in under an hour using a normal household computer. Security experts are describing the news as ‘catastrophic’, with one source quoted as saying: “This will make the Y2K problem look like a walk in the park. RSA encryption or signing is at the heart of almost every secure system – the costs for moving to a new scheme, or even a longer key size, will be staggering. Existing systems will be at severe risk until changes are made.”
Fortunately, the scenario above is fictional. RSA is still thought to be secure against ‘brute-force’ attack. Yet, as many people still dedicate their lives to cryptanalysis and the mathematics behind code breaking, it is inevitable that weaknesses will be found in algorithms or the ways in which they are used. MD5 was once a popular choice for hashing data used in certificates and digital signatures, but attack methods have become so effective that it can be broken in a matter of hours using standard computer equipment. The DES algorithm protected financial transactions for many years in the 80’s and 90’s, but is now considered too weak for use by the security community. Businesses must be prepared to adapt to gradual changes in attack sophistication as well as the sudden catastrophes that might occur through a mathematical discovery.
The role of cryptography
To understand why modern security is challenging, we should consider how cryptography is commonly deployed within a business. 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 is 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 a period of time, learning the idiosyncrasies and interfaces of the chosen brand of HSM, the developers will write the project software to conform to the security design, hopefully in a manner that allows some degree of flexibility later, but just as likely not.
Quite often the project is already deployed by the time somebody asks the vital question – how should we manage the lifecycle of the cryptographic keys? For some reason, despite many security experts understanding that keys should be rotated frequently to lower the risk of exposure, few projects incorporate key management during the design phase. Consequently, key management is either added later at great expense or ignored completely in favour of ‘manual’ alternatives.
There are several problems with this traditional approach to cryptography. First and foremost 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.
The second issue is a lack of agility and flexibility. Just 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.
Finally, the effort involved in demonstrating compliance with mandatory standards is compounded when the use of cryptography is spread across a business. Banking and retail companies often need to follow best practices in terms of cryptographic algorithms, key sizes, key storage and logging capabilities. Demonstrating this on a per-project basis is time-consuming, even if all projects stem from a company-wide policy. Annual audits can take weeks, as consultants investigate each system and its adherence to company policies and the relevant regulations. 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 21st century.
Cryptography as a service
Nowadays it would seem rather old-fashioned to buy servers for each new project and deploy them in their own rack, managed by a small team of people. The world has moved on – more and more resources are being managed as a service. 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, somewhere deep within the bowels of the business, and were shared between all the projects that needed them. As and 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 that we have a farm of cryptographic resources, it would make sense to apply some policies centrally too. If too many security decisions are pushed out into the individual projects, they become brittle and hard to change in a crisis. Instead, projects should be able to express what they want to do, not how they want to do it, and a centralised policy can then 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.
Key management should be offered as part of the service, ensuring that every project benefits from a consistent, automated approach to key lifecycle management. This not only involves the generation and rotation of key material, but also the ability to retrieve old keys when accessing historic encrypted data. Centralising this functionality makes it easier to control and lowers the cost of auditing.
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.
The future of cryptography
Recent revelations in the press have caused industry experts to question just how much trust can be placed in existing standards or even in certain ways 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 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.
In time, as more organisations adopt a service-based methodology, confidence will grow in the value offered by such a change and internal resistance will decline. In the meantime, it may be the cost of demonstrating compliance that drives businesses to think differently. Centralising the management of one of the most highly-regulated and standards-driven aspects of a modern business will provide immediate return on investment and reduce the headaches experienced at audit time. The additional cost benefits for project deployments and resource sharing will be the icing on the cake.
