A Provably Secure PKCS#11 Configuration Without Authenticated Attributes

Abstract

Abstract. Cryptographic APIs like PKCS#11 are interfaces to trusted hardware where keys are stored; the secret keys should never leave the trusted hardware in plaintext. In PKCS#11 it is possible to give keys conflicting roles, leading to a number of key-recovery attacks. To prevent these attacks, one can authenticate the attributes of keys when wrapping, but this is not standard in PKCS#11. Alternatively, one can configure PKCS#11 to place additional restrictions on the commands permitted by the API. Bortolozzo et al. proposed a configuration of PKCS#11, called the Secure Templates Patch (STP), supporting symmetric encryption and key wrapping. However, the security guarantees for STP given by Bortolozzo et al. are with respect to a weak attacker model. STP has been implemented as a set of filtering rules in Caml Crush, a software filter for PKCS#11 that rejects certain API calls. The filtering rules in Caml Crush extend STP by allowing users to compute and verify MACs and so the previous analysis of STP does not apply to this configuration. We give a rigorous analysis of STP, including the extension used in Caml Crush. Our contribution is as follows: (i) We show that the extension of STP used in Caml Crush is insecure.(ii) We propose a strong, computational security model for configurations of PKCS#11 where the adversary can adaptively corrupt keys and prove that STP is secure in this model. (iii) We prove the security of an extension of STP that adds support for public-key encryption and digital signatures.

A Formally Verified Configuration for Hardware Security Modules in the Cloud

“…In [8] and [29] the analysis was generalized to other key configurations and was proved correct via typing and automated verification, respectively. In [36] a PKCS#11 configuration proposed in [7] was proved secure on a computational model of PKCS#11, using wrap_with_trusted to prevent key cycles which, by the way, is not the primary purpose of this attribute. All of these works assume that the attributes of keys are immutable.…”

“…Note that, while this attribute can potentially prevent previous attacks, in the standard it is not mandatory to set wrap_with_trusted on sensitive keys and there is no mention of how trusted keys should be generated and managed, vanishing all advantages of this mechanism. Some works proved that an accurate use of this attribute in a very controlled an limited way may work correctly, but they put limits to its application and assume that the attributes of keys are immutable, which is not realistic as it reduces the API functionality and breaks compliance with the PKCS#11 standard [1,8,23,29,36].…”

“…Since the API is flawed, full API access allows for extracting sensitive keys and makes any attempt of defining a secure configuration void. In other words, the general API-level attacker model is too strong and requires changing the API in order to achieve some security (see, e.g., [1,7,9,17,29,36]). Our strategy is to exploit a form of mild access control over keys that makes it possible to define different HSM users with specialized roles.…”

“…Particular installations might use ad-hoc solutions to prevent the above mentioned vulnerabilities, such as disabling key wrapping and any other dangerous key management functionalities in production devices, or replace them with nonstandard proprietary APIs as, e.g., [7,9,17,29,36]. However, these solutions break portability and, in general, it would be preferable to use the full API functionality in a secure way rather then cutting it down to a secure subset, or modifying it in nonstandard ways.…”