Secure your PKCS#11 token against API attacks!

PKCS#11 defines a widely adopted API for cryptographic devices such as USB crypto-tokens and smartcards. Despite its widespread adoption, PKCS#11 is known to be vulnerable to various attacks that enable the extraction (as plaintext) of sensitive keys stored on the device. These attacks have been formalized and analyzed via model-checking, so as to automatically find flaws on specific subsets of PKCS#11 and on given device configurations. The analyses, however, are performed on an abstract model of the standard and the ‘theoretical ’ attacks have to be tried by hand on real devices. In this paper we shortly describe a new tool, named API attacks!, that aims at automatically performing the above mentioned analyses on real PKCS#11 devices. We believe this tool might be helpful both to hardware developers, willing to improve the security of their existing and new devices, and to system administrators that might want to check their device is configured is a secure way before distributing it to end-users.

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

An Overview of Cryptography (Updated Version, 3 March 2016)

There are many aspects to security and many applications, ranging from secure commerce and payments to private communications and protecting passwords. One essential aspect for secure communications is that of cryptography...While cryptography is necessary for secure communications, it is not by itself sufficient. This paper describes the first of many steps necessary for better security in any number of situations. A much shorter, edited version of this paper appears in the 1999 edition of Handbook on Local Area Networks published by Auerbach in September 1998

Automated analysis of security protocols with global state

Security APIs, key servers and protocols that need to keep the status of transactions, require to maintain a global, non-monotonic state, e.g., in the form of a database or register. However, most existing automated verification tools do not support the analysis of such stateful security protocols - sometimes because of fundamental reasons, such as the encoding of the protocol as Horn clauses, which are inherently monotonic. A notable exception is the recent tamarin prover which allows specifying protocols as multiset rewrite (msr) rules, a formalism expressive enough to encode state. As multiset rewriting is a "low-level" specification language with no direct support for concurrent message passing, encoding protocols correctly is a difficult and error-prone process. We propose a process calculus which is a variant of the applied pi calculus with constructs for manipulation of a global state by processes running in parallel. We show that this language can be translated to msr rules whilst preserving all security properties expressible in a dedicated first-order logic for security properties. The translation has been implemented in a prototype tool which uses the tamarin prover as a backend. We apply the tool to several case studies among which a simplified fragment of PKCS\#11, the Yubikey security token, and an optimistic contract signing protocol

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 low-level implementations of cryptographic protocols

This thesis examines the vulnerabilities due to low-level implementation deficiencies of otherwise secure communication protocols in smart-cards. Smart-cards are considered to be one of the most secure, tamper-resistant, and trusted devices for implementing confidential operations, such as authentication, key management, encryption and decryption for financial, communication, security and data management purposes. The self-containment of smart-cards makes them resistant to attacks as they do not depend on potentially vulnerable external resources. As such, smart-cards are often incorporated in formally-verified protocols that require strong security of the cryptographic computations. Such a setting consists of a smart-card which is responsible for the execution of sensitive operations, and an Application Programming Interface (API) which implements a particular protocol. For the smart-card to execute any kind of operation there exists a confidential low-level communication with the API, responsible for carrying out the protocol specifications and requests. This communication is kept secret on purpose by some vendors, under the assumption that hiding implementation details enhances the system’s security. The work presented in this thesis analyses such low-level protocol implementations in smart-cards, especially those whose implementation details are deliberately kept secret. In particular, the thesis consists of a thorough analysis of the implementation of PKCS#11 and Bitcoin smart-cards with respect to the low-level communication layer. Our hypothesis is that by focusing on reverse-engineering the low-level implementation of the communication protocols in a disciplined and generic way, one can discover new vulnerabilities and open new attack vectors that are not possible when looking at the highest levels of implementation, thereby compromising the security guarantees of the smart-cards. We present REPROVE, a system that automatically reverse-engineers the low-level communication of PKCS#11 smart-cards, deduces the card’s functionalities and translates PKCS#11 cryptographic functions into communication steps. REPROVE deals with both standard-conforming and proprietary implementations, and does not require access to the card. We use REPROVE to reverse-engineer seven commercially available smart-cards. Moreover, we conduct a security analysis of the obtained models and expose a set of vulnerabilities which would have otherwise been unknown. To the best of our knowledge, REPROVE is the first system to address proprietary implementations and the only system that maps cryptographic functions to communication steps and on-card operations. To that end, we showcase REPROVE’s usefulness to a security ecosystem by integrating it with an existing tool to extract meaningful state-machines of the card’s implementations. To conduct a security analysis of the results we obtained, we define a threat model that addresses low-level PKCS#11 implementations. Our analysis indicates a series of implementation errors that leave the cards vulnerable to attacks. To that end, we showcase how the discovered vulnerabilities can be exploited by presenting practical attacks. The results we obtained from the PKCS#11 smart-card analysis showed that proprietary implementations commonly hide erroneous behaviours. To test the assumption that the same practice is also adopted by other protocols, we further examine the low-level implementation of the only available smart-card based Bitcoin wallets, LEDGER. We extract the different protocols that the LEDGER wallets implement and conduct a through analysis. Our results indicate a set of vulnerabilities that expose the wallets as well as the processed transactions to multiple threats. To that end, we present how we successfully mounted attacks on the LEDGER wallets that lead to the loss of the wallet’s ownership and consequently loss of the funds. We address the lack of well-defined security properties that Bitcoin wallets should conform to by introducing a general threat model. We further use that threat model to propose a lightweight fix that can be adopted by other, not necessarily smart-card-based, wallets

A Roadmap for High Assurance Cryptography

International audienceAlthough an active area of research for years, formal verification has still not yet reached widespread deployment. We outline the steps needed to move from low-assurance cryptography, as given by libraries such as OpenSSL, to high assurance cryptography in deployment. In detail, we outline the need for a suite of high-assurance cryptographic software with per-microarchitecture optimizations that maintain competitive speeds with existing hand-optimized assembly and the bundling of these cryptographic primitives in a new API that prevents common developer mistakes. A new unified API with both formally verified primi-tives and an easy-to-use interface is needed to replace OpenSSL in future security-critical applications

Interoperable Credentials Management for Wholesale Banking

A gap exists between wholesale-banking business practices and security best practices: wholesale banks operate within the boundaries of contract law, while security best practices often relies upon a benevolent trusted party outside the scope of straightforward contracts. While some business domains may be able to bridge this gap, the ultra-high-value transactions used in business-to-business banking substantially increase the size of the gap. The gap becomes most apparent when regarded from the perspective of interoperability. If a single user applies the same credential to sign high-value transactions at multiple banks, then the trusted-party model becomes overly cumbersome and conflicts with an acceptable concept of liability. This paper outlines the business complexities of wholesale banking and proposes a solution called Partner Key Management (PKM). PKM technology manages the credentials required to authenticate users and sign transactions. This paper presents PKM technology by describing an interoperable protocol, requisite data structures, and an interoperable XML definition. The paper uses formal methods to demonstrate a security equivalence between revocation options within PKM against the security offered by the traditional Public Key Infrastructure (PKI), a technology that features the benevolent trusted party

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