Gavin Keighren
T H E UN I V E RS I T Y O F E D I N B U RG H Master of Science Artificial Intelligence School of Informatics University of Edinburgh 2006Devices which operate on sensitive data are becoming an ever-increasing part of our lives, and we are placing a continually growing amount of trust in them. However, their ability to provide the proper level of data protection is typically only checked through analysis by hand. This method cannot be known to be complete, and as a result it can be possible to obtain data which should remain secret. It is only recently that formal methods have been applied to the analysis of such devices.
We present results from the application of a model checker to the analysis of the API used by a number of security modules in Automated Teller Machine networks — IBM’s Common Cryptographic Architecture API. We show that it is capable of rediscovering all known attacks on the API, using models containing a greater set of API commands.
We also analyse the set of recommendations released, in response to one of the discovered attacks, by IBM and show that, under certain assumptions, they do not prevent the attack. We use a revised set of assumptions, under which they do prevent the attack, to determine a number of our own recommendations aimed at the design and implementation of the API.
Finally, we discuss various issues concerning the analysis of security APIs, based on our experiences of carrying out the work presented.
I would like to thank my supervisor, Graham Steel, for not only having proposed the topic, but for providing me with continual support, advice, and encouragement throughout my research. Thanks also go to Alan Bundy for providing critical feedback on my work.
I am grateful for the support provided by Mathieu Laurient for CL-AtSe, and his apparent desire to help me out with absolutely any problem I encountered with it.
Alessandro Cimatti, Marco Roveri, Roberto Cavada and the other members of the Autonomous Reasoning Systems division at ITC-irst deserve a mention, for without them, I may have never entered the field of formal verification. I am eternally grateful for the opportunity that they gave me.
I am sure that my year would have been significantly harder without the generous funding provided by the Engineering and Physical Sciences Research Council. I am greatly indebted to them for that.
Last but by no means least, are my friends and family. Too numerous to mention individually, they have all played a part in making sure that I never lost sight of the important things in life, and were always there when I needed them. Thank-you.
I declare that this thesis was composed by myself, that the work contained herein is my own except where explicitly stated otherwise in the text, and that this work has not been submitted for any other degree or professional qualification except as specified.
List of Tables 6
1 Introduction 7
1.1 Thesis Overview . . . 8
1.2 Our Contributions . . . 9
2 Introduction to Security APIs 10 2.1 History . . . 11
2.2 Selected Applications . . . 13
2.3 Summary . . . 16
3 Literature Review 17 3.1 Pure API Command Attacks . . . 18
3.2 Brute Force Attacks . . . 21
3.3 Information Leakage Attacks . . . 25
3.4 Formal Analysis Methods . . . 26
3.5 Current Research . . . 28
3.6 Summary . . . 29
4 Overview of IBM’s CCA API 31 4.1 Working Keys . . . 32
4.2 API Commands . . . 33
4.3 Access Controls . . . 36
4.4 Summary . . . 37
5 Rediscovery of Known Attacks 38 5.1 Tools Used . . . 38
5.2 Modelling the API . . . 41
5.3 Modelling the Attacks . . . 42
5.4 Results . . . 47
6 Verification of IBM Recommendations 53 6.1 Recommendation 1 . . . 53 6.2 Recommendation 2 . . . 57 6.3 Recommendation 3 . . . 60 6.4 Overall Conclusions . . . 62 6.5 Summary . . . 64 7 Discussion 65 7.1 Differences Between Security APIs and Security Protocols . . . 65
7.2 Modelling Security APIs . . . 66
7.3 Model Checking Tools . . . 67
7.4 Intruder Capabilities . . . 68 7.5 Summary . . . 68 8 Conclusions 70 8.1 Related Work . . . 71 8.2 Future Directions . . . 71 A Command Notation 73
B HLPSL Model of IBM’s CCA API 74
5.1 Results for the Rediscovery of Bond’s Key Import Attack . . . 47
5.2 Results for the Rediscovery of the First Variant of Bond’s Import / Export Loop Attack . . . 49
5.3 Results for the Rediscovery of the Second Variant of Bond’s Import / Export Loop Attack . . . 49
5.4 Results for the Rediscovery of the First Variant of the IBM Attack . . . 50
5.5 Results for the Rediscovery of the Second Variant of the IBM Attack . . . 51
6.1 Results for the Verification of IBM’s First Recommendation . . . 56
6.2 Results for the Verification of IBM’s Second Recommendation . . . 59
6.3 Results for the Verification of IBM’s Third Recommendation . . . 61
Introduction
Electronic devices that control our access to a particular product or service exist all around us, from Automated Teller Machines (ATMs) to television set-top boxes. These devices are inten-ded to only grant access when the user has demonstrated that they have the required permission (e.g. a personal identification number (PIN), or valid subscription card).
These devices have a secure component that contains the sensitive data required for the validation process. This component has to provide the necessary services to the overall device, while ensuring that the sensitive data cannot be extracted. This is the ultimate aim of the com-ponent’s security API — an application programmer interface with additional security goals.
Collectively, these devices provide trusted services in an otherwise untrustworthy, or even hostile, setting. The level of trust that a device can provide arises as a direct consequence of the secrecy of the sensitive data which it is designed to protect. In the vast majority of cases, the sensitive data will be one or more cryptographic keys, which are used to access and produce encrypted data. This data is itself sensitive, and must not appear in an unencrypted form outside of the secure component.
This is similar in nature to the use of cryptographic keys to encrypt secure communications between two computers. However, while such security protocols are more restrictive and thus easier to check for flaws, security APIs are generally far more complex and significantly harder to verify.
Since 2000, a number of serious flaws have been discovered in the security APIs of devices used in ATMs, which potentially allow an attacker to obtain the associated PIN of any given primary account number. These flaws were discovered through detailed hand analysis, but it was quickly realised that such a task was perfectly suited to formal verification methods.
Initially, it was thought that the tools which had been used to verify security protocols would work, but a number of subtle differences meant that this was not the case. For starters, there are typically far more interactions involved in a security API attack, and at each step, all
the commands are typically available. In contrast, security protocols follow a very strict series of commands, and it is only the content of each one that an attacker can manipulate.
However, it is the use of operators, such as exclusive-or, by the security modules that causes the biggest problem. Their algebraic properties cause a severe blow-up in the size of the search space to be checked, and until recently, no tools were able to rediscover the known attacks on anything except highly constrained models, unless provided with a significant level of human help and guidance.
It is only now, as genuinely useful tools and practices become available, that the formal verification of security APIs is beginning to mature as a field. This is not a moment too soon, given the increasing prevalence and pervasiveness of devices which provide a security API.
1.1
Thesis Overview
Chapters 2 through 4 introduce the research topic, and provide a background and motivation to our work. Chapters 5 and 6 present the bulk of our work, along with the associated results and conclusions, while chapter 7 contains a general discussion of various points relating to the formal verification of security APIs, based on our experiences. Overall conclusions are given in chapter 8 along with how our work relates to the other research in the field and pointers to future work.
It should be noted that the majority of the groundwork that has been carried out on security API analysis has been done by Ross Anderson, Mike Bond and Joylon Clulow, while members of the Computer Laboratory at the University of Cambridge. As a result, the information presented in the chapters 2 and 3 draws heavily from their published works, especially [7], [14], and [3].
Chapter Breakdown
Chapter 2 introduces security APIs, charts their development, and provides examples of their use today. This serves to provide a proper context for anyone unfamiliar with the field.
Chapter 3 introduces the concept of an API attack, and presents a comprehensive review of the main attacks which have been found on financial APIs — specifically IBM’s Common Cryptographic Architecture (CCA) API, and the API provided by VISA Security Modules. The chapter also includes a brief overview of formal analysis tools and their application to security API analysis, as well as outlining the current state of research in the field.
Chapter 4 gives an overview of IBM’s CCA API — the focus of our research in this thesis. It discusses the main features, how it works, and includes a description of the commands which are of interest.
Chapter 5 presents our experiments to rediscover the main known attacks on IBM’s CCA API, and includes the associated results, analysis and conclusions. This work was designed to demonstrate that the methods and tools used are capable of being used for the purpose of analysing real world security APIs.
Chapter 6 presents our attempts to formally analyse IBM’s recommendations, which were pub-lished in response to one of the attacks discovered by Mike Bond. It contains analyses of the results, and concludes with a series of more specific recommendations, aimed at the design and implementation of the CCA API.
Chapter 7 discusses the differences between security API analysis and conventional security protocol analysis, along with how current tools designed for the latter of the two perform when applied to the former. The discussion is based on our experiences from having carried out the work presented in this thesis, and includes suggestions of methods and techniques which potentially could be used to improve the analysis and verification process.
Chapter 8 contains general observations regarding our work, along with some concluding re-marks. It discusses how our experiments relate to other research, and provides suggested dir-ections for future work.
1.2
Our Contributions
The work undertaken for this thesis provides the following contributions to the field of security API analysis:
• What we believe to be the first application of a model checker to the problem of security API analysis.
• The rediscovery of all known attacks on IBM’s Common Cryptographic Architecture API, having modelled a greater set of commands than in previous instances.
• The discovery of a variant of a known attack, that we believe has not previously been found. Furthermore, we were still able to find the attack when the intruder had to carry out one of the initial steps that is usually assumed to have been done.
• A formal analysis of the recommendations published by IBM (in response to one of the attacks) which show that there may be situations where they do not prevent an attack from being mounted.
• A discussion on the points that should be considered when designing future verification tools used in the analysis of security APIs.
Introduction to Security APIs
Computer systems have long been used to handle and process sensitive information in a manner designed to prevent outside parties from gaining access to it. The most notable method by which this is achieved is through data encryption, where cryptographic keys are used to encrypt and decrypt pieces of data.
Symmetric encryption uses the same key for both these operations, whereas asymmetric encryption uses two keys, each of which is able to decrypt data that has been encrypted using the other one. The latter of these is the basis for public key cryptography, where an organisation or individual is sent data encrypted with their published public key, such that it can only be decrypted using their private key.1 Cryptography succeeds provided that the keys required for decryption are known only to the parties which are meant to have access to the data.
It is often the case, however, that the data has to be manipulated in a secure manner as well. As a result, the system that manipulates the data must be able to accept commands to carry out the desired actions. This suite of commands constitutes the Application Programmer Interface (API) of the system, and typically includes additional commands which are required to set up and modify the system.
A security API is defined as being the set of commands which specify the interactions between a security system and an external entity, with the goal that any sensitive data is not made available outside of the security system itself, and that the data is only manipulated in a precisely controlled manner. The latter of these features is often referred to as the security policy which the system enforces. Any data released by the system will generally be encrypted under one or more secret keys which are loaded into it upon initialisation. Thus, the data is meaningless outside of the system itself, and can only be manipulated by sending it back into the system under the desired API command.
Due to their nature, security APIs are designed under the assumption that any interactions carried out might be with a malicious user whose aim is to obtain the secret data contained
1A fuller description of these methods can be found in any good book on cryptography, e.g. [25].
within the security system.
It should be made clear that the majority of the information presented in this chapter has been sourced from Mike Bond’s PhD thesis [7], with some additional material taken from various papers published by Mike Bond and Ross Anderson.
2.1
History
It is impossible to discuss the development of security APIs without alluding to the systems which implement them, since the API is just the interface that determines how they can be used, and one is of little use without the other. They are designed to collectively protect any sensitive data which the system as a whole uses. The API is intended to avoid any sensitive data being released through a series of commands sent to the device, whereas the hardware aims to ensure that the sensitive data should not be accessible through physical inspection of the system’s components (e.g. by probing the internal memory).
Cryptographic Systems
Modern security APIs have their origins in the cryptographic systems developed for use by the military, and in diplomatic circles, which were designed to prevent people from eaves-dropping on sensitive communications. The creation of these systems was motivated by the fact that the cryptographic functions could only be carried out by dedicated hardware since, at that time, general purpose computers were too slow. The Data Encryption Standard (DES) algorithm [17], used by the majority of early cryptographic systems, was purposely designed to be efficient to implement in hardware.
A set of commands were required for the general purpose computers to interact with the cryptographic systems, and these would typically include ones to encrypt and decrypt data, as well as ones to set the encrypting and decrypting keys. These commands constituted the APIs of the systems, although since they did not enforce any policy on usage, they could not really be considered security APIs.
As the cryptographic devices became smaller, and the risk of them falling into the hands of hostile outsiders grew, measures had to be taken to ensure that the secrecy of the cryptographic keys was maintained. Initially, these took the form of small explosive charges that would destroy the hardware, and thus the sensitive data, if the casing was opened. While rather crude, this formed the basis for modern tamper-resistance mechanisms which typically erase all internal data in a matter of nano-seconds if any form of tampering is detected.
However, it soon became apparent that the keys had to be protected from corrupt insiders as well. Such people would generally have daily access to the systems and could manipulate
them in whatever way their API allowed. This lead to the introduction of access levels which would provide different users of the systems with different privileges and typically meant that the powerful commands to initialise and retrieve the internal keys were only available under very strict circumstances, or for a very limited period of time. As such, day-to-day users were only able to use a subset of the API commands with which sensitive data was not meant to be recoverable.
These systems form the basis for what are now referred to as key management systems. Typically, they are loaded with a unique master key during initialisation and any additional keys are encrypted under this master key. External data can then be encrypted or decrypted using the different keys as prescribed by the API.
ATM User Verification
Automated Teller Machine (ATM) networks were responsible for bringing cryptography and security into the commercial domain, and are currently still the biggest application area for stand-alone devices implementing security APIs.
In the 1970s, IBM developed a system for authenticating users to an ATM. A secret DES key, known as a pin derivation key (PDK), was used to calculate the customer’s PIN from their primary account number (PAN). The PAN would be encrypted by the PDK with the result converted into a four digit number. Initially, these PDKs were stored in the banks’ mainframes but it was soon realised that they were vulnerable to discovery by some of their own employees. The banks decided to logically isolate the code that implemented the PIN processing and management commands (i.e. the parts that required use of the PDK). The isolated code required a way to allow other software routines to interact with it, and thus were born the security APIs that would form the basis for those used in modern ATM networks.
However, the PIN derivation keys were still accessible to the maintenance staff who had full access to all parts of the bank mainframes. This prompted the development of Hard-ware Security Modules (HSMs), otherwise known as cryptoprocessors, which were separate tamper-resistant devices that contained all the PIN processing and management code. The only interaction that bank staff had with these HSMs was at initialisation time, when the (encrypted) PDK was being loaded.
By isolating the sections of code which were responsible for PIN processing and manage-ment, the HSMs were able to be placed inside the ATMs themselves, reducing the load on the banks’ mainframes and also allowing the ATMs to be located in areas with no network access. The mid 1980s saw the launch of the Visa Security Module (VSM), which was a simple cryptographic device designed to protect PINs in transit over ATM networks. It allowed the customers of one bank to withdraw cash from an ATM belonging to another bank, provided that both were connected to Visa’s network. Their network was link-based with VSMs at each node
securing the communications along the links. To prevent one bank from gaining access to the PINs of another bank’s customers, interbank keys were introduced. These keys are generated by the banks’ central security modules and are typically transferred to ATM HSMs in multiple encrypted parts, which means that a customer’s PIN should only be available to their own bank’s security modules.
Internal Value Counters
Although ATMs are now able to provide a wide range of services including direct funds transfer and PIN modification, the HSMs are still only key management systems that carry out a limited number of functions. Typically, they only contain a cryptographic master key which is used to perform internal decryption of data during the process of PIN verification, as well as allowing for other keys to be stored outside the HSM, encrypted under this master key.
Increasingly however, security APIs are being used by devices that provide services for a specific period, with a secure internal counter that determines how much of the period remains. Such vending devices are generally ones which would previously have been coin operated and now use tokens such as magnetic cards or smart cards, e.g. prepayment electricity meters. Similar counters are also present in the machines which provide the tokens, where they are used to limit the total value of the tokens sold before the machine has to be reset — generally upon payment by the machine operator.
Modern Security Systems
Systems which only provide their main functions under certain conditions can be considered to have an internal state that determines when specific operations are permitted, and are thus generalisations of key management systems, which always allow the use of their keys for en-cryption and deen-cryption purposes. As a result, the security API has to ensure that not only are the cryptographic keys kept secure, but the internal state is too. Note that, in both cases, the availability of any operations may be further restricted by the security API’s usage policy.
A modern security API may therefore have to enforce any number of possible constraints on the use of the commands that it provides, as well as on the manipulation of the data that it has been designed to protect.
2.2
Selected Applications
Security APIs, and the HSMs which implement them, are primarily used to distribute access rights and controls, as well as metering and billing facilities to the devices that utilise them. This is done for a variety or reasons including reducing the load on a particular (secure) pro-cessor or server that would normally carry out these services, and in situations when the
net-work connection to such a system may be temporarily unavailable, or non-existent. What follows is an overview of the most common application areas in which they are found today.
ATM and EPOS Networks
The security APIs used in Automated Teller Machine (ATM) and Electronic Point of Sale (EPOS) networks provide distributed access rights and controls. They facilitate access by a customer to their bank account from a remote location in order to carry out a specific operation (usually a withdrawal), so long as they are able to provide the correct PIN.
The main function of these security APIs is to protect the customer’s PIN, which translates into ensuring that it is never available in an unencrypted form outside of the security modules belonging to the customer’s bank.
When the PIN is initially entered into an ATM or EPOS terminal, it is encrypted under the interbank key for the customer’s bank — the keypad is typically integrated into a HSM that securely communicates with a second HSM containing the interbank keys. The encrypted PIN is then transferred through the network to the central security module of the customer’s bank which decrypts the PIN and carries out the verification.
The PDK required to verify the PIN should only be known to the bank’s own security modules, as should the key which obtains the PIN from its encrypted form. Therefore, the goal of the security APIs used in ATM and EPOS networks is to protect these keys from discovery.
Electronic Vending Machines
These systems provide services when presented with a smart card, magnetic card, or similar input token. The tokens will usually contain a set of encrypted instructions for the machine to execute, and will be provided by a separate vending machine (if the instructions were not en-crypted, then it would be relatively straightforward to create arbitrary input tokens). Together, their security APIs provide distributed metering and billing services, as the tokens are available upon payment of a fee, and the services are provided for a specific period as determined by the instructions on the token.
The most common example of such a system is that of prepayment electricity meters, which are primarily used to provide electricity to people in temporary accommodation (e.g. students in halls of residence), people in third world countries, or to poorer people in rich countries.
In the case of the prepayment electricity meter, a specific quantity of electricity will be supplied upon receipt of an encrypted instruction from an input token. The security API used by the meter’s HSM is designed to protect the counter which determines how much electricity remains to be supplied, as well as the key used to decrypt the instructions on the input token.
The machine which distributes the input tokens also has a value counter, but it is used to limit the value of the tokens that it can sell before requiring to be reset. This safeguard is
designed to ensure regular payment by the machine operator, and also to limit the loss from stolen or misused machines. In order to be able to generate the encrypted instructions, the token vending machine contains the secret keys of all the meters in its area. Its security API is therefore intended to protect these keys, as well as its internal value counter.
Note that the token vending machines require an encrypted message to reset them, and thus will also have an internal key that must be protected by its security API. The machine which generates such instructions will typically be owned by the power company and be responsible for all token vending machines in a given region.
Online Security and Authentication
Online security is a prerequisite for a number of important web services including Internet banking and virtual private networks, as well as being crucial for arbitrary secure communic-ations. This is primarily achieved by using the Secure Sockets Layer (SSL) protocol, which employs public key cryptography to prevent others from eavesdropping on the communica-tions. In order to transmit data to some web server in a secure manner, it is first encrypted under the server’s public key. The security comes from the fact that only the web server itself has the necessary private key to decrypt the data.
Certification and authentication methods, such as digital signatures, are implemented in a similar fashion. A document or piece of data is ‘signed’ by encrypting it with the private key of the issuing organisation, and only their public key can decrypt it — thus proving that the document or data is genuine.
In the same way that the PDKs used by banks to generate and verify customer PINs are pro-tected by HSMs to prevent employees with access to the mainframes from discovering them, companies and certification authorities use HSMs to protect their private keys from discov-ery by their staff and hackers alike. As a result, security APIs used for online security and authentication are designed to protect and control the use of the private keys.
Payment-Based TV Services
Television broadcasts which require payment to watch are encrypted before transmission, and can only be viewed using a set-top box that contains the appropriate decryption key. The decryption key is transmitted along with the program, but is encrypted under another key. This allows the broadcaster to change the decryption key periodically (usually every few minutes), so that compromised keys are only effective for a short amount of time.
Typically, the key required to obtain the decryption key is also changed on a regular, yet less frequent, basis and is also transmitted in an encrypted form along with the programs. Therefore, a compromised second key will only work for a certain amount of time too.
The key required to decrypt the second key is pre-loaded onto the card used with the set-top box, and is unique to that card. It is generally an RSA private key, with the corresponding public key known by the broadcaster. Therefore, the second key transmitted with the programs can be encrypted under the public keys of just those cards which are permitted to decrypt them. The security API provided by the card has to prevent any of the secret keys from being extracted, and therefore allow any programs to be decrypted. In doing so, the API provides access rights to the customer, in a manner that can be controlled by the broadcaster.
2.3
Summary
We have seen the reason why data encryption is necessary, and outlined how a system can provide functions to securely operate on sensitive data in a precisely controlled manner. The development of modern security APIs has been charted, with descriptions of the main points which have driven their evolution. Current application areas of security systems have been presented, showing just how pervasive these products have become, and how important it is that they operate as intended.
Literature Review
The concept of a security API attack was introduced by Ross Anderson in a talk given at the Cambridge Security Protocols workshop in 2000 [2]. He described an attack that he had originally presented in [4], which was caused by the inclusion of a specific transaction into a security API. The attack itself (see section 3.1 for details) involved only the one transaction, but Anderson asked: “So how can you be sure that there isn’t some chain of 17 transactions which will leak a clear key?”.
Over the next few years, Anderson and Mike Bond — a PhD student working with Ander-son at Cambridge University — discovered a number of attacks on the two main security APIs used in the financial sector: IBM’s Common Cryptographic Architecture (CCA) API and the API used by VISA Security Modules (VSMs) and compatible devices.
The attacks, presented together in Bond’s PhD thesis [7], were all found through detailed manual analysis of the API commands, although attempts were made to re-discover them using the theorem prover SPASS[29] and a custom built tool.
The publication of Bond’s thesis served to define the field of security API analysis and bring it to the attention of researchers in the formal verification community. However, due to the inherent complexity of security APIs, the tools available at the time were not well suited to the task, and initial attempts to rediscover the attacks often relied on vastly simplified models of the APIs, or on the provision of guidance in the search process.
One of the major reasons why verification tools were unable to deal with the models was that the aforementioned APIs make heavy use of the exclusive-or function — the algebraic properties of which result in a massive blow-up of the search space if not properly handled. As such, there was a great incentive to develop special purpose tools able to deal with the algebraic properties of functions like exclusive-or. Only very recently have such tools been developed, and researchers begun to not only re-discover existing attacks having modelled APIs in their entirety, but look for new attacks as well.
As this field of research is very new, there are only a small number of researchers that have made significant contributions, and a limited amount of relevant publications available. As a result, Mike Bond’s PhD thesis [7] is once again a major influence on the content of this chapter, although Jolyon Clulow’s MSc thesis [14], Paul Youn’s MSc thesis [30], and a number of papers by Ross Anderson are also significant sources.
3.1
Pure API Command Attacks
The attack which Anderson originally presented in [4] resulted from a temporary transaction being added to the API of a security module, and not being removed. While known to be dangerous, the transaction in question was intended to allow a particular bank to restructure all of its customers’ primary account numbers (PANs) without it affecting their PINs. Recall that a customer’s PIN is calculated from their PAN by encrypting it with a PIN derivation key (PDK) and converting the result into a four digit number. Normally, if a customer wants a different PIN, the bank stores in its database the difference (termed the offset) between their desired PIN and the one given by the PDK.
The transaction which was added to the security module API returned the new offset given a customer’s old PAN, their new PAN, and the current offset value:1
GENERATENEWOFFSET
Host→HSM:old PAN,new PAN,offset
HSM→Host:new offset
A warning was issued by the programmers that this transaction was dangerous and should be removed from the API as soon as the batch conversion of the offsets was completed. However, the transaction was never removed, leaving the door open for an attacker as follows: by using his own PAN as the new PAN, the target customer’s PAN as the old PANand their offset as
theoffset, the command would return the difference between the attacker’s original PIN and
the target customer’s current PIN. Most people do not change their PIN, so it may not even be necessary for the attacker to know their offset.
XOR to Null Key Attack on VSM Compatibles
Not long after his talk at the Cambridge Security Protocols workshop, Anderson took a second look at the API of the VISA Security Module (VSM), and identified an attack, which Bond calls the ‘XOR to Null Key Attack’ in his PhD thesis [7].
VSMs were designed to provide secure communications across the ATM network, so as to allow sensitive information such as PDKs to be transferred between banks and their ATMs.
When a new ATM is added to the network, it needs to have a terminal master key securely generated and loaded into its HSM. This process is carried out by the VSM that it will be communicating with:
GENERATEKEYPART GENERATEKEYPART
HSM→Printer:KP1 HSM→Printer:KP2
HSM→Host :{|KP1|}
KM HSM→Host :{|KP2|}KM
In order to eliminate the possibility of a single corrupt insider obtaining the terminal key, it is generated in two parts, each of which is meant to be entered into the new ATM by a separate service engineer. The ATM then combines the two parts using the exclusive-or (XOR) function to obtain the secret key. Once the ATM and the VSM have the same key, all the other keys can be securely transferred.
The VSM has very limited internal storage, but may have to communicate with a large number of different ATMs, and thus keep a large number of keys. Therefore, instead of keeping the ATM keys internally, they are encrypted under the VSM’s master key and stored on an attached host computer. The attack stems from the fact that the generated key parts for a new ATM are also stored outside of the VSM, albeit encrypted under its master key.
Since the VSM generates the key in two parts, it does not know the value of the overall key, and it too must combine the generated key parts to obtain the terminal key:
COMBINEKEYPARTS Host→HSM:{|KP1|}
KM,{|KP2|}KM HSM→Host:{|KP1⊕KP2|}
KM
Anderson realised that if the same key part was fed in twice, then the terminal key in the VSM will consist of all zeroes, because anything XOR-ed with itself is zero. The terminal key is used to encrypt the other keys that are to be transferred to the new ATM — including the PIN derivation key. Since the key is known, the encrypted keys can easily be decrypted, and thus the PDK can be obtained.
The commands required to generate and combine the key parts are privileged transactions that can only be carried out when the supervisor key switch of the VSM is turned on. Before this attack was discovered, however, the command to combine the key parts was not a privileged transaction, and could be carried out by anyone with access to the VSM. The security of this fix relies on the assumption that the supervisor is a trusted individual who will not abuse the power that their position affords them.
Type System Attack on VSM Compatibles
While working with Anderson towards the end of 2000, Mike Bond discovered another attack on the VSM [6]. The key types are determined by which master key they are encrypted under,
yet terminal master keys and PIN derivation keys were encrypted under the same master key. Rather than a typing system as such, the different master keys were actually being used to differentiate various levels of importance on the different keys. The attack arises because a command will accept any key encrypted under the appropriate master key, e.g. commands expecting a terminal master key would quite happily accept a PIN derivation key in its place.
Terminal communication keys (TCKs) were encrypted under a separate master key, al-though they were entered in the clear rather than being generated automatically. Furthermore, they also had to be able to be encrypted for a particular ATM under its terminal master key:
ENCRYPTCLEARTCK ENCRYPTTCKFORATM
Host→HSM:TCK Host→HSM:{|TCK|}KM2,{|TMK|}KM1 HSM→Host:{|TCK|}KM2 HSM→Host:{|TCK|}TMK
Bond realised that these transactions could be used together to obtain the PIN for any primary account number:
1. ENCRYPTPANASTCK 2. ENCRYPTPANUSINGPDK
Host→HSM:PAN Host→HSM:{|PAN|}KM2,{|PDK|}KM1 HSM→Host:{|PAN|}KM2 HSM→Host:{|PAN|}PDK
By entering the PAN as a clear TCK, and then encrypting it for an ATM using the PIN deriv-ation key instead of the terminal master key, the result would be the PAN encrypted under the PDK, i.e. the PIN.
Key Import Type Casting Attack on IBM’s 4758 CCA
Bond also studied the Common Cryptographic Architecture (CCA) API for IBM’s 4758 HSM, and identified yet another attack.2 In the appendix of the CCA manual [11], a description is given of a ‘feature’ which allows the type of a key being imported to be altered. It was included to allow interoperability with earlier HSMs that use a less diverse key type system, but also results in a fairly straight-forward attack. For example, it can be used to import a PDK as a data key, thus allowing the attacker to use the Encipher command with an arbitrary PAN to obtain the associated PIN.
The key import command takes the key to be imported, which is encrypted under an import-type key encryption key (KEK), along with the encrypted version of the KEK and the import-type of the key being imported:
KEYIMPORT
Host→HSM:{|KEY|}KEK⊕TYPE,TYPE,{|KEK|}KM⊕IMP HSM→Host:{|KEY|}KM⊕TYPE
In order for the attacker to change the type of a key being imported, there must be a known difference (of origType⊕newType) between the KEK used to encrypt the key being imported, and the KEK given as the third parameter in the Key Import command. This can be achieved either through key conjuring (see pg. 22), or by manipulating a key part when the KEK is loaded into the HSM, as follows.
A KEK is transferred to an HSM in more than one part, since collusion between a number of individuals is less likely than the existence of a single corrupt insider. However, as is shown below, this attack does not require the holders of all key parts to work together. For the purposes of this example, we assume that there are only two key parts, although it should be noted that this attack would work for any number, provided that only the one is modified.
The key parts are loaded into the HSM using the following two commands:
‘FIRST’ KEYPARTIMPORT ‘LAST’ KEYPARTIMPORT
Host→HSM:KP1,TYPE Host→HSM:{|KP1|}KM⊕KP⊕TYPE,KP2,TYPE HSM→Host:{|KP1|}KM⊕KP⊕TYPE HSM→Host:{|KP1⊕KP2|}KM⊕TYPE
TheKPcontrol vector indicates that the key is only partially complete. If the attacker XORs his key part with the type of the key being imported, and the type that he wishes it to be changed to, then imports it, the overall KEK will have the required difference.
Given a modified import-type KEK, the attacker can then use the Key Import command to change the type of the target key. For example, if the attacker had access to an encrypted PDK, and had obtained the appropriately modified KEK, then he could change the type of the PDK fromPINtoDATA, and then use it to encrypt arbitrary data (i.e. encrypt PANs to get the associated PINs):
CHANGETYPE OFPDK
Host→HSM:{|PDK|}KEK⊕PIN,DATA,{|KEK⊕DATA⊕PIN|}KM⊕IMP HSM→Host:{|PDK|}KM⊕DATA
The attack works because of the way in which the HSM processes the different parameters to the Key Import command. Initially, the third packet is decrypted to obtain the (tampered) KEK, which is subsequently XOR-ed with the provided control vector,DATA. Due to the cancellation properties of XOR, this results in KEK⊕PIN, which can then be used to correctly decrypt the PDK. Finally, the PDK is output as a key of the given type (i.e.DATA).
3.2
Brute Force Attacks
So far, the attacks presented have all directly exploited weaknesses in the design of API com-mands, and have not required any more general cryptanalysis techniques. This section outlines some of the more brute force attacks that have been found, and the methods required to carry them out.
Parallel Key Search
While investigating the VSM and CCA APIs, Bond discovered that both had functions to gen-erate test encryptions for arbitrary keys — these returned a fixed string (usually binary zeroes) encrypted under the given key:
GENERATETESTENCRYPTION(VSM API) Host→HSM:{|KEY|}
KM
HSM→Host:{|0000 0000 0000 0000|} KEY
The designers were aware that test encryptions could be used to find a key — by generating every possible key, running the test, and comparing the output to that of a secret key — but this was deemed unfeasible for 56-bit DES keys. However, another feature of the two security modules reduces this search space dramatically: all the encrypted keys, with the exception of the master keys, are stored on an external host.
Since there are no real memory restrictions, an attacker is able to generate a large number of keys of a particular type, then run the test encryption command for each one, storing the result. According to Bond, it would take anywhere from five minutes to one hour to generate and test 216 keys. With test encryption results for 216 keys, an attacker would only have to generate and check roughly 240 trial keys in order to find one that matched, requiring only a few days on a home PC.
Once the attacker has found a key used by the HSM, they are able to gain access to any data encrypted with it. In order to obtain a PDK, the attacker could generate a large number of terminal master keys, find the value of one of them, export the PDK under the known terminal key, and then decrypt it at home.
Key Conjuring
Key conjuring is a very simple idea that involves choosing a random value and submitting it as an encrypted key in a command. The goal is just to obtain a key that the security module will accept as valid. For a single DES key, when the security module tries to decrypt it, there is a 1 in 28 chance of the result having the correct parity, and being accepted. For double length
keys, such as key encryption keys, the chances are 216.
Once a valid key has been found, it will have a known relationship to the key returned by the command being used, and thus can usually be exploited to effect an attack.
Import / Export Loop Attack on IBM’s 4758 CCA
This attack, originally presented by Bond in [6], builds on his Key Import Attack and can be carried out by someone who does not have access to an initial key part. Instead of requiring
an encrypted key that is to be imported into the HSM, this attack first exports the required key, before changing its type when importing it again. The first step is to generate a pair of related keys withimp⊕expas the known difference (KEK1andKEK2below). This can be achieved by tampering with a key part during importation, or by conjuring a key part and modifying it using the ‘last’ Key Part Import command.
The next step is to conjure an import-type key encryption key,KEKC, as a key part by using the Key Import command withKEK1, before using the same command withKEK2to change its type:3
1. USEKEYIMPORT WITHKEK1
Host→HSM:{|KEKC|}KEK1⊕IMP⊕KP,IMP⊕KP,{|KEK1|}KM⊕IMP HSM→Host:{|KEKC|}KM⊕IMP⊕KP
2. USEKEYIMPORT WITHKEK2
Host→HSM:{|KEKC|}KEK1⊕IMP⊕KP,EXP⊕KP,{|KEK2|}KM⊕IMP HSM→Host:{|KEKC|}KM⊕EXP⊕KP
The ‘last’ Key Part Import command can then be used to complete the resulting key, and it can then be used to export any of the keys in the HSM that have export permissions. In order to re-import a key and change its type, the originalKEKCkey part has to be XOR-ed with the key’s original type and the desired type, and can be carried out as follows:
USE‘LAST’ KEYPARTIMPORTCOMMAND
Host→HSM:oldType⊕newType,{|KEKC|}KM⊕IMP,IMP⊕KP HSM→Host:{|KEKC⊕oldType⊕newType|}KM⊕IMP
Any number of modifiedKEKCkeys can be used to change the type of any exported key. The most obvious use of this attack is to change the PIN derivation key to a data key.
Data Control Vector Exploit Attack on IBM’s 4758 CCA
When Bond’s Key Import/Export Loop attack was brought to the attention of IBM engineers, they discovered a similar attack during the course of their investigations that is also simpler. By exploiting the fact that the data control vector is actually a string of binary zeroes, an attacker is able to discover the value of a conjured export-type key encryption key, and thus decipher any key exported under it. The attack is presented in section 2.7.2 of Clulow’s MSc [14], and proceeds as follows.
The attacker first conjures a pair of import key encryption keys with the known difference ofDATA⊕EXP, in the same way as for Bond’s Key Import/Export Loop Attack. The Key Import
3These two steps are impossible in practice, as the Key Import command will not accept key parts. However,
this impossibility is not documented in the CCA manual, “for security reasons”, and only came to light in 2003, when Youn presented a series of potential new attacks to IBM (see [30, Section 4.1])
command is then used to conjure two forms of an unknown export KEK — one encrypted under the local master key, and the other encrypted under one of the conjured import KEKs.4 This gives the attacker the following four keys:
{|UKEK1|}KM⊕IMP {|UKEK2|}KM⊕EXP {|UKEK1⊕DATA⊕EXP|}KM⊕IMP {|UKEK2|}UKEK1⊕EXP
The attacker then changesUKEK2to a data key upon import, before exporting with the export-type version of itself:
1. CHANGETYPE OFUKEK2UPONIMPORT
Host→HSM:{|UKEK2|}UKEK1⊕EXP,DATA,{|UKEK1⊕DATA⊕EXP|}KM⊕IMP HSM→Host:{|UKEK2|}KM⊕DATA
2. EXPORTUKEK2 UNDERITSELF
Host→HSM:{|UKEK2|}KM⊕DATA,DATA,{|UKEK2|}KM⊕EXP HSM→Host:{|UKEK2|}UKEK2⊕DATA
Since theDATAcontrol vector is a string of binary zeroes, this is equivalent to{|UKEK2|}UKEK2. The attacker hasUKEK2as a data key, and is therefore able to decrypt{|UKEK2|}UKEK2to obtain the clear value ofUKEK2. He can then decrypt any key exported under{|UKEK2|}KM⊕EXP, e.g. the PIN derivation key.
3DES Key Binding Attack on IBM’s 4758 CCA
Triple DES (3DES) is an extension of single DES that uses a double length 112-bit key, where data is encrypted in the following manner. The data is first encrypted using the left half of the 3DES key, then decrypted using the right half, before finally being encrypted again with the left half. This has the intentional property that if both halves of the key are the same, then the encryption is equivalent to single DES.
The aim of 3DES is to make it essentially impossible to find a key by brute force search alone — searching the entire 2112key space is not currently feasible — but Bond showed in [6] that implementation issues in the 4758 CCA allow 3DES keys to be cracked in roughly the same time as a single DES key. Although a distinction is made between the separate halves of a 3DES key, the two are not associated with each other in any way. As such, it is possible to use the parallel key search method to discover each half of a 3DES key.
The simplest method is to generate a large number of replicate 3DES keys (these are keys with identical halves) of the desired type and then use the parallel key search method to find the value of two of them — roughly a 241 search if 216 keys are generated. Each half of the
discovered keys can be used to create a known full 3DES key which can then be used to export other keys from the HSM.
In the case where the attacker is not able to generate replicate 3DES keys, he must generate single DES keys and find the value of one using the parallel key search method. Once the attacker has a known single DES key, it can be re-imported as a left half of a 3DES key using the key import attack. The next step is to generate 2163DES keys, swapping the known left
half into all of them, and encrypting the test vector with each one. As before, a 240parallel key
search should find one of the 3DES keys.
If it is not possible to encrypt test vectors for the desired key type (as is the case with key encryption keys), the attacker must first find a key whose type does allow this. Once he has this key, it can be used as a test vector for the desired key type, using the key export command to do the encryption.
This attack is even able to extract keys which do not have export permissions. By using a known 3DES key, two new versions of the target key can be made — one with the left half swapped for the left half of the known key, and one with the right half swapped for the right half of the known key. Although this leaves a 256search to find both new keys (and thus the target key), such an attack may be available to individuals or organisations with sufficient resources.
A discussion of how this attack can be carried out is given in Section 7.3.7 of [7].
3.3
Information Leakage Attacks
Not all attacks which have been found rely on obtaining all the desired information at once from the security module. More recently, attacks have been found in which an API command only provides a ‘hint’ about the sensitive data, but repeated calls of the command with differing parameters results in enough hints for the attacker to work out the desired information.
Decimalisation Table Attack
When a customer’s primary account number is encrypted with a PIN derivation key, the result is usually a 64-bit binary block. In order to obtain the four digit PIN, the first four hexadecimal digits of the block (i.e. the first 16 binary bits) are taken then converted into decimal using a decimalisation table. Table 3.1 shows an example of this process, taken from [7].
For one reason or another, the decimalisation table is not hard-wired into the security mod-ules, but is instead passed in (unencrypted) as a parameter. By modifying the decimalisation table and entering a trial PIN, it is possible to obtain a considerable amount of information, rather than simply that the PIN is wrong. For example, if the attacker enters0000as the trial PIN, and000000100000000as the decimalisation table (i.e. all zeroes with a 1 in the 7 posi-tion), then the correct PIN does not contain a 7 if the verification succeeds. Therefore, a large
ACCOUNTNUMBER 4556 2385 7753 2239 ENCRYPTEDA/C NO. 3F7C 2201 00CA 8AB3
TRUNCATEDVALUE 3F7C
DECIMALISATIONTABLE 0123456789ABCDEF 0123456789012345
DECIMALISEDPIN 3572
Table 3.1: Example of the PIN derivation process, taken from [7].
number of possible PINs have been eliminated.
However, it is rarely the case that an attacker is able to enter a clear PIN as a guess, but rather has to enter an encrypted PIN block. The PIN block can have a number of formats, but will usually contain the PIN and the primary account number. If the attacker is only given access to the encrypted block for a specific account, the attack can still be carried out by manipulating the offset, rather than the PIN itself.
This attack was discovered independently by Bond and Clulow, and is presented in [7] and [14] respectively.5 Bond also presents an optimised version of his algorithm, due to Zielinski and originally given in [10], which is able to obtain a PIN with an average of 15 guesses.
3.4
Formal Analysis Methods
All of the attacks presented so far were originally discovered by hand, through detailed analysis of the commands in the security APIs. However, this is far from ideal, since it is a laborious task which cannot be known to be complete. Once it was realised that a number of attacks existed, the obvious next step was to use formal methods to check the APIs.
There are two main types of verification tool — theorem provers and model checkers. At the lowest level, they both perform some form of search, but differ in the way that systems are modelled and analysed.
Theorem Provers
Originally developed to find proofs of mathematical theorems, theorem provers can be applied to any situation which can be expressed as a logical theory. A logical theory com-prises a number of axioms (facts and rules) which are used in the derivation of other facts. The most common representation used is first-order logic, as it is generally considered to be of sufficient expressive power, and automatic procedures for applying inference
rules and determining the truth of statements are well understood. [18] provides a full introduction to both first-order logic and automated theorem proving.
The goal of a theorem prover is to show whether or not a particular fact or rule is true, given the initial axioms. First-order logic has the property that any valid theorem can, given adequate resources, be shown to hold, although it is not guaranteed that a particular invalid theorem can be shown to not hold. However, it is often the case that a theorem prover requires a certain level of human guidance in order to find a proof.
In the context of security API analysis, the theory will capture the set of API comands, along with the intruder’s initial knowledge and his own abilities to produce new terms. The aim is then to prove that the intruder is able to obtain information which should remain secret, with the resulting proof corresponding to an attack trace. If no proof exists, then the intruder is not able to obtain the secret information.
Model Checkers
Designed to verify properties of discrete state systems, model checkers are most often used to verify properties of hardware designs, although tools do exist which are aimed at software verification (e.g. SPIN [22]). The models are typically given as state transition systems, with properties expressed in a temporal logic, such as linear temporal logic (LTL), or computation tree logic (CTL). [13] gives a comprehensive introduction to the field of model checking, although it was published too early for bounded model checking [5] to be included.
Early model checkers worked by building a finite state machine (FSM) from the state transition system, and determining whether any of the states violating the property to be verified could be reached from an initial state. However, this approach suffers from what is commonly referred to as the state explosion problem [27] since the number of possible states is generally exponential in the number of state variables and processes in the model. As such, modern model checkers, such as NUSMV [12], represent the FSM and any properties symbolically as a propositional logic formula and use binary decision diagrams or SAT solvers to carry out the verification. A counter-example is returned in the case that a particular property does not hold. Bounded model checking places an upper bound on the length of the counter-examples searched for.
With respect to the problem of security API analysis, the intruder is typically the system being modelled, as it is his knowledge which changes over time. The API commands are given by transitions that capture how the intruder’s knowledge changes when they are called, and the intruder’s initial knowledge is used to define the initial state. If any of the security properties are violated, the model checker will return a counter-example (attack trace) showing why it does not hold.
Using these kinds of verification tools, researchers initially tried to rediscover some of the attacks which had previously been found. Unfortunately, this was not as straight-forward as some had hoped, since the algebraic properties of XOR resulted in a massive blow-up of the search space. The way in which the security modules used XOR to combine items of data could not be ignored since a number of the more subtle attacks exploited this directly.
Bond used the theorem prover SPASSin his attempt to rediscover the Key Import Attack
which he had found, and Ganapathy et al. tried to do the same using a custom-built model checker [19]. However, even with only three of the API commands included in the model, SPASS had still not found the attack after days of run time, although the attack was able to be found by providing hints and proving intermediate conjectures. Ganapathy et al. were only able to rediscover the attack by including just two API commands in their model.
The problem stemmed from the fact that the intruder had to be given the capability to XOR known terms together, but the tools did not take into account the algebraic properties of the function (i.e. transitivity, commutativity, associativity and self-inverse). This resulted in infinite branches of the search space with ever-repeating combinations of terms being XOR-ed together.
Because of this limitation, early attempts to rediscover known API attacks involved only a small subset of the commands, or required guidance in the verification process. It was quickly realised that the XOR function had to be handled in an efficient manner in order for security APIs to be formally verified in their entirety.
3.5
Current Research
In the last year or so, a number of researchers have managed to rediscover known attacks on IBM’s CCA API, having modelled all of the key management commands. Graham Steel was one of the first to publish such results [26], having modified daTac [28] — a theorem prover which supports AC unification — to handle constraints specifying equality of terms modulo XOR. These constraints built upon regular equality and captured the fact that XOR-ing anythXOR-ing with itself produces the identity value, anythXOR-ing XOR-ed with the identity value remains unchanged, and that the operator is both associative and commutative.
Steel was able to rediscover Bond’s Key Import Attack, the more complex Import / Export Loop Attack, and the attack discovered by IBM’s engineers.
Since the publication of his PhD thesis, Mike Bond has turned his attention to the rediscovery of the attacks on IBM’s CCA API, working in collaboration with Paul Youn and other researchers at Cambridge University [31]. They used the theorem prover Otter [36], and were also able to successfully rediscover all known attacks on IBM’s CCA API. However, rather than specifying constraints in order to reduce the size of the search space, they restricted the way in which the
intruder can build new terms from existing knowledge, as follows:
• A term which is already encrypted cannot be further encrypted under another term.
• An encrypted term cannot be XOR-ed with any other term.
These restrictions result in a finite bound on the number of terms that the intruder can generate, while still ensuring that no attacks are missed. This latter point has only very recently been proved by Cortier and Steel [15].
After presenting the attacks in his PhD thesis, Bond suggests that because they all exploit the way in which the exclusive-or function is used, it would be prudent to use a non-invertible function instead. However, he stopped short of providing any formal proof that such a change would indeed have the desired effect.
In [16], Judica¨el Courant and Jean-Franc¸ois Monin used the proof assistant Coq [34] to show that using a non-invertible function would indeed prevent the attacks. Although not a fully automated procedure, Coq has the necessary induction capabilities to be able to prove that the required properties always hold.
The main focus of current research in this area is on how security API analysis differs from conventional security protocol analysis. It is already known that, although similar, the two are different enough to make the tools and methods which work for analysing protocols perform significantly worse when applied to the analysis of security APIs. Already though, researchers are turning their attentions to the modification of existing tools with the aim of improving their performance when used to analyse security APIs [20].
3.6
Summary
We have seen what constitutes a security API attack, and how the notion of it came about. In section 3.1 examples of pure API attacks were given, which serve to highlight the ways in which these security lapses can occur — through procedural failures and exploitation of the algebraic properties of the underlying operators used by cryptographic devices. We have also seen, in section 3.2, how API commands can be used in unintended ways to conjure cryptographic keys, as well as ways to reduce the size of the search space when looking for a key. More subtle attacks were presented that make use of these methods, and although longer access to the security module is often required, they are harder to discover. In section 3.3, another class of attacks were also presented, where information is released that provides small ‘hints’ to the attacker about the value of certain sensitive data. These information leakage attacks are very difficult to check for, as it is often hard to know if a command is capable of providing the necessary hints to effect an attack.
Methods of formally verifying security properties were introduced, along with the types of problems that researchers have faced when using them. This led on to the current state of research in this field where the majority of researchers have been investigating how security API analysis differs from conventional protocol analysis, and thus how the formal tools being used can be improved.
Overview of IBM’s CCA API
IBM’s Common Cryptographic Architecture (CCA) API [11] is used by security modules in a significant number of automated teller machines (ATMs) across the world, as well as in the mainframe computers of many banks. The API is provided by IBM’s 4758 Cryptographic Coprocessor1whose main task, in this setting, is to carry out PIN verification requests, although a large percentage of the commands facilitate the transfer of secret cryptographic keys in order to initialise a new device.
At its heart, the CCA is a key management system, which provides commands that use encrypted keys to achieve desired functions. A 168-bit triple-DES key, known as the master key, is stored in the security module’s tamper proof memory and is used to encrypt all other keys which are then kept on the host computer. These other keys, known as working keys, are used to perform the various functions provided by the CCA API, and have types associated with them.
In all, the CCA supports the following functions and features:
• Encryption and decryption of data, using the DES algorithm in cipher block chaining (CBC) mode.
• Message authentication code (MAC) generation, and data hashing functions.
• Formation and validation of digital signatures.
• Generation, encryption, translation and verification of PINs and transaction validation messages.
• General key management facilities.
• Administrative services for controlling the initialisation and operation of the security module.
As a number of the provided commands are particularly sensitive, the CCA enforces an access-control system, whereby certain commands are only available under specific circumstances. It
1http://www-03.ibm.com/security/cryptocards/pcicc/overview.shtml
is, however, the responsibility of the device owner to ensure that the correct separation of duty provided is upheld.
4.1
Working Keys
The CCA API uses four main types for classifying DES working keys, each of which is further sub-divided into more specific and restrictive types. Each type takes the form of a control vector that is the same length as the associated working key. A working key is stored outside of the security module, encrypted under the exclusive-or of the device’s master key and the control vector representing the type of the key. The main key types, and their uses, are as follows:
Data Keys
Keys of this type are used to encipher and decipher arbitrary data, as well as for the generation and verification of Message Authentication Codes (MACs). Subtypes place greater restrictions on exactly which of these various functions a particular key can be used for.
PIN Keys
This type covers keys which are used for PIN block encryption, PIN block decryption, PIN generation and verification, and just PIN verification. A key cannot be of the general PIN type, but instead must be assigned a subtype that restricts its use to exactly one of the four operations mentioned.
Key Encryption Keys
These keys are used to encrypt and decrypt other working keys during transportation between security modules. This type is sub-divided into import and export types — export keys are used to encrypt a working key for transport to another security module, and import keys are used to decrypt it at its destination. Note that the same key encryption key must be present in both security modules — as an export key in one and as an import key in the other.
Key Generation Keys
The CCA API provides commands which generate DES keys, given an initial key. This type covers such initial keys and restricts them from being used with other commands in order to prevent the value of the generated key being discovered.
The typing mechanism restricts the working keys which can be used for a particular command, for example, the PIN derivation key used in the verification of a customer’s PIN cannot be used with the encipher command to encrypt arbitrary data.
4.2
API Commands
This section presents the core key management commands, along with some selected others, and the definitions are designed to capture the important semantics of the commands.2 The fol-lowing terms are used in this section to represent the various control vectors and cryptographic keys:
DATA Control vector for data keys
IMP Control vector for import key encryption keys
EXP Control vector for export key encryption keys
KGN Control vector for key generation keys
KP Control vector indicating that a key is only a key part, and not a complete key
KM The security module’s master key
KEK An arbitrary key encryption key
KEY An arbitrary cryptographic key
TYPE An arbitrary key type control vector
KPi Key part i (used to build an arbitrary key)
X Arbitrary (unencrypted) data
Note that the exact steps that the security module carries out for each command have not been included, since the process is virtually the same in all cases. The master key and all control vectors are known to the security module, and any additional information required is either passed as a plaintext parameter, or is encrypted under a known key. For example, in the case of the Key Import command, the security module knows bothKMandIMPso is therefore able to obtainKEKfrom the third parameter. This key encryption key is then XOR-ed with the second parameter, TYPE, and used to obtainKEY from the first parameter. Finally, KEY is encrypted under the exclusive-or ofKMandTYPEto produce the result that is returned by the command.
Key Import
User→HSM:{|KEY|}KEK⊕TYPE,TYPE,{|KEK|}KM⊕IMP HSM→User:{|KEY|}KM⊕TYPE
Converts a key (of the given type) from encryption under the supplied import-type key encryp-tion key to encrypencryp-tion under the local master key. A variant of this command exists which is more restrictive in that it only allows data keys to be imported. Although not mentioned in the manual, the key being imported must be a complete key (i.e. it cannot be a key part).
Clear Key Import
User→HSM:KEY
HSM→User:{|KEY|}KM⊕DATA
Takes a clear (unencrypted) key value and returns it as a data type working key. This command is normally disabled.
Key Export
User→HSM:{|KEY|}KM⊕TYPE,TYPE,{|KEK|}KM⊕EXP HSM→User:{|KEY|}KEK⊕TYPE
Converts a working key from being encrypted under the local master key, to being encrypted under the supplied export-type key encryption key. A variant of this command exists which is more restrictive in that it only allows data keys to be exported. Note thatKEYmust be able to be exported.
Encipher
User→HSM:X,{|KEY|}KM⊕DATA HSM→User:{|X|}KEY
Encrypts given plaintext with the supplied data key. The data key can either be of the general type, or one of the subtypes that permits data ciphering.
Decipher
User→HSM:{|X|}KEY,{|KEY|}KM⊕DATA
HSM→User:X
Decrypts ciphertext which has been encrypted under the supplied data key. The data key can either be of the general type, or one of the subtypes that permits data deciphering.
Key Part Import
FIRST ADD/ MIDDLE
User→HSM:KP1,TYPE User→HSM:KP2,{|KP1|}KM⊕KP⊕TYPE,TYPE HSM→User:{|KP1|}KM⊕KP⊕TYPE HSM→User:{|KP1⊕KP2|}KM⊕KP⊕TYPE
COMPLETE LAST
User→HSM:{|KEY|}KM⊕KP⊕TYPE,TYPE User→HSM:KP3,{|KP1⊕KP2|}KM⊕KP⊕TYPE,TYPE HSM→User:{|KEY|}KM⊕TYPE HSM→User:{|KP1⊕KP2⊕KP3|}KM⊕TYPE
