Run-time analysis of PKCS#11 attacks

The goal of this paper is to report on the development of a tool aimed at the automatic detection of attacks against PKCS#11 devices. Instead of modifying or configuring the API, we propose a stateful run-time monitor which is able to track key usage over time, for the identification of operations that might result in the leakage of sensitive keys. We briefly report on the components developed for implementing the monitor and discuss new challenges and open issues

Type-Based Analysis of Generic Key Management APIs

In the past few years, cryptographic key management APIs have been shown to be subject to tricky attacks based on the improper use of cryptographic keys. In fact, real APIs provide mechanisms to declare the intended use of keys but they are not strong enough to provide key security. In this paper, we propose a simple imperative programming language for specifying strongly-typed APIs for the management of symmetric, asymmetric and signing keys. The language requires that type information is stored together with the key but it is independent of the actual low-level implementation. We develop a type-based analysis to prove the preservation of integrity and confidentiality of sensitive keys and we show that our abstraction is expressive enough to code realistic key management APIs

Analysis of Key Wrapping APIs:Generic Policies, Computational Security

International audienceWe present an analysis of key wrapping APIs with generic policies. We prove that certain minimal conditions on policies are sufficient for keys to be indistinguishable from random in any execution of an API. Our result captures a large class of API policies, including both the hierarchies on keys that are common in the scientific literature and the non-linear dependencies on keys used in PKCS#11. Indeed, we use our result to propose a secure refinement of PKCS#11, assuming that the attributes of keys are transmitted as authenticated associated data when wrapping and that there is an enforced separation between keys used for wrapping and keys used for other cryptographic purposes. We use the Computationally Complete Symbolic Attacker developed by Bana and Comon. This model enables us to obtain computational guarantees using a simple proof with a high degree of modularity

A Provably Secure PKCS#11 Configuration Without Authenticated Attributes

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

Proving Cryptographic C Programs Secure with General-Purpose Verification Tools

Security protocols, such as TLS or Kerberos, and security devices such as the Trusted Platform Module (TPM), Hardware Security Modules (HSMs) or PKCS#11 tokens, are central to many computer interactions. Yet, such security critical components are still often found vulnerable to attack after their deployment, either because the specification is insecure, or because of implementation errors. Techniques exist to construct machine-checked proofs of security properties for abstract specifications. However, this may leave the final executable code, often written in lower level languages such as C, vulnerable both to logical errors, and low-level flaws. Recent work on verifying security properties of C code is often based on soundly extracting, from C programs, protocol models on which security properties can be proved. However, in such methods, any change in the C code, however trivial, may require one to perform a new and complex security proof. Our goal is therefore to develop or identify a framework in which security properties of cryptographic systems can be formally proved, and that can also be used to soundly verify, using existing general-purpose tools, that a C program shares the same security properties. We argue that the current state of general-purpose verification tools for the C language, as well as for functional languages, is sufficient to achieve this goal, and illustrate our argument by developing two verification frameworks around the VCC verifier. In the symbolic model, we illustrate our method by proving authentication and weak secrecy for implementations of several network security protocols. In the computational model, we illustrate our method by proving authentication and strong secrecy properties for an exemplary key management API, inspired by the TPM

A Secure Key Management Interface with Asymmetric Cryptography

Cryptographic devices such as Hardware Security Modules are only as secure as their application programme interfaces (APIs) that offer cryptographic functionality to the outside world. Design flaws and implementation errors in security APIs have been shown to cause vulnerabilities that may leak secrets such as keys and PINs. Ideally, we would like to design such interfaces in such a way that we can formally prove security properties, even in the presence of some corrupted keys. In this work, we take such a design for a provably secure interface for symmetric key management, due to Cortier and Steel, and extend it to asymmetric cryptography, giving new security definitions and associated proofs. Asymmetric cryptography forces us to consider confidentiality and integrity properties separately and provide support for classical operations of public key infrastructure (e.g. certification of public keys). As far as we are aware this is the first such provably secure interface to support asymmetric key operations for key management: Cachin and Chandran's secure token interface supports asymmetric key operations only for encrypting and signing data, not for managing keys.Les systèmes cryptographiques tels que les modules matériels de sécurité ne peuvent apporter un niveau de sécurité que dans la mesure où leur interface de programmation (API) qui offre les services de cryptographie à l'extérieur de module atteint ce même niveau de sécurité. Il a été constaté que des défauts de conception ou des erreur d'implémentation dans les APIs de sécurité sont à l'origine de vulnérabilités pouvant entrainer la fuite de secrets comme des clefs ou des PINs. Idéalement, nous voudrions concevoir de telles interfaces de manière à pouvoir prouver formellement des propriétés de sécurité, même si certaines clefs sont corrompues. Dans cet article, nous partons d'une telle API, due à Cortier et Steel, conçue de manière disposer d'une preuve de sécurité pour la gestion de clefs symétriques, et nous l'adaptons à la cryptographie asymétrique en donnant une nouvelle définition de sécurité avec les preuves associées. Afin de prendre en compte la cryptographie asymétrique, nous sommes amenés à gérer de manière différentiée les propriétés de confidentialité et d'intégrité et à ajouter les fonctionalités classiques d'une infrastructure de gestion de clefs publiques (i.e. la certification des clefs publiques). Á notre connaissance, il s'agit de la première preuve d'interface prouvée permettant l'usage de primitives asymétriques pour la gestion de clefs : l'interface de Cachin et Chandra prévoit l'usage de primitives asymétriques uniquement pour le chiffrement et la signature de données, et non pas pour la gestion des clefs

How to wrap it up - A formally verified proposal for the use of authenticated wrapping in PKCS#11

Being the most widely used and comprehensive standard for hardware security modules, cryptographic tokens and smart cards, PKCS#11 has been the subject of academic study for years. PKCS#11 provides a key store that is separate from the application, so that, ideally, an application never sees a key in the clear. Again and again, researchers have pointed out the need for an import/export mechanism that ensures the integrity of the permissions associated to a key. With version 2.40, for the first time, the standard included authenticated deterministic encryption schemes. The interface to this operation is insecure, however, so that an application can get the key in the clear, subverting the purpose of using a hardware security module. This work proposes a formal model for the secure use of authenticated deterministic encryption in PKCS#11, including concrete API changes to allow for secure policies to be implemented. Owing to the authenticated encryption mechanism, the policy we propose provides more functionality than any policy proposed so far and can be implemented without access to a random number generator. Our results cover modes of operation that rely on unique initialisation vectors (IVs), like GCM or CCM, but also modes that generate synthetic IVs. We furthermore provide a proof for the deduction soundness of our modelling of deterministic encryption in Böhl et.al.'s composable deduction soundness framework

B.: Security for key management interfaces

Abstract—We propose a much-needed formal definition of security for cryptographic key management APIs. The advantages of our definition are that it is general, intuitive, and applicable to security proofs in both symbolic and computational models of cryptography. Our definition relies on an idealized API which allows only the most essential functions for generating, exporting and importing keys, and takes into account dynamic corruption of keys. Based on this we can define the security of more expressive APIs which support richer functionality. We illustrate our approach by showing the security of APIs both in symbolic and computational models. Keywords-Key management, security APIs, cryptography I