}w!"#$%&'()+,-./012345<ya

Transcription

1 }w!"#$%&'()+,-./012345<ya MASARYK UNIVERSITY FACULTY OF INFORMATICS Verifying and improving cryptographic key security in PKCS#11 implementations DIPLOMA THESIS Josef Hertl Brno, Spring 2014

2 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Advisor: Adam Rambousek ii

3 Acknowledgement I would like to thank my advisor RNDr. Adam Rambousek for discussions concerning my thesis and provided counsel. I would also like to thank my technical advisor from Red Hat, Mgr. Miloslav Trmač, for all the invaluable help and advice he gave me. Moreover, I would like to thank prof. RNDr. Václav Matyáš, M.Sc., Ph.D. and RNDr. Petr Švenda, Ph.D. for giving me the opportunity to test the developed tool on hardware tokens and for discussions regarding my thesis. Finally, I would like to thank my family and friends for all their help, support and understanding over the course of my whole studies. iii

4 Abstract This thesis deals with automated analysis of PKCS#11 implementations with focus on cryptographic key protection. It analyses the PKCS#11 standard, defines functions critical for cryptographic key protection and designs tests to determine if the implementation of these functions adheres to the standard. It also designs tests for known attacks on PKCS#11 implementations. The most important contribution of the thesis is Caetus, open source tool that automatically performs the designed tests on real PKCS#11 implementations. iv

5 Keywords PKCS#11, Cryptoki, key, cryptography, model checker v

6 Contents 1 Introduction Thesis Outline Terminology PKCS# Standardization Cryptoki PKCS#11 Key Protection Cryptographic Key Attributes Functions Cryptoki Function Input and Output Basic Function Testing Chapter Conclusion Known Attacks on PKCS# Known Attacks Known Attack Table Attack Testing Chapter Conclusion Possible Restrictions to Cryptoki Interface Cryptographic Key Roles Limiting WrapKey and UnwrapKey Cryptographic Strength Restrictions Removing Miscellaneous Simple Key Derivation Mechanisms Chapter Conclusion Model Checking AVISPA Tool HLPSL Language Transcription of PKCS#11 into HLPSL Limitations Chapter Conclusion Java and PKCS# Java Cryptography Architecture Java Wrapper

7 7.3 Sample Code Chapter Conclusion Caetus Tool Structure of the Tool Steps Parameters Complications Chapter Conclusion Tested Tokens NSS OpenCryptoki Softhsm GNT USB Security Token Chapter Conclusion Conclusion Bibliography

8 Chapter 1 Introduction PKCS#11 is a widely implemented standard that defines API for cryptographic tokens. In practice there have been shown many attacks on the standard implementations. This thesis aims to detect incorrect implementations of PKCS#11 standard with regard to stored cryptographic key security. Moreover, the implementations can be vulnerable to certain attacks even if the implementation fully conforms to the standard. Therefore the thesis also aims to detect the possibilities of such attacks and to warn the user or developer about them. Note that this thesis is only concerned with attacks within PKCS#11 API. There may be ways to retrieve the stored keys outside of PKCS#11, e.g. reading the keys from memory. Such attacks, however, are beyond the scope of this thesis. 1.1 Thesis Outline The thesis first outlines the PKCS#11 standard and the Cryptoki API specified by the standard, including the various components of the API. Then the thesis describes the mechanics of cryptographic key protection in Cryptoki. It analyses the individual functions relevant to key protection and defines the first set of tests. Then the thesis performs an analysis of the previously published attacks against keys stored on the device and also outlines the second set of tests with focus on discovering attack vulnerabilities. Afterwards the thesis examines various ways to improve the security of Cryptoki by altering the standard. The discussion of the proposed restrictions takes into consideration their impact on practical usability of the tokens. In order to further evaluate the security of the tokens against possible attacks, the thesis also utilizes model checker software. The results of the previously defined tests are used to compose a model that is sent to a model checker for further analysis. Since the developed software is written in Java, the thesis also examines 3

9 1. INTRODUCTION the Java PKCS#11 wrapper and discusses the advantages and disadvantages against using C for implementation. The most obvious advantage is that the software can be easily deployed on other operating systems, which is particularly useful for testing tokens that only work on Windows. The disadvantage is that the used wrapper does not implement all the Cryptoki functions, but the thesis shows that all these limitations either do not matter to the thesis or they can be worked around. The thesis also presents the developed tool, called Caetus. It describes its principles and mechanics in detail. The last part of the thesis consists of tables with results of token testing and discussion of the results. 1.2 Terminology This section briefly describes the terminology used in the thesis. Most of the expressions are also used by the model checker and are described in detail in [26]. Ka represents a cryptographic key Ka that is in plain and therefore fully known to the user. {Ka}_Kb stands for a cryptographic key Ka encrypted by a cryptographic key Kb. h(ka) means the user knows the handle (2.2) of a cryptographic key Ka, but does not know the key value of Ka. Secret key means a cryptographic key used in symmetric cryptography. In literature this type of key is also commonly called symmetric key. 4

10 Chapter 2 PKCS#11 This chapter provides a brief overview of the PKCS#11 cryptographic standard and its relationship to this thesis. 2.1 Standardization Cryptographic standards serve two important goals: making different implementations inter-operable and avoiding various known pitfalls in commonly used schemes. PKCS standards are a set of standards, called PKCS #1 through #15. These standards cover e.g. RSA encryption, RSA signature or cryptographic token interface. The PKCS standards are published by RSA Laboratories. [30] This thesis focuses on PKCS#11 standard, which is also known as "Cryptographic Token Interface Standard". It specifies an application programming interface, called "Cryptoki", to devices which hold cryptographic information and perform cryptographic functions. Cryptoki follows a simple object-based approach, addressing the goals of technology independence and resource sharing, presenting to applications a common, logical view of the device called a "cryptographic token". Cryptoki is intended to be implemented as a library supporting the functions in the interface, and applications will be linked to the library. [30] Very important property of the Cryptoki interface is that it should be able to work without giving the user access to raw values of the cryptographic keys stored on the token. The goal of this thesis is to develop an open-source application that can automatically discover incorrect PKCS#11 implementation with regard to the aforementioned key security. There are two types of standards - de facto and de jure. De jure standards are, as the name implies, based on law. That means a central authority, usually a state, prepares, implements and enforces the standard. On the contrary, de facto standards are voluntary and formed in the market process as a consequence of interactions among agents [1]. The de facto standards can 5

11 2. PKCS#11 be further split into two categories. One category is unsponsored standards that have no identified originator holding a proprietary interest, but nevertheless exist in a well-documented form in the public domain. The other is sponsored standards, where one or more sponsoring entities holding a direct or indirect proprietary interest. [14] The PKCS#11 standard clearly fits into the sponsored de facto standards category. The implication for this thesis is that since the standard is not enforced by any public authority, the implementation errors discovered by the software developed in this thesis mean a significant security risk, but do not constitute a breach of law. 2.2 Cryptoki This section describes the Cryptoki interface in detail. Cryptoki interface provides an abstract view of a security module, or token, as a store of objects such as key, certificate, and data objects [11]. The basic terms that describe Cryptoki functionality are handles, objects, keys, mechanisms, attributes, templates, users and functions. The following figure shows general Cryptoki model and its relationship to the applications. Figure 1 - Cryptoki model [16] 6

12 2. PKCS#11 Handles The objects are accessed via object handles so that even though, e.g., a key object is used to encrypt some data its value is not necessarily known to the API programmer [11]. The handles can actually be thought of as names of the objects or more precisely as pointers to the objects. [9] For example function WrapKey, which is used to export keys, does not require the user to enter the value of the exported key, it only takes the handles. Therefore even malicious users should not be able to retrieve values of the keys. Objects Cryptoki follows an object-based approach, which means objects form the core of its functionality. The objects are split into the following categories: Storage, Hardware feature and Mechanism. The Storage category further splits into Data, Key, Certificate and Domain parameters, as shown in the figure. As can be seen from the figure, Cryptoki supports a hierarchical object structure that is very similar to Inheritance mechanics used in Java or other object-oriented languages. Figure 2 - Cryptoki objects [16] Since the thesis focuses on retrieval of cryptographic keys, it will work mostly with Key and Mechanism categories. Both will be described in detail later. Domain parameters are only utilized by certain algorithms (DSA, DH), which are not used in this thesis. Hardware Features, which include e.g. real-time clocks [16], are also beyond the scope of this thesis. Finally Certificate and Data object types will be used in some attacks. Objects are 7

13 2. PKCS#11 also classified according to their lifetime and visibility. Token objects are visible to all applications connected to the token that have sufficient permission, and remain on the token even after the sessions (connections between an application and the token) are closed and the token is removed from its slot. Session objects are more temporary: whenever a session is closed by any means, all session objects created by that session are automatically destroyed. In addition, session objects are only visible to the application which created them. [16] Attributes An attribute is specified as a pair of attribute type and attribute value [11]. Attributes in Cryptoki are very similar to attributes in Java or other objectoriented languages. Cryptoki defines the attribute types and which objects contain which attributes. For example Mechanism objects only have two attributes - mechanism type and object class. Both these attributes can be seen in the above figure. Object class is an attribute common to all objects, but mechanism type is specific to Mechanism objects. The essential attribute types for this thesis are value, sensitive, extractable, wrap, decrypt, encrypt and unwrap. They all are related to cryptographic keys and will be described in following chapters. In Cryptoki all attributes start with CKA_. For the sake of brevity these prefixes will be mostly omitted in the thesis. Templates Formally the attribute templates can be described as a set of attributes [11]. The purpose of templates is to set multiple attributes of an object when the object is being created or generated. The templates are essential to the security of PKCS#11 keys, since some cryptographic key attributes can conflict with each other. Mechanisms A mechanism specifies precisely how an operation is performed [11]. From a user s point of view, mechanism is an entity that is passed to a function and defines the cryptographic procedure that is performed. Mechanisms in Cryptoki can be compared to global static variables in Java in the functionality they serve. For example a function called wrap needs four parameters, one of which is the mechanism. When the user wants to wrap another key with an AES 8

14 2. PKCS#11 key, he needs to pass an AES mechanism that supports wrapping to the function, such as CKM_AES_ECB. Cryptoki lists a significant amount of mechanisms that are mapped to API functions. This mapping specifies if the mechanism can be used for one or more of the following: encryption & decryption, signature & verification with and without message recovery, digest, key & key pair generation, wrapping & unwrapping, key derivation. The important fact for this thesis is that virtually every mechanism that supports decryption also supports wrapping and vice versa. There are few exceptions to this rule, such as mechanisms designated solely for wrapping, such as CKM_BATON_WRAP, and some mechanisms that only support encryption & decryption, such as AES_GCM. Still, the vast majority of mechanisms either supports both encryption and wrapping or none of them. That implies most keys that can be used for encryption or decryption can also be used for wrapping or unwrapping and vice versa. Users Cryptoki is intended for cryptographic devices associated with a single user, therefore it does not have a means of distinguishing multiple users. The focus is on a single user s keys and perhaps a small number of certificates related to them [30]. That means the thesis can work with one user per one token or even with multiple tokens per one user, when appropriate. There are two types of users. One type is a Security Officer (SO). The other type is the normal user. Only the normal user is allowed access to private objects on the token, and that access is granted only after the normal user has been authenticated. Some tokens may also require that a user be authenticated before any cryptographic function can be performed on the token, whether or not it involves private objects. The role of the SO is to initialize a token and to set the normal user s PIN and possibly to manipulate some public objects. The normal user cannot log in until the SO has set the normal user s PIN [16]. One of the core points of Cryptoki key protection is that the keys marked as sensitive should never be revealed, not even to a legitimate user. Therefore the thesis can assume every user is malicious and continuously attempts to discover raw cryptographic key values. In real life situations only a minority of users will actually be malicious, but they still can use the token in a compromised environment, which is essentially equal to the user being malicious. An example of a compromised environment would be an infected computer that logs the user s PIN and opens multiple malicious sessions with the token in which it attempts to discover valuable data stored 9

15 2. PKCS#11 on the token, such as its cryptographic keys. This assumption also means the thesis can view all users as normal users. Note that particularly in the case of software tokens this thesis focuses on, malicious application can just read the keys from memory, as long as it runs in the same address space as the token. Therefore, in order to keep the stored cryptographic keys secure, it is necessary to assure that the only way to access the token is via the PKCS#11 API. Such security measures are outside of the scope of this thesis, but are crucial to PKCS#11 key security. Functions According to the standard, the Cryptoki functions are organized into 13 categories [16]. The ones particularly interesting for this thesis are the object management functions and key management functions. Also very important are encryption functions and decryption functions. On the other hand, the thesis due to the aforementioned reasons does not consider session, slot and token management functions. In Cryptoki the functions all start with C_, e.g. function that wraps keys is called C_WrapKey. For the sake of brevity the function names in this thesis will mostly be written without the preceding C_. Keys Protection of cryptographic keys stored on a token is the core focus of this thesis. A key object is defined by the value of the key and a set of other attributes [11]. There are three basic key types: public key, private key and secret key. Public keys and private keys form key pairs used in asymmetric cryptography and secret keys are for symmetric cryptography. This thesis will work with both symmetric and asymmetric cryptography. As stated in [5], many tokens implement these two types quite differently, so a different approach is often needed. The key types, mechanisms and their attributes will be described in detail in the following chapter. To describe the raw key value of secret keys the standard uses the attribute CKA_VALUE. Public and private keys have no such common attribute. For example RSA does not use the CKA_VALUE attribute at all [16]. Since the standard deals with both asymmetric and symmetric cryptography, a common term key value will be used for the attributes that describe the raw key value. 10

16 Chapter 3 PKCS#11 Key Protection This chapter describes the most important cryptographic key attributes and all the functions Cryptoki offers for key management and discusses the possibility to use these functions in an attack to discover raw key data values. Like in most other programming languages the PKCS#11 API cryptographic functions are usually not performed as a single operation. E.g. function to decrypt data first requires the user to call C_DecryptInit followed either by C_Decrypt if the data is short enough to be decrypted in a single operation or by multiple calls of C_DecryptUpdate and following C_DecryptFinal if multiple operations are required due to larger data size. The thesis will abstract from this and will only consider these functions as a single-part operation. Therefore to refer to a function for decrypting data only plain Decrypt will be used. Similarly, almost every function requires CK_SESSION_HANDLE (2.2) as its parameter. Since the thesis only uses one session that is assumed to be compromised, there is no need to mention this parameter with every function. Similarly, every function that takes a template as a parameter also requires the length of the template as another parameter. Since the thesis abstracts from the low-level function parameters, this parameter will not be mentioned, but is always presumed to be set to the correct template size. Furthermore, some parameters will be omitted because they are relatively clear and unimportant for the thesis, e.g. the pointer to the location that receives a newly created object. Full documentation of the API is available at [16]. 3.1 Cryptographic Key Attributes This section in detail describes the attributes of PKCS#11 cryptographic keys. The following table shows which attributes the cryptographic key types can have set or unset. DERIVE enables using the key for key derivation process that will be de- 11

17 3. PKCS#11 KEY PROTECTION scribed later. LOCAL is a very important attribute that defines whether the key was generated on this token or has been created from another key that has LOCAL = true using function CopyObject. Note that LOCAL alone should only be used as a guarantee of security in conjunction with other attributes such as ALWAYS_SENSITIVE. SENSITIVE is a crucial attribute that controls if it is possible to read key value using GetAttributeValue function. EXTRACTABLE defines whether the key can be used as input for WrapKey function and therefore exported outside of the token. Moreover, key value should not be retrievable via GetAttributeValue when the key has EXTRACTABLE = false, even if its SENSITIVE is also false. These two attributes are essential to cryptographic key protection and therefore widely used in the thesis. ENCRYPT, DECRYPT, WRAP and UNWRAP simply state if the key can be used for the respective cryptographic operations. Note that some attributes are tied together. Always when a key has SENSITIVE attribute, it also has ALWAYS_SENSITIVE. This attribute is only set to true if SENSITIVE had always been set to true. It can not be changed by the user, but instead are automatically set by the token. Note that once SENSITIVE has been set to false, ALWAYS_SENSITIVE also changes to false and can t ever change to true again, even if SENSITIVE is set back to true. Very similar principle applies to EXTRACTABLE and NEVER_EXTRACTABLE. Every key that has UNWRAP must also have the attribute UNWRAP_TEMPLATE. Equally every key with WRAP attribute also must have WRAP_TEMPLATE. All cryptographic keys also share the following attributes: CLASS (object class, e.g. CKO_SECRET_KEY), KEY_TYPE (defines the key algorithm) and KEY_GEN_MECHANISM. Attributes that are less important for the purposes of this thesis, such as key identifier and dates, have been omitted from the table as well. Secret Key Private Key Public Key DERIVE X X X LOCAL X X X SENSITIVE X X EXTRACTABLE X X ENCRYPT X X DECRYPT X X WRAP X X UNWRAP X X The table quite clearly shows asymmetric usage of Private Keys and Pub- 12

18 3. PKCS#11 KEY PROTECTION lic Keys. The nature of Public Keys implies they cannot be sensitive and therefore there is no reason to define EXTRACTABLE for them. 3.2 Functions The functions will first be sorted by categories they belong to [16], which are sorted by relevance for the thesis from the most important one to the least important category. Certain less important categories are grouped together. The functions will be described in the following format: function name, purpose, required parameters, conditions and usage, all with respect to PKCS#11 key storage. The conditions section lists the conditions that must be met for the function to work, but does not include restrictions on the attributes specified by the template parameters. These conditions are only a subset of the conditions that are required for the function to adhere to the PKCS#11 standard. Note that not all Object Management Functions are described here. These functions are general functions that manipulate objects. There are additional functions used specifically for cryptographic key management, called Key Management Functions. GetObjectSize is a low-level function that is not used in this thesis due to the Java implementation. Moreover, functions FindObject and DestroyObject are also not used by this thesis, because it does not work with token objects. CreateObject This function creates a new object based off the ptemplate parameter and provides the handle of the newly created object. Parameters ptemplate - the template that is passed to the newly created object. For any key the template must contain Object class and Key type attributes. The template also must contain the fields that specify the key value. This is very different for symmetric and asymmetric cryptography and these often do not conform to the standard. Moreover, VALUE_LEN used by certain cryptographic algorithms must not be specified in the object creation template. MODULUS_BITS that serves the same functionality for RSA also must not be specified here. Neither private keys nor secret keys allow the attributes ALWAYS_SENSITIVE and NEVER_EXTRACTABLE to be specified in the process of key creation. 13

19 3. PKCS#11 KEY PROTECTION Conditions None. Creating new objects is possible without restrictions, as long as the aforementioned attribute requirements are met. Usage This function is one of two functions that enable importing new keys into the token. The user is required to insert the key value and since the user is considered to be malicious, such an imported key must be considered compromised and known to the intruder. The keys imported via this function have their LOCAL attribute always set to false. CopyObject Creates a new object based off the input object and template for the new object. Parameters hobject - the handle that specifies the object that is copied by this function. Its LOCAL attribute determines the LOCAL value of the new object. This specific functionality is a subject to testing by the application Caetus. ptemplate - this template can only specify attributes that could be ordinarily modified. For example if the former object had its EXTRACTABLE attribute set to true, this template can specify EXTRACTABLE to be set to false, but not the other way around [16]. This functionality seems like an easy thing to miss in an implementation and therefore is an important subject to token testing. Conditions The hobject must have its COPYABLE attribute enabled. Strangely, the attribute COPYABLE is only mentioned in the description of CopyObject function and nowhere else in the standard, not even in the attributes of cryptographic key types. Therefore the COPYABLE attribute is not a subject to testing. Usage One particular usage of this function with keys is to make session keys persistent by copying them and specifying the TOKEN attribute in ptempate to TRUE. This is due to the fact that some tokens seemingly do not allow to alter the value of TOKEN attribute. 14

20 3. PKCS#11 KEY PROTECTION GetAttributeValue This function returns values of the attributes specified in ttemplate, if possible. Parameters hobject - the handle that specifies the object whose attributes are returned. ptemplate - this template specifies the attributes whose values are desired. It means multiple attribute values can be returned at a time. However, this is done as seldom as possible in the thesis, since if the function is not successful, it can be difficult to discover the reason for the failure when multiple attributes are specified at a time. Cryptoki provides a considerably robust error handling for such cases [16], but it is still better to avoid such cases altogether. Conditions When a key has its SENSITIVE attribute set to true or its EXTRACTABLE attribute set to false, its key value attribute cannot be revealed and the function fails. Also, obviously, all the requested attributes must be set for the key, otherwise the function fails. Usage This is the only function that allows the user to obtain key value in plain format. As aforementioned, it should never work for keys that are marked as SENSITIVE or are not EXTRACTABLE. However, previous research has showed that many tokens ignore this restriction [5]. Therefore this function is a crucial subject for thorough testing. SetAttributeValue This function sets values of the attributes specified in ttemplate, if possible. Parameters hobject - the handle that specifies the object whose attributes are modified. ptemplate - this template specifies the attributes whose values are modified. More than one attribute value can be modified at a time. There are some attributes that cannot be modified by this function at all and some attributes that can only be set one-way. For the sake of brevity the full listing of such attributes will be done in section

21 Conditions None other than the attribute restrictions described above. 3. PKCS#11 KEY PROTECTION Usage SetAttributeValue provides one of few ways in Cryptoki to alter attributes of object and thus enables many attacks, if not implemented properly. GenerateKey Generates a new key for the given mechanism based off the given attributes. Parameters pmechanism - the mechanism that specifies which algorithm will the new key belong to. ptemplate - the user can specify some attributes for the newly generated key in this template. Contrary to CreateObject, the template must always include attribute that defines key length and must never contain attribute related to key value. The template also must not specify the attributes ALWAYS_SENSITIVE and NEVER_EXTRACTABLE. Conditions None other than the attribute restrictions described above. Usage Clearly this function is used for generating fresh values for cryptographic keys. If the generated key is marked as SENSITIVE, it can be considered unknown to the user, even if the user is malicious. The thesis uses this presumption for the model checking. GenerateKeyPair This function works exactly like GenerateKey, but generates both private key and public key at the same time. WrapKey Wraps the given key and returns the wrapped key as byte[]. More specifically, wrap takes key E, uses it to encrypt key K and then returns {K}_E. WrapKey can be used in the following situations: 16

22 3. PKCS#11 KEY PROTECTION To wrap any secret key with a public key that supports encryption and decryption. To wrap any secret key with any other secret key. To wrap a private key with any secret key. [16] Parameters pmechanism - the mechanism that is used to wrap the key. It is usually the same mechanism that is used for encryption and decryption by the given algorithm. hwrappingkey - the handle of the key that is used for the wrapping (E in the above description). It must use the same algorithm as pmechanism, otherwise the function will not work. hkey - the handle of the key that is wrapped. Note that this is only handle. That means the user does not need to know the key value. Conditions hkey needs to be EXTRACTABLE and hwrappingkey must have its WRAP attribute set to true. These two attributes are crucial for the security of PKCS#11 tokens and the Caetus application will test them very thoroughly. Another condition suggested by Clulow [7] is that the algorithm used to wrap the key K should have higher cryptographic strength than the algorithm of key K. Otherwise wrapping could actually make key K more susceptible to attacks. Usage Wrapping is essential for exporting keys, since it is the only way the key can leave the token in an encrypted format. Big weakness of wrapping is that it uses the same algorithm as encryption, which enables the Wrap+Decrypt attack shown in e.g. [5], which will be described in section 4.1. UnwrapKey Unwraps (=decrypts) a wrapped key and uses the unwrapped data to create a new private key or secret key [16]. This function should work similarly to CreateObject in that both functions set the new object s LOCAL attribute to false. 17

23 3. PKCS#11 KEY PROTECTION Parameters pmechanism - the mechanism that is used to unwrap the key. It must be the same mechanism that was used to wrap the key. hunwrappingkey - the handle of the key that is used for the unwrapping. It must use the same algorithm and have the same value as the key that was used for wrapping. It does not have to be the same object. ptemplate - the template that is passed to the unwrapped key. It must contain the KEY_TYPE attribute. Like CreateObject, ALWAYS_SENSITIVE and NEVER_EXTRACTABLE may not be specified in the process of key creation. Conditions None other than the attribute requirements specified in the ptemplate. Usage Unwrapping is used to import wrapped keys. The major difference from CreateObject is that in the process of UnwrapKey the user obtains no knowledge about the unwrapped key. Therefore the unwrapped keys do not have to be automatically considered to be compromised. DeriveKey Derives a key from a base key, creating a new cryptographic key object [16]. Parameters pmechanism - the mechanism for the key derivation. The mechanism must specifically support key derivation. An example of such a mechanism is CKM_CONCATENATE_BASE_AND_KEY hbasekey - the handle of the key from which the new key is derived. Its attributes affect the attributes of the new key in a similar approach to the function CopyObject. ptemplate - the template that is passed to the newly derived key. There are no restrictions put on it by the standard. Conditions None other than the base key must support key derivation. Usage In a typical access control system, if a user has a high level of privilege, he 18

24 3. PKCS#11 KEY PROTECTION may need to store a considerable number of keys. Since the cost of tamperresistant storage for keys increases linearly with the size of key storage, a technique to generate keys from a smaller seed or compress key materials is needed. There is a similar problem facing emerging applications like sensor networks and RFID tags. Despite the dropping cost of storage, key storage is still a big concern in these applications, involving low cost embedded devices which have to store a significant amount of secret keys. Compressing key materials is essential to the scalability of such designs [6]. This thesis focuses on extracting cryptographic keys and therefore concerns with mechanisms that can directly contribute to that goal. That is why the thesis works with e.g. CKM_CONCATENATE_BASE_AND_KEY, but not with the more practical mechanisms that leave less room for error such as CKM_SHA256_KEY_DERIVATION. Encrypt Encrypts given data. Parameters pmechanism - the mechanism for encryption. Note that it is the same as the mechanism used in WrapKey function. hkey - The handle of the encryption key. pdata - The data that gets encrypted. The data is input in plain format. Conditions The used key must have its ENCRYPT attribute set to true. This condition is a subject to testing. Usage Encrypt allows the user to encrypt plain data into a ciphertext. Therefore the user always must know the data. This limits the options of using the function Encrypt to extract key value of other stored keys. On the other hand, the output of Encrypt is the same as output of WrapKey, which provides some opportunities for exploitation, as will be shown later. Decrypt Decrypts the given ciphertext. 19

25 3. PKCS#11 KEY PROTECTION Parameters pmechanism - the mechanism for encryption. Note that it is the same as the mechanism used in UnwrapKey function. hkey - The handle of the decryption key. It must be the same algorithm and have the same key value as the key that was used for encryption, but it does not have to be the identical object. pdata - The ciphertext to decrypt. Conditions The used key must have its DECRYPT attribute set to true. This condition is essential to PKCS#11 token security and it is subject to thorough testing. Usage The function simply decrypts the data given to it. It does not check the content of the decrypted data. There is an easy Wrap + Decrypt attack based off this property [5]. General Purpose Functions, Slot, Token and Session Management Functions These functions include e.g. Initialize or GetMechanismInfo. Other examples of important functions in these categories are Login and Logout. These functions are used for setting up the API and the individual session and tearing down the session afterwards. They are essential part of almost any application that utilizes Cryptoki. However, as was explained in 2.2, this thesis automatically assumes the session has been compromised and the user is malicious. Therefore, while these functions are used in the practical part, they are not subject to research. Other Functions All other functions that were not mentioned fall into this category. They are not considered in the thesis, because they either have absolutely nothing to do with cryptographic keys, such as Message Digesting Functions, or seemingly offer no key extraction possibility other than brute force, such as Signing Functions. Function GenerateRandom may potentially present serious security risks to the saved tokens, since it has recently been shown that there may be backdoors inserted into the random number generating functions [24]. However, such attacks are beyond the scope of this thesis. 20

26 3.3 Cryptoki Function Input and Output 3. PKCS#11 KEY PROTECTION In order to further clarify the Cryptoki functions, there will be a table that clearly shows the most important input and output forms of all the possibly relevant functions. While some of the functions are not restricted to the cryptographic keys and can work with more general objects, this thesis is focused on keys. Therefore the table will only consider keys even when the functions, such as CreateObject, can work with other object types. Important note is that all the consideration in this section are based on the presumption that the implementation works as specified in the standard. In real-life situations this presumption is very often false. [5] Input and Output Table The input formats are as follows: Key handle - means the input is a key handle that is known to the user, but the key value is not known to the user. Known key handle - a key that is fully known to the user, including the key value. Plaintext - the function takes data that is in the plain form. It can even be a cryptographic key with key value known to the user or input attributes for a new key. Ciphertext - the functions accepts data that is in encrypted form. The data can contain anything, even a cryptographic key and while the user may know what data in general the ciphertext contains, he does not know the exact data values, but only as long as he does not have access to the relevant key. Command - represents a situation when the user only enters a command that does not include any other input from the above. The possible output formats are: Key handle - the function creates a new key and returns the new key handle, but does not reveal any information about the key value and the user has no knowledge of the key value. 21

27 3. PKCS#11 KEY PROTECTION Known key handle - the function creates a new key and also returns the handle. It does not reveal any information about the key value, but the user does know the key value, e.g. due to the fact he knew it before. Plaintext - the function returns data that is in the plain form. It can even be a cryptographic key. The data is obviously completely known to the user. Ciphertext - the function returns data in encrypted form. The data can contain anything, even a cryptographic key and the data is not known to the user. Digest - the function returns digest of the input data. This digest is usually not meant to be kept secret. Signature - the function signs the input data. The signature usually is not meant to be secret. Boolean - the function responds true or false depending on if the function was successful. The following table provides a clear overview of the input and output of the functions. Note that the key handle on the input for function DeriveKey is different from the key handle on the output of the same function. Function Input Output CreateObject Plaintext Known handle CopyObject Key handle Key handle GetAttributeValue Key handle Plaintext SetAttributeValue Key handle Boolean GenerateKey Command Key handle GenerateKeyPair Command Key handle WrapKey Key handle + Key handle Ciphertext UnwrapKey Ciphertext + Key handle Key handle DeriveKey Key handle Key handle Encrypt Key handle + Plaintext Ciphertext Decrypt Key handle + Ciphertext Plaintext Digest Plaintext Digest Sign Key handle + Plaintext Signature Verify Key handle + Signature Boolean 22

28 3. PKCS#11 KEY PROTECTION Note that the table always lists the more restrictive and secure option that limits user s (and therefore intruder s) knowledge as much as possible. For example CopyObject function can always be called on a Known key handle, but the consequence is that the output of the function will also be known to the user. The table also assumes no ciphertext had been compromised before it was passed to the function. An example of such security issue is when a cryptographic key is generated on one device and shown to the user, then it is wrapped and the resulting ciphertext is given as an input to the UnwrapKey function on another device. The device will assume the key to be unknown to the user, but it fact the user will possess that knowledge and may be able to exploit it. Implications The goal of an attacker is to obtain a key value in plaintext. The desired process is key handle -> plaintext. From the table it is clear that only two functions output plaintext. First one is GetAttributeValue, which already has key handle as an input, and the other is Decrypt. Decrypt takes a ciphertext as an input, therefore it is necessary to also consider functions that output a ciphertext. Those are Encrypt and Wrap. Unfortunately, Encrypt requires plaintext as an input. Therefore, if an attacker wanted to encrypt a cryptographic key in order to obtain a ciphertext as an input for Decrypt, he would have to already know the key value. On the other hand, WrapKey lets a malicious user create a ciphertext out of a cryptographic key possibly even if he does not know the key value. That means the two possible processes that convert an unknown key handle into a plaintext can be performed with functions GetAttributeValue and Wrap + Decrypt. Another clear possibility comes from using CreateObject. This function permits the user to substitute unknown key handle by a known key handle. The first function this can have impact on is Wrap, since it takes two key handles as an input, so it lets the attacker use one compromised key to compromise the other by wrapping the other key and decrypting it outside of the token. From the table is can be seen that the only function relevant to this is DeriveKey, because it requires a key handle on input and makes a new key that is based off the input. Therefore, if the input key is compromised, the newly derived key must also be considered compromised. From the table it is also clear that function Digest does not have to be considered at all, since it has absolutely nothing to do with cryptographic keys. Moreover, Sign and Verify are functions that relate to digital sig- 23

29 3. PKCS#11 KEY PROTECTION natures. They do require cryptographic keys, but from their output it is clear that they offer no possibility for cryptographic key retrieval other than brute force. Therefore the only hypothetical situation in which Sign or Verify would be viable for an attack would be when these functions supported much weaker cryptographic algorithms than the rest of the API. Therefore Digest, Sign and Verify and the attributes connected with them will not be considered by this thesis any further. It could be argued that Encrypt could be omitted as well, but later it will be shown that Encrypt can be used for certain attacks, particularly Trojan Key Attacks. 3.4 Basic Function Testing This section lists the tests that will be performed on Cryptoki functions. Later chapters will add more complex conditions for the tests. The basic tests in this section determine whether the implementation adheres to the PKCS#11 standard and mostly do not directly discover security risks. However, as it will be shown later, many attacks against PKCS#11 exploit incorrect implementation of one or more functions described in this section. Many functions put either requirements or restrictions on the template that is passed as their argument. These conditions are aggregated under ptemplate required and forbidden. Formally, the requirements are as follows: 1. Function does not work if ptemplate does not contain any of the attributes marked as required. 2. Function must work when ptemplate contains all of the required attributes. 3. Function must work even when ptemplate only contains attributes that are required and no more. 4. Function must not work when ptemplate contains any of the forbidden attributes. There are certain attributes that may never be set or modified by the user, mostly because they should be set by the token itself. These attributes are ALWAYS_SENSITIVE, NEVER_EXTRACTABLE, KEY_GEN_MECHANISM and LOCAL. Therefore these attributes are not mentioned among the forbidden attributes, but always count as such. 24

30 3. PKCS#11 KEY PROTECTION CreateObject 1. ptemplate required: OBJECT_CLASS and KEY_TYPE and Key value. 2. ptemplate forbidden: VALUE_LENGTH, MODULUS_BITS. 3. The following attributes of the newly created key are set to false: LOCAL, ALWAYS_SENSITIVE, NEVER_EXTRACTABLE. Implementations often require more attributes in ptemplate than the standard specifies. Caetus takes this into account and in such a case attempts to discover the actually required configuration. CopyObject 1. If the original key had EXTRACTABLE set to false, the new key cannot be set to EXTRACTABLE = true. 2. If the original key had SENSITIVE set to true, the new key cannot be set to SENSITIVE = false. 3. The new key will always have the same NEVER_EXTRACTABLE as the original key. 4. The new key will always have the same ALWAYS_SENSITIVE as the original key. 5. The new key will always have the same LOCAL as the original key. GetAttributeValue 1. Key value must not be shown if the key has SENSITIVE = true. 2. Key value must not be shown if the key has EXTRACTABLE = false. 3. Key value must be shown if the key has SENSITIVE = false and EXTRACTABLE = true. 4. Values of attributes other than key value must be always shown if set. The condition #2 implies that key value must not be shown even when the key has SENSITIVE = false and EXTRACTABLE = false. 25

31 3. PKCS#11 KEY PROTECTION SetAttributeValue 1. If SENSITIVE = true, it cannot be set to false. 2. If SENSITIVE = false, it can be set to true. 3. If EXTRACTABLE = true, it can be set to false. 4. If EXTRACTABLE = false, it cannot be set to true. 5. When setting SENSITIVE = true, ALWAYS_SENSITIVE does not change and remains false. 6. When setting EXTRACTABLE = false, NEVER_EXTRACTABLE still is false. GenerateKey 1. ptemplate required: VALUE_LENGTH or MODULUS_BITS. 2. ptemplate forbidden: Key value. 3. LOCAL attribute of the newly generated key will always be set to true. WrapKey 1. It is possible to wrap a secret key with a secret key 2. It is possible to wrap a secret key with a public key 3. It is possible to wrap a private key with a secret key 4. The function succeeds if and only if hkey has EXTRACTABLE = true and hwrappingkey has WRAP = true and fails otherwise. UnwrapKey 1. ptemplate required: KEY_TYPE. 2. ptemplate forbidden: Key value, VALUE_LENGTH, MODULUS_BITS. 3. The function succeeds if and only if hunwrappingkey has UNWRAP = true and fails otherwise. 26

32 3. PKCS#11 KEY PROTECTION 4. LOCAL attribute of the newly generated key will always be set to false. 5. The new key will have the ALWAYS_SENSITIVE attribute set to false, and the NEVER_EXTRACTABLE attribute set to false. DeriveKey 1. The function only works if the first input key has DERIVE = true 2. The newly created key always has its LOCAL set to false. 3. If any of the input keys has SENSITIVE = true, the new key will also have SENSITIVE = true. 4. When any one of the input keys has EXTRACTABLE = false, the new key will also have EXTRACTABLE = false. The tests for DeriveKey take into consideration the fact that function DeriveKey has multiple mechanisms which use different input types. The mechanisms CONCATENATE_BASE_AND_KEY (simply takes two keys and concatenates them) and EXTRACT_KEY_FROM_KEY (should simply create one key from bits of another key) were chosen for the most tests, since the other weaker mechanisms effectively only test a subset of the aforementioned test conditions. Moreover, DeriveKey tests will only use symmetric cryptography, since the mechanisms used for the key derivation are always the same, regardless of what key is passed as input. Therefore the tests for asymmetric cryptography would always yield identical results to the tests performed with symmetric keys. Encrypt 1. The function succeeds if and only if hkey has ENCRYPT = true and fails otherwise. Decrypt 1. The function succeeds if and only if hkey has DECRYPT = true and fails otherwise. 2. Decrypt(Encrypt(X)) equals X, where X is a random block of bytes. 27

33 3. PKCS#11 KEY PROTECTION Functions Encrypt and Decrypt are not intended for key management, therefore their basic tests are trivial. Testing of these two functions in Caetus also features comparing data X and Decrypt(Encrypt(X)) in order to confirm that the functions work properly, as otherwise most tests performed by Caetus could provide misleading data. If, by any chance, the PKCS#11 token s implementation of encrypt or decrypt was wrong, WrapKey and UnwrapKey would have to be considered broken, too. The reason for this is that all these functions commonly use the same mechanisms. Since almost every test features one of these functions in some way, their correct functionality is critical for Caetus to work properly. Moreover, wrong implementation of these basic functions likely would render the device useless. 3.5 Chapter Conclusion This chapter has further described Cryptoki interface and the functions and attributes intended for protection or management of stored cryptographic keys. It has defined functions and attributes that are crucial for key protection and also functions that can be omitted from further research and testing because they clearly have no role in attacks on cryptographic key storage. 28

34 Chapter 4 Known Attacks on PKCS#11 The purpose of this chapter is to list known attacks that have some potential to compromise stored keys. Also, since performing the whole attack is often infeasible, this chapter also lists the additional tests Caetus application performs on the token. 4.1 Known Attacks Many attacks on PKCS#11 tokens have been shown in the literature. Attacks based off hardware tampering, such as a side channel attack [22], are not considered. While such attacks may be of big help in acquiring information about the token that can potentially lead a successful extraction of a sensitive key, this thesis is primarily concerned with software tokens and therefore such hardware-based attacks fall outside its scope. Key Separation Attack The secret key objects of PKCS#11 do allow for the specification of the use of the key for the operations of encrypting, decrypting, signing (MAC generation), verifying (MAC verification), key wrapping and key unwrapping. Unfortunately, the API allows the specification of conflicting properties in that such attributes can be independently specified. [7] This attack is also widely known as Wrap + Decrypt Attack [5, 9]. Ks stands for a sensitive key, Kw means a key that is used for wrapping other keys. The attack is based on a presumption that key Kw can be used for both wrapping other keys and decrypting data. 1. Wrap(h(Ks),h(Kw)) -> {Ks}_Kw 2. Decrypt({Ks}_Kw, h(kw)) -> Ks The result of this attack is key Ks in plain. This attack is possible even when the token fully conforms to the current PKCS#11 standard. 29

35 4. KNOWN ATTACKS ON PKCS#11 Since the basic requirement for this attack is that there is one key K that can both wrap and decrypt, the testing of this attack on the tokens focuses not only on the attack itself, but also on acquiring such a key K. Therefore, besides WRAP and DECRYPT, the tests also heavily feature GenerateKey, CreateObject, SetAttributeValue, CopyObject and DeriveKey. Expanded Key Separation Attacks Key Separation attack is based on the fact that one cryptographic key has attributes WRAP and DECRYPT both set to true. However, in order to successfully perform such an attack, wrapping and decryption do not have to be performed by the same key object. The Expanded Key Separation attack presumes the Cryptoki implementation deals with the basic Key Separation attack by somehow forbidding one cryptographic key from having WRAP and DECRYPT both set to true. An example algorithm of Expanded Key Separation follows. Ks stands for a sensitive key and Kw for a key that can wrap and unwrap. Kwc represents a cryptographic key with the same key value as Kw. In step 2 the ENCRYPT and DECRYPT attributes of the newly created Kwc are set to true and its WRAP and UNWRAP are set to false in order to avoid attribute collision. 1. Wrap(h(Kw),h(Kw)) -> {Kw}_Kw 2. Unwrap({Kw}_Kw,h(Kw)) -> h(kwc) 3. Wrap(h(Ks),h(Kw)) -> {Ks}_Kw 4. Decrypt({Ks}_Kw,h(Kwc)) -> Ks [9] The shown algorithm is only one of the various possible Expanded Key Separation attacks. Other variations include using CopyObject to duplicate the key or importing the exported key to another token, creating another key via DeriveKey function or even using UnwrapKey twice in a row on the same key, but with different attributes. All of these attack variation, however, rely on calling Decrypt on the wrapped key Ks. Tookan project [5] has presented patched Cryptoki that prevents even Expanded Key Separation by severely restricting the templates for cryptographic keys in the following way: 1. Keys generated on the token can only have either WRAP, UNWRAP or ENCRYPT, DECRYPT set to true, bot never both attribute pairs. 30

36 4. KNOWN ATTACKS ON PKCS#11 2. Imported keys can only have attributes ENCRYPT and UNWRAP set to true. When a Cryptoki implementation enforces the aforementioned rules, keys duplicated via Unwrap will always have their attributes WRAP and DECRYPT set to false. Moreover, if the token also correctly implements all the key management functions, there will be no way for a cryptographic key or even multiple cryptographic keys with the same key value to be able to use both WrapKey and Decrypt on another cryptographic key. While cryptographic key restrictions always present a trade-off between increased security and decreased practical usability, the above restrictions seem to be very effective in increasing security while only introducing practical limitations that can be worked around. This issue will be thoroughly discussed later in chapter 5. Caetus software will perform thorough tests of Expanded Key Separation attacks in all aforementioned variations. Key Conjuring Attack Key conjuring is the process by which an attacker obtains an unknown, encrypted key by repeatedly calling a cryptographic API function with random values in place of keys [8]. This attack leads to the attacker obtaining access to h(k). As explained in [8], Key Conjuring can be a very dangerous attack, but it does not directly lead to cryptographic key extraction. This thesis works under the presumption that the user is authenticated and malicious (2.2). This attack can be very potent in real-life situations where the attacker is not fully authenticated, but in this thesis it is only valid when the user s capabilities are severely restricted. Therefore the current version of Caetus does test Key Conjuring Attack, but it may be included in future versions. Key Binding Attack Cryptographic keys get split into distinct parts when the block length of the algorithm protecting them is shorter than the key length. 3DES is particularly common, and has a 112 bit key made up from two 56 bit single DES keys. When the association between the halves of keys is not kept, the security of the key is crippled [4]. This attack is specific to 3DES. A typical Key Binding attack algorithm looks as follows: 1. Export the 3DES key K (under any encrypting key and in any mode). 31

37 4. KNOWN ATTACKS ON PKCS#11 2. Re-import the first half of the key (under the same encrypting key and in ECB mode). This creates a key K1. 3. Re-import the second half of the key (under the same encrypting key and in ECB mode). This creates a key K2. 4. Perform a key search against the newly acquired K1 and K2 individually. [7] Step 4 obviously requires application of brute force, which is not a primary goal of this thesis. Furthermore, successful execution of steps 1, 2 and 3 does not by itself automatically guarantee that the 3DES key will be discovered in step 4 [4]. Therefore the thesis will test this attack, but only up to step 3. If step 3 is successful, the Caetus application will return a warning that the tested token may be vulnerable to Key Binding. Weaker Algorithm Attack The PKCS#11 specification allows for the wrapping of a key by a second key of shorter length. Thus it is only necessary to attack the weaker key in order to recover the original key [7]. An example algorithm for Weaker Algorithm follows. Ks stands for strong cryptographic key (e.g. a AES key), while Kw stands for a shorter and therefore weaker key supported by Cryptoki (for example RC2). Key values of both keys are unknown to the user. Kw must have its Wrap set to true. 1. Wrap(h(Ks),h(Kw)) -> {Ks}_Kw 2. Wrap(h(Kw),h(Kw)) -> {Kw}_Kw 3. Perform an exhaustive search on {Kw}_Kw in order to discover Kw. 4. Use Kw to decrypt {Ks}_Kw. [7] Unless a serious vulnerability is discovered in one of the cryptographic algorithms supported by Cryptoki, Weaker Algorithm attack obviously requires brute force or to succeed. However, this attack is mentioned, because it can seemingly work even on Cryptoki implementations that resist all other attacks. The only way the PKCS#11 standard could prevent this type of attack is to define set of weaker algorithms and disable Wrap for these algorithms. On the other hand, such a step could severely limit the functionality of many PKCS#11 tokens. 32

38 4. KNOWN ATTACKS ON PKCS#11 Since Weaker Algorithm attack requires brute force, the Caetus will only perform tests to discover if step 2 in the above algorithm is possible and if yes, it will issue a minor warning. Downgrade Attack This attack is not to be confused with the previously shown Weaker Algorithm attack. It does not require brute force and its execution is much simpler, but potentially very effective. In the following sample algorithm Ks stands for a cryptographic key that has both attributes Sensitive and Extractable set to true. K represents any cryptographic key that has Wrap and Unwrap set to true and Decrypt set to false. None of the keys is known to the user. Kn is an imported key with key value equal to Ks, but in the process of unwrapping its Sensitive is set to false. 1. Wrap(h(Ks),h(K)) -> {Ks}_K 2. Unwrap({Ks}_K,h(K)) -> h(kn) %Sensitive of Kn is unset 3. GetAttributeValue(h(Kn),KEY_VALUE) -> Kn Downgrade attack simply wraps a key and then immediately unwraps it back, but its unwrapping template contains Sensitive = false. Possible ways to mitigate this attack include forcing every key imported with Unwrap to be Sensitive or forbidding Sensitive and Extractable to be set to true at the same time. While the second approach is not really viable, as it would severely limit functionality of PKCS#11 tokens, the first approach could potentially increase security of PKCS#11 implementations. An ostensibly working solution would be forcing each cryptographic key stored on a token to be unique. That means no two keys on the token could have the same key value. This solution, however, would present new security risks and could be simply defeated by using multiple tokens or by calling DeleteObject on the original key before it is re-imported. Downgrade attack is a critical vulnerability that is trivial to exploit and therefore Caetus will thoroughly test the tokens for it. Key Derivation Attacks Clulow described three attacks based off symmetric key derivation [7]. Downside to these attacks is that all require non-trivial exhaustive search and they can only work when specific conditions are met. Therefore only the 33

39 4. KNOWN ATTACKS ON PKCS#11 most straightforward of these attacks is described and partially tested in the thesis. The Reduced Key Space attack uses the CKM_EXTRACT_KEY_FROM_KEY mechanism to extract a subset of the bits from a given key to create a shorter key. This new cryptographic key can then be used to significantly reduce the key space that needs to be searched with brute force. For example, it is possible to extract 40 bits from a DES key to create a 40-bit RC2 key, which can then be separately searched by exhaustive means. The remaining 24 bits of the original DES key can then be searched for independently. [7] The Caetus application will test if DeriveKey function can be used to shorten a cryptographic key. If so, the application will warn about the potential security vulnerability. Private Key Modification Attack One of the premises for this attack is that PKCS#1 requires RSA keys to be BER-encoded. [16] When the key is wrapped using a block symmetric cipher mechanism, such as AES, the attacker can replace one block of the the wrapped key (ciphertext) with a different value. When the key is unwrapped, this will cause the corresponding block of plaintext as well as the following block to have different values. The rest of the key remains intact. An attacker can modify one of the big numbers independently of the other data in the wrapped private key (including the padding at the end). If the various key components are not explicitly tested for consistency, the attacker gains access to a modified Trojan key in the system [7]. From the point of view of the table mentioned in 3.3, UnwrapKey thus has its output altered to known key handle. However, this attack does not directly lead to recovery of other cryptographic keys stored on the device. On the other hand, it has many other possible uses and definitely compromises security of the PKCS#11 implementation. Trojan Wrapped Key Attack In PKCS#11 cryptographic keys wrapped with a public key can only be unwrapped with the corresponding private key. Also, by definition, a public key is always known to the user (=attacker). Since key wrapping and encryption use the same mechanisms, the following attack may be possible. Kt stands for a trojan key, Kpub is a public key and Kpr is the corresponding private key. 1. Encrypt(Kt,Kpub) -> {Kt}_Kpub %Outside of the device 34

40 2. Unwrap({Kt}_Kpub,h(Kpr)) -> h(kt) 4. KNOWN ATTACKS ON PKCS#11 Similar to Private Key Modification Attack, this attack also changes the output of UnwrapKey function to a known key handle. It can, however, also work with secret keys and thus is not limited to Asymmetric cryptography. 4.2 Known Attack Table This table sums up the most important facts from the previous section. It lists the attacks and their potential outcomes. Outcomes Extract Key means the attack can result in successfully gaining access to key value of another cryptographic key stored on a token. Attacks with this possible outcome are the main goal of this thesis. Brute Force means the attack with this outcome can lead to successfully recovering another stored key, but non-trivial exhaustive search is necessary to get the key value. Trojan Key means the attack can create a new key with known key value by other means than using CreateObject, but the attack can not directly lead to recovering key value of another stored key. Attack Extract Key Brute Force Trojan Key Key Separation X Expanded Key Separation X Downgrade X Key Binding X Weaker Algorithm X Key Derivation X Private Key Modification X Trojan Wrapped Key X Clearly the attacks that can directly lead key recovery have the highest testing priority. Attacks that need brute force will be tested for, but vulnerability to one of them does not automatically mean the PKCS#11 implementation is insecure. Vulnerability to trojan keys is more difficult to evaluate. It is unclear if it can in any way, directly or indirectly, lead to extraction of other stored cryptographic keys. From the function input and output table (3.3) it is clear 35

41 4. KNOWN ATTACKS ON PKCS#11 that the only two functions that can get the key value of an unknown key are Decrypt and GetAttributeValue. The later is clearly not applicable here, because an attack that creates a trojan key cannot in any way change Sensitive attribute of another key. Decrypt does not have to be called from the token, because attacker already knows the key value of the trojan key and can therefore trivially perform decryption outside of the token. Therefore the attacker only needs the trojan key to have its WRAP attribute set to true. The conclusion is that Private Key Modification Attack and Trojan Wrapped Key Attack are a potential security risk to the stored keys only if the keys imported with UnwrapKey can have WRAP = true. It could be argued that a much easier way to obtain a trojan key is to use CreateObject. However, since keys imported with UnwrapKey are presumed to be unknown to the user, it is much easier to overlook this potential trojan key vulnerability in the course of implementation. Therefore it is reasonable to include the attacks that lead to trojan key in the tests. 4.3 Attack Testing This section follows the same approach as 3.4 in that it lists the performed tests in a semi-formalized way. These tests, however, go beyond PKCS#11 standard. They focus on discovering vulnerabilities that are necessary for the attacks to work. Moreover, these tests rely on the fact that all the tests in 3.4 were successful, unless explicitly stated otherwise. It is also important to note that the conditions states in the following tests do not mean violation of the standard. Therefore Caetus shows the results for these tests in a separate section. When stating that a key cannot have a list L of two or more attributes set, it means the following: 1. When a key has one of the attributes in L set to true, it is not possible to use setattributevalue to change value of any other attribute from L to true. 2. When creating a new key (does not matter if key value is known to user) via function GenerateKey, CreateObject, CopyObject or DeriveKey, it is not possible to specify an input template that has more than one attribute of L set to true. 3. When the key is public or private, whole key pair is considered for the purpose of this test. 36

42 4. KNOWN ATTACKS ON PKCS#11 Key Separation Attack 1. No cryptographic key can have both Wrap and Decrypt set. Test for Key Separation Attack clearly forms a subset of the following expanded version. That implies that if a protection measure prevents Expanded Key Separation Attack, it also prevents this attack. This attack is mentioned because plain Key Separation Attack is much easier to execute and thus the vulnerability must be considered more severe. Expanded Key Separation Attacks 1. No cryptographic key can have both Wrap and Decrypt set. 2. Keys created via GenerateKey or GenerateKeyPair can only have either [Wrap, Unwrap] or [Encrypt, Decrypt] set. 3. Keys that have Local = false can only have Decrypt = false and Wrap = false. The above tests should ensure that no Expanded Key Separation Attack can be performed with any number of devices. It, however, cannot assure that permits using imported keys for e.g. decryption. Conditions #2 and #3 further expand condition #1. That implies that if conditions #2 and #3 are fulfilled, condition #1 is fulfilled as well. Key Binding Attack 1. When a 3DES key is exported with WrapKey, its first half cannot be reimported on its own. 2. When a 3DES key is exported with WrapKey, its second half cannot be reimported on its own. When both of these tests conditions fail, Caetus will issue a warning. Weaker Algorithm Attack 1. There are no two keys Ks and Kw such as that Kw has significantly lesser cryptographic strength that Ks, both keys have the attribute EXTRACTABLE = true and Kw has WRAP = true. This clearly is not feasible to test for all cryptographic algorithm combinations. Therefore only few algorithms will be tested. 37

43 4. KNOWN ATTACKS ON PKCS#11 Downgrade Attack 1. Every key created via UnwrapKey must have Sensitive = true. Key Derivation Attacks 1. It is not possible to use DeriveKey to create a key of lesser cryptographic strength than any of the input keys. 2. In the derivation process it is not possible to set SENSITIVE to false or EXTRACTABLE to true. The test condition #2 is rather trivial, but extremely dangerous. Correct implementation of the standard should prevent it, but it is explicitly tested in this section, as it can equal using SetAttributeValue in order to change SENSITIVE or EXTRACTABLE to the desired value, but is more easily overlooked. Private Key Modification Attack 1. It is not possible to import (via UnwrapKey) a private key that was randomly modified outside the device. 2. A key imported via UnwrapKey cannot have WRAP = true. Condition #1 will hardly ever be satisfied, since that would require nonstandard wrapping formats. That condition, however, is not very high priority, since success in condition #2 renders the new modified private key essentially harmless. Trojan Wrapped Key Attack 1. A key imported via UnwrapKey cannot have WRAP = true. 4.4 Chapter Conclusion This chapter dealt with known attacks on PKCS#11 implementations. It could be seen that some attacks pose a direct threat to security of other cryptographic keys stored on a device and therefore will be tested for with high priority. On the other hand, particularly attacks that result in a trojan key on the token, may be considered less dangerous, but still subject to the tests. 38

44 Chapter 5 Possible Restrictions to Cryptoki Interface The previous chapters have shown possible security vulnerabilities in the PKCS#11 standard and some attacks that exploit them. This chapter discusses the aforementioned attacks and security vulnerabilities and analyses potential fixes to the standard that would help improve security of PKCS#11 tokens. Bortolozzo, Focardi, Centenaro and Steel [5] have proposed restrictions to cryptographic key attributes that were described in the section 4.1 in the Tookan research. Moreover, they also proposed making more attributes sticky and different wrapping formats. This chapter will go through various ways to mitigate the shown security risks and analyse their impact on functionality of PKCS#11 implementations. Note that the approaches discussed below are independent on each other and there is no reason to combine them. 5.1 Cryptographic Key Roles Key role is a term defined in [11] that specifies in which roles the key is intended to act over time. For example, shortly after its generation, key K may have no role available at all, but then k may be enabled for the role to be extracted and exported to other domains, and after transport to another domain K s roles may be modified again, to disable the previous role and to enable the roles for data encryption and for data decryption. From the point of view of this thesis Key role is defined by the attributes of the cryptographic key. If an implementation enforces key roles, such as proposed in [5], there are the following questions to consider: 1. Does a key role have to be defined on key creation? 2. Can a cryptographic key have more than one key role? 3. Is it possible to change key role of a key? 39

45 5. POSSIBLE RESTRICTIONS TO CRYPTOKI INTERFACE 4. Can the token know the right role to use for a key? 5. Does the design break if the communicating tokens don t agree on a role? In order to answer the above questions it is first necessary to define the basic proposed roles relevant to the cryptographic key storage. Wrapping Key - key with this role only has the attributes WRAP, UNWRAP, SENSITIVE and EXTRACTABLE set to true and all other attributes are false. Encrypting Key - this key has ENCRYPT, DECRYPT, SENSITIVE and EXTRACTABLE set to true, all other attributes are false. Imported Key - this key has ENCRYPT, UNWRAP, SENSITIVE and DERIVE set to true, all other attributes are false. The proposed key roles are based off [5]. They should allow for asymmetric usage of keys. For example a key K is generated on one device D1 with role Encrypting Key. It is then exported via WrapKey and later imported onto another device D2 via UnwrapKey. On the device D2 the key K is automatically assigned the role Imported Key. Now both devices have key K, but encrypt -> decrypt process can only be performed in D2 -> D1 direction, because on device D2 key K belongs to role Imported Key, which cannot use Decrypt. Therefore it is necessary to establish another key (or key pair) between the two devices which will permit encrypted communication in the opposite direction. While this approach doubles key management, it eliminates the possibility of Expanded Key Separation Attack, Downgrade Attack and both attacks that result in a trojan key. Note that the same roles also apply to the asymmetric cryptography, although they are less intuitive. The above example answers question one (Does a key role have to be defined on key creation?) with the case of an imported key. Since the tokens may be stateless, importing a new key without immediately defining its role can be very dangerous. Imagine a situation when a key is imported and its role is left empty at first, but later it is assigned the role Wrapping Key, because the device was somehow made to forget the key was imported (e.g. through hardware tampering). Therefore it is necessary to always define role for each key immediately after it is created. There may be some exceptions to this, such as when a key is generated on the token. Still, even in such a case there is no reason not to define the role right away. 40

46 5. POSSIBLE RESTRICTIONS TO CRYPTOKI INTERFACE Question two (Can a cryptographic key have more than one key role?) is a matter of a trade-off. Allowing more than one role with one key is possible (e.g. CKM_RSA_PKCS mechanism [16]) and permits using one key for multiple cryptographic operations. It clearly should never be possible for a key to have both Wrapping Key and Encrypting Key roles, but combining one of these with e.g. Signing Key may reduce cryptographic key overhead significantly. However, even such combination may lead to dangerous misuses. Therefore it is not recommended to give multiple roles to one key, even if they are not conflicting. In any case every key should only be able to have at most one key role related to cryptographic key storage. And should it be possible to change key role of a key? The are three basic approaches to this problem. First is to make the key roles changeable without any limits. This approach obviously fails, since it would be possible to just change a key from Wrapping Key to Encrypting Key, so that it can decrypt. The key role mechanics would make no sense, since it would no longer prevent even the Key Separation Attack. Second approach would be to make key roles sticky in the similar manner as SENSITIVE attribute. Clear downside to this approach is that it makes the cryptographic keys rigid and increases key overhead. Third approach is to permit only some key role alteration, e.g. it would be possible to remove Signing Key role, but not Wrapping Key. Similar to proposed solution to question #2, this approach could reduce key overhead. While some roles are defined merely by the process of creating the key (e.g. key imported via UnwrapKey must always have the role Imported Key. On the other hand, keys created via GenerateKey should let the user choose if the key will have the role Wrapping Key, Encrypting Key or neither. Therefore in some situations the token can immediately know the correct role for the key, but at other times the user must decide. Answer to the last question clarifies that even with the proposed restrictions the PKCS#11 tokens still can be vulnerable to some of the attacks shown in this thesis as long as not all the implementations conform to the standard. Consider a simple example where D1 is a device that correctly implements the standard including the role mechanics, device D2 that is a malicious or just erroneous device and does not implement the role mechanics and is vulnerable to the previously shown Key Separation Attack and a secret key K with the role Wrapping Key shared between D1 and D2. While the key K should correctly have the role Imported Key on D2, it does not and it even has DECRYPT = true. That means D1 assumes it can safely wrap its Encryption Key and send it to D2, where it should be unwrapped as Imported Key. However, D2 instead uses its K to decrypt the wrapped key rather than to 41

47 5. POSSIBLE RESTRICTIONS TO CRYPTOKI INTERFACE unwrap it, which compromises the whole scheme. Therefore this approach could only be considered secure if all implementations conformed to the standard, including the role restrictions. Unfortunately, the less restrictive approaches to key roles also seem prone to implementation errors. While they may work in theory, it has been shown [5] that many PKCS#11 implementations are vulnerable to very simple attacks because of incorrect implementation of the standard. Therefore the most restrictive approaches to the above problems should be adopted. The result of such approach would be that essentially every cryptographic key would have to be used asymmetrically as shown above. Moreover, there would have to be a different key for every cryptographic operation. It may seem very restrictive from theoretical point of view, but in practice, many cryptographic keys are single-purpose anyway. Therefore the best case scenario is that one cryptographic key still suffices (this may apply in e.g. signing documents or s). Worst case scenario would increase key overhead so that instead of just one key the user would need to use six or even more keys, but such a situation is not very likely to occur in practice. Moreover, one of the goals of the PKCS#11 standard is that the stored cryptographic keys are secure. Unfortunately some widely used protocols may encounter problems with this approach. Consider the example of The Transport Layer Security (TLS) Handshake Protocol [10]. This protocol does not use WrapKey or UnwrapKey (although in some cases it may actually use them to create the master secret) and instead utilizes DeriveKey to achieve shared keys. Since any key obtained via DeriveKey would be considered Imported Key, the shared keys could only encrypt, but not decrypt. This means that the role mechanics would not work in every situation. 5.2 Limiting WrapKey and UnwrapKey The published attacks on Cryptoki key storage have shown that virtually every attack somehow uses WrapKey or UnwrapKey. This section deals with the question what would happen if these two functions were either disabled or severely limited. The purpose of WrapKey is to export a cryptographic key and to import in onto another device without giving the user any knowledge of key value. In ideal case a key imported via UnwrapKey could be considered completely secure and thus usable for all cryptographic operations. Previous sections, however, have shown that in practice this is not true. 42

48 5. POSSIBLE RESTRICTIONS TO CRYPTOKI INTERFACE Consider a PKCS#11 implementation where functions WrapKey and UnwrapKey did not exist. Such implementation would be unable to securely import or export keys. It still could use CreateObject to import keys, but under the presumption that the user is malicious, CreateObject is insecure. There actually may be some scenarios where a legitimate user could use CreateObject to import cryptographic keys securely, e.g. when the user inserts the key to the other device personally without sending it through any channels. Generally, however, it is not possible to export and import keys securely without WrapKey and UnwrapKey. What limitations would such approach pose in practice? From the point of view of asymmetric cryptography, the limitations would be minimal. All asymmetric cryptography algorithms work with a key pair that consists of a private key, which should remain unknown to the user, and public key, which is completely public and thus known by everyone. Cryptoki reflects this by the fact that a public key does not even have the SENSITIVE attribute. Therefore asymmetric encryption -> decryption process does not require key wrapping. When the encryption is performed on another token, there still is the need to import the public key, but that can be easily done via CreateObject. Symmetric cryptography, on the other hand, would be severely crippled by disabling importing and exporting keys. Essentially this would mean that only the token that was used for encryption could be also securely used for decryption, since there would be no secure way to transfer the key from one token to another. This may be less of an issue with software tokens that can be more easily moved around, but even these tokens should only be available to one user. Therefore it would be impossible to use symmetric encryption for e.g. messages exchanged between two users. Note there still are exceptions to this, such as TLS, which does not use wrapping at all, but utilizes key derivation instead. The table in 3.3 showed that other than brute force there are two ways to discover key value of a stored cryptographic key. Moreover, none of the nontrivial published attacks utilizes GetAttributeValue. Therefore removing the possibility of doing WrapKey + Decrypt would greatly increase security of PKCS#11 implementations. Moreover security of this approach should also hold even if there was an erroneous or malicious device, such as was discussed in the previous role suggestion. It can be seen that removing WrapKey and UnwrapKey from Cryptoki would increase its security, but it would limit usability symmetric cryptography. Even though symmetric cryptography is older and often considered less secure than asymmetric cryptography, it is still very important, mostly 43

49 5. POSSIBLE RESTRICTIONS TO CRYPTOKI INTERFACE because symmetric cryptography algorithms are much faster in comparison [15]. Therefore the conclusion is that disabling wrapping is not a viable solution to Cryptoki weaknesses. 5.3 Cryptographic Strength Restrictions This proposal aims to make the Weaker Algorithm Attack and Key Derivation Attacks impossible. There are two ways to do that. First approach is to define a list of mechanisms ordered by cryptographic strength of the algorithms in the Cryptoki API. Function WrapKey would only permit a key of the same or lower cryptographic strength as the input key to be wrapped. Similarly, DeriveKey would not allow creating a key with less cryptographic strength as function output. This restriction, however, could be very difficult to implement for multiple reasons. Not all the algorithms supported by Cryptoki have been published, it is difficult to compare symmetric and asymmetric cryptography etc. This approach also seems to be rather error-prone and wrong implementation of these rules could prove disastrous in that it would not only decrease security, but it would also complicate legitimate use of the token. The other approach would be to simply remove support of all algorithms that are considered weaker, such as RC2, from Cryptoki API. Unfortunately, this is not highly desirable, because even though some cryptographic algorithms may be weaker, they still have some advantages that make them useful. Examples of this would be speed or legacy support. Both presented restrictions would increase security of Cryptoki, but at the cost of scalability, extensibility and greatly limited choice of algorithm. The obvious downside of these restrictions is that they only make Cryptoki more secure against specific attacks that require brute force anyway and can be more easily prevented by other means, such as one of the approaches introduced above. 5.4 Removing Miscellaneous Simple Key Derivation Mechanisms It has been shown above that there are attacks based on specific key derivation mechanisms [7]. All of these mechanisms actually fit in the Miscellaneous simple key derivation mechanisms category in the PKCS#11 standard. They include the following: CKM_CONCATENATE_BASE_AND_KEY 44

50 5. POSSIBLE RESTRICTIONS TO CRYPTOKI INTERFACE CKM_CONCATENATE_BASE_AND_DATA CKM_CONCATENATE_DATA_AND_BASE CKM_EXTRACT_KEY_FROM_KEY Question is: Would disabling these mechanisms negatively impact practical token usability? There are other key derivation mechanisms that do not possess the vulnerabilities of the above shown mechanisms, such as SHA256_KEY_DERIVATION or AES_ECB_ENCRYPT_DATA. These and can perform common functions for key derivations (e.g. generating multiple keys from one master key) much better and without the aforementioned drawbacks. However, there are applications that use specifically concatenation and extraction, such as in RFC 5246 that describes The Transport Layer Security (TLS) Protocol [10]. That means the Miscellaneous simple key derivation mechanisms are necessary, even though they present possible opportunities for attacks. Preventing attacks against DeriveKey therefore depends on the correctness of the implementation. While removing these mechanisms would not be practical, the standard could more clearly specify the potential misuse of key derivation. 5.5 Chapter Conclusion This chapter analysed four possible ways to mitigate Cryptoki vulnerabilities by imposing further restrictions on the API. All four are trade-offs in that they increase security, but limit, remove or complicate functionality. Unfortunately none of the above approaches would be generally beneficial for the usability and security of the tokens. Therefore the conclusion of this chapter is that correct PKCS#11 implementation and awareness of the existing attack is crucial for the security and usefulness. 45

51 Chapter 6 Model Checking Many security-critical protocols and services have been designed and developed only to be found flawed years after their deployment. These flaws are usually due to the complex and unexpected interactions of the protocols and services as well as to the possible interference of malicious agents. Since these weaknesses are very difficult to spot by traditional verification techniques (e.g. manual inspection and testing), security-critical systems are a natural target for formal method techniques. [2]. Model checking is the algorithmic analysis of models to prove properties of their executions [13]. There are general purpose model checkers, such as those that can be used for analysing software, or model checkers specialized on analysis of security protocols [2]. This thesis utilizes SATMC model checker, which mostly focuses on security checking. However, as it can be seen later, the Caetus software is not strictly tied to SATMC and, if necessary, can potentially work with a different model checker. 6.1 AVISPA Tool The AVISPA Tool is a specialized tool for the Automated Validation of Internet Security Protocols and Applications. It provides a modular and expressive formal language for specifying protocols and their security properties, and integrates different back-ends that implement a variety of automatic protocol analysis techniques [29]. The back-ends include the previously mentioned SATMC model checker, OFMC model checker [3], CL- ATSE model checker and TA4SP model checker. A user interacts with the tool by specifying a security problem(a protocol paired with a security property that it is expected to achieve) in the High-Level Protocol Specification Language HLPSL. The HLPSL is an expressive, modular, role-based, formal language that allows for the specification of control-flow patterns, data structures, different cryptographic operators and their algebraic properties, alternative adversary models, as well 46

52 6. MODEL CHECKING as complex security properties. The AVISPA Tool automatically translates the user-defined security problem into an equivalent specification written in the rewrite-based formalism Intermediate Format. An IF specification describes an infinite-state transition system amenable to formal analysis: IF specifications are automatically input to the back-ends of the AVISPA Tool, which implement different techniques to search the corresponding infinitestate transition system for states that represent attacks on the intended properties of the protocols [29]. The following figure shows a graphical representation of a security problem analysis by the AVISPA Tool. Figure 3 - AVISPA architecture [29] The tool works under the assumption of perfect cryptography. That means it abstracts from used cryptographic algorithms and assumes that an intruder is not capable of breaking encryption in the model. On the other hand, it does not assume perfect security [23], which means an intruder can partially analyse the encrypted messages. The tool also uses Dolev-Yao Intruder Model, which basically means the intruder is in a complete control of the system. The intruder the intercept any message, change any message (as long as he possesses the cryptographic key necessary for decrypting the original message and/or encrypting the changed message), prevent any message from reaching the destination and send any message to any communicating party at any time he wants [29]. Note that the thesis reflects the Dolev-Yao model in that is assumes the user is always authenticated and 47

53 6. MODEL CHECKING malicious, which essentially means the attacker is in complete control of the environment. 6.2 HLPSL Language This section provides a basic description of HLPSL model specification language sufficient to read the specifications in this thesis. For a detailed description refer to AVISPA user manual [27]. The description will often compare HLPSL entities to similar ones in object-oriented programming languages, particularly Java. A HLPSL specification is composed of three parts: a list of definitions of roles, a list of declarations of goals (if any), and the instantiation of the main role. Roles The roles form the core of model specification. From a object-oriented point of view, roles are very similar to objects in that they have mechanics similar to attributes, methods and constructors. There two types of roles. The first are basic roles played by the agents which represent real world actors (people or devices) that somehow interact in the model. The other type are complex roles which are achieved by gluing basic roles together, so that they can execute together, usually in parallel [26]. These composed roles usually are Session and Environment. The basic roles have the following structure [28] 1. Role Declaration - contains role name and list of formal arguments. It is comparable to Java constructors in that it also specifies variables that are passed to the role on its creation. 2. Declaration of local variables and ownership rules, if any 3. Initialisation of variables, if required - local variables can be initialised in this section. 4. Transaction section or Composition section - see the respective sections for further description. For the purpose of model checking it is important to to note that every role also has a state. For a given role, its set of state variables is defined as all those variables that are in scope within the role (that is, those that are visible from within the role). A role s state is then defined as the values of 48

54 6. MODEL CHECKING all of its state variables [28]. Note that that back-end used by this thesis, the SATMC model checker, it capable of working with infinite state models [13]. This is not to be confused with State integer variable that appears in most HLPSL specifications. Example of a basic agent HLPSL role specification (minus the transition section) might look like the following: role alice(a,b,s : agent, Kas : symmetric_key, SND, RCV : channel (dy)) played_by A def= local State: nat, Kab: symmetric_key init State := 0 transition... end role [26] Transitions Each transition represents the receipt of a message and the sending of a reply message. Note that PKCS#11 function calls and return values used in this thesis can be also considered messages for the purpose of the model checking. A transition consists of a trigger, or precondition, and an action to be performed when the trigger event occurs [26]. The transitions are immediate reactions and therefore their actions are performed as soon as the transition is triggered and its conditions are met. Transitions have the form X = > Y and relate an event X and an action Y [28]. Important property of HLPSL variables is that they can be primed. X stands for a primed variable X. That means X is getting assigned a new value and refers to the new value. For example the following simple transition RCV(X ) = > SND({X.X }_Ks) specifies that when the role receives a new value X, it assigns the new value to X and sends both the formed value (X) concatenated with the new value (X ) and encrypted by a key Ks. Common transition triggers and conditions Variable comparison - using common algebraic notation, e.g. =,>,< 49

55 RCV(X) - means the actor received message X. 6. MODEL CHECKING Common transition actions Variable assignment - in the form X :=Y, where Y is the new value for the variable X. SND(X) - means the actor sends message X. Goal specification - see the next subsection devoted to goals Security Goals Security goals are specified in HLPSL by augmenting the transitions of basic roles with so-called goal facts and by then assigning them a meaning by describing, in the HLPSL goal section, what conditions - that is, what combination of such facts - indicate an attack [26]. The three basic goal predicates supported by HLPSL are secret, witness and request. The later two relate to authentication, which, as was clarified earlier(2.2), is not examined in this thesis. Secrecy of keys, on the other hand, is the goal of the thesis. The secret predicate has the following form: secret(x,x,{a,b}). That means the variable X must be only known to actors A and B. If any other actor discovers plain value of X, the secrecy goal is considered to be violated. The middle parameter, x, is a constant that is used to identify the goal in the model. Intruder Intruder is a malicious entity that attempts to break the security of the evaluated model. HLPSL language allows to define the capabilities of the intruder and initial knowledge of the intruder. The initial knowledge typically includes names of all other agents, all public keys, all keys either specific to intruder or shared between the intruder and some other party, and known functions. Important intruder capability is that, as mentioned above, the thesis uses Dolev-Yao intruder model for the communication channels, which gives the intruder complete control over sent and received messages. The intruder can either stay out of the system or he can directly play one of the roles. This is accomplished in HLPSL by substituting one of the roles in Environment composition by the intruder (i constant). The intruder then plays that role, which effectively compromises that role and all the 50

56 6. MODEL CHECKING data that role learns. Since this thesis works with the presumption that the user is malicious, the prepared models for the model checker will always substitute the user actor with an intruder. HLPSL also allows specification of what the intruder must never know by marking such objects as Secret security goals. Note that if the intruder plays e.g. role A and key K is designed to be secret between A and B, the fact that the intruder learns the key K does not violate the security of the model. This situation, however, does not occur in model checking in this thesis, because the keys in the Cryptoki model are intended to be kept secret from users anyway and the only actor that does legitimately know the key value is the token. Naturally, the intruder never plays the role of the token. 6.3 Transcription of PKCS#11 into HLPSL This section shows how some PKCS#11 functions are transcribed into the HLPSL language. An important problem the transcription has to deal with is that the model checker does not support key handles. That means the keys that are unknown (or are supposedly unknown) to the user must be specified in another way. The functions are transcribed as HLPSL transitions, which means everyone has a trigger and actions and some may also include conditions. Unlike most HLPSL specifications, Caetus model only has two states. Most operations, however, take place in State = 1, because the only purpose of State = 0 is to force initialization of cryptographic keys. This section shows the three most critical functions for this thesis. Model checker variables Unlike Cryptoki, HLPSL does not support easy object manipulation. Therefore Caetus defines the cryptographic key objects in a more rigid manner. There are total five keys that may appear in the model checking depending on the results of the token testing. The keys are as follows: SK - symmetric key that is known to the token and is used for either wrapping, encryption or both. It is assumed that this key is created using GenerateKey and has its LOCAL set to true and its EXTRACTABLE to false. Intruder should never find out the value of this key. LSK - this is a secondary symmetric key intended so that when SK is used for wrapping, it does not have to wrap itself. 51

57 6. MODEL CHECKING ISK - this is also symmetric key, but it has LOCAL = false. The asymmetric key pairs serve exactly the same functionality as the symmetric ones, so they do not have to be mentioned in the table. The HLPSL specification includes no variables that represent the values of attributes SENSITIVE, EXTRACTABLE, WRAP etc. The reasoning for this is that the specification of these attributes is done during the phase of model construction and the respective transitions are only included if the functions are possible in Cryptoki. This is based on the principle that the intruder can run any transition whenever he wants and therefore can set any attribute to true (or false in the case of SENSITIVE) whenever he wants, as long as the Cryptoki implementation permits that. That means the attribute setting transitions can be omitted, which makes the resulting model much clearer and easier to read. WrapKey Wrapping a key requires the user to specify the key that is used for wrapping and the key that is wrapped. The user should not know the value of either of the two keys, which means none of the two keys can be included in the trigger. Therefore another way to specify the keys is needed. In order to achieve this Caetus uses command constants, that is text constants known to the intruder, where each constant is only specific to one transition and therefore determines the used keys. Example of such a constant is wrap_secret_by_secret_sk, which commands the token to wrap a secret key (LSK) by SK. Note that the imported ISK cannot be used for wrapping, since it is known to the intruder and would thereby lead to a trivial attack. The output of WrapKey is the wrapped key encrypted by the wrapping key, which is reflected in the model checking. The SND content in model checking is equal to the essential function output in Cryptoki, but only if that output is shown to the user. Example of WrapKey State = 1 /\ RCV(wrap_secret_by_secret_sk) = > SND({LSK}_SK) UnwrapKey The most intuitive transcription of unwrapping would be as follows: 52

58 6. MODEL CHECKING State = 1 /\ RCV(unwrap.{M }_SK) = > LSK := M Unfortunately any transition trigger that contains a text constant (the command words such as unwrap) concatenated with another input causes the model checker to either crash or to enter an infinite loop. That means the unwrapping must be simplified, as shown in the following example: State = 1 /\ RCV({LSK }_SK) = > SND(unwrap_success) Decrypt For the reasons mentioned previously, the Decrypt transcription looks as follows: State = 1 /\ RCV({M }_SK) = > SND(M ) It is immediately obvious that Decrypt trigger is similar to Wrap. The only difference is that Decrypt accepts generic encrypted data M, while Wrap requires the encrypted data to be a specific cryptographic key. That means Decrypt will also decrypt the wrapped keys and show them to the user (and therefore also to the intruder). This may sound like a critical issue, but it actually represents the Key Separation Attack shown in Limitations Unfortunately, mostly due to the facts mentioned in the section 6.3, the power of model checking in Caetus is limited in that the model cannot possibly completely reflect the tested token. One reason for this is that the tokens can usually work with unlimited amount of cryptographic keys and introduce various combinations to the key properties. HLPSL does not support such mechanics, which means a limited number of keys must be used. These keys are designed to reflect the token capabilities as closely as possible, but the model still cannot reflect all possible combinations with a large number of keys. 53

59 6. MODEL CHECKING Another limitation is posed by the fact that attempting to change key attributes over the course of the run of the model checker causes the model checker to enter seemingly infinite loop. It is unknown if this is caused by a bug or by a wrong implementation, but even after trying different approaches to this, this issue was not solved and had to be worked around by effectively specifying the attributes by the available functions in HLPSL. The model checker cannot reflect the inner working of the token mechanisms. That means the model checker cannot e.g. tell if the token is actually vulnerable to a discovered attack, because the token may have in place some mechanics that prevent the attack, even though the properties sent to the model checker suggest otherwise. In future development of Caetus tool there are plans to mitigate these weak points by adding complex State mechanics. However, in the current version the model checker must be considered a limited addition to the tool that is capable of discovering attacks against the token, but since the token cannot be fully modelled, there may be attacks that cannot be discovered by the model checker. Unfortunately the current version of model checking in Caetus behaves non-deterministically. On different runs it sometimes finds different attacks or the same attacks with different attack traces. Sometimes it does not find the attack at all even though an attack is clearly possible. This problem only occurred once in fifteen runs, but illustrates that the model checker still cannot be safely relied upon, as explained above, and that the model checking in Caetus still needs more work. 6.5 Chapter Conclusion This chapter described the basics and principles of model checking. It also defined some problems Caetus tool deals with in the process of constructing a HLPSL specification that is passed to the model checker and showed that model checking in Caetus still needs more work in order to be a reliable component of the tool. 54

60 Chapter 7 Java and PKCS#11 While Cryptoki is intended for C language, there also is a Java wrapper available that provides virtually the same functionality. Both C and Java have their advantages and disadvantages, but author of this thesis prefers Java. The most obvious advantage of Java is that since Caetus is developed as an open-source software, Java makes its code much easier to read and eventually modify. The possible downside of using Java wrapper is that the wrapper may not be perfect and may possibly introduce some limitations to the thesis. This chapter first briefly describes Java Cryptography Architecture and then it proceeds to describe the provider used in Caetus. Note that for compatibility reasons the code is compiled with Java 6 rather than with the current Java 7. In practice, however, situations that a computer only has Java 6 installed are still common, so using Java 6 prevents such issues. 7.1 Java Cryptography Architecture Java Cryptography Architecture, abbreviated as JCA, is a security platform based on the following principles [19] 1. Implementation independence - the algorithms do not have to be implemented by the application developer, but rather by security providers, which are imported into the application via a standard interface. 2. Implementation interoperability - an application is not necessarily bound to a specific provider and a provider does not have to be bound to a specific application. 3. Algorithm Extensibility - it is easy install new providers to the default built-in list of providers in order to e.g. work with proprietary devices or to implement a new standard. JCA is provider-based. That means implementation of the security algorithms is done by the providers. There are many built-in providers such as 55

61 7. JAVA AND PKCS#11 the SUN Provider or the SunRsaSign Provider. There are additional providers available, such as the popular BouncyCastle. The provider crucial for this thesis is SunPKCS11 provider. The SunPKCS11 provider is unique in that, unlike other providers, it does not implement the algorithms itself, but rather acts as a conduit between the Java environment and the native PKCS#11 providers. When properly configured, the SunPKCS11 provider enables applications to use the standard JCA APIs to access native PKCS#11 libraries. However, the thesis is not interested in accessing PKCS#11 functions via JCA, but rather directly uses the provided wrapper to call Cryptoki functions. 7.2 Java Wrapper The wrapper included in SunPKCS11 Java security provider enables calling the PKCS#11 functions described in the standard from Java code. It should enable the same functionality as if the C Cryptoki library was used. The functions provided by the wrapper, however, slightly differentiate from the PKCS#11 standard specification. This section will go through the differences and analyse their impact on this thesis. Missing Functions The PKCS#11 standard provides a list of functions to implement. The wrapper does not include all of these functions. The missing ones are [16] CancelFunction - legacy function. CloseAllSessions - closes all sessions an application has with a token. GetFunctionList - returns a pointer to the Cryptoki library s list of function pointers. GetFunctionStatus - legacy function. GetOperationState - used to save a state of a cryptographic operation. GetObjectSize - returns the size of an object in bytes. Initialize - initializes the Cryptoki library. InitPIN - initializes the normal user s PIN. 56

62 7. JAVA AND PKCS#11 InitToken - initializes a token. SetPIN - changes PIN of a user. SetOperationState - used to restore a state of a cryptographic operation. WaitForSlotEvent - waits for a slot event, such as token insertion or token removal, to occur. It is immediately clear that the legacy functions are not important at all. For the other missing functions the important question to ask is: Are the functions relevant for the PKCS#11 key security tests? And is so, is it possible to work around the fact that the wrapper does not include the function? Caetus tool only needs one session for proper tests and even if it needed more, it would be possible to manually close them one by one, so the function CloseAllSessions is not necessary. Still, unlike most others, it is not actually clear why this function is missing, since it provides an assurance that the sessions have been closed and the token can be safely removed. Getting a list of functions would be obsolete, since the wrapper handles this functionality for the programmer. It also better fits Java philosophy, where the programmer must deal with as few low-level issues as possible. Similarly, initializing the Cryptoki library, or more specifically provider in this case, is done in setting up the provider in Java code, so there is no need to duplicate this functionality in the wrapper. Saving and restoring a state of a cryptographic operation (functions GetOperationState and SetOperationState) and waiting for a slot event are not needed by this thesis at all. InitPIN and InitToken are functions specific to SO user and therefore not interesting for this thesis anyway. It is clear that since the wrapper does not include these two functions, SunPKCS provider cannot be used by SO user. SetPIN is similar to the above token management functions, but can actually be used by a normal user. In practice its lack would severely limit the security of the token, as it would make it impossible to change PIN of a user. Still, in such a case another Cryptoki implementation could be used. From the point of view of this thesis, however, SetPIN is not important at all. Caetus is a tool designed only to test, so it should never alter anything in any tested token. Changing PIN would be a severe violation of this policy. GetObjectSize is a function that seems necessary, since many functions in Cryptoki effectively take object size as a parameter. Fortunately the 57

63 7. JAVA AND PKCS#11 wrapper also handles this automatically, so that the programmer does not have to deal with object size or template size at all. It has been shown that none of the functions missing in the wrapper is needed by this thesis. On the other hand the missing functions may limit practical functionality of the SunPKCS11 Provider. Missing Structures A very important difference between Cryptoki and Java PKCS#11 wrapper is that the Java version is missing certain structures defined by Cryptoki. In Cryptoki data structure is a structure that is used to hold particular predefined data. An example of such a structure is CK_EXTRACT_PARAMS. That is also one of the missing structures. CK_EXTRACT_PARAMS is a parameter of EXTRACT_KEY_FROM_KEY, which has been mentioned in previous chapters as one of the weaker key derivation mechanisms. Since some other key derivation mechanisms also use structures that are missing in the Java wrapper, it may seem that the weaker key derivation mechanisms cannot be tested at all. Fortunately, it has been discovered that the aforementioned data structures were not included in the wrapper, because they would have been obsolete anyway. The reason for this conclusion is that CK_EXTRACT_PARAMS only consists of one unsigned long int, so there is no need to create an extra structure just for that single parameter. Instead the long can be directly input as the parameter of the EXTRACT_KEY_FROM_KEY mechanism. The same applies to other weaker key derivation mechanisms, only the direct input is either byte[] or key handle. Other crucial structures that are defined by Cryptoki but are not included in the Java wrapper are CK_SESSION_HANDLE that points to the current session and CK_OBJECT_HANDLE that points to the location of objects in the session. These structures are also replaced by simple long variable. This, unlike the case with key derivation structures, was much easier to determine with the help of the publicly available documentation [12]. Different Function Parameters As explained above, the functions in Java wrapper have different parameters than in Cryptoki specification. Moreover, there is very little publicly available documentation for the Java wrapper [12]. Fortunately there is consistency between the two, so it is considerably easy to determine the correct Cryptoki function parameters in Java even without detailed documenta- 58

64 7. JAVA AND PKCS#11 tion. When a function in Cryptoki requires a parameter that determines object size or length of a template, the same function in Java wrapper will not require that parameter. From a high-level point of view this approach is very useful, since it means the programmer does not have to deal with parameters that can be determined from other parameters passed to the function. Over the course of work on the Caetus tool this approach caused a problem once, since it was discovered that if a flawed template is passed to a function, it will cause a connected software token to crash. Flawed template means a template that has less attributes than its length or a template that is missing an attribute in one of its slots. Most Cryptoki functions related to this thesis also have an attribute that specifies the location that receives the output of the function, which usually is a newly created object or encrypted data. For example in Cryptoki WrapKey has parameter pwrappedkey of the type BYTE_PTR, which points to the location that receives the wrapped key [16]. In Java there is no such attribute and the function instead returns the wrapped bytes as its return value. Cryptoki specification uses return values to determine whether the function worked properly on not and if not, the return value further specifies the cause of the failure. As shown above, Java wrapper adheres to Java design and returns the essential function output instead. In order to notify the user of a function failure, it uses Java exceptions that contain the Cryptoki return values as exception messages. For example when the function WrapKey attempts to wrap a key that has its EXTRACTABLE = false, it instead throws a new PKCS11Exception with its message containing CKR_KEY_UNEXTRACTABLE. Actually, that is the behaviour specified by Cryptoki and intended by the Java wrapper, but it has been shown that some tokens ignore even this basic rule [5]. 7.3 Sample Code This section shows a brief sample in order to depict the difference between Java and C implementations. The first code snippet is taken from the examples provided in the standard [16] and the other comes from Caetus code. C implementation CK_SESSION_HANDLE hsession; 59

65 7. JAVA AND PKCS#11 CK_OBJECT_HANDLE hwrappingkey, hkey; CK_MECHANISM mechanism = { CKM_DES3_ECB, NULL_PTR, 0 }; CK_BYTE wrappedkey[8]; CK_ULONG ulwrappedkeylen; CK_RV rv;.. ulwrappedkeylen = sizeof(wrappedkey); rv = C_WrapKey(hSession, &mechanism, hwrappingkey, hkey, wrappedkey, &ulwrappedkeylen); if (rv == CKR_OK) {.. } Java implementation try { long sessionhandle; long wrappingkeyhandle; long hkey; CK_MECHANISM mechanism = new CK_MECHANISM( PKCS11Constants.CKM_DES3_ECB); byte[] wrappedkey;.. wrappedkey = pkcs11.c_wrapkey(sessionhandle, mechanism, wrappingkeyhandle, hkey); } catch (PKCS11Exception ex) {.. } The most notable difference is that Java uses less parameters to accomplish the same result. That is due to the aforementioned difference in the parameters required by the functions. The other important difference is that C code examines the return value in order to determine the result, while Java code surrounds the procedure in a try-catch block. The results are again the 60

66 7. JAVA AND PKCS#11 same. Also note that Java code only uses two variable types, long and byte[], while C code uses five different structures. The reason for this is that Java wrapper substitutes all the C structures that only effectively contain one long anyway with a plain long. The Java code snippet contains two objects crucial for the whole Caetus tool. The first one is PKCS11 class which only has its instance, denoted as pkcs11, shown in the snippet. This class is the core of the Java PKCS#11 wrapper and handles all the functions. For example wrapping is called by pkcs11.c_wrapkey(parameters). The wrapper takes the function, translates it for the underlying PKCS#11 token and takes the Cryptoki return value. If the return value is anything other than CKR_OK, the PKCS11 class throws the PKCS11Exception with the Cryptoki return value in its message. If the Cryptoki return value is CKR_OK, the essential function output as described above is returned. The other key class for the Java wrapper is PKCS11Constants, which basically bridges the Java wrapper and Cryptoki by providing the Java code pointers to the objects in Cryptoki. This approach greatly reduces the amount of Java classes needed in the wrapper. 7.4 Chapter Conclusion It has been shown that the Java SunPKCS11 Provider offers functionality that is very similar to Cryptoki specifications. There are some limitations, but they do not concern this thesis, since they are not related to stored cryptographic key protection. Therefore Java has been deemed a viable choice for implementing the tool for automated token analysis. 61

67 Chapter 8 Caetus Tool The primary goal of this thesis was to develop an open-source tool that could be used to automatically analyse the PKCS#11 tokens. The tool focuses on finding mistakes in PKCS#11 implementation and also tries to analyse vulnerability of the tested tokens to the attacks showed in previous chapters of this thesis and to some trivial key recovery attempts. The tool is distributed under the Apache License, Version 2.0 [25]. The model checker, which is distributed together with Caetus, consists of multiple parts, one of which (zchaff ) has a more restrictive license that forbids distributing the software unless an explicit permission is given. The permission has been granted by John F. Ritter, JD, MBA. This is referenced in the license files distributed with Caetus. The code is available at com/p/caetus/. 8.1 Structure of the Tool This section describes the object structure of the tool, so that it is as easy to access or modify as possible. The basic structure of the tool is as follows: Model Checking Goals - the secrecy goals of the model are common to the whole HLPSL specification. These classes manage the goals. Roles - the roles are prepared here. Since these classes form the core of HLPSL specification preparation, they are described in detail below. Transitions - these classes form a high level interface that makes adding new transitions to the HLPSL specification as short and simple as possible. Variables - permits high-level definition of variables in the rest of the code. It also manages sorting variables by their types, 62

68 8. CAETUS TOOL which is very important for the HLSPL specification. In the code the variables are referred to by String names. In Java these classes utilize the inheritance mechanics. Model Maker - this class performs the preparation in that it evaluates the discovered token capabilities, constructs roles and creates the final HLPSL specification. PKCS#11 Keys - forms high level key mechanics. These classes are described below in detail. Session - the bulk of the code is focused into this class. It runs all the tests. Templates - high level wrapper over Cryptoki templates that makes working with the templates closer to Java lists. Token Capabilities - these classes form a transition between the capability extraction and model checking. The capability extraction results are saved here and later evaluated by Model Maker. Token Initializer - this class handles the initialization of the token. Roles There are total six Java classes representing HLSPL roles, to which they also correspond. The ModelRole is an abstract class from which all other roles inherit. It contains code used by all other roles, i.e. preparing the list of variables, manipulation with variables and composing String representation of beginning and end of the role. The following figure shows the structure of the role classes. There always is exactly one instance of ModelEnvironment and ModelSession. In practice there also is only one instance of ModePerson, but it is fully possible to test models with multiple persons. As of this moment, however, it makes little sense, since the person only represents an intruder with only one simple transition. All the important transitions are included in the class ModelToken. 63

69 8. CAETUS TOOL Figure 4 - Role class diagram 8.2 Steps The tool works in the following steps: 1. Initialize the token, create a session and login. 2. Perform tests on the token. (a) (b) Determine the basic capabilities. Perform in-depth tests to discover if the functions adhere to the standard as in 3.4. (c) Test known attacks as in Prepare HLPSL specification for the model checker. 4. Run the model checker. 5. Close the session and log out of the token. Step 1 This step is not very interesting for the thesis, since it just covers the process necessary for the tests to begin. Over the course of software implementation there were many difficulties particularly with the initialization of software tokens, though. These problems will be detailed in chapter 9. 64