OpenPGP Hardware-Backed Secret Keys

Internet-Draft	OpenPGP Hardware-Backed Secret Keys	December 2023
Gillmor	Expires 30 June 2024	[Page]

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.¶

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 [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).¶

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.¶

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 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.¶

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.¶

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:¶

Table 1: Row to add to OpenPGP Secret Key Encrpytion (S2K Usage Octet) registry
S2K usage octet	Shorthand	Encryption parameter fields	Encryption	Generate?
TBD (252?)	HardwareBacked	none	no data, see Section 2 of RFC XXX (this document)	Yes

Modify this row of the "OpenPGP Symmetric Key Algorithms" registry:¶

Table 2: Row to modify in OpenPGP Symmetric Key Algorithms registry
ID	Algorithm
253, 254, and 255	Reserved to avoid collision with Secret Key Encryption

to include TBD (252?) in this reserved codepoint sequence, resulting in the following entry:¶

Table 3: Modified row in OpenPGP Symmetric Key Algorithms registry
ID	Algorithm
TBD (252?), 253, 254, and 255	Reserved to avoid collision with Secret Key Encryption

6. References

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, <https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-12>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

6.2. Informative References

[GNUPG-SECRET-STUB]: Koch, W., "GNU Extensions to the S2K algorithm", 4 July 2023, <https://dev.gnupg.org/source/gnupg/browse/master/doc/DETAILS;gnupg-2.4.3$1511>.
[OPENPGP-SMARTCARD]: Pietig, A., "Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems, Version 3.4", 18 March 2020, <https://www.gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.pdf>.
[RFC7512]: Pechanec, J. and D. Moffat, "The PKCS #11 URI Scheme", RFC 7512, DOI 10.17487/RFC7512, April 2015, <https://www.rfc-editor.org/rfc/rfc7512>.
[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, <https://doi.org/10.1145/3133956.3133969>.
[SMART-CARD-FAULTS]: Massolino, P. M. C., Ege, B., and L. Batina, "Smart Card Fault Injections with High Temperatures", 15 November 2016, <http://hdl.handle.net/2117/99293>.
[TPM]: Trusted Computing Group, "Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 01.59", November 2019, <https://trustedcomputinggroup.org/resource/tpm-library-specification/>.
[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, <https://doi.org/10.48550/ARXIV.2108.06131>.

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.¶