Model Checking Security APIs

Transcription

1 Model Checking Security APIs Gavin Keighren E H U N I V E R S I T Y T O H F G R E D I N B U Master of Science Artificial Intelligence School of Informatics University of Edinburgh 2006

2 Abstract Devices 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.

3 Acknowledgements 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.

4 Declaration 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. (Gavin Keighren)

5 Table of Contents List of Tables 6 1 Introduction Thesis Overview Our Contributions Introduction to Security APIs History Selected Applications Summary Literature Review Pure API Command Attacks Brute Force Attacks Information Leakage Attacks Formal Analysis Methods Current Research Summary Overview of IBM s CCA API Working Keys API Commands Access Controls Summary Rediscovery of Known Attacks Tools Used Modelling the API Modelling the Attacks Results

6 5.5 Summary Verification of IBM Recommendations Recommendation Recommendation Recommendation Overall Conclusions Summary Discussion Differences Between Security APIs and Security Protocols Modelling Security APIs Model Checking Tools Intruder Capabilities Summary Conclusions Related Work Future Directions A Command Notation 73 B HLPSL Model of IBM s CCA API 74 Bibliography 80

7 List of Tables 5.1 Results for the Rediscovery of Bond s Key Import Attack Results for the Rediscovery of the First Variant of Bond s Import / Export Loop Attack Results for the Rediscovery of the Second Variant of Bond s Import / Export Loop Attack Results for the Rediscovery of the First Variant of the IBM Attack Results for the Rediscovery of the Second Variant of the IBM Attack Results for the Verification of IBM s First Recommendation Results for the Verification of IBM s Second Recommendation Results for the Verification of IBM s Third Recommendation

8 Chapter 1 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 intended 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 component 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 7

9 Chapter 1. Introduction 8 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.

10 Chapter 1. Introduction 9 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 published 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 remarks. It discusses how our experiments relate to other research, and provides suggested directions 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.

11 Chapter 2 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 1 A fuller description of these methods can be found in any good book on cryptography, e.g. [25]. 10

12 Chapter 2. Introduction to Security APIs 11 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 eavesdropping 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

13 Chapter 2. Introduction to Security APIs 12 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 Hardware 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 management, 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

14 Chapter 2. Introduction to Security APIs 13 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 encryption and decryption 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) processor or server that would normally carry out these services, and in situations when the net-

15 Chapter 2. Introduction to Security APIs 14 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 encrypted, 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

16 Chapter 2. Introduction to Security APIs 15 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 communications. This is primarily achieved by using the Secure Sockets Layer (SSL) protocol, which employs public key cryptography to prevent others from eavesdropping on the communications. 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 protected 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 discovery 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.

17 Chapter 2. Introduction to Security APIs 16 The key required to decrypt the second key is pre-loaded onto the card used with the settop 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.

18 Chapter 3 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 Anderson 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. 17

19 Chapter 3. Literature Review 18 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 GENERATE NEW OFFSET 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 PAN and their offset as the offset, 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. 1 See Appendix A for an overview of the notation used to describe command semantics.

20 Chapter 3. Literature Review 19 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: GENERATE KEY PART HSM Printer : KP1 GENERATE KEY PART 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: COMBINE KEY PARTS 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,

21 Chapter 3. Literature Review 20 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, although 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: ENCRYPT CLEAR TCK Host HSM : TCK HSM Host : { TCK } KM2 ENCRYPT TCK FOR ATM Host HSM : { TCK } KM2, { TMK } KM1 HSM Host : { TCK } TMK Bond realised that these transactions could be used together to obtain the PIN for any primary account number: 1. ENCRYPT PAN AS TCK 2. ENCRYPT PAN USING PDK 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 derivation 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 importtype key encryption key (KEK), along with the encrypted version of the KEK and the type of the key being imported: KEY IMPORT Host HSM : { KEY } KEK TYPE, TYPE, { KEK } KM IMP HSM Host : { KEY } KM TYPE 2 See chapter 4 for a full introduction to IBM s CCA API, and a description of all the relevant commands.

22 Chapter 3. Literature Review 21 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 KEY PART IMPORT Host HSM : KP1, TYPE LAST KEY PART IMPORT Host HSM : { KP1 } KM KP TYPE, KP2, TYPE HSM Host : { KP1 } KM KP TYPE HSM Host : { KP1 KP2 } KM TYPE The KP control 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 from PIN to DATA, and then use it to encrypt arbitrary data (i.e. encrypt PANs to get the associated PINs): CHANGE TYPE OF PDK 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 commands, 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.

23 Chapter 3. Literature Review 22 Parallel Key Search While investigating the VSM and CCA APIs, Bond discovered that both had functions to generate test encryptions for arbitrary keys these returned a fixed string (usually binary zeroes) encrypted under the given key: GENERATE TEST ENCRYPTION (VSM API) Host HSM : { KEY } KM HSM Host : { } 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 2 16 keys. With test encryption results for 2 16 keys, an attacker would only have to generate and check roughly 2 40 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 2 8 chance of the result having the correct parity, and being accepted. For double length keys, such as key encryption keys, the chances are 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

24 Chapter 3. Literature Review 23 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 with imp exp as the known difference (KEK1 and KEK2 below). 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 with KEK1, before using the same command with KEK2 to change its type: 3 1. USE KEY IMPORT WITH KEK1 Host HSM : { KEKC } KEK1 IMP KP, IMP KP, { KEK1 } KM IMP HSM Host : { KEKC } KM IMP KP 2. USE KEY IMPORT WITH KEK2 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 original KEKC key 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 KEY PART IMPORT COMMAND Host HSM : oldtype newtype, { KEKC } KM IMP, IMP KP HSM Host : { KEKC oldtype newtype } KM IMP Any number of modified KEKC keys 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 of Clulow s MSc [14], and proceeds as follows. The attacker first conjures a pair of import key encryption keys with the known difference of DATA EXP, in the same way as for Bond s Key Import/Export Loop Attack. The Key Import 3 These 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])

25 Chapter 3. Literature Review 24 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 { UKEK1 DATA EXP } KM IMP { UKEK2 } KM EXP { UKEK2 } UKEK1 EXP The attacker then changes UKEK2 to a data key upon import, before exporting with the exporttype version of itself: 1. CHANGE TYPE OF UKEK2 UPON IMPORT Host HSM : { UKEK2 } UKEK1 EXP, DATA, { UKEK1 DATA EXP } KM IMP HSM Host : { UKEK2 } KM DATA 2. EXPORT UKEK2 UNDER ITSELF Host HSM : { UKEK2 } KM DATA, DATA, { UKEK2 } KM EXP HSM Host : { UKEK2 } UKEK2 DATA Since the DATA control vector is a string of binary zeroes, this is equivalent to { UKEK2 } UKEK2. The attacker has UKEK2 as a data key, and is therefore able to decrypt { UKEK2 } UKEK2 to obtain the clear value of UKEK2. 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 key 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 2 41 search if 2 16 keys are generated. Each half of the 4 The former is returned by the command, when the latter is provided (and accepted) as the random value.