openpgp D. K. Gillmor Internet-Draft ACLU Intended status: Informational 28 December 2023 Expires: 30 June 2024 OpenPGP Hardware-Backed Secret Keys draft-dkg-openpgp-hardware-secrets-00 Abstract This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored on a hardware device. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://dkg.gitlab.io/openpgp-hardware-secrets/. Status information for this document may be found at https://datatracker.ietf.org/doc/ draft-dkg-openpgp-hardware-secrets/. Discussion of this document takes place on the OpenPGP Working Group mailing list (mailto:openpgp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/openpgp/. Subscribe at https://www.ietf.org/mailman/listinfo/openpgp/. Source for this draft and an issue tracker can be found at https://gitlab.com/dkg/openpgp-hardware-secrets/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 June 2024. Gillmor Expires 30 June 2024 [Page 1] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Hardware-backed Secret Key Material . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Usability Considerations . . . . . . . . . . . . . . . . . . 5 4.1. Some Hardware Might Be Unavailable To Some Implementations . . . . . . . . . . . . . . . . . . . . . 5 4.2. Hardware Should Support Multiple Secret Keys . . . . . . 6 4.3. Authorization Challenges . . . . . . . . . . . . . . . . 6 4.4. Latency and Error Handling . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Historical notes . . . . . . . . . . . . . . . . . . 9 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 9 Appendix C. Document History . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Some OpenPGP secret key material is held by hardware devices that permit the user to operate the secret key without divulging it explicitly. For example, the [OPENPGP-SMARTCARD] specification is intended specifically for this use. It may also possible for OpenPGP implementations to use hardware-backed secrets via standard platform library interfaces like [TPM]. An OpenPGP Secret Key Packet (see Section 5.5.3 of [I-D.ietf-openpgp-crypto-refresh]) is typically used as part of a Transferable Secret Key (Section 10.2 of Gillmor Expires 30 June 2024 [Page 2] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 [I-D.ietf-openpgp-crypto-refresh]) for interoperability between OpenPGP implementations. An implementation that uses a hardware- backed secret key needs a standardized way to indicate to another implementation specific secret key material has been delegated to some hardware device. This document defines a simple mechanism for indicating that a secret key has been delegated to a hardware device by allocating a codepoint in the "Secret Key Encryption (S2K Usage Octet)" registry (see Section 3.7.2.1 of [I-D.ietf-openpgp-crypto-refresh]). This document makes no attempt to specify how an OpenPGP implementation discovers, enumerates, or operates hardware, other than to recommend that the hardware should be identifiable by the secret key's corresponding public key material. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology "Secret key" refers to a single cryptographic object, for example the "56 octets of the native secret key" of X448, as described in Section 5.5.5.8 of [I-D.ietf-openpgp-crypto-refresh]. "Public key" likewise refers to a single cryptographic object, for example the "56 octets of the native public key" of X448, as above. "OpenPGP certificate" or just "certificate" refers to an OpenPGP Transferable Public Key (see Section 10.1 of [I-D.ietf-openpgp-crypto-refresh]). "Hardware" refers to any cryptographic device or subsystem capable of performing an asymmetric secret key operation using an embedded secret key without divulging the secret to the user. For discoverability, the hardware is also expected to be able to produce the public key corresponding to the embedded secret key. While this document talks about "hardware" in the abstract as referring to a cryptographic device embedding to a single secret key, most actual hardware devices will embed and enable the use of multiple secret keys (see Section 4.2). Gillmor Expires 30 June 2024 [Page 3] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 This document uses the term "authorization" to mean any step, such as providing a PIN, password, proof of biometric identity, button- pushing, etc, that the hardware may require for an action. 2. Hardware-backed Secret Key Material An OpenPGP Secret Key packet (Section 5.5.3 of [I-D.ietf-openpgp-crypto-refresh]) indicates that the secret key material is stored in cryptographic hardware that is identifiable by public key parameters in the following way. The S2K usage octet is set to TBD (252?), known in shorthand as HardwareBacked. A producing implementation MUST NOT include any trailing data in the rest of such a Secret Key packet. A consuming implementation MUST ignore any trailing data in such a Secret Key packet. 3. Security Considerations Hardware-backed secret keys promise several distinct security advantages to the user: * The secret key cannot be extracted from the device, so "kleptography" (the stealing of secret key material) is harder to perform. * Some hardware can be moved between machines, enabling secret key portability without expanding the kleptographic attack surface. * Some hardware devices offer auditability controls in the form of rate-limiting, user-visible authorization steps (e.g., button- presses or biometric sensors), or tamper-resistant usage counters. Malicious use of a secret key on such a device should be harder, or at least more evident. However, none of these purported advantages are without caveats. The hardware itself might actually not resist secret key exfiltration as expected. For example, isolated hardware devices are sometimes easier to attack physically, via temperature or voltage fluctuations (see [VOLTAGE-GLITCHING] and [SMART-CARD-FAULTS]). In some cases, dedicated cryptographic hardware that generates a secret key internally may have significant flaws (see [ROCA]). Furthermore, the most sensitive material in the case of decryption is often the cleartext itself, not the secret key material. If the host computer itself is potentially compromised, then kleptographic Gillmor Expires 30 June 2024 [Page 4] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 exfiltration of the secret key material itself is only a small risk. For example, the OpenPGP symmetric session key itself could be exfiltrated, permitting access to the cleartext to anyone without access to the secret key material. Portability brings with it other risks, including the possibility of abuse by the host software on any of the devices to which the hardware is connected. Rate-limiting, user-visible authorization steps, and any other form of auditability also suffer from risks related to compromised host operating systems. Few hardware devices are capable of revealing to the user what operations specifically were performed by the device, so even if the user deliberately uses the device to, say, sign an object, the user depends on the host software to feed the correct object to the device's signing capability. 4. Usability Considerations Hardware-backed secret keys present specific usability challenges for integration with OpenPGP. 4.1. Some Hardware Might Be Unavailable To Some Implementations This specification gives no hints about how to find the hardware device, and presumes that an implementation will be able to probe available hardware to associate it with the corresponding public key material. In particular, there is no attempt to identify specific hardware or "slots" using identifiers like PCKS #11 URIs ([RFC7512]) or smartcard serial numbers (see Appendix A). This minimalism is deliberate, as it's possible for the same key material to be available on multiple hardware devices, or for a device to be located on one platform with a particular hardware identifier, while on another platform it uses a different hardware identifier. Not every OpenPGP implementation will be able to talk to every possible hardware device. If an OpenPGP implementation encounters a hardware-backed secret key as indicated with this mechanism, but cannot identify any attached hardware that lists the corresponding secret key material, it should warn the user that the specific key claims to be hardware-backed but the corresponding hardware cannot be found. It may also want to inform the user what categories of hardware devices it is capable of probing, for debugging purposes. Gillmor Expires 30 June 2024 [Page 5] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 4.2. Hardware Should Support Multiple Secret Keys Most reasonable OpenPGP configurations require the use of multiple secret keys by a single operator. For example, the user may use one secret key for signing, and another secret key for decryption, and the corresponding public keys of both are contained in the same OpenPGP certificate. Reasonable hardware SHOULD support embedding and identifying more than one secret key, so that a typical OpenPGP user can rely on a single device for hardware backing. 4.3. Authorization Challenges Cryptographic hardware can be difficult to use if frequent authorization is required, particularly in circumstances like reading messages in a busy e-mail inbox. This hardware MAY require authorization for each use of the secret key material as a security measure, but considerations should be made for caching authorization If the cryptographic hardware requires authorization for listing the corresponding public key material, it becomes even more difficult to use the device in regular operation. Hardware SHOULD NOT require authorization for the action of producing the corresponding public key. If a user has two attached pieces of hardware that both hold the same secret key, and one requires authorization while the other does not, it is reasonable for an implementation to try the one that doesn't require authorization first. Some cryptographic hardware is designed to lock the device on repeated authorization failures (e.g. 9 bad PIN entries locks the device), so this approach reduces the risk of accidental lockout. 4.4. Latency and Error Handling While hardware-backed secret key operations can be significantly slower than modern computers, and physical affordances like button- presses or NFC tapping can themselves incur delay, an implementation using a hardware-backed secret key should remain responsive to the user. It should indicate when some interaction with the hardware may be required, and it should use a sensible timeout if the hardware device appears to be unresponsive. A reasonable implementation should surface actionable errors or warnings from the hardware to the user where possible. Gillmor Expires 30 June 2024 [Page 6] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 5. IANA Considerations This document asks IANA to make two changes in the "OpenPGP" protocol group. Add the following row in the "OpenPGP Secret Key Encrpytion (S2K Usage Octet)" registry: +========+================+============+===============+===========+ | S2K | Shorthand | Encryption | Encryption | Generate? | | usage | | parameter | | | | octet | | fields | | | +========+================+============+===============+===========+ | TBD | HardwareBacked | none | no data, see | Yes | | (252?) | | | Section 2 of | | | | | | RFC XXX (this | | | | | | document) | | +--------+----------------+------------+---------------+-----------+ Table 1: Row to add to OpenPGP Secret Key Encrpytion (S2K Usage Octet) registry Modify this row of the "OpenPGP Symmetric Key Algorithms" registry: +===================+=============================+ | ID | Algorithm | +===================+=============================+ | 253, 254, and 255 | Reserved to avoid collision | | | with Secret Key Encryption | +-------------------+-----------------------------+ Table 2: Row to modify in OpenPGP Symmetric Key Algorithms registry to include TBD (252?) in this reserved codepoint sequence, resulting in the following entry: +===============================+=============================+ | ID | Algorithm | +===============================+=============================+ | TBD (252?), 253, 254, and 255 | Reserved to avoid collision | | | with Secret Key Encryption | +-------------------------------+-----------------------------+ Table 3: Modified row in OpenPGP Symmetric Key Algorithms registry 6. References Gillmor Expires 30 June 2024 [Page 7] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 6.1. Normative References [I-D.ietf-openpgp-crypto-refresh] Wouters, P., Huigens, D., Winter, J., and N. Yutaka, "OpenPGP", Work in Progress, Internet-Draft, draft-ietf- openpgp-crypto-refresh-12, 17 October 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [GNUPG-SECRET-STUB] Koch, W., "GNU Extensions to the S2K algorithm", 4 July 2023, . [OPENPGP-SMARTCARD] Pietig, A., "Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems, Version 3.4", 18 March 2020, . [RFC7512] Pechanec, J. and D. Moffat, "The PKCS #11 URI Scheme", RFC 7512, DOI 10.17487/RFC7512, April 2015, . [ROCA] Nemec, M., Sys, M., Svenda, P., Klinec, D., and V. Matyas, "The Return of Coppersmith's Attack: Practical Factorization of Widely Used RSA Moduli", Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, DOI 10.1145/3133956.3133969, October 2017, . [SMART-CARD-FAULTS] Massolino, P. M. C., Ege, B., and L. Batina, "Smart Card Fault Injections with High Temperatures", 15 November 2016, . Gillmor Expires 30 June 2024 [Page 8] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 [TPM] Trusted Computing Group, "Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 01.59", November 2019, . [VOLTAGE-GLITCHING] Bittner, O., Krachenfels, T., Galauner, A., and J. Seifert, "The Forgotten Threat of Voltage Glitching: A Case Study on Nvidia Tegra X2 SoCs", arXiv article, DOI 10.48550/ARXIV.2108.06131, 2021, . Appendix A. Historical notes Some OpenPGP implementations make use of private codepoint ranges in the OpenPGP specification within an OpenPGP Transferable Secret Key to indicate that the secret key can be found on a smartcard. For example, GnuPG uses the private/experimental codepoint 101 in the S2K Specifier registry, along with an embedded trailer with an additional codepoint, plus the serial number of the smartcard (see [GNUPG-SECRET-STUB]). However, recent versions of that implementation ignore the embedded serial number in favor of scanning available devices for a match of the key material, since some people have multiple cards with the same secret key. Appendix B. Acknowledgements This work depends on a history of significant work with hardware- backed OpenPGP secret key material, including useful implementations and guidance from many people, including: * NIIBE Yutaka * Achim Pietig * Werner Koch * Heiko Schäfer The people acknowledeged in this section are not respsonsible for any proposals, errors, or omissions in this document. Appendix C. Document History Gillmor Expires 30 June 2024 [Page 9] Internet-Draft OpenPGP Hardware-Backed Secret Keys December 2023 Author's Address Daniel Kahn Gillmor American Civil Liberties Union 125 Broad St. New York, NY, 10004 United States of America Email: dkg@fifthhorseman.net Gillmor Expires 30 June 2024 [Page 10]