i n f o rma t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 5 ( 2 0 1 0 ) 2 8e3 2

ava i lab le a t www.sc iencedi rec t .com

www.compseconl ine . com/publ i ca t ions /prod in f .h tm

Caveat venditor

George French a,*, Mike Bond b

aBarclays Bank Plc, 1 Churchill Place, Canary Wharf, London, UKbComputer Laboratory, University of Cambridge, JJ Thompson Avenue, Cambridge, CB3 0FD, UK

* Corresponding author.E-mail addresses: George.French@barclay

1363-4127/$ e see front matter ª 2010 Elsevdoi:10.1016/j.istr.2010.10.003

a b s t r a c t

Tamper-resistant Hardware Security Modules (HSMs) are a core technology used to build

assurance in the security of large IT systems protecting and manipulating sensitive data.

This paper draws on the authors years of experience working to deploy HSM-based solu-

tions in the financial industry. We argue that as soon as you scratch the surface of the

simple “buy and forget” model where an HSM is bought to satisfy a compliance require-

ment, the buyer encounters initial and ongoing challenges when trying to cover all the

bases for security. There is now (compared with 10 years ago) a good public literature on

HSM vulnerabilities, but even checking resistance against known threats and attack classes

becomes very difficult in practice, let alone considering theoretic and new attacks which

have not been widely implemented across HSM platforms. Part of the problem is the lack of

security details in vendor information, part is lack of awareness of the issues for the

buyers. Some older attacks such as the decimalisation table attack have been largely

addressed; others such as PIN block translation (and other oracles) have not. This paper

argues that the balance of responsibility between buyer and vendor to maintain security

awareness has much room for improvement, and that existing certification processes such

as FIPS-140 leave huge gaps that need to be covered when building assurance. In the retail

sector strong buyer protections exist because the layperson cannot be expected to

understand and manage all the relevant risks, but in the financial industry the assumption

has been that buyers have the skills to evaluate the products e “Caveat Emptor”. But maybe

it is time to redress this balance with a little “Caveat Venditor”?

ª 2010 Elsevier Ltd. All rights reserved.

1. Introduction third-party data, personal customer/patient/employee data

The use of encryption within business is without doubt on the

rise: the vast majority of this impetus to adopt cryptography is

generated by ever greater regulatory, industry best practice,

and customer/consumer pressures to protect the information

that they hold on behalf of their customers and third parties.

As the amount and more importantly the type of infor-

mation that companies and institutions collect and hold

grows, larger sections of this data become subject to some

form of data protection. This data includes, for example,

s.com (G. French), Mike.Bier Ltd. All rights reserve

and Payment Card transactional data.

The 2009 Encryption and Key Management industry

Benchmark Report (Section II, Table 9) cites 25 data protection

regulations:(Fig. 1)

In order to meet these obligations many organisations are

turning to the use of cryptography to try to neutralise the risks

and compliance issues surrounding sensitive data. As many

standards put it, once data is in encrypted form, the rules no

longer apply, and it only remains to consider how youwill look

after the keys instead. Cryptography has the attraction of

ond@cl.cam.ac.uk (M. Bond).d.

Fig. 1 e Data protection regulations.

i n f o rm a t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 5 ( 2 0 1 0 ) 2 8e3 2 29

taking a big data problem (the protection terabytes of sensitive

data) into a smaller problem (just the protection of a few

hundred bytes of key material), but a problem remains

nonetheless.

Oragnisations will encounter a number of obstacles to the

implementation of encryption within applications, which

broadly speaking manifest in terms of added costs and oper-

ational complexity.

The complexity related costs, include the cost for devel-

opment and testing, and design of an application to ensure

resilience and recovery e.g. from data corruption which has

amuch greater effect on encrypted than clear-text data. There

is also the cost for the creation and implementation of a key

management schema to support the use of encryption.

While these costs are related to design and initial deploy-

ment phases of a cryptography solution, there are yet more

that arise throughout the life cycle of a business application.

Such operational issues include performance impact on

applications (increase in transaction latency times which

might already be close to an agreed maximum).

In addition, therewill be business concerns about not being

able to recover data and the impact to applications in terms of

increased outages to perform the additional tasks that the use

of cryptography requires e.g. such as key the roll-over/renewal

and data migration/re-encryption.

Capital costs may include cost of paying for upgrade to

third-party or the modification of existing internally devel-

oped applications, which are not currently designed to

support the use of cryptography. Also there are the costs that

might arise from the delay in waiting for vendors to embed

encryption into their products.

If the cryptography is to be performed in hardware as

opposed to software, there is the added cost of acquiring the

cryptographic hardware with adequate performance for the

data rate required, and with sufficient capacity to meet

operational requirement for resilience and failover support.

Hardware solutions also come with their associated lifecycle

management costs.

In light of all these obstacles a number of organisationswill

choose to make the investment and deploy hardware-based

cryptography in order to reach what some view as the

pinnacle of data protection. This is because hardware cryp-

tography offers the tantalizing capability to safely look after

the cryptographic keys and end the chain of controls which

push the risk from one system to another. once it goes inside

the HSM, all is well. However, unfortunately this is not the full

story. While cryptography is good at turning a big problem

into a smaller one, HSMs are also just converters of problems:

they turn technical problems into procedural ones. So ulti-

mately, even when working perfectly in a technical sense,

they are not a silver bullet which will remove the risks

entirely.

The use of an HSM normally requires the enforcing dual

control and split-knowledge principles which are heavily

audited (the organisation must often demonstrate its

compliance to regulations etc.) This comes about because the

deployment of HSMs requires human interaction during the

initialisation and configuration of the device as well as

management of key material prior to loading into or transfer

between HSMs. If the reason for these controls is not under-

stood or the controls are not applied correctly then security

issues can still arise. Such examples would include leaving

HSMs in authorised states, or leaving unused commands and

interfaces available for use which can be used to attack

cryptographic APIs leading to the compromise of keys (Formal

Analysis of PIN Block Attacks; PIN Crackers).

When a new type of attack comes along, such as the oracle

problemswith the PKCS#11 import and export of keys, there is

a tendency to react to it not by addressing and changing the

underlying API vulnerability, but by augmenting the proce-

dural controls to mitigate the risk, or control the circum-

stances under which the vulnerability might manifest itself.

This is always a danger, and for this reason, and other

economic considerations, modern HSMs unfortunately

remain vulnerable to a number of implementation issues

which are well known and understood in the academic

community.

In the first section we describe the basic functionality

provided by an HSM. In the next section we look at examples

of implementation issues which are active causes of concern

for those deploying HSMs, and then finally we conclude with

some suggestions and proposals for helping build assurance

better and more fairly in future. In particular we discuss the

idea of a central repository of measurements and tests of

HSMs which is independent of manufacturers, but which is

just a source of data and not a certification provider in its own

right.

2. Overview of HSM functionality

In general an HSM can be thought of as providing three core

functions:

1. An Application Programming Interface (API) This is a set of

calls that will provide access to cryptographic functionality

of the HSM. It is this functionality of an HSM that is the

most heavily standardised.

i n f o rma t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 5 ( 2 0 1 0 ) 2 8e3 230

2. A simple access control system which is used to configure

the device and enable sensitive security operations such as

loading or extracting keys. The most basic level is a root

password, but many HSMs use split-knowledge master

passwords spread over smartcards.

3. Key management functionality, to generate keys, and to

move keys between different HSMs for the purposes of

communication and backup, normally consisting of wrap-

ping and unwrapping functions which use one key to

encrypt another. Many HSMs will also implement some

form of key usage mechanism which will attempt to

enforce a particular cryptographic function on that key.

Also there is the requirement to be able to move keys

between multiple HSMs for resilience (which is most often

overlooked and can be the hardest to get right).

HSMs as you would expect come in a variety of different

form factors. They range from the very simplest HSMs which

just provide the usage functionality, have a static security

configuration, and maybe just one or two keys generated at

manufacture time (an example would be a Smartcard), up to

more complex devices which can be in the form of a PCI card

or a network attached device. For a more in-depth look at

HSMs see (Anderson et al., 2005).

HSMs can be separated into two types, namely HSMs that

provide cryptographic acceleration by allowing a server to

offload cryptographic processing to them but do not offer full

secure key protection. The second type also provides the

ability to securely store and generate keymaterial under strict

controls, in addition to acceleration. It is the latter type that

we will be looking at more closely.

HSMs use multiple physical and logical security mecha-

nisms to protect cryptographic key material. Such mecha-

nisms include the incorporation of tamper-resistant or

tamper-evident enclosures and packaging procedures in the

physical construction, as well as the deployment of strong

authentication mechanisms to ensure segregation of duties

between the administrator of the device and the user of the

device. This is sometimes extended to provide mechanisms

that provide strong segregation between different users of the

devices e multi-user HSMs. HSMs normally offer a bespoke

API to access the capabilities of the device.

Full-function HSMs (as opposed to hardware accelerators)

can be further sub-divided based on the sectors they support.

The first use of HSMs within business was by the financial

sector in the 1970’s and they focused on providing crypto-

graphic mechanisms based on symmetric keys to secure ATM

traffic, Credit Cards and financial transactions and have ten-

ded to use Vendor Specific APIs to access services.

The second type of HSMs are normally referred to as

general purpose HSMs. These devices support all the other

cryptographic mechanisms outside of the payment trans-

action arena. The largest driver in this was the growth and

adoption of PKI, hence these devices tended to focus on the

use of asymmetric keys.

But recently the line between the two areas has merged

and both types are offering symmetric and asymmetric cryp-

tography as well as supporting a variety of Cryptographic APIs

such as PKCS#11 or MSCAPI and JCE, as well a de-facto Stan-

dards such as the Thales HSM8000 command set and shared

data formats with differing APIs such as the Atalla keyblock,

2002 (or ANSI TR-31 keyblock).

Another one of the attractions of using HSMs from a busi-

ness perspective is the fact that most HSMs are compliant

against one or more Standards, such as the NIST FIPS 140-2

Standard (Fips Pub) or Common Critera EAL4. This again can

be seen as following industry best practice or in order to

demonstrate compliance with a scheme or legal requirement.

However, although HSMs may pass certification this does

not mean they are free from errors as we elaborate in the next

section. Themain issuewith the current accreditations is they

do not cover all aspects of the HSM, for example they do not

cover the implementation of the API(s) the HSM supports. Also

the accreditations are somewhat binary in nature; a pass/fail

against a fixed set of criteria as in the case of FIPS 140-2 or

against a set of functions which are defined within a Security

Target (ST) document that may be different depending on the

product. The intention of the ST was to demonstrate compli-

ance to a Protection Profile which would define the list of

security requirements of a specificuser or community of users.

This approachplaces the burdenof defining the security on the

user and presupposes that a user has the requisite knowledge

to be able to specify a detailed Protection Profile. Again these

profiles will fail to cover the supported APIs in any depth other

than specifying one or more specific ones to be implemented.

But it isoften thecase thatwhenaflawis foundwithinanAPI

the hardware vendor in correcting the problemwill be required

to alter elements of the product that are covered by a standard.

This obviously will require the vendor to resubmit the product

for evaluation, which not only slows down the deployment of

a fixbut alsohas a cost implication for the vendor. This cost and

delay is a major factor driving vendors and users into devising

additional compensating controls such as augmenting proce-

dural controls or attempting to limit the circumstances under

whichthevulnerabilitymightmanifest itself.Afinal twist is that

if the workarounds are widely adopted or used out of scope to

achieve another requirements (such as pre-XORing control

vectors to achieve legacy device interoperation using the IBM

common cryptographic architecture) then fixing the problem

may well cause operational issues for the user.

In the next section we will consider two specific attacks

which remain possible on accredited HSMs.

3. Technical issues

This section discusses the technical shortcomings of existing

HSM APIs, surveying the literature and giving a few pertinent

examples. HSM attacks were first academically studied by

Longley and Rigby around 1990 (Longley, 1987; Longley and

Rigby, 1992), and then reignited from 2000 onward by

Anderson, Bond et al (2005). For more detailed overview see

Bond, 2004; Anderson et al., 2005. The vulnerability classes

documented included pure API attacks (where a design

mistake is made which has nothing to do with underlying

crypto), key metadata binding attacks (interpreting one key as

another), key material binding attacks (splitting a large key

into smaller ones more susceptible to brute force), and oracle

attacks both with deterministic and statistical information

leakage properties.

i n f o rm a t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 5 ( 2 0 1 0 ) 2 8e3 2 31

Key material and metadata binding attacks have largely

been addressed in new APIs with formats such as the Atalla

Key Block (Atalla Key Block, 2002), and the ANSI X9 TR-31 key

exchange block, so deviceswhich take advantage of these new

formats are largely resistant. The story is not so bright

regarding oracle attacks. One of the first oracle attacks docu-

mented against HSMs was Clulow’s PIN translation attack

(Clulow, 2003), yet since 2003 little has changed in PIN pro-

cessing APIs besides the introduction of the ISO-3 PIN block

format which has little impact on the generic techniques. Our

next example is an oracle attack.

3.1. PKCS#11 padding oracle attack

Roundabout 2003, Vaudenay highlighted CBC padding oracle

attacks and their application to various cryptographic proto-

cols (Vaudenday, 2000). The PKCS#11 HSM programming API

(the most standard and popular API) is vulnerable to this CBC

padding oracle attack: according to the specification the HSM

would normally return an error code depending uponwhether

the unwrapped key unpadded correctly or not. However, the

specification permits arbitrary deviation from normal behav-

iour, and it is commonplace for certain commands or features

in the API simply to be prevented. One might naturally expect

than an old attack such as the CBC padding oracle would now

be prevented, seven years later. Since then a PKCS#11 version

2.20 has augmented the standard with an approved mecha-

nism list and templating system, but this still has limitations

in dealing with importing and exporting keys from multilayer

key hierarchies, and the uptake of the latest version of the

PKCS#11 API has been limited anyway.

The authors implemented the padding oracle attack on

HSMs from three major vendors and found them all to be

vulnerable as of early 2010, with subtle differences in the error

codes returned for the oracle.

Regardless of the inconvenience of the devices containing

this vulnerable functionality, despite the documentation

making reference to differing risk levels from enabling or

disabling certain HSM functionality, it was far from clear from

the documentation as to whether the HSM was vulnerable to

this attack (and in which configurations).

3.2. Statistical inference attacks

Statistical inference attacks are a class of oracle attacks where

combining and analysing the results of many hundreds of

calls to an HSM start to leak information about weak secrets

managed by the API, such as PINs and passwords. A good

example of a fairly sophisticated statistical attack is the PIN

block alignment attack in Eracom Workshop, 2004. This 2005

attack exploits API calls to generate a very large number of

encrypted PINs for the same bank account which are stored in

a poorly randomised encryption format, enabling the more

frequently occurring PINs (due to decimalisation table skew)

to be identified and separated from the less common ones.

Together with use of PIN Offset API functionality which is

designed to permit customers to change ATM PINs securely,

the attack allows an entire dictionary of PINs to be recovered

using a few thousand API calls.

One of the authors originally implemented this in simula-

tion against the API of the IBM 4758 CCA Version 2.41 as part of

the paper. We have since re-implemented the same attack on

the Thales HSM8000 (the most common HSM used for finan-

cial transactions) and found that it as well as the IBM device

remains vulnerable to this attack.

As with the PKCS#11 oracle attack, despite being public

knowledge for more than five years, the API vulnerability

persists, andyet it isdifficult to tell for certain justby reading the

manuals whether such an attack is possible, particularly

because HSM vendors have the option of adding hidden

semantics (secret or undocumented functionality which is not

clear from the API specification) to resist such attacks. For

instance, the Futurex Guardian 9000 HSM (Futurex Excrypt

Guardian 9000), claims to have specical functionality to detect

and prevent exhaustive PIN guessing attacks e something

whichwouldnotmanifest itself directly in theAPI specification.

3.3. Addressing technical vulnerabilities

In order to address these persistent technical issues at

a business-level, we believe the core requirement is

measurement and analysis of existing HSMs with respect to

known and documented attacks. Ideally an independent body

would undertake these tests in a similar way to the Euro NCAP

car safety initiative (Euro NCAP).

Such an initiative would encourage better APIs, and

encourage designs which make it easier to prove security: the

less esoteric the HSM functionality the better. Previous

academic literature has already picked out the core concerns

that APIs must assure, such as proper binding of metadata

with keys, and granular access control.

Ideally the function of an API should define its form, and

extending or modifying other APIs to include a new feature is

a major source of risk and design complexity. It leads to the

evolution of the Swiss-army knife, rather than the ideal of

creating the ice-cream scoop e a tool perfect for the job at

hand, but difficult to misuse or hurt yourself with.

The authors have also experimented with flexible APIs

which do allow a variety of calls, butmaintain some invariants

on action sequences, such as the “upgrade only” rule. Here, the

API allows re-encryption from any loaded key to another, but

only so long as the key strengths anddata format strengths are

equal or higher. This is not just enforcing that a 3DES key

cannot be encrypted under single DES, but also ensures that

while legacydata inan insecure format suchasCBCencryption

with no integrity check can be handled by the same API, and

even outputted, data with a better format including MACs etc,

can never be downgraded to the weaker format.

Finally, academic initiatives such as the Analysis of Secu-

rity APIs (ASA) workshopwhich seek to use formalmethods to

build assurance will have a lot to say in future about both

which APIs are secure, andwhich APIs aremost demonstrably

secure e a factor which is almost as important.

4. Conclusions

It is not reasonable to expect every purchaser of HSMs to

evaluate and rigorously test each product they use for fitness

i n f o rma t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 5 ( 2 0 1 0 ) 2 8e3 232

for purpose. The tamper-resistant security standards such as

FIPS-140 and PCI-PED, PCI-HSM bear witness to depending

parties building assurance for their own benefit. But it seems

that in the long run, such standards lack the flexibility to

measure security with a fine granularity, and to keep up with

the developing threats.

Technical standards are not a panacea and are only part of

the solution. Where these standards break down is that they

do not just measure security, but then heavily quantise the

result of this measurement into a very specific pass/fail or

level 1/2/3/4 score, which throws away the vastmajority of the

information gained from the measurement process. As soon

as a buyer’s requirements stray outside the confined threat

model against which the pass/fail setting is calibrated, the

result becomes meaningless.

The approach we propose is an implementation led

approach to develop and extended a framework formeasuring

and assessing HSM security in an impartial and repeatable

way.We leave it to the buyer to draw conclusions of fitness for

purpose, but we rely on the vendor to make their devices

available for testing.

Such an approach depends on raising awareness that

customers do need security evaluation beyond simple pass/

fail certification in order to properly manage their risk, and on

encouraging greater transparency from the vendors over their

shortcomings. However, the vendors may draw some benefit

as the relaxation of prescriptive pass/fail certification stan-

dards gives vendors more freedom to approach and solve

problems in a unique way that adds value. Much vendor

innovation is stifled by the inability of certification standards

to accommodate new approaches.

In future wemay see semi-automated tools such as Tookan

(Bortolozzo et al., 2010) (of course used together with pure

manual analysis) toprovide thebedrockof suchameasurement

service. Ultimatelywithoutmeasurementwe cannot amass the

evidence and arguments needed to make it economic to rede-

sign more modern API, and address the root cause.

r e f e r e n c e s

Anderson R, Bond M, Clulow J, Skorobogatov S. Cryptographicprocessors ea survey 2005, http://www.cl.cam.ac.uk/%7Emkb23/research/Survey.pdf.

Atalla key block, white paper 2002, http://h71028.www7.hp.com/ERC/downloads/ATKEYBLWP.pdf.

Bond M. Understanding security APIs 2004, http://www.cl.cam.ac.uk/%7Emkb23/research/Thesis.pdf.

Bortolozzo M, Centenaro M, Focardi R, Steel G. Attacking andFixing PKCS#11. In: Security tokens proceedings of the 17thACM conference on computer and communications security(CCS’10), Chicago, Illinois, USA, October 2010: ACM Press, inpress.

Clulow J. The design and analysis of cryptographic APIs forsecurity devices. Master’s thesis, University of Natal, Durban;Jan. 2003.

Encrypted? Randomised? Compromised? (Whencryptographically secured data is not secure); Cryptographicalgorithms and their uses. In: Eracom workshop, http://www.cl.cam.ac.uk/%7Emkb23/research/Enc-Rand-Comp.pdf 2004.

Euro NCAP, http://www.euroncap.com/home.aspx.Fips Pub 140-2 Security requirements for cryptographic modules,

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf.Formal analysis of PIN block attacks, 2006, http://homepages.inf.

ed.ac.uk/gsteel/papers/tcs06.pdf.Futurex Excrypt Guardian 9000, Retrieved 2010, http://www.

futurex.com/products_hsm_excrypt_guardian9000.asp.Longley D, Rigby S. An automatic search for security flaws in

key management. Computers & Security March 1992;11:75e89.

Longley D. Expert systems applied to the analysis of keymanagement schemes. Computers & Security Feb 1987;6(1):54e67.

PIN Crackers, Nab Holy Grail of Bank Card Security, Retrieved2010, http://www.wired.com/threatlevel/2009/04/pins/.

Section II Table 9 2009 Encryption and key management industrybenchmark report, http://www.trustcatalyst.com/2009EncryptionSurvey.php.

Serge Vaudenday. Security flaws induced by CBC padding e

applications to SSL, IPSEC, WTLS . 2000, LNCS 2232.