Formal security analysis of PKCS#11 and proprietary extensions

Abstract

PKCS#11 defines an API for cryptographic devices that has been widely adopted in industry. However, it has been shown to be vulnerable to a variety of attacks that could, for example, compromise the sensitive keys stored on the device. In this paper, we set out a formal model of the operation of the API, which differs from previous security API models notably in that it accounts for non-monotonic mutable global state. We give decidability results for our formalism, and describe an implementation of the resulting decision procedure using the model checker NuSMV. We report some new attacks and prove the safety of some configurations of the API in our model. We also analyse proprietary extensions proposed by nCipher (Thales) and Eracom (Safenet), designed to address the shortcomings of PKCS#11.

A Provably Secure PKCS#11 Configuration Without Authenticated Attributes

“…We say that an API is secure if, for any cryptographic primitives used by the API, encrypting and signing data using the API is as secure as using the primitives themselves in isolation. This is strictly stronger than the model from Delaune et al, where an API is considered secure if the attacker cannot learn the values of honestly-generated secret keys [12,13]. Moreover, the adversary in our model is allowed to adaptively corrupt certain keys.…”

“…Weak Security Models: Many existing analyses of APIs use a Dolev-Yao style symbolic model to express the security of the API and only prove that the adversary cannot recover keys in full with certainty [1,5,7,[11][12][13]16]. While this notion of security rules out many of the attacks that have been described in the literature, it does not guarantee that any cryptographic primitives using these keys are secure, which is the security goal in our model.…”

“…STP has been implemented as a set of filtering rules in Caml Crush, a software filter that rejects certain PKCS#11 calls [2]. However, the filtering rules in Caml Crush allow users to compute and verify MACs, which is not captured by the model from Delaune et al [12,13]. Therefore the previous analysis of STP does not apply to what is implemented in Caml Crush.…”

“…In 2008, Delaune et al presented a formal, Dolev-Yao style model of PKCS#11 and used model-checking tools to find new attacks [12,13]. Bortolozzo et al then developed an automated tool called Tookan, built on the model by Delaune et al, that found and executed attacks against real hardware devices using PKCS#11 [5].…”

Universally Composable Key-Management

“…Building on the work of Longley and Rigby [9] and Bond and Anderson [10] on API attacks, several recent papers have investigated the security of APIs on the logical level adapting symbolic techniques for protocol analysis [11][12][13], finding many new attacks. As discussed before, recent work on appropriate security notions for APIs in terms of cryptographic games [4,5] lacks composability.…”