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

MASARYKUNIVERSITY FACULTY OFINFORMATICS

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

Verifying and improving

cryptographic key security in

PKCS#11 implementations

DIPLOMATHESIS

Josef Hertl

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.

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ˇc, 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 de-veloped 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.

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

1 Introduction . . . 3 1.1 Thesis Outline . . . 3 1.2 Terminology . . . 4 2 PKCS#11 . . . 5 2.1 Standardization . . . 5 2.2 Cryptoki . . . 6 3 PKCS#11 Key Protection. . . 11

3.1 Cryptographic Key Attributes . . . 11

3.2 Functions . . . 13

3.3 Cryptoki Function Input and Output . . . 21

3.4 Basic Function Testing . . . 24

3.5 Chapter Conclusion . . . 28

4 Known Attacks on PKCS#11 . . . 29

4.1 Known Attacks . . . 29

4.2 Known Attack Table . . . 35

4.3 Attack Testing . . . 36

4.4 Chapter Conclusion . . . 38

5 Possible Restrictions to Cryptoki Interface . . . 39

5.1 Cryptographic Key Roles. . . 39

5.2 Limiting WrapKey and UnwrapKey . . . 42

5.3 Cryptographic Strength Restrictions . . . 44

5.4 Removing Miscellaneous Simple Key Derivation Mechanisms 44 5.5 Chapter Conclusion . . . 45 6 Model Checking . . . 46 6.1 AVISPA Tool . . . 46 6.2 HLPSL Language . . . 48 6.3 Transcription of PKCS#11 into HLPSL . . . 51 6.4 Limitations . . . 53 6.5 Chapter Conclusion . . . 54 7 Java and PKCS#11 . . . 55

7.1 Java Cryptography Architecture . . . 55

7.4 Chapter Conclusion . . . 61

8 Caetus Tool . . . 62

8.1 Structure of the Tool . . . 62

8.2 Steps . . . 64 8.3 Parameters . . . 67 8.4 Complications . . . 68 8.5 Chapter Conclusion . . . 69 9 Tested Tokens . . . 70 9.1 NSS . . . 70 9.2 OpenCryptoki . . . 72 9.3 Softhsm . . . 74

9.4 GNT USB Security Token. . . 75

9.5 Chapter Conclusion . . . 76

10 Conclusion. . . 77

Introduction

PKCS#11 is a widely implemented standard that defines API for crypto-graphic tokens. In practice there have been shown many attacks on the standard implementations.

This thesis aims to detect incorrect implementations of PKCS#11 stan-dard with regard to stored cryptographic key security. Moreover, the imple-mentations 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 speci-fied 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 re-strictions takes into consideration their impact on practical usability of the tokens. In order to further evaluate the security of the tokens against pos-sible 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.

the Java PKCS#11 wrapper and discusses the advantages and disadvan-tages 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].

∙ Karepresents a cryptographic key Ka that is in plain and therefore fully known to the user.

∙ {Ka}_Kbstands for a cryptographic key Ka encrypted by a

crypto-graphic key Kb.

∙ h(Ka) means the user knows the handle (2.2) of a cryptographic

key Ka, but does not know thekey valueof Ka.

∙ Secret keymeans a cryptographic key used in symmetric cryptogra-phy. In literature this type of key is also commonly calledsymmetric key.

PKCS#11

This chapter provides a brief overview of the PKCS#11 cryptographic stan-dard and its relationship to this thesis.

2.1 Standardization

Cryptographic standards serve two important goals: making different im-plementations inter-operable and avoiding various known pitfalls in com-monly 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 "Cryp-tographic Token Interface Standard". It specifies an application program-ming interface, called "Cryptoki", to devices which hold cryptographic in-formation 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 imple-mented as a library supporting the functions in the interface, and applica-tions 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 crypto-graphic 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 factoandde jure.De jurestandards are, as the name implies, based on law. That means a central authority, usu-ally a state, prepares, implements and enforces the standard. On the con-trary,de factostandards are voluntary and formed in the market process as a consequence of interactions among agents [1]. Thede factostandards can

be further split into two categories. One category is unsponsored standards that have no identified originator holding a proprietary interest, but nev-ertheless 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 thesponsored de factostandards 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 Cryp-toki model and its relationship to the applications.

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 ob-ject 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 de-tail 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

also classified according to their lifetime and visibility.Token objectsare vis-ible to all applications connected to the token that have sufficient permis-sion, 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 objectsare more temporary: whenever a session is closed by any means, all session objects created by that session are automatically de-stroyed. 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 object-oriented languages. Cryptoki defines the attribute types and which objects contain which attributes. For example Mechanism objects only have two at-tributes - mechanism type and object class. Both these atat-tributes 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 de-scribed 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 secu-rity 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 function-ality 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

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 en-cryption & deen-cryption, such asAES_GCM. Still, the vast majority of mecha-nisms 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 certifi-cates 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 aSecurity Officer (SO). The other type is thenormal user. Only thenormal useris allowed access to pri-vate 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 theSOis to ini-tialize a token and to setthe normal user’sPIN and possibly to manipulate some public objects. Thenormal usercannot log in until theSOhas 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. There-fore the thesis can assume every user is malicious and continuously at-tempts 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 to-ken 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

on the token, such as its cryptographic keys. This assumption also means the thesis can view all users asnormal 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 cat-egories [16]. The ones particularly interesting for this thesis are the object management functions and key management functions. Also very impor-tant 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 withC_, e.g. function that wraps keys is calledC_WrapKey. For the sake of brevity the function names in this thesis will mostly be written without the precedingC_.

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 attributeCKA_VALUE. Public and private keys have no such common attribute. For example RSA does not use theCKA_VALUEattribute at all [16]. Since the standard deals with both asymmetric and symmetric cryptography, a common termkey valuewill be used for the attributes that describe the raw key value.

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 pos-sibility to use these functions in an attack to discover raw key data values.

Like in most other programming languages the PKCS#11 API crypto-graphic functions are usually not performed as a single operation. E.g. func-tion to decrypt data first requires the user to callC_DecryptInitfollowed either byC_Decryptif the data is short enough to be decrypted in a sin-gle 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 func-tions as a single-part operation. Therefore to refer to a function for decrypt-ing data only plainDecryptwill be used. Similarly, almost every function requiresCK_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 the-sis, 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.

de-scribed later.LOCALis 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 readkey valueusingGetAttributeValue

function.EXTRACTABLEdefines whether the key can be used as input for

WrapKeyfunction and therefore exported outside of the token. Moreover,

key valueshould not be retrievable viaGetAttributeValuewhen the key

hasEXTRACTABLE=false, even if itsSENSITIVEis alsofalse. These

two attributes are essential to cryptographic key protection and therefore widely used in the thesis.ENCRYPT,DECRYPT,WRAPandUNWRAPsimply 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 tofalseand can’t ever change totrueagain, even ifSENSITIVE

is set back to true. Very similar principle applies to EXTRACTABLE and

NEVER_EXTRACTABLE. Every key that hasUNWRAPmust also have the

at-tribute UNWRAP_TEMPLATE. Equally every key with WRAP attribute also must haveWRAP_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

Pub-lic Keys. The nature ofPublic Keysimplies they cannot be sensitive and there-fore there is no reason to defineEXTRACTABLEfor 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 to-gether. 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 thetemplateparameters. 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 allObject Management Functionsare described here. These functions are general functions that manipulate objects. There are addi-tional functions used specifically for cryptographic key management, called Key Management Functions.GetObjectSizeis 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,

be-cause 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 containObject classandKey typeattributes. The template also must contain the fields that specify the key value. This is very different for symmetric and asymmetric cryptography and these of-ten do not conform to the standard. Moreover,VALUE_LENused by certain cryptographic algorithms must not be specified in the object creation tem-plate.MODULUS_BITSthat serves the same functionality for RSA also must not be specified here. Neitherprivate keysnorsecret keysallow the attributes

ALWAYS_SENSITIVEandNEVER_EXTRACTABLEto be specified in the

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 com-promised and known to the intruder. The keys imported via this function have theirLOCALattribute always set tofalse.

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.

ItsLOCALattribute determines theLOCALvalue of the new object. This

spe-cific 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 itsEXTRACTABLEattribute set totrue, this template can specifyEXTRACTABLEto be set tofalse, 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 hObjectmust have its COPYABLE attribute enabled. Strangely, the at-tribute 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 theCOPYABLEattribute is not a subject to testing.

Usage

One particular usage of this function with keys is to makesession keys per-sistent by copying them and specifying theTOKENattribute inpTempateto

TRUE. This is due to the fact that some tokens seemingly do not allow to alter the value ofTOKENattribute.

GetAttributeValue

This function returns values of the attributes specified intTemplate, if possi-ble.

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 success-ful, 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 itsSENSITIVEattribute set totrueor itsEXTRACTABLE

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

asSENSITIVEor 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 intTemplate, 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 3.4.

Conditions

None other than the attribute restrictions described above. Usage

SetAttributeValueprovides 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 al-ways include attribute that defines key length and must never contain at-tribute related tokey value. The template also must not specify the attributes

ALWAYS_SENSITIVEandNEVER_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 pre-sumption for the model checking.

GenerateKeyPair

This function works exactly likeGenerateKey, but generates bothprivate keyandpublic keyat the same time.

WrapKey

Wraps the given key and returns the wrapped key as byte[]. More specifi-cally, wrap takes keyE, uses it to encrypt keyKand then returns{K}_E.

∙ To wrap any secret key with a public key that supports encryption and decryption.

∙ To wrap anysecret keywith any othersecret key.

∙ To wrap aprivate keywith anysecret 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 (Ein the above description). It must use the same algorithm aspMechanism, other-wise 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 thekey 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 Kshould have higher cryptographic strength than the algo-rithm of keyK. Otherwise wrapping could actually make keyKmore sus-ceptible 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 cre-ate a newprivate keyorsecret key[16]. This function should work similarly to

CreateObjectin that both functions set the new object’sLOCALattribute

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 con-tain the KEY_TYPEattribute. LikeCreateObject, ALWAYS_SENSITIVE

andNEVER_EXTRACTABLEmay not be specified in the process of key

cre-ation. Conditions

None other than the attribute requirements specified in thepTemplate. 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 functionCopyObject.

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

may need to store a considerable number of keys. Since the cost of tamper-resistant storage for keys increases linearly with the size of key storage, a technique to generate keys from a smaller seed or compress key materi-als 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 em-bedded 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 con-cerns 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 inWrapKeyfunction.

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 itsENCRYPTattribute set totrue. 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 Encryptto 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

Parameters

pMechanism- the mechanism for encryption. Note that it is the same as the mechanism used inUnwrapKeyfunction.

hKey- The handle of the decryption key. It must be the same algorithm and have the samekey valueas 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 itsDECRYPTattribute set totrue. 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.InitializeorGetMechanismInfo. Other examples of important functions in these categories areLoginandLogout. 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 prac-tical 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 noth-ing to do with cryptographic keys, such asMessage Digesting Functions, or seemingly offer no key extraction possibility other than brute force, such asSigning Functions. FunctionGenerateRandommay 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.

3.3 Cryptoki Function Input and Output

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 pos-sibly 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 asCreateObject, 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 thekey valueis not known to the user.

∙ Known key handle- a key that is fully known to the user, including thekey 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 relevantkey.

∙ Command- represents a situation when the user only enters a com-mand 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 thekey valueand the user has no knowledge of thekey value.

∙ 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 thekey 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 respondstrueorfalsedepending on if the function was successful.

The following table provides a clear overview of the input and output of the functions. Note that thekey handleon the input for functionDeriveKey

is different from thekey handleon 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

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 exampleCopyObject 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 nociphertext 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 ciphertextis given as an input to the

UnwrapKeyfunction 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 akey valueinplaintext. The desired pro-cess iskey handle->plaintext. From the table it is clear that only two func-tions output plaintext. First one is GetAttributeValue, which already haskey handleas an input, and the other isDecrypt.Decrypttakes a ci-phertextas an input, therefore it is necessary to also consider functions that output aciphertext. Those areEncryptandWrap. Unfortunately,Encrypt

requiresplaintext as an input. Therefore, if an attacker wanted to encrypt a cryptographic key in order to obtain aciphertextas an input forDecrypt, he would have to already know thekey value. On the other hand,WrapKey

lets a malicious user create aciphertextout of a cryptographic key possibly even if he does not know thekey value. That means the two possible pro-cesses that convert anunknown key handleinto aplaintextcan be performed with functionsGetAttributeValueandWrap+Decrypt.

Another clear possibility comes from usingCreateObject. This func-tion permits the user to substituteunknown key handleby aknown key handle. The first function this can have impact on isWrap, since it takes twokey han-dlesas an input, so it lets the attacker use one compromised key to compro-mise 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 akey handleon 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 functionDigestdoes not have to be considered at all, since it has absolutely nothing to do with cryptographic keys. Moreover,Sign andVerifyare functions that relate to digital

sig-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 whichSign

or Verifywould be viable for an attack would be when these functions

supported much weaker cryptographic algorithms than the rest of the API. ThereforeDigest,SignandVerifyand 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

Encryptcan be used for certain attacks, particularlyTrojan 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. How-ever, as it will be shown later, many attacks against PKCS#11 exploit incor-rect implementation of one or more functions described in this section.

Many functions put either requirements or restrictions on thetemplate that is passed as their argument. These conditions are aggregated under pTemplaterequired and forbidden. Formally, the requirements are as fol-lows:

1. Function does not work if pTemplate does not contain any of the attributes marked asrequired.

2. Function must work when pTemplate contains all of the required attributes.

3. Function must work even whenpTemplateonly contains attributes that arerequiredand no more.

4. Function must not work whenpTemplatecontains any of the forbid-denattributes.

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

CreateObject

1. pTemplaterequired:OBJECT_CLASSandKEY_TYPEandKey value. 2. pTemplateforbidden:VALUE_LENGTH,MODULUS_BITS.

3. The following attributes of the newly created key are set tofalse:

LOCAL,ALWAYS_SENSITIVE,NEVER_EXTRACTABLE.

Implementations often require more attributes inpTemplatethan the stan-dard specifies. Caetus takes this into account and in such a case attempts to discover the actually required configuration.

CopyObject

1. If the original key hadEXTRACTABLE set to false, the new key cannot be set toEXTRACTABLE=true.

2. If the original key hadSENSITIVEset totrue, the new key cannot be set toSENSITIVE=false.

3. The new key will always have the sameNEVER_EXTRACTABLEas the original key.

4. The new key will always have the sameALWAYS_SENSITIVE as the original key.

5. The new key will always have the sameLOCALas the original key. GetAttributeValue

1. Key valuemust not be shown if the key hasSENSITIVE=true. 2. Key valuemust not be shown if the key hasEXTRACTABLE=false. 3. Key value must be shown if the key hasSENSITIVE=falseand

EXTRACTABLE=true.

4. Values of attributes other thankey valuemust be always shown if set.

The condition #2 implies thatkey valuemust not be shown even when the key hasSENSITIVE=falseandEXTRACTABLE=false.

SetAttributeValue

1. IfSENSITIVE=true, it cannot be set tofalse.

2. IfSENSITIVE=false, it can be set totrue.

3. IfEXTRACTABLE=true, it can be set tofalse.

4. IfEXTRACTABLE=false, it cannot be set totrue.

5. When settingSENSITIVE =true,ALWAYS_SENSITIVEdoes not change and remainsfalse.

6. When settingEXTRACTABLE=false,NEVER_EXTRACTABLEstill isfalse.

GenerateKey

1. pTemplaterequired:VALUE_LENGTHorMODULUS_BITS. 2. pTemplateforbidden:Key value.

3. LOCAL attribute of the newly generated key will always be set to

true. WrapKey

1. It is possible to wrap asecret keywith asecret key 2. It is possible to wrap asecret keywith apublic key 3. It is possible to wrap aprivate keywith asecret key

4. The function succeeds if and only ifhKeyhasEXTRACTABLE=true

andhWrappingKeyhasWRAP=trueand fails otherwise. UnwrapKey

1. pTemplaterequired:KEY_TYPE.

2. pTemplateforbidden:Key value,VALUE_LENGTH,MODULUS_BITS. 3. The function succeeds if and only ifhUnwrappingKeyhasUNWRAP=

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 theNEVER_EXTRACTABLEattribute set tofalse.

DeriveKey

1. The function only works if the first input key hasDERIVE=true

2. The newly created key always has itsLOCALset tofalse.

3. If any of the input keys hasSENSITIVE=true, the new key will also haveSENSITIVE=true.

4. When any one of the input keys hasEXTRACTABLE =false, the new key will also haveEXTRACTABLE=false.

The tests forDeriveKey take into consideration the fact that function

DeriveKeyhas multiple mechanisms which use different input types. The

mechanismsCONCATENATE_BASE_AND_KEY (simply takes two keys and concatenates them) andEXTRACT_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 aforemen-tioned test conditions. Moreover,DeriveKeytests will only use symmet-ric cryptography, since themechanismsused for thekey derivationare 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 ifhKeyhasENCRYPT=trueand fails otherwise.

Decrypt

1. The function succeeds if and only ifhKeyhasDECRYPT=trueand fails otherwise.

2. Decrypt(Encrypt(X)) equalsX, whereXis a random block of

Functions Encrypt and Decrypt are not intended for key manage-ment, therefore their basic tests are trivial. Testing of these two functions in Caetus also features comparing dataXandDecrypt(Encrypt(X))in or-der 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 ofencryptordecryptwas wrong,

WrapKeyandUnwrapKey would have to be considered broken, too. The

reason for this is that all these functions commonly use the same mecha-nisms. 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 de-vice 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 pro-tection and also functions that can be omitted from further research and testing because they clearly have no role in attacks on cryptographic key storage.

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 of-ten 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. At-tacks based off hardware tampering, such as a side channel attack [22], are not considered. While such attacks may be of big help in acquiring infor-mation 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 gen-eration), 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 asensitive key, Kwmeans a key that is used for wrapping other keys. The attack is based on a presumption that keyKwcan 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 keyKsin plain. This attack is possible even when the token fully conforms to the current PKCS#11 standard.

Since the basic requirement for this attack is that there is one keyKthat 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 keyK. Therefore, besides WRAPandDECRYPT, the tests also heavily featureGenerateKey,

CreateObject,SetAttributeValue,CopyObjectandDeriveKey.

Expanded Key Separation Attacks

Key Separation attack is based on the fact that one cryptographic key has attributesWRAPandDECRYPTboth set totrue. However, in order to suc-cessfully 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 basicKey Separation attack by somehow forbidding one cryptographic key from having WRAP

andDECRYPTboth set totrue.

An example algorithm ofExpanded Key Separationfollows.Ksstands for a sensitive key andKwfor a key that can wrap and unwrap.Kwcrepresents a cryptographic key with the samekey value asKw. In step 2 theENCRYPT

andDECRYPTattributes of the newly created Kwc are set totrue and its

WRAPandUNWRAPare 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 possibleExpanded Key Separationattacks. Other variations include usingCopyObjectto duplicate the key or importing the exported key to another token, creating another key viaDeriveKeyfunction or even usingUnwrapKeytwice in a row on the same key, but with different attributes.

All of these attack variation, however, rely on callingDecrypton the wrapped key Ks. Tookan project [5] has presented patched Cryptoki that prevents evenExpanded Key Separationby severely restricting the templates for cryptographic keys in the following way:

1. Keys generated on the token can only have either WRAP, UNWRAP or

2. Imported keyscan only have attributesENCRYPTandUNWRAPset 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 thekey management functions, there will be no way for a cryptographic key or even multiple cryptographic keys with the samekey valueto be able to use bothWrapKey andDecrypton 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 limi-tations that can be worked around. This issue will be thoroughly discussed later in chapter 5.

Caetus software will perform thorough tests ofExpanded Key Separation attacks in all aforementioned variations.

Key Conjuring Attack

Key conjuring is the process by which an attacker obtains an unknown, en-crypted key by repeatedly calling a cryptographic API function with ran-dom values in place of keys [8]. This attack leads to the attacker obtaining access toh(K). As explained in [8],Key Conjuringcan 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 testKey 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 par-ticularly 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 typicalKey Bindingattack algorithm looks as follows:

2. Re-import the first half of the key (under the same encrypting key and in ECB mode). This creates a keyK1.

3. Re-import the second half of the key (under the same encrypting key and in ECB mode). This creates a keyK2.

4. Perform a key search against the newly acquiredK1andK2 indi-vidually. [7]

Step 4 obviously requires application of brute force, which is not a pri-mary 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 dis-covered 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 toKey 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 forWeaker Algorithmfollows.Ksstands for strong cryptographic key (e.g. a AES key), whileKwstands for a shorter and there-fore weaker key supported by Cryptoki (for example RC2). Key values of both keys are unknown to the user.Kwmust have itsWrapset totrue.

1. Wrap(h(Ks),h(Kw)) -> {Ks}_Kw

2. Wrap(h(Kw),h(Kw)) -> {Kw}_Kw

3. Perform an exhaustive search on{Kw}_Kwin order to discoverKw. 4. UseKwto decrypt{Ks}_Kw. [7]

Unless a serious vulnerability is discovered in one of the cryptographic algorithms supported by Cryptoki, Weaker Algorithm attack obviously re-quires brute force or to succeed. However, this attack is mentioned, be-cause 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 ofweaker algorithmsand disableWrapfor these algorithms. On the other hand, such a step could severely limit the func-tionality of many PKCS#11 tokens.

SinceWeaker Algorithmattack 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 Algo-rithmattack. It does not require brute force and its execution is much sim-pler, but potentially very effective. In the following sample algorithmKs

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 tofalse. None of the

keys is known to the user.Knis an imported key withkey valueequal toKs, but in the process of unwrapping itsSensitiveis set tofalse.

1. Wrap(h(Ks),h(K)) -> {Ks}_K

2. Unwrap({Ks}_K,h(K)) -> h(Kn) %Sensitive ofKnis unset

3. GetAttributeValue(h(Kn),KEY_VALUE) -> Kn

Downgradeattack simply wraps a key and then immediately unwraps it back, but itsunwrapping templatecontainsSensitive = false. Possi-ble ways to mitigate this attack include forcing every key imported with

Unwrapto be Sensitiveor forbidding Sensitive andExtractable

to be set totrueat 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 samekey value. This solution, however, would present new security risks and could be simply defeated by using multiple tokens or by callingDeleteObjecton the original key before it is re-imported.

Downgradeattack 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 offsymmetric key derivation[7]. Down-side to these attacks is that all require non-trivial exhaustive search and they can only work when specific conditions are met. Therefore only the

most straightforward of these attacks is described and partially tested in the thesis.

TheReduced Key Spaceattack uses theCKM_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 ifDeriveKeyfunction can be used to ’shorten’ a cryptographic key. If so, the application will warn about the po-tential 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 asAES, the attacker can replace one block of the the wrapped key (ciphertext) with a different value. When the key is un-wrapped, this will cause the corresponding block of plaintext as well as the following block to have different values. The rest of the key remains in-tact. 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,UnwrapKeythus has its output altered toknown key handle. However, this attack does not di-rectly 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 un-wrapped with the corresponding private key. Also, by definition, a public key is always known to the user (=attacker). Since key wrapping and en-cryptionuse the samemechanisms, the following attack may be possible.Kt

stands for atrojan key,Kpubis a public key and Kpris the corresponding private key.

2. Unwrap({Kt}_Kpub,h(Kpr)) -> h(Kt)

Similar toPrivate Key Modification Attack, this attack also changes the output ofUnwrapKeyfunction to aknown key handle. It can, however, also work withsecret keysand 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 ac-cess 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 suc-cessfully recovering another stored key, but non-trivial exhaustive search is necessary to get thekey value.

∙ Trojan Key means the attack can create a new key with knownkey valueby other means than usingCreateObject, but the attack can not directly lead to recoveringkey valueof 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 vulnera-bility to one of them does not automatically mean the PKCS#11 implemen-tation is insecure.

Vulnerability totrojan keysis more difficult to evaluate. It is unclear if it can in any way, directly or indirectly, lead to extraction of other stored cryp-tographic keys. From the function input and output table (3.3) it is clear

that the only two functions that can get the key valueof an unknown key

areDecryptandGetAttributeValue. The later is clearly not applicable

here, because an attack that creates a trojan keycannot in any way change

Sensitiveattribute of another key.Decryptdoes not have to be called

from the token, because attacker already knows thekey valueof thetrojan key and can therefore trivially perform decryption outside of the token. There-fore 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 Attackare a potential security risk to the stored keys only if the keys imported withUnwrapKeycan haveWRAP=true.

It could be argued that a much easier way to obtain a trojan key is to

useCreateObject. However, since keys imported withUnwrapKey are

presumed to be unknown to the user, it is much easier to overlook this potentialtrojan keyvulnerability in the course of implementation. Therefore it is reasonable to include the attacks that lead totrojan keyin 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 listLof two or more attributes set, it means the following:

1. When a key has one of the attributes inLset totrue, it is not pos-sible to use setAttributeValue to change value of any other attribute fromLtotrue.

2. When creating a new key (does not matter ifkey valueis 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 ofLset totrue.

3. When the key ispublicorprivate, whole key pair is considered for the purpose of this test.

Key Separation Attack

1. No cryptographic key can have bothWrapandDecryptset. Test for Key Separation Attack clearly forms a subset of the following expanded version. That implies that if a protection measure prevents Ex-panded Key Separation Attack, it also prevents this attack. This attack is men-tioned 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 bothWrapandDecryptset. 2. Keys created via GenerateKey or GenerateKeyPair can only

have either [Wrap,Unwrap] or [Encrypt,Decrypt] set.

3. Keys that haveLocal=falsecan only haveDecrypt=false

andWrap=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 a3DESkey is exported withWrapKey, its first half cannot be reimported on its own.

2. When a3DESkey is exported withWrapKey, 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 keysKsandKwsuch as thatKwhas significantly lesser cryptographic strength thatKs, both keys have the attribute

EXTRACTABLE=trueandKwhasWRAP=true.

This clearly is not feasible to test for all cryptographic algorithm combi-nations. Therefore only few algorithms will be tested.

Downgrade Attack

1. Every key created viaUnwrapKeymust haveSensitive=true. Key Derivation Attacks

1. It is not possible to useDeriveKeyto create a key of lesser crypto-graphic strength than any of the input keys.

2. In the derivation process it is not possible to set SENSITIVE to

falseorEXTRACTABLEtotrue.

The test condition #2 is rather trivial, but extremely dangerous. Cor-rect implementation of the standard should prevent it, but it is explicitly tested in this section, as it can equal usingSetAttributeValuein order to changeSENSITIVEorEXTRACTABLEto the desired value, but is more easily overlooked.

Private Key Modification Attack

1. It is not possible to import (viaUnwrapKey) a private key that was randomly modified outside the device.

2. A key imported viaUnwrapKeycannot haveWRAP=true.

Condition #1 will hardly ever be satisfied, since that would require non-standard wrapping formats. That condition, however, is not very high pri-ority, since success in condition #2 renders the new modified private key essentially harmless.

Trojan Wrapped Key Attack

1. A key imported viaUnwrapKeycannot haveWRAP=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 atrojan keyon the token, may be considered less dangerous, but still subject to the tests.

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 dis-cusses the aforementioned attacks and security vulnerabilities and anal-yses 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 theTookanresearch. Moreover, they also proposed making more attributes sticky and different wrapping formats.

This chapter will go through various ways to mitigate the shown secu-rity risks and analyse their impact on functionality of PKCS#11 implemen-tations. 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, keyK

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 domainK’s roles may be modified again, to disable the previous role and to enable the rolesfor data encryptionandfor data decryption.

From the point of view of this thesisKey roleis 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 akey rolehave to be defined on key creation? 2. Can a cryptographic key have more than onekey role? 3. Is it possible to changekey roleof a key?