Model Checking Security Apis: Gavin Keighren

Model Checking Security APIs
Gavin Keighren
U
E
NI VER
IT
TH
D I U N B
Master of Science Articial Intelligence School of Informatics University of Edinburgh 2006
O F
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 IBMs 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.
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 eld of formal verication. I am eternally grateful for the opportunity that they gave me. I am sure that my year would have been signicantly 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.
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 qualication except as specied.
(Gavin Keighren)
Table of Contents
List of Tables 1 Introduction 1.1 1.2 2 Thesis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 7 8 9 10
Introduction to Security APIs 2.1 2.2 2.3
History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Selected Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17
Literature Review 3.1 3.2 3.3 3.4 3.5 3.6
Pure API Command Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Brute Force Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Information Leakage Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Formal Analysis Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Current Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 31
Overview of IBMs CCA API 4.1 4.2 4.3 4.4
Working Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 API Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 38
Rediscovery of Known Attacks 5.1 5.2 5.3 5.4
Tools Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Modelling the API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Modelling the Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 6
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 53
Verication of IBM Recommendations 6.1 6.2 6.3 6.4 6.5
Recommendation 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Recommendation 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Recommendation 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Overall Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 65
Discussion 7.1 7.2 7.3 7.4 7.5
Differences Between Security APIs and Security Protocols . . . . . . . . . . . 65 Modelling Security APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Model Checking Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Intruder Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 70
Conclusions 8.1 8.2
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 73 74 80
A Command Notation B HLPSL Model of IBMs CCA API Bibliography
List of Tables
5.1 5.2 5.3 5.4 5.5 6.1 6.2 6.3 Results for the Rediscovery of Bonds Key Import Attack . . . . . . . . . . . . 47 Results for the Rediscovery of the First Variant of Bonds Import / Export Loop Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Results for the Rediscovery of the Second Variant of Bonds Import / Export Loop Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Results for the Rediscovery of the First Variant of the IBM Attack . . . . . . . 50 Results for the Rediscovery of the Second Variant of the IBM Attack . . . . . . 51 Results for the Verication of IBMs First Recommendation . . . . . . . . . . 56 Results for the Verication of IBMs Second Recommendation . . . . . . . . . 59 Results for the Verication of IBMs Third Recommendation . . . . . . . . . . 61
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 identication 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 components 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 aws, security APIs are generally far more complex and signicantly harder to verify. Since 2000, a number of serious aws 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 aws were discovered through detailed hand analysis, but it was quickly realised that such a task was perfectly suited to formal verication 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
Chapter 1. Introduction
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 signicant level of human help and guidance. It is only now, as genuinely useful tools and practices become available, that the formal verication of security APIs is beginning to mature as a eld. 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 verication 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 eld 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 eld. Chapter 3 introduces the concept of an API attack, and presents a comprehensive review of the main attacks which have been found on nancial APIs specically IBMs 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 eld. Chapter 4 gives an overview of IBMs 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 1. Introduction
Chapter 5 presents our experiments to rediscover the main known attacks on IBMs 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 IBMs 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 specic 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 verication 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 eld of security API analysis: What we believe to be the rst application of a model checker to the problem of security API analysis. The rediscovery of all known attacks on IBMs 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 nd 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 verication tools used in the analysis of security APIs.
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 dened 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].
10
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 Bonds 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 systems 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 efcient 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
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 Verication
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 customers 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 Visas network. Their network was link-based with VSMs at each node
13
securing the communications along the links. To prevent one bank from gaining access to the PINs of another banks 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 customers PIN should only be available to their own banks security modules.
Internal Value Counters
Although ATMs are now able to provide a wide range of services including direct funds transfer and PIN modication, 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 verication, 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 specic 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 specic 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 APIs 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-
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 specic 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 customers PIN, which translates into ensuring that it is never available in an unencrypted form outside of the security modules belonging to the customers bank. When the PIN is initially entered into an ATM or EPOS terminal, it is encrypted under the interbank key for the customers 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 customers bank which decrypts the PIN and carries out the verication. The PDK required to verify the PIN should only be known to the banks 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 specic 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 specic quantity of electricity will be supplied upon receipt of an encrypted instruction from an input token. The security API used by the meters 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
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 rst encrypted under the servers public key. The security comes from the fact that only the web server itself has the necessary private key to decrypt the data. Certication 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 certication 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.
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.
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 specic 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 isnt 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 nancial sector: IBMs Common Cryptographic Architecture (CCA) API and the API used by VISA Security Modules (VSMs) and compatible devices. The attacks, presented together in Bonds 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 S PASS [29] and a custom built tool. The publication of Bonds thesis served to dene the eld of security API analysis and bring it to the attention of researchers in the formal verication 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 simplied models of the APIs, or on the provision of guidance in the search process. One of the major reasons why verication 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
Chapter 3. Literature Review
18
As this eld of research is very new, there are only a small number of researchers that have made signicant contributions, and a limited amount of relevant publications available. As a result, Mike Bonds PhD thesis [7] is once again a major inuence on the content of this chapter, although Jolyon Clulows MSc thesis [14], Paul Youns MSc thesis [30], and a number of papers by Ross Anderson are also signicant 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 customers 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 customers old PAN, their new PAN, and the current offset value:1
G ENERATE N EW O FFSET
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 customers PAN as the old PAN and their offset as the offset, the command would return the difference between the attackers original PIN and the target customers 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 identied 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.
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:
G ENERATE K EY PART G ENERATE K EY PART
HSM Printer : KP1 HSM Host :{ |KP1| KM }
HSM Printer : KP2 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 VSMs 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:
C OMBINE K EY PARTS
Host HSM : { |KP1| KM , { } |KP2| KM } HSM Host : { |KP1KP2| 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 x 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,
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:
E NCRYPT C LEAR TCK E NCRYPT TCK FOR ATM
Host HSM : TCK HSM Host : { |TCK| KM2 }
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. E NCRYPT PAN AS TCK 2. E NCRYPT PAN USING PDK
Host HSM : PAN HSM Host : { |PAN| KM2 }
Host HSM : { |PAN| KM2 , { } |PDK| KM1 } 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 IBMs 4758 CCA
Bond also studied the Common Cryptographic Architecture (CCA) API for IBMs 4758 HSM, and identied 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:
K EY I MPORT
Host HSM : { |KEY| KEKTYPE , TYPE , { } |KEK| KMIMP } HSM Host : { |KEY| KMTYPE }
2 See
chapter 4 for a full introduction to IBMs CCA API, and a description of all the relevant commands.
21
In order for the attacker to change the type of a key being imported, there must be a known difference (of origTypenewType) 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 modied. The key parts are loaded into the HSM using the following two commands:
F IRST K EY PART I MPORT L AST K EY PART I MPORT
Host HSM : KP1 , TYPE HSM Host : { |KP1| KMKPTYPE }
Host HSM : { |KP1| KMKPTYPE , KP2 , TYPE } HSM Host : { |KP1KP2| KMTYPE }
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 modied 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 modied 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):
C HANGE T YPE OF PDK
Host HSM : { |PDK| KEKPIN , DATA , { } |KEKDATAPIN| KMIMP } HSM Host : { |PDK| KMDATA } 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 KEKPIN, 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.
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 xed string (usually binary zeroes) encrypted under the given key:
G ENERATE T EST E NCRYPTION (VSM API)
Host HSM : { |KEY| KM } HSM Host : { |0000 0000 0000 0000| KEY } The designers were aware that test encryptions could be used to nd 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 ve 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 nd 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, nd 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 IBMs 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
23
an encrypted key that is to be imported into the HSM, this attack rst exports the required key, before changing its type when importing it again. The rst step is to generate a pair of related keys with impexp 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. U SE K EY I MPORT WITH KEK1
Host HSM : { |KEKC| KEK1IMPKP , IMPKP , { } |KEK1| KMIMP } HSM Host : { |KEKC| KMIMPKP }
2. U SE K EY I MPORT WITH KEK2
Host HSM : { |KEKC| KEK1IMPKP , EXPKP , { } |KEK2| KMIMP } HSM Host : { |KEKC| KMEXPKP } 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 keys original type and the desired type, and can be carried out as follows:
U SE L AST K EY PART I MPORT C OMMAND
Host HSM : oldTypenewType , { |KEKC| KMIMP , IMPKP } HSM Host : { |KEKColdTypenewType| KMIMP } Any number of modied 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 IBMs 4758 CCA
When Bonds 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 Clulows MSc [14], and proceeds as follows. The attacker rst conjures a pair of import key encryption keys with the known difference of DATAEXP, in the same way as for Bonds Key Import/Export Loop Attack. The Key Import
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])
3 These
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| KMIMP } { |UKEK1DATAEXP| KMIMP } { |UKEK2| KMEXP } { |UKEK2| UKEK1EXP }
The attacker then changes UKEK2 to a data key upon import, before exporting with the exporttype version of itself:
1. C HANGE T YPE OF UKEK2 UPON I MPORT
Host HSM : { |UKEK2| UKEK1EXP , DATA , { } |UKEK1DATAEXP| KMIMP } HSM Host : { |UKEK2| KMDATA }
2. E XPORT UKEK2 U NDER I TSELF
Host HSM : { |UKEK2| KMDATA , DATA , { } |UKEK2| KMEXP } HSM Host : { |UKEK2| UKEK2DATA } 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| KMEXP, e.g. the } PIN derivation key.
3DES Key Binding Attack on IBMs 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 rst encrypted using the left half of the 3DES key, then decrypted using the right half, before nally 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 nd a key by brute force search alone searching the entire 2112 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 nd the value of two of them roughly a 241 search if 216 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.
25
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 nd 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 216 3DES keys, swapping the known left half into all of them, and encrypting the test vector with each one. As before, a 240 parallel key search should nd 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 rst nd 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 256 search to nd both new keys (and thus the target key), such an attack may be available to individuals or organisations with sufcient 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 customers 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 rst four hexadecimal digits of the block (i.e. the rst 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 modules, 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 enters 0000 as the trial PIN, and 000000100000000 as the decimalisation table (i.e. all zeroes with a 1 in the 7 position), then the correct PIN does not contain a 7 if the verication succeeds. Therefore, a large
26
ACCOUNT N UMBER E NCRYPTED A/C N O . T RUNCATED VALUE D ECIMALISATION TABLE
4556 2385 7753 2239 3F7C 2201 00CA 8AB3 3F7C 0123456789ABCDEF 0123456789012345
D ECIMALISED PIN
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 specic 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 verication 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 nd proofs of mathematical theorems, theorem provers can be applied to any situation which can be expressed as a logical theory. A logical theory comprises a number of axioms (facts and rules) which are used in the derivation of other facts. The most common representation used is rst-order logic, as it is generally considered to be of sufcient expressive power, and automatic procedures for applying inference
5 Clulow
actually presents six attacks that are able to recover the value of a PIN from an encrypted PIN block.
27
rules and determining the truth of statements are well understood. [18] provides a full introduction to both rst-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 nd a proof. In the context of security API analysis, the theory will capture the set of API comands, along with the intruders 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 verication (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 eld of model checking, although it was published too early for bounded model checking [5] to be included. Early model checkers worked by building a nite state machine (FSM) from the state transition system, and determining whether any of the states violating the property to be veried 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 N U SMV [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 verication. 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 intruders knowledge changes when they are called, and the intruders initial knowledge is used to dene 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.
28
Using these kinds of verication 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 S PASS in 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, S PASS 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 innite 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 verication process. It was quickly realised that the XOR function had to be handled in an efcient manner in order for security APIs to be formally veried in their entirety.
3.5
Current Research
In the last year or so, a number of researchers have managed to rediscover known attacks on IBMs CCA API, having modelled all of the key management commands. Graham Steel was one of the rst to publish such results [26], having modied daTac [28] a theorem prover which supports AC unication to handle constraints specifying equality of terms modulo XOR. These constraints built upon regular equality and captured the fact that XORing anything with itself produces the identity value, anything XOR-ed with the identity value remains unchanged, and that the operator is both associative and commutative. Steel was able to rediscover Bonds Key Import Attack, the more complex Import / Export Loop Attack, and the attack discovered by IBMs engineers. Since the publication of his PhD thesis, Mike Bond has turned his attention to the rediscovery of the attacks on IBMs 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 IBMs CCA API. However, rather than specifying constraints in order to reduce the size of the search space, they restricted the way in which the
29
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 nite 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 l Courant and Jean-Francois Monin used the proof assistant Coq [34] to e 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 signicantly worse when applied to the analysis of security APIs. Already though, researchers are turning their attentions to the modication 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 difcult to check for, as it is often hard to know if a command is capable of providing the necessary hints to effect an attack.
30
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 eld 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.
Chapter 4
Overview of IBMs CCA API

IBMs Common Cryptographic Architecture (CCA) API [11] is used by security modules in a signicant number of automated teller machines (ATMs) across the world, as well as in the mainframe computers of many banks. The API is provided by IBMs 4758 Cryptographic Coprocessor1 whose main task, in this setting, is to carry out PIN verication 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 modules 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 verication 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 accesscontrol system, whereby certain commands are only available under specic circumstances. It
1 http://www-03.ibm.com/security/cryptocards/pcicc/overview.shtml
31
Chapter 4. Overview of IBMs CCA API
32
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 specic 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 devices 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 verication 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 verication, and just PIN verication. 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 verication of a customers PIN cannot be used with the encipher command to encrypt arbitrary data.
33
4.2
API Commands
This section presents the core key management commands, along with some selected others, and the denitions are designed to capture the important semantics of the commands.2 The following terms are used in this section to represent the various control vectors and cryptographic keys: DATA IMP EXP KGN KP KM KEK KEY TYPE KPi X Control vector for data keys Control vector for import key encryption keys Control vector for export key encryption keys Control vector for key generation keys Control vector indicating that a key is only a key part, and not a complete key The security modules master key An arbitrary key encryption key An arbitrary cryptographic key An arbitrary key type control vector Key part i (used to build an arbitrary key) 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 both KM and IMP so is therefore able to obtain KEK from the third parameter. This key encryption key is then XOR-ed with the second parameter, TYPE, and used to obtain KEY from the rst parameter. Finally, KEY is encrypted under the exclusive-or of KM and TYPE to produce the result that is returned by the command.
Key Import
User HSM : { |KEY| KEKTYPE , TYPE , { } |KEK| KMIMP } HSM User : { |KEY| KMTYPE } Converts a key (of the given type) from encryption under the supplied import-type key encryption key to encryption 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).
2 See
Appendix A for an overview of the notation used to describe the commands.
34
Clear Key Import
User HSM : KEY HSM User : { |KEY| KMDATA } 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| KMTYPE , TYPE , { } |KEK| KMEXP } HSM User : { |KEY| KEKTYPE } 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 that KEY must be able to be exported.
Encipher
User HSM : X , { |KEY| KMDATA } HSM User : { }KEY |X| 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 : { }KEY , { |X| |KEY| KMDATA } 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
F IRST A DD / M IDDLE
User HSM : KP1 , TYPE HSM User : { |KP1| KMKPTYPE }

C OMPLETE
User HSM : KP2 , { |KP1| KMKPTYPE , TYPE } HSM User : { |KP1KP2| KMKPTYPE }
L AST
User HSM : { |KEY| KMKPTYPE , TYPE } HSM User : { |KEY| KMTYPE }
User HSM : KP3 , { |KP1KP2| KMKPTYPE , TYPE } HSM User : { |KP1KP2KP3| KMTYPE }
35
This series of commands builds up a working key from individual parts and can be used in one of two ways. Either the rst, middle and last commands can be used, or the rst, add and complete ones. In order to provide security through separation of duty, the commands are split into three groups, with individuals only allowed access to one. However, the add/middle and last commands are in the same group, so the combination using those ones allows a malicious insider to obtain a pair of keys with a known difference (a prerequisite for a number of the attacks discovered by Bond). The other series of commands ensures that the people responsible for inserting the key parts cannot obtain a nal key, and the person who obtains the nal key cannot modify it in any way. Furthermore, the nal key can be checked using the Key Test command, below, which encrypts a set test vector under a given key.
Key Test
User HSM : { |KEY| KMTYPE[KP] } HSM User : { |0000 0000 0000 0000| KEY } Returns a test vector encrypted under the supplied (full or partial) key. The test vector can be made to consist entirely of binary zeroes, and thus be known. This command can be abused by an attacker to encrypt the known vector under a large number of generated keys, and then try to nd one of them via brute force search (see Parallel Key Search, pg. 22).
Key Translate
User HSM : { |KEY| KEK1TYPE , TYPE , { } |KEK1| KMIMP , { } |KEK2| KMEXP } HSM User : { |KEY| KEK2TYPE } Translates a key from encryption under one key encryption key to encryption under another. The rst key encryption key must be of import type, and the latter must be of export type.
Key Generate
User HSM : TYPE1 , TYPE2
,{ |KEK1| KMIMP }
,{ |KEK2| KMEXP }
HSM User : { |NEW| [KM | KEK1 | KEK2] TYPE1 , { } |NEW| [KM | KEK1 | KEK2] TYPE2 } The key generate command has nine variants, each of which returns one or two copies of a randomly generated key, each with their own type, and each encrypted in one of three possible ways. A generated key can be encrypted under the local master key (for immediate use by the security module), it can be encrypted under a supplied import-type key encryption key (for re-importation and use at a later date), or it can be encrypted under an export-type key encryption key (for importation into another security module). In the case where two keys are
36
generated, the combination of types is restricted usually such that the two keys perform inverse operations, e.g. encipher and decipher.
Diversied Key Generate
User HSM : X , TYPE , { |KEY| KMKGN } HSM User : { { }KEY| | |X| }

KMTYPE
Generates a new data key by encrypting the supplied plaintext under the key generation key, then encrypting the result to obtain a working key of the specied type. The encryption can either be single- or triple-DES, and there is also an option for the plaintext to be decrypted by the key generation key using the triple-DES algorithm. The KGN control vector prevents the key generation key from being used with other commands (e.g. encipher), so as to avoid the value of the new key being discovered.
4.3
Access Controls
As a security measure, the CCA software provides role-based access controls, so as to limit the commands which any particular user3 has access to, as well as place restrictions on when they are able to access the system. A user of the security module is assigned to be a member of one of the specied roles, and once logged in, inherits the privileges dened therein. This approach is in contrast to the alternative method of keeping individual user proles, and has been chosen since it is often the case that a large number of users will share the same access rights. The security module is required to have a default role which denes the capabilities of any user who has not logged on and authenticated with the system. Additional roles can be dened by the device administrator, and are stored internally by the security module. With respect to the key management commands, the following roles will typically be dened: General User This role will have very few extra privileges over the default role, and will typically only allow the use of existing keys with certain operations, e.g. data keys with the encipher and decipher commands. Security Ofcer 1 IBM recommend that the process of importing a new key from clear key parts be carried out by different users whose individual capabilities are not sufcient to mount an attack. The key parts are typically loaded into a device by security ofcers, and this role only allows the use of the Key Part Import command to insert the rst key part.
3A
user can either be a human individual or a computer process
37
Security Ofcer 2 Users assigned to this role are only able to add subsequent cleartext key parts to an existing encrypted incomplete key. Security Ofcer 3 In response to the attacks discovered by Bond, IBM modied the API in such a way as to separate the ability to add new key parts and to generate the completed key. The third security ofcer is not able to modify the incomplete key, but can turn it into a complete key, as well as verify that the completed key has not been tampered with. It will also be likely that there are other roles which allow existing working keys to be exported or modied, and that allow new keys to be generated. In general, it is best if users are only provided with the bare minimum of privileges required to carry out their work, and that potentially dangerous combinations of commands are not enabled in the same role.
4.4
Summary
We have introduced IBMs Common Cryptographic Architecture (CCA) API, and described its main functions and features. We have seen the method by which cryptographic keys are stored, and how their use is restricted by means of a typing system. The main key types were presented along with their uses. We have also seen a semantic overview of the main API commands that relate to the key management functions, along with a few others like encipher and decipher. The access control mechanism was also discussed, since it is the method by which the CCA allows for separation of duty. The level of security provided by the CCA API is dependant on these two aspects of its design.
Chapter 5
Rediscovery of Known Attacks

The rst aim of this thesis was to show that it is possible to re-discover all known API attacks on the subset of CCA commands that dene the key management operations (see Section 4.2, pg. 33). Doing so would demonstrate that the methods used are a viable means of formally verifying security APIs. The approach chosen in this thesis was to use model checkers specically designed for the analysis of security protocols, with the aim of investigating how they cope when applied to the more complex task of security API analysis. A number of versions of each attack were used in order to determine how different classes of additional information (e.g. commands, initial knowledge) would affect the performance of the tools used.
5.1
Tools Used
As recent research has shown [26], attempting to formally verify security APIs which employ the exclusive-or function requires tools that handle the associated algebraic properties in an efcient manner. To this end, the model checkers CL-AtSe [33] and OFMC [35] were selected, although this was not the only factor in the decision process. Both tools were developed as separate back-ends in the Avispa tool set [32] specically designed to be used for the analysis and verication of security protocols. They accept models written in the High Level Protocol Specication Language (HLPSL) [21], which was also developed as part of the Avispa project. HLPSL is intended to be geared towards the modelling of communication and security protocols, and provides important primitives such as communication channels, cryptographic keys and security properties.
38
Chapter 5. Rediscovery of Known Attacks
39
HLPSL
In security protocol analysis, the typical scenario consists of two honest agents, and an intruder agent who is attempting to obtain secret information, or pose as an honest agent. In HLPSL, the protocol is modelled as a series of roles which are played by one or more of the honest agents, and possibly the intruder. The roles contain a series of transitions which dene the behaviour of the particular agent playing that role. The main roles are composed in a special role called the session which describes when they are active. It is usually the case that the roles are composed in parallel, meaning that they are all active at the same time. The session role is also used to dene what roles are played by which agents, and communication protocol models will typically have more than one session with different agent-role assignments in each. The agents interact with each other by passing messages, of a predetermined structure, across one or more communication channels. Currently, HLPSL only provides channels based on the Dolev-Yao model, where the intruder is able to eavesdrop on everything transmitted meaning that all communication is effectively done via the intruder. Therefore, all unencrypted terms transmitted will be added to the intruders knowledge, as will encrypted terms if the intruder has the necessary key to decrypt them. Furthermore, the intruder can potentially modify the contents of transmitted messages, as well as creating his own transmissions, and preventing others reaching their destination. Two types of security properties are provided: secrecy of terms, and authentication on terms. The former allows for the specication of the agents for which knowledge of a particular term, or terms, is acceptable. If another agent, usually the intruder, obtains the information then the property has been violated. The latter property lets you specify that two communicating agents agree on the value of a particular term, or terms. This is typically used to check whether or not two agents can communicate securely a violation occurs if one of the two parties is unknowingly communicating with a different agent than is intended. As well as the communication channels and secrecy properties, HLPSL also provides a number of primitive types that are typically required in protocol analysis, including symmetric keys, public keys, and agents. The model checkers do not work with HLPSL directly, but rather a lower level representation called the Intermediate Format [24]. This is automatically generated from the original HLPSL model, and models each transition as a rewrite relation on the intruders knowledge. That is, if the intruder knows the terms on the left-hand side, then he can obtain the terms on the right-hand side. This corresponds to the intruder forming a message using the terms on the left-hand side, sending it to the appropriate honest agent, and receiving the terms on the righthand side in response. Other issues such as the internal state of the honest agents are modelled as additional pre-conditions of the specic relation.
40
CL-AtSe
CL-AtSe (Constraint Logic based Attack Searcher) has in-built support for a number of algebraic operators, including exclusive-or. Initially, a set of constraints are obtained which precisely dene the transitions in the model, and during the search process, the effect of a particular transition occurring is computed by adding new constraints, as well as modifying or deleting existing ones. At each step, the constraints are checked in order to determine if any of the security properties have been violated. The intruder is able to carry out off-line encryption and decryption using known terms, as well as being able to obtain the exclusive-or of any two known terms. These abilities are not provided explicitly, but rather are consequences of the unication algorithm employed. For example, if the exclusive-or of three terms is required to unify two equations (in order for the intruder to effect a transition) then they will unify if the intruder has those three terms as part of his knowledge. The verication process is carried out for a bounded number of sessions, i.e. the bound determines the maximum number of times that each role can be run. Unfortunately, although HLPSL provides various cryptographic primitives, CL-AtSe only applies the exclusive-or operator to terms of the generic message type. This means that all models have had to be run with the typing information ignored thus resulting in a larger search space as there are fewer restrictions on term unication.
OFMC
OFMC (On-the-Fly Model Checker) represents the state space symbolically and, like CL-AtSe, veries a model over a specied number of sessions. Its default behaviour is to use iterativedeepening to progressively search over larger and larger bounds, although it uses standard depth-rst search if an explicit bound is given. Unlike CL-AtSe however, OFMC accepts a user-dened theory le which can be used to specify the properties of any algebraic operator. The only restriction is that the operator must be able to be dened by strictly reducing cancellation properties, and rewrite rules dening a nite theory. The theory le not only species how operators are dened, but captures how the intruder can use them to generate new terms. It was hoped that this would allow for a ner-tuned model of the intruder, resulting in a smaller search space and faster run-times. Unfortunately, the experiments uncovered a fundamental problem with OFMC that prevented the attacks being rediscovered. When attempting to unify two equations, OFMC places an upper bound on the number of times that particular steps can be carried out (e.g. introducing new free variables). However, rather than being independent, the bound is the same as the one used during the initial stages where the transition rules are normalised with respect to the cancellation properties of
41
the provided theory. The problem arises because this bound is too low for the necessary uniers to be discovered. This results in the intruder effectively being prevented from obtaining terms which he should be able to get, and from using known terms in the transitions. For example, with Bonds Key Import Attack, the intruder could obtain the tampered key encryption key, but he was unable to use it to modify the type of the key being imported.
5.2
Modelling the API
Unlike standard security protocol analysis, where the intruder is attempting to break a secure communication between two honest agents, the attack scenario for the CCA API consists only of the security module and the intruder. Furthermore, the security module is essentially stateless in that the result of a command only depends on its inputs. A consequence of this property is that there is no enforced ordering on the execution of the commands. To begin with, the API commands were modelled as separate transitions within a single role, but this was problematic for CL-AtSes initial optimisation steps. Each role is explored to the full depth in order to determine any simplications that can be made, but the nondeterministic nature of the transitions caused the runtime of this procedure to blow up. To avoid this problem, the commands were instead modelled as separate roles, each containing just the one transition. For example, the key import command was modelled as follows: role keyImport(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def=
local K1 : symmetric_key, % An arbitrary key % An arbitrary key encrypting key % An arbitrary key type control vector
KEK1 : symmetric_key, TYPE : nat
transition
keyImport. Rcv({K1}_xor(KEK1,TYPE).TYPE.{KEK1}_xor(km,imp_CV)) /\ in(TYPE,KeyTypes) =|> Snd({K1}_xor(km,TYPE))
end role
42
Recall that the key import command takes as input the key to be imported (encrypted under a key encryption key), the type of the key, and the key encryption key. The security module then modies the key so that it is encrypted under the local master key, and returns the result. These requirements are captured in the transition by the message patterns in the Snd and Rcv channels, where a primed value represents a free variable, a period denotes message concatenation, and
{X }_Y means that X is encrypted under Y . Because the channels are based on the Dolev-Yao
model, the intruder is able to send anything to the security module agent, and receive anything that it returns, and is therefore able to make use of the commands. As all of the commands are available at any given time, they were composed in parallel within the session role. Not shown in the above example is the variable State which OFMC requires to be present in all roles. Since the security module is stateless, it is initialised to zero, then checked for equality to zero as part of the preconditions of the transitions. It has not been included above as it does not contribute to the semantics of the role. Full and partial keys in the CCA must belong to exactly one of the major key groups, and this is achieved by ensuring that the value of the variable TYPE is suitably constrained. Although not documented in the manual, the majority of the commands will only accept full keys. The exception to this rule is the Key Part Import command which only accepts key parts, and the Key Test command which accepts either. As noted earlier, CL-AtSe only considers the exclusive-or of terms that are of the generic message type. However, the API is modelled using the more specic primitives as a guide to the actual uses of the various terms. The intruders initial knowledge contained all of the public control vectors, one working key of each type, and any other information which a legitimate user of the security module would have. Appendix B contains a full listing of all the roles used in the experiments.
5.3
Modelling the Attacks
There are three signicant attacks which have been found on IBMs CCA API: Bonds Key Import Attack, his Import / Export Loop Attack, and IBMs attack which exploits the fact that the data control vector is actually zero. While strict procedural controls are able to prevent the attacks, the models provide concrete evidence of dangerous command combinations. All attacks are presented as the intruder obtaining the PIN from an arbitrary known primary account number. While this requires an extra step in each attack, it is the most likely conclusion of the attacks within the nancial setting, and therefore more realistic. Furthermore, this means that the attacks provide concrete evidence of one of the two main security goals of the API being broken ensuring the secrecy of customer PINs. IBMs attack also breaks the other
43
main security goal preventing the clear value of any cryptographic key being discovered.
Disabled Commands
The rst Key Part Import command was disabled in all models, since a trivial attack exists if the intruder has access to it in addition to the last Key Part Import command. Together, these two commands allow the intruder to create a known export type key encryption key, export the desired key (e.g. the PIN derivation key) which can then be decrypted. The last Key Part Import command cannot be disabled since all three attacks require it at some point. Additionally, the Key Test command has not been included in the models for the following reason. Keys accepted by the other commands all adhere to a particular format: { }KMtype |key| { }KMtypeKP |key| { }kektype |key|
FULL KEYS PARTIAL KEYS KEYS THAT CAN BE IMPORTED
Of these three, the Key Test command is only able to return a result which matches the last one, and even then key will be a string of binary zeroes. This means that, in practice, such a key would be rejected by the security module when it was imported, and is therefore useless to the attacker.1 As a result, the Key Test command only serves to increase the search space a problem which is exaggerated by the fact that we have had to tell CL-AtSe to ignore the type information in the models. Only one form of the Key Generate command has been included in the models the one which returns a single working key of the desired type. The other versions of the command produce keys that are meant to be imported into another security module, or re-imported into the original one at a later date. As such, they do not result in the intruder gaining keys of any practical use, and therefore also just serve to increase the search space. Finally, the Clear Key Import and Diversied Key Generate commands have not be included since the former is normally disabled in practice, and the latter has the same conceptual effect as the included version of the Key Generate command.
Key Import Attack
The Key Import Attack can be carried out when a new key is to be transferred to a security module, and requires a modied key encryption key that has a known difference with the one used to encrypt the key being imported. The attack requires that the last Key Part Import command, the Key Import command, and the Encipher command are all available to the intruder.
1 This is not strictly true, since the output from the Key Test command can be used as part of a parallel key search process (see pg. 22). However, such brute force attacks are not considered in these experiments.
44
See Key Import Type Casting Attack on IBMs 4758 CCA on pg. 20 for a full description of this attack. In this attack, the intruder is responsible for adding one of the parts of an import type key encryption key, during initialisation of a new security module. The other keys are to be transferred to the security module encrypted under this key encryption key. The model assumes that the attacker is responsible for adding the nal key part and thus, in addition to the default public knowledge, the attacker is provided with the nal key part, as well as the encrypted initial key parts. The security module is assumed to be in a pre-initialised state, i.e. no keys have been loaded and therefore the intruder does not have any working keys to begin with. This is the most likely scenario in which the attack would be carried out, since it allows the attacker to import the correct key encryption key into the security module as well. If an earlier key part is altered, then only the modied nal key would be added, and it would therefore be more likely that the attack would be discovered. In order to show that this attack can be used to change the type of a PIN derivation key, and thus allow it to encrypt arbitrary data, the intruder is also provided with a PDK that is encrypted under the complete key encryption key.
Import / Export Loop Attack
The Import / Export Loop Attack works by rst exporting a key from the security module, then changing its type as it is re-imported, using the same method as the key import attack. The attack rst requires that a pair of related import-type key encryption keys be conjured, and then two forms of a key part for another import-type key encryption key one encrypted under a conjured key, and one encrypted under the master key. See Import / Export Loop Attack on IBMs 4758 CCA on pg. 22 for a full description of this attack. Three variants of this attack were modelled, capturing whether both, one, or none of the initial key conjuring steps have been carried out: Variant 1: Attacker is Given All Initial Conjured Keys The intruder is provided with a pair of import-type key encryption keys that have the known difference of IMPEXP, as well as conjured key parts for a second import-type key encryption key: { |UKEK| KMIMP } { |UKEKIMPEXP| KMIMP } { |KEKP| KMIMPKP } { |KEKP| UKEKIMPKP }
The attacker is also provided with a PIN derivation key, encrypted under the master key, and an arbitrary PAN, with the attack presented as the PDK being changed to a data key,
45
and then used to encrypt the PAN, thus obtaining the associated PIN number. Variant 2: Attacker is Only Given the Pair of Related Keys This model requires the attacker to generate the required key parts which are given in variant 1. Key parts are conjured using the Key Import command, using an available import key encryption key, and a random value for the key part. If the random value is accepted, then it and the returned key are valid conjured key parts. In order to simulate this, an extra role was added to the model which took as parameters a key encryption key and a key type control vector (potentially XOR-ed with the key part control vector).2 It would then return the conjured keys as required. Note that the intruder still has to provide the correct key encryption key and key type control vector for the returned keys to be of use in this attack. Variant 3: Attacker is not Given Anything This version shows the actual series of steps that are required to carry out the attack from scratch. In addition to the extra role required for the above variant, a similar one was added that allowed the attacker to conjure related keys. The last Key Part Import command can be used to conjure an unknown key as a full key and a partial key. The partial key can then be modied using the same command by providing the required difference as the nal key part parameter. The added role only simulates the rst step of this process, since the attacker can add in the required difference afterwards, and just takes in the desired key type and returns the conjured key as a full and partial key. As with the other key conjuring role, the attacker must provide the correct key type, and then the correct difference to carry out the attack. Although not modelled here, it is also possible to obtain the related pair of import-type key encryption keys by tampering with a key part, as done in the Key Import Attack.
Data Control Vector Value Exploit Attack
The attack discovered by IBM engineers exploits the fact that the data control vector is actually a string of binary zeroes, and thus XDATA = X. The attacker is able to obtain the clear value of an export-type key encryption key, and therefore easily decrypt any other keys exported under it, such as the PDK. As with the Import / Export Loop Attack, the attacker must conjure two sets of keys, and therefore this attack also has three variants. The attack requires the Key Part Import, Key Import, Key Export and Decipher commands.
2 As noted earlier, the Key Import command does not accept partial keys in practice, and therefore cannot actually be used to conjure key parts as required by this attack. However, it is still a useful test case for verication tools.
46
Variant 1: Attacker is Given All Initial Conjured Keys The attacker is provided with a pair of import key encryption keys that have the known difference of EXPDATA, as well as two forms of a conjured export key encryption key: { |UKEK| KMIMP } { |UKEKEXPDATA| KMIMP } { |CKEK| KMEXP } { |CKEK| UKEKEXP }
In order to allow the attacker to realise that the data control vector is actually a string of binary zeroes, the model was rst changed so that the value of the data control vector was hardwired to zero. However, this uncovered a minor bug in CL-AtSe which prevented the attack from being found. As a workaround, a new role was added with the following two transitions: t1.Rcv({xor(X,data CV)} Y) =|> Snd({X} Y) t2.Rcv({X} xor(Y,data CV)) =|> Snd({X} Y) Unfortunately, because the knowledge is expressed as a role, the attacker is limited in the number of times that he can use it, since the search is bounded to a set number of role instances. This does not stop the attack being found however, as it is only required once, although it may prevent other attacks being found under different circumstances. As with the other models, the attacker is also given an arbitrary PAN, and the attack is presented as the discovery of the associated PIN. Unlike the other attacks, however, the clear value of the PDK is obtained which is far more dangerous in reality, as it does not require continued access to the security module in order to obtain PINs. Variant 2: Attacker is Only Given the Pair of Related Keys In this version of the attack, only the initial pair of related import-type key encryption keys are provided, with the attacker having to conjure the necessary export-type key encryption key. The model of this variant required the same extra role as the second variant of the Import / Export Loop Attack, although it is used in this attack to conjure full keys, rather than partial keys. Variant 3: Attacker is not Given Anything As with the third variant of the Import / Export Loop Attack, the attacker is not provided with any initial conjured keys. With the exception of the role that captures the fact that the data control vector is a string of binary zeroes, this model is the same as the model for the third variant of that attack.
47
5.4
Results
The system used to obtain the following results had a 3.6GHz Intel Xeon processor with 3.5Gb RAM, running Fedora Core 3. Two sets of options were used with CL-AtSe the rst to make it do a breadth-rst search (to look for the shortest attack), and the second to make it carry out a depth-rst search. Unfortunately, because of the way in which CL-AtSe enforces the search bound, the results for attacks requiring multiple uses of the same command suffered. Rather than the bound giving a limit to the number of commands allowed in the attack, it gives a limit on the number of sessions that are allowed. That is, if a command is required three times for a particular attack, then the bound must be at least three. However, this means that the maximum length of attacks considered is the product of the bound and the number of roles in the session. This typically results in a much higher search bound than is necessary, as it is not strictly tied to the length of the attack being searched for. Although some conclusions are given in this section, a more general discussion of what can be drawn from these results is given in chapter 7.
Key Import Attack
As well as the described model, containing all of the key management commands described in Section 4.2, a version was used that is equivalent to Youn et al.s model given in [30] and [31]. They only included the Encipher, Decipher, Key Import, Key Export, and last Key Part Import commands along with the version of the Key Generate command that produces a single working key of the desired type. Table 5.1 shows the results of running CL-AtSe on both models. Model Youn et al. Full Search Strategy Breadth-First Depth-First Breadth-First Depth-First States Analysed 200 114 70 20 31 14 70 20 Reachable States 64 43 34 10 15 6 34 10 Run-Time (s) 0.05 0.03 0.07 0.02 0.02 0.01 0.07 0.02
Table 5.1: Results for the rediscovery of Bonds Key Import Attack using CL-AtSe. The right-hand column in each pair refers to the results of running CL-AtSe with the initial protocol optimisation step disabled.
On a marginally slower system, Youn et al. showed that they were able to discover the attack using Otter in a range of times from 0.2s to 28s depending on various factors. As can be seen from the above results, CL-AtSe is able to nd the attack quicker, even with the model that contains more API commands. The fact that the analysed states and the reachable states are
48
the same for the full model is due to the ordering of the commands being optimal. While a different ordering does not change the number of reachable states, it does affect the number of states analysed, and also the overall run-time (although not enough to cause the above results to be an unfair comparison). Additionally, the intruder model in CL-AtSe does not restrict the attacker to only applying the exclusive-or operator to unencrypted terms, or prevent him from re-encrypting an already encrypted term. Both these limitations increase the size of the search space that has to be checked, and it is therefore believed that had similar restrictions been possible, the run-times would have been faster still.
Import / Export Loop Attack
A total of six versions of the rst variant of the Import / Export Loop Attack model were checked with CL-AtSe. The rst two contained only the commands required for the attack, the second two included the Encipher, Decipher, Key Import, Key Export and Key Translate commands as well as the add and last Key Part Import commands. This pair is referred to as the Standard Commands model in the table below. The third pair added the version of the Key Generate command which returns a single operational key. Within each pair, the second model provided the intruder with a data key, whereas the rst did not. The reason behind these different versions of the model was to observe how the differences affected CL-AtSes performance. Table 5.2 shows the results of running CL-AtSe on all six versions of the models for the rst variant of Bonds Import / Export Loop Attack. The results show that the addition of the data key to the intruders initial knowledge has a signicant effect on the run time, due primarily to the fact that the intruder is thus able to encrypt any known term using the Encipher command, and obtain a new term. This can be seen by the jump in the number of reachable states. However, the biggest jump is caused by the inclusion of the Key Generate command, since it allows the intruder to add additional working keys, of any type, to his knowledge and thus results in a far greater number of possible command calls being made available. Overall, the run-time is most sensitive to the number of working keys in the intruders knowledge, so it is therefore of paramount importance that he is not able to obtain unnecessary keys. Note that unnecessary means keys which do not cause the attacker to gain anything by having knowledge of them. For example, two completely unrelated keys of the same type are unlikely to both be of use to the intruder.3 In [26], Steel used a model that included the Encipher, Decipher, Key Import, Key Export, last Key Part Import and Key Translate commands, and only the PIN derivation key (i.e. no data key). He was able to nd the attack using a modied version of daTac in 1.47s. CL-AtSe
3 The
obvious exception to this is when the two keys are part of separate related key sets.
49
Search Model Strategy Breadth-First Rqd. Cmds. Rqd. Cmds. + Data Key Std. Cmds. Std. Cmds. + Data Key All Cmds. All Cmds. + Data Key Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First
States Analysed 88 70 460 299 805 5857 161384 415673 88 70 460 299 805 5857 5753 19142 -
Reachable States 49 35 395 283 348 4066 68565 201331 49 35 395 283 348 4066 3948 15184 Run-Time (s) 3.40 5.52 13.67 132.64 57.38 >3600 176.43 >3600 700.16 >3600 2030.65 >3600 3.47 5.51 13.89 132.15 57.73 >3600 177.97 >3600 648.62 >3600 1935.48 >3600
Table 5.2: Results for the rediscovery of the rst variant of Bonds Import / Export Loop Attack using CL-AtSe. The right-hand column in each pair refers to the results of running CL-AtSe with the initial protocol optimisation step disabled.
is slightly slower on an equivalent model, taking 7.23s using breadth-rst search. Unfortunately, the only other model in which the attack was found, was the simplest version of the second variant, using depth-rst search with the initial simplication steps enabled, as shown in table 5.3. Model Rqd. Cmds. Search Strategy Depth-First States Analysed 5637 Reachable States 2958 Run-Time (s) 3058.21
Table 5.3: Results for the rediscovery of the second variant of Bonds Import / Export Loop Attack using CL-AtSe. All other models required too much time or memory, and are not shown.
The reason for the other models running out of time or memory is almost certainly due to the large number of valid keys that the intruder can add to their knowledge. However, we believe that this is the rst time that formal methods have been used to rediscover the attack, when the intruder has only been given one of the related key sets, and has to conjure the other one.
Data Control Vector Value Exploit Attack
As noted earlier, a minor bug in CL-AtSe meant that the intruder is not able to provide zero (or even XX) as a parameter to any of the commands. While this does not prevent the attack
50
from being found, it does make it harder to do so, since the data control vector could not be hard-wired to zero. Table 5.4 gives the results for the rst variant of the attack, where the intruder is provided with both sets of conjured keys. States Model Search Strategy Breadth-First Rqd. Cmds. 1 Rqd. Cmds. 1 + Data Key Rqd. Cmds. 2 Rqd. Cmds. 2 + Data Key Std. Cmds. Std. Cmds. + Data Key All Cmds. All Cmds. + Data Key Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Analysed 454 454 293 293 293 293 664 664 1114 1114 60358 60358 454 454 293 293 293 293 664 664 1114 1114 2252 2252 Reachable States 355 355 220 220 225 225 338 338 688 688 19121 19121 355 355 220 220 225 225 338 338 688 688 1352 1352 Run-Time (s) 805.61 806.82 MEM MEM 37.51 37.30 68.00 68.29 49.88 49.24 120.05 123.34 1192.56 1184.53 MEM MEM 798.78 721.38 MEM MEM 37.61 37.80 68.18 68.74 49.75 49.99 122.12 122.75 943.04 952.14 MEM MEM
Table 5.4: Results for the rediscovery of the rst variant of IBMs Attack using CL-AtSe. The right-hand column in each pair refers to the results of running CL-AtSe with the initial protocol optimisation step disabled.
The reason for the two sets of required commands is that two versions of this attack exist. In the second case, the Key Translate command is used to directly obtain the conjured key encrypted under itself: Host HSM : { |UKEK2| UKEK1EXP , DATA , { } |UKEK1DATAEXP| KMIMP , { } |UKEK2| KMEXP } HSM Host : { |UKEK2| UKEK2DATA } This is not discussed in [14], and we are therefore led to believe that this version of the attack may not previously have been known. The second version does not take as long to nd because each required command is only used once, whereas in the rst version, the Key Import command is used twice. This means that there is a lower bound on the search for the second version. It is also the attack found when the standard and all command sets are used.
51
Table 5.5 shows the results for the second variant of IBMs attack, although only the simpler version of the attack that uses the Key Translate command could be discovered. However, we believe that this is the rst time that this variant of the attack has been rediscovered using formal methods. States Model Search Strategy Breadth-First Rqd. Cmds. 2 Rqd. Cmds. 2 + Data Key Std. Cmds. Std. Cmds. + Data Key All Cmds. All Cmds. + Data Key Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Breadth-First Depth-First Analysed 7111 551 8081 613 22712 7339 30999 882 63 582 63 1772 337 839 Reachable States 3465 181 4075 207 5306 763 3235 400 31 410 31 837 104 278 Run-Time (s) 580.61 38.20 1103.20 83.27 758.64 158.93 MEM 1877.52 MEM >3600 MEM >3600 442.18 41.20 899.91 98.13 694.50 238.14 MEM 2917.17 MEM >3600 MEM >3600
Table 5.5: Results for the rediscovery of the second variant of IBMs Attack using CL-AtSe. The right-hand column in each pair refers to the results of running CL-AtSe with the initial protocol optimisation step disabled.
Sadly, CL-AtSe was unable to nd the full attack, as given by the third variant of this model, which required both sets of related keys to be conjured. However, that attack requires a depth bound of two, and as was shown with the Import / Export Loop Attack, this can cause a severe blow-up in the resources required.
5.5
Summary
The way in which we modelled IBMs CCA API, and the attacks, has been presented, along with the two tools that were originally intended to be used to rediscover the known attacks. Unfortunately, we were only able to use CL-AtSe in our experiments, as our models exposed a bug within OFMC that prevented it from nding the attacks. The results have shown that CL-AtSe is able to outperform some previous attempts, while doing less well in a few cases. While the results for the model of IBMs attack may be hampered by CL-AtSes minor bug, the results for the Import / Export Loop Attack show that the means by which the search bound is enforced does not sit well with the highly non-deterministic
52
nature of the commands in security APIs. We have also obtained what we believe to be the rst rediscovery of a couple of the more complex variants of the latter attacks, which require the intruder to conjure a set of related keys himself. Overall, however, we have shown that the underlying techniques used by CL-AtSe are more than capable of verifying properties of security APIs, even if the way in which they are employed is less than ideal.
Chapter 6
Verication of IBM Recommendations

In response to Bonds discovery of the Key Import Attack, IBM released a set of three recommendations [23] designed to prevent it from being carried out, covering suggested command usage, the security modules access control system, and general procedural safeguards. However, they are presented as informal guidelines, and it is not clear which ones are necessary or sufcient to prevent the attack. Furthermore, the recommendations had never been formally veried, so their effectiveness had never been properly checked. The Key Import Attack does not require collusion between multiple individuals, and as such, the recommendations only attempt to prevent single-party attacks. However, one of them may not actually prevent the attack, and could even potentially expose the system to a more serious security breach, where the clear value of a key can be obtained. The analysis of the recommendations highlighted a number of issues that may undermine their effectiveness, as well as clarifying a few points regarding their deployment. These have been drawn together into a concrete set of recommendations which aim to remove any remaining uncertainty over what needs to be done in order to prevent the various identied attacks on the CCA API. All verication runs were done using breadth-rst search with CL-AtSes initial protocol optimisation step disabled.
6.1
Recommendation 1
IBMs rst recommendation is to use public key techniques to transfer the initial key encryption key (KEK). This approach ensures that the KEK is never present in the clear, and therefore cannot be modied. IBM state that transferring the KEK (or any key for that matter) using clear key parts is not recommended, and is only supported because it was a standard method in the past and there are customers who still prefer it. Using the public key approach, the KEK to be transferred is encrypted under the public
53
Chapter 6. Verication of IBM Recommendations
54
key of the security module that the KEK is being sent to. Once decrypted, all other keys are transferred as before, encrypted under this shared KEK. Although the paper describes two ways of providing two security modules with the same KEK encrypting an existing KEK, and randomly generating a new one only the latter is possible, because the suggested command for the former will not accept key encryption keys.
Overview of KEK Transfer Process
Public keys used for encryption must rst be registered with the security module a two stage process designed to prevent a malicious individual from adding their own public key. The rst step causes the security module to store a hash value for the key, and in the second step, this is checked against the value computed for the key being added. The entire key transfer process, based on this recommendation, is as follows: 1. Use the PKA Key Generate command at the destination security module to obtain an RSA public-private key pair, retaining the private key within the module. 2. One individual uses the PKA Public Key Hash Register command to register a hash value for the public key at the source security module. 3. A second individual uses the PKA Public Key Register command at the source security module to actually add the public key. 4. Use the PKA Symmetric Key Generate command to create two versions of a random KEK at the source security module one as an importer, encrypted under the previously registered public key, and one as an exporter, encrypted under the local master key. 5. Use the PKA Key Import command at the destination security module to import the randomly generated KEK. 6. Transfer all other keys using this common KEK. It should be obvious that no single individual should have access to both commands required to register a public key with the source security module. Such a situation would allow that person to register their own public key, then decrypt the randomly generated KEK, and thus obtain the clear value of any exportable key. Additionally, the PKA Key Generate command allows for the private key to be returned in the clear. However, this is only possible if the administrator of the security module allows it, since such an ability is not enabled by default. Using public key techniques may prevent an attacker from modifying an existing KEK, but it does not stop them from conjuring their own KEK with the Key Part Import command.
55
The rst and last, or rst and complete, versions of the command allow an attacker to introduce a known key into the security module. As part of the second recommendation, IBM state that there is no need for this command when public key methods are used to transfer the initial KEK, and it should therefore be disabled. However, the manual (as of version 2.54) only suggests that a policy of dual control can be enforced, and does not highlight the dangers of allowing a single person to have access to both.
Checking the Recommendation
In order to check IBMs rst recommendation, a new role was added to the model for the PKA Symmetric Key Import command, which has the following semantics:
PKA S YMMETRIC K EY I MPORT
User HSM : { |KEY.TYPE| PK } HSM User : { |KEY| KMTYPE } It takes an encrypted data block, containing the key to be imported and corresponding type information, and returns the key encrypted under the local master key. The data block is encrypted under the public key that corresponds to the security modules private key. In practice, the data block includes additional information such as a device-specic identier that prevents the key from being re-imported into the exporting security module. However, only the key and type information were considered in the model, since the other items can be safely ignored for the purposes of the verication process. It was also assumed that the public key for the destination security module had already been securely registered with the originating device, and that the intruder was responsible for loading the key encryption key.
A Potential Attack
Having modelled IBMs rst recommendation, CL-AtSe found a rather simple attack that allows the clear value of a key being transferred to be discovered. It involves adding a known export-type key encryption key into the security module, before using it to export the key being transferred. The attack relies on the intruder being able to create encrypted data blocks that will be accepted by the PKA Symmetric Key Import command. The precise format of the data block is given in the CCA manual, along with the steps required to encrypt and decrypt it. In order to encrypt the data block, the attacker must have access to the security modules public key. The only other apparent restriction is that the unique identier cannot be the same as the one of the security module for which the key is to be imported. Since the clear value of the arbitrary key is used, the intruder can ensure that the parity bits are valid, and therefore guarantee that it will be accepted by the security module.
56
The attack can be carried out in two ways, only one of which requires the attacker to have the key being transferred: 1. Create a data block for an export-type key encryption key, and encrypt it under the public key of the appropriate security module in the manner described in the CCA manual. 2. Use the PKA Symmetric Key Import command to import the known key into the security module. 3. Obtain the key encrypted under the known KEK in one of the following ways: use the Key Translate command to convert the key being transferred to encryption under the known export-type KEK use the Key Export command to export the target key from the security module. 4. Since the value of the export-type KEK is known, the key can be decrypted. This is a very simple attack which CL-AtSe found in under a second, using breadth-rst search, on a model containing all of the commands (except for those listed as disabled in section 5.3 on pg. 42). Since the above attack relies on the assumption that the attacker is able to create the data block containing the known export type KEK, and this may not be true in reality, a version of the model was checked where the attacker could not create the data block. This was achieved by requiring an extra term to be present in the data block which the attacker did not know. With this change, no attack was found up to a bound of 10, using the standard command set. The results are presented in table 6.1. Bound 1 2 3 4 5 6 7 8 9 10 11 States Analysed 21 70 245 882 3234 12012 45045 170170 646646 2469012 Reachable States 2 9 34 125 461 1725 6434 24309 92377 352715 Run-Time (s) 0.00 0.01 0.06 0.22 0.86 3.44 13.76 55.63 226.42 974.17 >3600
Table 6.1: Results for the verication of IBMs rst recommendation using CL-AtSe.
57
The addition of the Key Generate command resulted in CL-AtSe only being able to show that the model was safe up to a bound of 1 (in less than a second), with the bound of 2 timing out, and subsequent bounds running out of memory.
6.2
Recommendation 2
IBMs second recommendation is to use the access control system to ensure that no single person is able to execute the commands required for the attack. These are the Key Part Import and Key Import commands, which are used to modify the key encryption key, and to change the type of the key being imported, respectively. Recall that security module users are assigned to a user prole which determines the set of commands that they are allowed to execute. Therefore, if these two commands are not enabled together in any prole, then the attack cannot be mounted. The Key Part Import command has four versions, allowing for ner grained usage restrictions, and as mentioned previously, the rst and last, or rst and complete, versions should not be enabled in the same role.
Example KEK Transfer Procedure
In their recommendations paper, IBM provide an example of how a key encryption key can be transferred securely using clear key parts. It details the roles and responsibilities of ve people (A E), although they concede that, in some environments, person A and person E may be the same individual. Assuming that only two key parts are used, the ve people carry out the transfer as follows: 1. Person A generates the two clear key parts, using the Random Number Generate command, and the key verication pattern (KVP) for the complete key encryption key (KEK). The rst key part is given to person B, the second to person C, and the verication pattern to persons C and E. 2. Person B enters the rst key part into the destination security module. 3. Person C enters the nal key part into the destination security module, and calculates the KVP to make sure that the key has not been modied. If the key is made up of more than two parts, then the intermediate key parts are added by people with equivalent privileges to Person C, although they will not have to check the KVP. 4. Person D exports the key to be transferred from the source security module, encrypted under KEK. 5. Person E checks the KVP for the KEK to ensure that it was loaded correctly into the destination security module, and then imports the key being transferred.
58
It is assumed that the key parts are loaded into both security modules in the same way. In Bonds Key Import Attack, the malicious insider was effectively playing the part of persons C and E. Note also that person A has access to all parts of the key encryption key. If this person is also responsible for transferring the keys, as IBM state may be the case, then they would potentially be able to obtain the clear value of those keys.
Of the ve people who are involved in the recommended key transfer process, only person B, person C and person E are considered to have access to the destination security module. A model was created for each of these individuals, with the appropriate restrictions on which commands are available to them. Person B does not have access to the middle and last versions of the Key Part Import command, or the Key Import command, person C cannot use the rst Key Part Import command, and person E is prevented from using any version of the Key Part Import command. Furthermore, person C does not have access to the key being transferred, although he was given the imported key. Although these restrictions are weaker than those suggested in the paper where only the necessary commands are available to each person they all ensure that at least one of the three requirements for the attack are missing. That is, none of them give the attacker access to a Key Part Import command, the Key Import command and the key being transferred. The models checked for the intruder being able to change the type of the PDK (the Key Import Attack), obtain the clear value of a secret key, and obtain the arbitrary PAN encrypted under the PDK. The results of the verication runs using the standard command set are shown in table 6.2, with no attack being found up to the bounds checked. With the addition of the Key Generate command, CL-AtSe was only able to verify that no attack existed for a bound of 1 for each person, with higher bounds requiring more memory than was available.
Analysis of Results
The results for person B show that the reachable states only increases by one each time, in line with the bound. On closer inspection of the commands available to the intruder, this is due to the fact that he only has the necessary terms in his knowledge to use the (modied) rst Key Part Import command. By using that command, he can obtain terms of the following form: { }KMtypeKP |kp| { |kpKEKKP1| KMIMP }
59
Model
Bound 1 2 3
States Analysed 9 14 19 24 29 34 29 113 413 9 14 19 24 29 34 39 44 49 54
Reachable States 1 2 3 4 5 6 4 18 68 1 2 3 4 5 6 7 8 9 10
Run-Time (s) 0.00 0.05 0.47 3.77 31.23 330.53 >3600 0.01 0.55 58.83 >3600 0.00 0.00 0.00 0.01 0.01 0.01 0.01 0.01 0.01 0.02
Person B
4 5 6 7 1 2
Person C
3 4 1 2 3 4 5
Person E
6 7 8 9 10
Table 6.2: Results for the verication of IBMs second recommendation using CL-AtSe.
where the left-hand term is the intermediate encrypted key part returned by the command, and the right-hand term is the subsequently completed full key. Note that kp is the clear key part provided as input to the command, and KP1 is the rst key part given to the intruder. Neither of these formats correspond to input parameters of any of the available commands, are are therefore useless to the intruder. As a result, all he can do is keep generating terms of the above form, with varying values for kp and type. Since the intruder cannot generate terms which can be used, he will never be able to mount an attack of any form. Note however, that this argument only holds when the intruder does not use the available commands to conjure keys. While the results for person C suggest that they are able to carry out a much greater range of command calls, they too are quite limited in what additional knowledge can be obtained. Initially, the intruder is able to call the middle and last Key Part Import commands, adding
60
new terms of the following format to his knowledge: { |kpKEKKP3| KMIMPKP } { |kpKEKKP3| KMIMP }
where the terms are returned by the middle and last versions of the Key Part Import command respectively. Similarly to before, kp is the clear key part provided as input to the commands, and KP3 is the nal key part given to the intruder. Only the left-hand term can be used by the intruder, as he does not have the required additional knowledge to use the commands that would accept the right-hand term. The lefthand term can only be used with the two Key Part Import commands, and therefore does not provide the intruder with anything useful he can only continue to create terms of the above form. The number of reachable states reects how many different options the intruder has when calling the Key Part Import commands. Again however, this argument only holds when the intruder does not use the available commands to conjure keys. The results for person E are almost identical to those for person B, and for the same reason. He only has the required knowledge to use the Key Import command with the key being transferred, and thus obtain the imported key. The imported key cannot be used with any commands and therefore, the intruder can only carry out the same import step again. Since no further new terms can be added to the intruders knowledge, the verication takes a trivial amount of time. As with the previous two cases though, this argument only holds when the intruder does not use the available commands to conjure keys. Models where the intruder was able to use the available commands to conjure keys were checked, but CL-AtSe was only able to verify that no attack existed for person B and a bound of 1. All other runs required more memory than was available, due to the large number of keys that the intruder could generate.
6.3
Recommendation 3
IBMs third recommendation is to ensure that no single person has the opportunity to carry out the steps necessary to the attack, by tightly controlling the environment in which keys are entered. The most obvious course of action which IBM recommend is to distribute each key part to two separate individuals one of whom enters the key part, and the other who veries that the entered data is the same as his copy. Another option is to monitor and log each key entry operation, so that suspicious actions can be traced to the person responsible. With respect to the commands provided by the CCA API, a key verication pattern can be distributed to an individual who is not responsible for entering the key parts. This person can
61
then verify that the key has been correctly added. The goal here is to ensure that the exporttype key encryption key used by the source security module is the same as the import-type key encryption key used by the destination security module. If they are identical, then no type change can take place when the key being transferred is imported. The last point that IBM make in this recommendation is that the people responsible for entering the key parts are generally not systems programmers and would therefore be unable to make use of the modied key. Overall, IBM argue that, while the attack may be possible in theory, sufcient procedural restrictions will make it impossible in reality.
The only part of this recommendation which directly relates to API usage is the suggestion that the loading of the initial key encryption key should be veried before additional keys are transferred to the security module. This was included implicitly in the model, by modifying the Key Import command so that it would only accept the correct key encryption key. This simulates the assumption that an incorrect key would be identied and deleted from the security module, before it could be used to import any of the keys being transferred. The intruder was provided with the same initial knowledge and capabilities as required for the Key Import Attack. That is, the nal key part, the initial encrypted key parts, and the key being transferred. The results are shown in table 6.3. Bound 1 2 3 4 States Analysed 46 687 13133 Reachable States 8 136 2625 Run-Time (s) 0.02 5.17 2827.35 Out of Memory
Table 6.3: Results for the verication of IBMs third recommendation using CL-AtSe.
Note that the security of this recommendation relies on the assumption that the intruder is not able to generate the modied KEK, take a copy of it, then delete it and generate the correct KEK, before using the copy to import the key being transferred once the verication procedure has been carried out. As outlined in the recommendation, proper procedural and environmental controls should prevent any one individual from gaining the opportunity to generate the necessary modied KEK, or at the very least detecting when such a event has occurred.
62
Analysis of Results
The commands initially available to the intruder are the same as for person C in recommendation two, although he is given the PIN derivation key before it is imported rather than being given it in an already imported state. However, while this means that the intruder can now use the Key Import command from the second step onwards (once he has created a complete import-type key encryption key), the model restricts him to only using the correct KEK. As a result, the variety of import-type KEKs and KEK-parts which the intruder can generate are useless. Therefore, once the intruder has generated the correct key encryption key and imported the PDK, there is nothing more of use that he can do. Of course, as with the equivalent analysis of the results from recommendation two, this argument only applies when the intruder does not use the available commands to conjure keys.
6.4
Overall Conclusions
We have shown that, in certain scenarios, each one of IBMs recommendations may not prevent someone from modifying the value of the initial key encryption key being transferred to a security module. However, our experiments were primarily considered the aspects of the recommendations that related to the API, that is the suggested availability of commands and assumed knowledge of the individual. As IBM point out, tight procedural controls are able to prevent an attack. What we have shown is that these procedural controls are necessary, and it is not enough to rely solely on the separation of duty provided by the Key Part Import command. The rst recommendation to use public key techniques potentially opens the door to a more serious attack. Even still though, logging when users call the PKA Symmetric Key Import command would detect inappropriate use, thus acting as a deterrent to potential attackers. The second recommendation to make proper use of the access control system gives the greatest protection against the attack, provided that the individuals involved in the key loading process are not provided with dangerous combinations of commands. Furthermore, the individual who is responsible for generating the key parts must not be involved in any other part of the process. Provided that these conditions are met, IBMs suggested transfer procedure is sufcient to prevent an attack. The third recommendation ensuring that the attacker never has the opportunity to execute the attack should work in theory, although simply using the Key Test command to verify the key encryption key may not be enough. It should be made clear that these conclusions, and the results presented in this chapter, do not take into consideration the possibility of an attacker using brute-force key-breaking techniques
63
such as parallel key search (pg. 22). However, such attacks require a prolonged period of exposure to the security module, and a signicant number of repeated command calls. Therefore, it is likely that procedural controls such as logging of command usage would detect, and potentially prevent, these kind of attacks.
Safety Precautions
The analysis of known attacks, and of IBMs recommendations, have shed light on a number of important points concerning the CCA API and its use. While the majority have already been identied, they are signicant enough to collectively present again here. The rst and last, or rst and complete, versions of the Key Part Import command should never be enabled in the same role. Together these commands allow for arbitrary known keys to be introduced into the security module. This restriction could quite easily be enforced by the CCA. The person responsible for importing working keys into a new security module should not be responsible for adding any of the parts of the key encryption key used in the transfer. This can be enforced at the API level by ensuring that the Key Import command cannot be enabled in any role that has one of the Key Part Import command variants enabled. The person(s) responsible for generating the key parts should not be involved with any other parts of the key transfer process, except for possibly the verication of the key encryption key. This cannot be enforced by the CCA, since the key parts can be generated without a security module. For greater security, key parts should be added twice, by different people. The key should then only be used if both complete versions are the same. Once again, such a procedure could be enforced by the API. For example, each version of the key could be stamped with a unique identier, and the complete Key Part Import command, which would now require two incomplete keys, could use these to determine that they are actually distinct. Obviously, the unique identier would have to be in an encrypted form. The different versions of the Key Part Import command should only be enabled for a short time when the initial key encryption key is being built up. The last and complete forms can be used to conjure key parts, which can then be modied using the last or add and complete forms. Public key techniques should only be used if the data block used to import keys with the PKA Symmetric Key Import command cannot be created by an individual. Additionally,
64
care should be taken to ensure that the correct public key is being used to transfer the key encryption key. No person should have access to the two commands required to register a public key with the security module, as this would allow for arbitrary public keys to be added. As before, the CCA could enforce this. Each role should only provide the minimal set of commands required to undertake the designated job, and individuals should not be assigned to more than one role. Where appropriate, roles should also place a restriction on the number of times that the user can execute particular commands. For example, there is no legitimate reason for someone who is adding a key part to use the command more than once. It should not be possible for a single person to create or modify roles, or enable any of the commands. This would prevent security module administrators from abusing their positions.
6.5
Summary
We have presented the three recommendations made by IBM in response to Bonds Key Import Attack. Each recommendation is concerned with a different aspect of the security modules usage. It was shown that, under certain assumptions, the recommendations may not prevent the attack, and may also leave the door open for more serious security breaches. However, under revised assumptions, each of the three recommendations were shown to prevent any attack. These revised assumptions formed the basis for a set of more specic recommendations, aimed more towards the implementation of the CCA itself.
Chapter 7
Discussion
One of the aims of this thesis was to investigate how the analysis of security APIs differs from the analysis of conventional security protocols, and to determine how existing model checking tools perform on real-world examples. This chapter presents a discussion of these topics, based on our experiences over the course of this work, and covers various points from across the analysis, modelling, and verication stages.
7.1
Differences Between Security APIs and Security Protocols
In general, there are a number of basic differences between security APIs and security protocols that result in the analysis of the former being conceptually somewhat simpler: There are only two agents the security module and the intruder. The intruder communicates directly with the security module. The intruder is only trying to obtain sensitive pieces of data (including clear values of cryptographic keys). The security module is typically stateless it is simply a reactive agent that responds in a deterministic manner to commands from the user. This last point, in combination with the fact that the intruders knowledge is monotonic, can be used to potentially reduce the number of terms that need to be considered at each step of the analysis. This is discussed in further detail in section 7.3. However, there are a couple of points which result in security APIs being considerable harder to verify: There is no enforced ordering on the interactions between the intruder and the security module.
65
Chapter 7. Discussion
66
Security modules may make use of operators with non-trivial algebraic properties, such as exclusive-or. The non-determinism resulting from the rst of these causes the search space to be far larger, and is the primary reason for security API analysis being so difcult. The latter point is also responsible for increasing the search space, although the effects can be tempered by efcient handling of the algebraic properties.
7.2
Modelling Security APIs
As was shown by the experiments to rediscover known attacks, the most important factor in minimising the search space is to ensure that the intruder does not start with, and is not able to generate, unnecessary terms. With respect to the modelling of the API,1 this amounts to ensuring that superuous commands are not included, or at the very least, are only added once the smaller command set has been veried. This can be determined by looking at the format of the input and output parameters of the commands. Commands which do not output terms that can be used by the intruder as input to other commands, and cannot be combined to form such a term, only serve to give the intruder an excessive amount of useless knowledge. It was for this reason that the Key Test command was not included in our models of IBMs CCA API. Furthermore, the output from commands which add arbitrary terms of a particular form (e.g. the Key Generate command) need to be carefully considered. It may be the case that multiple versions of essentially equivalent terms (e.g. many data keys with unknown, and unrelated, values) will be of no use to the intruder. This is why our models did not include all variants of the Key Generate command. In future though, as the tools used to carry out the verication process become better, and computing resources become more powerful and possess greater amounts of memory, then the points outlined in this section will be of lesser importance. After all, if it is possible to prove, beyond a shadow of a doubt, that no attacks exist given the entire command set, then there is no need to identify which ones are can be safely ignored. However, these points given an insight into particular methods that future purpose-built verication tools may employ in order to be able to check entire API command sets.
1 The
intruders ability to generate new terms is discussed in secion 7.4.
67
7.3
Model Checking Tools
One of the biggest disadvantages that CL-AtSe has over theorem provers, when applied to our models, is caused by how it interprets the idea of a bound on the search. While theorem provers will typically increment the number of commands that are applied in succession, CL-AtSe increments the number of times that a command can be applied. This means that the upper bound on the length of the attack being searched for will increase by the number of commands that have been modelled. For example, in the Import / Export Loop Attack (which has seven steps), a couple of the commands are required twice, so because there are eight commands in the model, CL-AtSe will consider certain paths with up to sixteen commands. This issue would be avoided by having each command as a separate transition within one big role, but that causes CL-AtSe to spend a massive amount of time trying to determine optimisations based on all possible interleavings of the various commands. Note that this is distinct from the initial simplication step, which can be disabled. The fact that the intruders knowledge is monotonic means that, at any given point, the API commands simply dene how additional terms can be obtained. At the each step of the search, it will be possible to carry out the exact same command call(s) as in the previous step, and possibly some new ones. It should be clear that, in order for the search to be efcient, only the new command calls should be considered. That is, for breadth-rst search, command calls that do not involve at least one new term can be ignored (as they will already have been considered), and for depth-rst search, only commands that add new terms should be candidates (otherwise they will not progress the search). From the perspective of unication, this means that, in the breadth-rst case, the part of the unier which corresponds to the input parameters of the command must involve at least one term obtained in the previous step. Similarly, in the depth-rst case, the part of the unier which corresponds to the return data from the command must contain at least one term obtained in the previous step. Another issue that needs to be considered is the in-built support for less abstract features, such as key parity, and how it affects other operators. For example, if the parity was modelled by two functions on the key, say even() and odd(), then the exclusive-or operator would have to contain the following additional rules: even(X) even(Y ) = even(XY ) even(X) odd(Y ) = odd(XY ) odd(X) odd(Y ) = even(XY ) As it stands, the ability to provide a user-dened theory le in OFMC is a great advantage, as this is very close to the complete exibility provided by theorem provers. It is just unfortunate
68
that we have been unable to use OFMC in our experiments and demonstrate this feature.
7.4
Intruder Capabilities
As well as being able to use commands to obtain additional knowledge, the intruder can use his own abilities to do so, free from any interaction with the device providing the security API. The intruders own ability to generate new terms is generally responsible for the huge size of the search space, as the number of terms that he can add at any given step is typically innite. The reason for this is that the intruder can take any two known terms and encrypt each one under itself, and under the other. This can then be repeated indenitely. Adding in an operator like exclusive-or simply exaggerates this problem further, especially when the cancellation properties are not taken into account. However, Cortier and Steel have recently shown that only a very small subset of all these possible terms need to be considered [15]. This subset can be generated by restricting the abilities of the intruder to only taking the exclusive-or of unencrypted terms, and not using encrypted terms in new encryptions. That is, only add XY and { }Y if both X and Y are |X| unencrypted terms. This restriction results in the set of new terms that the intruder can generate at any given step being nite. Currently, with CL-AtSe at least, the intruder is able to provide arbitrary new terms of the different types provided. However, he is not able to provide arbitrary new encrypted terms, where certain values are unknown. For example, given the Key Import command, the intruder cannot provide { |unknown| KEKtype as the key to be imported. } Allowing the intruder to do this would mean that he could conjure input parameters for potentially any command. Of course, such an ability would have to be tempered in order to prevent the intruder conjuring the precise value of a key. Using the Key Import command as an example again, the intruder should not be able to conjure the import-type key encryption key, since in reality there is a 1 in 2112 chance of getting it right. A consequence of this is that there would be no need to explicitly add variations of the commands which capture the conjuring process. Obviously, such an ability would increase the search space by some factor, but would increase the accuracy of the model.
7.5
Summary
We have outlined the main differences between security APIs and security protocols, describing how they make analysing the former considerably more difcult. The effect of useless terms in the intruders knowledge (i.e. terms which cannot be used to gain anything of worth) was discussed, as were methods by which they could be reduced. We also looked at points which
69
should be taken into consideration for the actual search, and highlighted possible features that future tools may have to provide. Finally, the ofine capabilities of the intruder were discussed, with suggestions as to how they should be modied so as to be better suited to the verication of security APIs.
Chapter 8
Conclusions
We have demonstrated the rst application of a model checker (CL-AtSe) to the problem of security API analysis, and showed that it is able to rediscover all known attacks on IBMs Common Cryptographic Architecture API. We had originally planned on using two model checkers, but our models exposed a bug in OFMC which prevented it from nding any of the attacks. Overall, the results from our initial attack rediscovery experiments were a success, although one or two were slightly worse than expected. Furthermore, CL-AtSe found a variant of one of the attacks which we believe had not previously been known. Part of the reason for this is that the Key Translate command, which was required for the attack, has not traditionally been modelled. This quite clearly shows the importance of developing tools that can handle as many commands as possible. The second part of our experiments involved verifying the recommendations published, in response to Bonds Key Import Attack, by IBM. They had never been formally veried before, and it was unknown whether or not they did indeed prevent the attack. We showed, that under certain assumptions, the attack was still possible, as was a more serious attack. By revising our assumptions, we were able to show that the recommendations were sufcient to prevent any known API attack. These revised assumptions formed the basis for our own set of recommendations that were aimed at the design, implementation, and use of the API itself. Unfortunately, we were unable to verify the recommendations beyond a bound of 1, when the intruder was assumed to be able to use the available commands to conjure keys. This was in line with the overall perception that any command which added a large number of keys to the intruders knowledge caused the search space to be too large. CL-AtSe was designed to verify properties of security protocols, and part of our work was concerned with determining how it coped with the more complex task of analysing security
70
Chapter 8. Conclusions
71
APIs. While the results achieved with CL-AtSe were generally better than with other methods, the experiments highlighted a number of issues that should be considered in the design of tools used for the analysis of security APIs. Overall, while our results show that progress is being made, it is clear that there is still more to be done before API command sets can be veried in their entirety without having potentially restrictive assumptions placed upon the intruder.
8.1
Related Work
The application of formal methods to the analysis of security APIs has traditionally involved the use of theorem provers, since they provide much greater exibility than model checkers. This exibility has been necessary to enable the algebraic properties of operators such as exclusiveor to be handled efciently, and to properly model the abilities of the intruder. Youn et al. have demonstrated some success using Otter [31], and Steel has also shown promising results with a modied version of daTac [26]. The other line of research, as demonstrated in this thesis, is the use of tools designed for security protocol analysis, as they already employ an intruder-based communication model. Herzog is currently pursuing this approach, although at the time of writing, only a brief mention of his intentions is available [20]. A fair amount of recent work has focused on exactly how security APIs differ from security protocols in terms of the analysis required, with Bond and Clulow having looked into the discovery of lower level attacks [9]. Restricting the intruders knowledge, while still ensuring completeness, is also an active area of research, with Cortier and Steel having recently proven the validity of one of the more common ways of achieving this [15].
8.2
Future Directions
We are at the stage where a great deal has been learned about the process of security APIs analysis, and some of the problems which have been identied are beginning to solved. From where the eld stands now, we foresee research continuing in the following directions: The development of purpose-built verication tools for the analysis of security APIs. Investigation into ways of representing less abstract features of security APIs in order to look for information leakage attacks, or to rely less on the perfect encryption model. Investigation into ways, either automatic or manual, to reduce the search space by means of identifying which terms are of no use to the intruder, and can be ignored.
Chapter 8. Conclusions
72
The development of verication methods that are able to prove that no attack exists for an unbounded number of command calls, ideally with a formal proof provided as output. The development of more realistic intruder models that incorporate abilities such as key conjuring through command misuse. We can only hope that sufcient developments will be made to ensure that the security devices which are becoming an increasing part of our everyday lives are capable of upholding the trust that we place in them.
Appendix A
Command Notation
The notation used to represent the semantics of the API commands in this thesis is based on the standard Alice-Bob notation. It is used to represent the exchange of messages between two agents, traditionally called Alice and Bob:
AB:M
A B : M 1. M 2
A B : M1 , M2 , . . . , Mn
where the concatenation of two messages is represented by a period, and multiple messages sent at the same time are separated by commas. Encrypted messages are represented as follows:
{ }key |M|
where key is a public or symmetric key. Finally, the exclusive-or of two terms is represented by:
T1 T2
For example, the Encipher command accepts a message from the user, along with a symmetric key that is encrypted under the exclusive-or of the security modules master key and the data type control vector:
User HSM : X , { |KEY| KMDATA } HSM User : { }KEY |X|

The security module then returns the message encrypted under the symmetric key.
73
Appendix B
HLPSL Model of IBMs CCA API

This appendix contains the HLPSL representation of the commands that were used across the all of the experiments. The modied versions of the rst Key Part Import and Key Import commands used in the verication of IBMs second and third recommendations are not given. The roles are split into three sections covering the API commands, those used to conjure keys, and any additional roles used. Furthermore, the session and environment roles are given for these commands along with the intruders default knowledge.
Command Roles
role encipher(HSM : agent, Snd, Rcv : channel(dy)) played_by HSM def= local X : message, K1 : symmetric_key
% Arbitrary data % An arbitrary data key
transition encipher. Rcv(X.{K1}_xor(km,data_CV)) =|> Snd({X}_K1) end role role decipher(HSM : agent, Snd, Rcv : channel(dy)) played_by HSM def= local X : message, K1 : symmetric_key
% Arbitrary data % An arbitrary data key
transition decipher. Rcv({X}_K1.{K1}_xor(km,data_CV)) =|> Snd(X) end role
74
Appendix B. HLPSL Model of IBMs CCA API
75
role keyImport(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local K1 : symmetric_key, KEK1 : symmetric_key, TYPE : nat transition keyImport. Rcv({K1}_xor(KEK1,TYPE).TYPE.{KEK1}_xor(km,imp_CV)) /\ in(TYPE,KeyTypes) =|> Snd({K1}_xor(km,TYPE)) end role
% An arbitrary key % An arbitrary key encrypting key % An arbitrary key type control vector
role keyExport(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local K1 : symmetric_key, KEK1 : symmetric_key, TYPE : nat transition keyImport. Rcv({K1}_xor(km,TYPE).TYPE.{KEK1}_xor(km,imp_CV)) /\ in(TYPE,KeyTypes) =|> Snd({K1}_xor(KEK1,TYPE)) end role
% An arbitrary key % An arbitrary key encrypting key % An arbitrary key type control vector
role keyPartImport1(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local KP1 : symmetric_key, TYPE : nat transition keyPartImport1. Rcv(KP1.TYPE) /\ in(TYPE,KeyTypes) =|> Snd({KP1}_xor(km,kpart_CV,TYPE) end role
% An arbitrary key part % An arbitrary key type control vector
76
role keyPartImport2(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local KP_old : symmetric_key, KP_new : symmetric_key, TYPE : nat transition keyPartImport2. Rcv(KP_new.{KP_old}_xor(km,kpart_CV,TYPE).TYPE) /\ in(TYPE,KeyTypes) =|> Snd({xor(KP_new,KP_old)}_xor(km,kpart_CV,TYPE)) end role
% An arbitrary old key part % An arbitrary new key part % An arbitrary key type control vector
role keyPartImport3(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local KP_old : symmetric_key, KP_new : symmetric_key, TYPE : nat transition keyPartImport3. Rcv(KP_new.{KP_old}_xor(km,TYPE,kpart_CV).TYPE) /\ in(TYPE,KeyTypes) =|> Snd({xor(KP_old,KP_new)}_xor(km,TYPE)) end role
% An arbitrary old key part % An arbitrary new key part % An arbitrary key type control vector
role keyTranslate(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local K1 : symmetric_key, KEK1,KEK2 : symmetric_key, TYPE : nat transition keyTranslate. Rcv({K1}_xor(KEK1,TYPE).TYPE.{KEK1}_xor(km,imp_CV). {KEK2}_xor(km,exp_CV)) /\ in(TYPE,KeyTypes) =|> Snd({K1}_xor(KEK2,TYPE)) end role
% An arbitrary key % Arbitrary key encrypting keys % An arbitrary key type control vector
77
role keyGenerateOP(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local K1 : symmetric_key, TYPE : nat transition keyGenerateOP. Rcv(TYPE) /\ in(TYPE,KeyTypes) =|> K1:=new() /\ secret(K1,key_val,{HSM}) /\ Snd({K1}_xor(km,TYPE)) end role
% An arbitrary key % An arbitrary key type control vector
Key Conjuring Roles

role conjureKeyPart(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local KEY : symmetric_key, TYPE : nat transition conjureKeyPart. Rcv(TYPE) /\ in(TYPE,KeyTypes) =|> KEY := new() /\ secret(KEY,key_val,{HSM}) /\ Snd({KEY}_xor(km,TYPE,kpart_CV).{KEY}_xor(km,TYPE)) end role role conjureUnknownKey(HSM : agent, Snd, Rcv : channel(dy), KeyTypes : nat set) played_by HSM def= local KEK : symmetric_key, TYPE : message, KEY_C : symmetric_key transition conjureUnknownKey. Rcv(TYPE.{KEK}_xor(km,imp_CV)) /\ in(TYPE,KeyTypes) =|> KEY_C := new() /\ secret(KEY_C,key_val,{HSM}) /\ Snd({KEY_C}_xor(KEK,TYPE).{KEY_C}_xor(km,TYPE)) end role
% Completed key that parts are conjured from % An arbitrary key type control vector
% An arbitrary key encrypting key, of type imp_CV % An arbitrary key type control vector % The (unknown) conjured key
78
Additional Roles
role dataCVisZero(HSM : agent, Snd, Rcv : channel(dy)) played_by HSM def= local X,Y : message transition dataCVisZero_1. Rcv({xor(X,data_CV)}_Y) =|> Snd({X}_Y) dataCVisZero_2. Rcv({X}_xor(Y,data_CV)) =|> Snd({X}_Y) end role
% Arbitrary terms
Session Role
role session(HSM : agent, KeyTypes : nat set) def= local SndHSM, RcvHSM : channel(dy), PDK : symmetric_key
% Communication channels for the HSM % Unencrypted PIN derivation key
init % hlpsl2if doesnt like external constants being used to encrypt PDK := pdk % The intruder should not be able to obtain the PDK in the clear /\ secret(pdk, key_val, {HSM}) % The intruder should not be able to obtain the arbitrary % primary account number encrypted under the PIN derivation key /\ secret({pan}_PDK, the_PIN, {HSM}) composition encipher(HSM, SndHSM, RcvHSM) decipher(HSM, SndHSM, RcvHSM) keyImport(HSM, SndHSM, RcvHSM, KeyTypes) keyExport(HSM, SndHSM, RcvHSM, KeyTypes) keyPartImport1(HSM, SndHSM, RcvHSM, KeyTypes) keyPartImport2(HSM, SndHSM, RcvHSM, KeyTypes) keyPartImport3(HSM, SndHSM, RcvHSM, KeyTypes) keyTranslate(HSM, SndHSM, RcvHSM, KeyTypes) keyGenerateOP(HSM, SndHSM, RcvHSM, KeyTypes) conjureKeyPart(HSM, SndHSM, RcvHSM, KeyTypes) conjureUnknownKey(HSM, SndHSM, RcvHSM, KeyTypes) dataCVisZero(HSM, SndHSM, RcvHSM)
/\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\
end role
79
Environment Role
role environment() def= local KeyTypes : nat set const theHSM, i : agent, % Public data_CV imp_CV exp_CV kpart_CV pin_CV control vectors : nat, : nat, : nat, : nat, : nat,
% Set of key types
% HSMs secret keys km : symmetric_key, kek : symmetric_key, pdk : symmetric_key, data : symmetric_key, % Arbitrary PAN pan : nat, % Things which should remain secret key_val : protocol_id, the_PIN : protocol_id init KeyTypes := {data_CV, imp_CV, exp_CV, pin_CV} intruder_knowledge = {% Control vectors data_CV, imp_CV, exp_CV, pin_CV, kpart_CV, % Working keys {pdk}_xor(km,pin_CV), {kek}_xor(km,imp_CV), {data}_xor(km,data_CV), % An arbitrary primary account number pan } composition session(theHSM, KeyTypes) end role goal secrecy_of key_val secrecy_of the_PIN end goal environment()
Bibliography
[1] R. Anderson. Why Cryptosystems Fail. Communications of the ACM, 37(11):3240, Nov. 1994. Earlier version available at http://www.cl.cam.ac.uk/users/rja14/wcf.html. [2] R. Anderson. The Correctness of Crypto Transaction Sets, 8th International Workshop on Security Protocols, Cambridge, UK, Apr. 2000. http://www.cl.cam.ac.uk/ftp/users/rja14/protocols00.pdf. [3] R. Anderson, M. K. Bond, J. Clulow, and S. Skorobogatov. Cryptographic Processors A Survey. Proceedings of the IEEE, 94(2):357369, Feb. 2006. [4] R. J. Anderson and M. G. Kuhn. Low Cost Attacks on Tamper Resistant Devices. In B. Christianson, B. Crispo, M. Lomas, and M. Roe, editors, Security Protocols: 5th International Workshop, volume 1361 of Lecture Notes in Computer Science, pages 125136. Springer-Verlag, Apr. 1997. [5] A. Biere, A. Cimatti, E. M. Clarke, and Y. Zhu. Symbolic Model Checking without BDDs. In R. Cleaveland, editor, TACAS 99: Proceedings of the 5th International Conference on Tools and Algorithms for Construction and Analysis of Systems, volume 1579 of Lecture Notes in Computer Science, pages 193207. SpringerVerlag, Mar. 1999. [6] M. K. Bond. Attacks on Cryptoprocessor Transaction Sets. In Cetin K. Koc, D. Naccache, and C. Paar, editors, Cryptographic Hardware and Embedded Systems CHES 2001: Third International Workshop, volume 2162 of Lecture Notes in Computer Science, pages 220234. Springer-Verlag, May 2001. [7] M. K. Bond. Understanding Security APIs. PhD thesis, University of Cambridge, Jan. 2004. [8] M. K. Bond and R. Anderson. API-Level Attacks on Embedded Systems. Computer, 34(10):6775, Oct. 2001. [9] M. K. Bond and J. Clulow. Extending Security Protocol Analysis: New Challenges. Electronic Notes in Theoretical Computer Science, 125(1):1324, Mar. 2005. [10] M. K. Bond and P. Zielinski. Decimalisation Table Attacks for PIN Cracking. Tech-
nical Report 560, University of Cambridge Computer Laboratory, Feb. 2003. http://www.cl.cam.ac.uk/TechReports/. [11] CCA Basic Services Reference and Guide, Release 2.54, Dec. 2004. 2 54.pdf.
Available from
Available online at
http://www-03.ibm.com/security/cryptocards/pdfs/IBM 4758 Basic Services Manual Release
[12] A. Cimatti, E. M. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore, M. Roveri, R. Sebastiani, and A. Tacchella. NuSMV 2: An OpenSource Tool for Symbolic Model Checking. In E. Brinksma and K. G. Larsen, editors, Proceedings of Computer Aided Verication: 14th International Conference (CAV 2002), volume 2404 of Lecture Notes in Computer Science, pages 359364. Springer-Verlag, July 2002. [13] E. M. Clarke, Jr., O. Grumberg, and D. Peled. Model Checking. MIT Press, 1999. [14] J. Clulow. The Design and Analysis of Cryptographic APIs for Security Devices. Masters thesis, University of Natal, Durban, Jan. 2003.
80
Bibliography
81
[15] V. Cortier and G. Steel. On the Decidability of a Class of XOR-Based Key-Management APIs. In P. Degano, R. K sters, L. Vigan` , and S. Zdancewic, editors, Proceedings of the Joint Workshop on Foundations of u o Computer Security and Automated Reasoning for Security Protocol Analysis (FCS-ARSPA), Aug. 2006. To appear. [16] J. Courant and J.-F. Monin. Defending the Bank with a Proof Assistant. In D. Gollmann and J. J rjens, u editors, Proceedings of the 6th International Workshop on Issues in the Theory of Security (WITS 06), pages 8798, Mar. 2006. [17] Data Encryption Standard (DES), Dec. 1993. Federal Information Processing Standards publication 46-2. Available online at http://www.itl.nist.gov/fipspubs/fip46-2.htm. [18] M. Fitting. First-Order Logic and Automated Theorem Proving. Springer-Verlag, 1990. [19] V. Ganapathy, S. A. Seshia, S. Jha, T. W. Reps, and R. E. Bryant. Automatic Discovery of API-Level Exploits. In ICSE 05: Proceedings of the 27th International Conference on Software Engineering, pages 312321. ACM Press, May 2005. [20] J. Herzog. Applying Protocol Analysis to Security Device Interfaces. IEEE Security and Privacy, 4(4):8487, 2006. [21] Deliverable D2.1: The High Level Protocol Specication Language, Aug. 2003. http://www.avispa-project.org/delivs/2.1/d2-1.pdf. [22] G. J. Holzmann. The SPIN Model Checker: Primer and Reference Manual. Addison Wesley Professional, 2003. [23] IBM Comment on A Chosen Key Difference Attack on Control Vectors, Jan. 2001. Available from http://www.cl.cam.ac.uk/mkb23/research.html. [24] Deliverable D2.3: The Intermediate Format, Aug. 2003. Available online at Available online at
http://www.avispa-project.org/delivs/2.3/d2-3.pdf. [25] B. Schneier. Applied Cryptography. John Wiley & Sons, 2nd edition, 1996. [26] G. Steel. Deduction with XOR Constraints in Security API Modelling. In Proceedings of the 20th International Conference on Automated Deduction (CADE 20), pages 322336. Springer-Verlag, July 2005. [27] A. Valmari. The State Explosion Problem. In W. Reisig and G. Rozenberg, editors, Lectures on Petri Nets I: Basic Models: Advances in Petri Nets, volume 1491 of Lecture Notes in Computer Science, pages 429528. Springer-Verlag, June 1998. [28] L. Vigneron. Associative-Commutative Deduction with Constraints. In A. Bundy, editor, Automated Deduction CADE-12: 12th International Conference on Automated Deduction, volume 814 of Lecture Notes in Computer Science, pages 530544. Springer-Verlag, June 1994. [29] C. Weidenbach, B. Afshordel, U. Brahm, C. Cohrs, T. Engel, E. Keen, C. Theobalt, and D. Topi . System c Description: S PASS version 1.0.0. In H. Ganzinger, editor, CADE-16: Sixteenth International Conference on Automated Deduction, volume 1632 of Lecture Notes in Articial Intelligence, pages 378382. SpringerVerlag, July 1999. [30] P. Youn. The Analysis of Cryptographic APIs using the Theorem Prover Otter. Masters thesis, Massachusetts Institute of Technology, May 2004. [31] P. Youn, B. Adida, M. K. Bond, J. Clulow, J. Herzog, A. Lin, R. L. Rivest, and R. Anderson. Robbing the Bank with a Theorem Prover. Technical Report 644, University of Cambridge Computer Laboratory, Aug. 2005. Available from http://www.cl.cam.ac.uk/TechReports/. [32] AVISPA Tool Set. Available from http://www.avispa-project.org/.
Bibliography
82
[33] CL-AtSe: Constraint Logic Based Attack Searcher. Available from http://www.loria.fr/equipes/cassis/softwares/AtSe/. [34] Coq Proof Assistant. Available from http://coq.inria.fr/. [35] OFMC: On-the-Fly Model Checker. Available from http://www.inf.ethz.ch/personal/moederss/research/. [36] Otter: An Automated Deduction System. Available from http://www-unix.mcs.anl.gov/AR/otter/.

Model Checking Security Apis: Gavin Keighren

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Model Checking Security Apis: Gavin Keighren

Uploaded by

Copyright:

Available Formats

Model Checking Security APIs

Master of Science Articial Intelligence School of Informatics University of Edinburgh 2006

List of Tables 1 Introduction 1.1 1.2 2 Thesis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction to Security APIs 2.1 2.2 2.3

History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Selected Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17

Literature Review 3.1 3.2 3.3 3.4 3.5 3.6

Overview of IBMs CCA API 4.1 4.2 4.3 4.4

Rediscovery of Known Attacks 5.1 5.2 5.3 5.4

Verication of IBM Recommendations 6.1 6.2 6.3 6.4 6.5

Discussion 7.1 7.2 7.3 7.4 7.5

Conclusions 8.1 8.2

Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 73 74 80

A Command Notation B HLPSL Model of IBMs CCA API Bibliography

Introduction to Security APIs

Chapter 2. Introduction to Security APIs

Chapter 2. Introduction to Security APIs

Chapter 2. Introduction to Security APIs

Chapter 2. Introduction to Security APIs

Chapter 2. Introduction to Security APIs

Chapter 2. Introduction to Security APIs

Chapter 3. Literature Review

Pure API Command Attacks

Appendix A for an overview of the notation used to describe command semantics.

Chapter 3. Literature Review

HSM Printer : KP1 HSM Host :{ |KP1| KM }

HSM Printer : KP2 HSM Host :{ |KP2| KM }

Chapter 3. Literature Review

Host HSM : TCK HSM Host : { |TCK| KM2 }

Host HSM : PAN HSM Host : { |PAN| KM2 }

Chapter 3. Literature Review

Host HSM : KP1 , TYPE HSM Host : { |KP1| KMKPTYPE }

Brute Force Attacks

Chapter 3. Literature Review

Parallel Key Search

Chapter 3. Literature Review

Chapter 3. Literature Review

Chapter 3. Literature Review

Information Leakage Attacks

Chapter 3. Literature Review

ACCOUNT N UMBER E NCRYPTED A/C N O . T RUNCATED VALUE D ECIMALISATION TABLE

Formal Analysis Methods

Chapter 3. Literature Review

Chapter 3. Literature Review

Chapter 3. Literature Review

Chapter 3. Literature Review

Overview of IBMs CCA API

Chapter 4. Overview of IBMs CCA API

Chapter 4. Overview of IBMs CCA API

Appendix A for an overview of the notation used to describe the commands.

Chapter 4. Overview of IBMs CCA API

Clear Key Import

User HSM : KP1 , TYPE HSM User : { |KP1| KMKPTYPE }

User HSM : { |KEY| KMKPTYPE , TYPE } HSM User : { |KEY| KMTYPE }

Chapter 4. Overview of IBMs CCA API

User HSM : TYPE1 , TYPE2

Chapter 4. Overview of IBMs CCA API

User HSM : X , TYPE , { |KEY| KMKGN } HSM User : { { }KEY| | |X| }

user can either be a human individual or a computer process

Chapter 4. Overview of IBMs CCA API

Rediscovery of Known Attacks

Chapter 5. Rediscovery of Known Attacks

Chapter 5. Rediscovery of Known Attacks