1. A Provably Secure PKCS#11 Configuration Without Authenticated Attributes 2017 FinancialCryptography
    Ryan Stanley-Oakes
    [View PDF on fc17.ifca.ai]
    [Show BibTex Citation]

    author = {Ryan Stanley{-}Oakes},
    title = {A Provably Secure PKCS{\textbackslash}{\#}11 Configuration Without
    Authenticated Attributes},
    journal = {{IACR} Cryptology ePrint Archive},
    volume = {2017},
    pages = {134},
    year = {2017},
    url = {http://eprint.iacr.org/2017/134},
    timestamp = {Tue, 14 Aug 2018 17:08:26 +0200},
    biburl = {https://dblp.org/rec/bib/journals/iacr/Stanley-Oakes17},
    bibsource = {dblp computer science bibliography, https://dblp.org}

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.