| Internet-Draft | OpenPGP External Secret Keys | August 2024 |
| Gillmor | Expires 3 February 2025 | [Page] |
This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored externally, for example on a hardware device or other comparable subsystem.¶
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-external-secrets/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-dkg-openpgp-external-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-external-secrets/.¶
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 3 February 2025.¶
Copyright (c) 2024 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.¶
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 external secret key material via standard platform library interfaces like [TPM].¶
An OpenPGP Secret Key Packet (see Section 5.5.3 of [RFC9580]) is typically used as part of a Transferable Secret Key (Section 10.2 of [RFC9580]) for interoperability between OpenPGP implementations. An implementation that uses an external secret key needs a standardized way to indicate to another implementation specific secret key material has been delegated to some external mechanism, like a hardware device.¶
This document defines a simple mechanism for indicating that a secret key has been delegated to an external mechanism by allocating a codepoint in the "Secret Key Encryption (S2K Usage Octet)" registry (see Section 3.7.2.1 of [RFC9580]).¶
It also establishes a registry of hints about how to locate the external device, and defines a minimalist "best effort" method for locating external secret keys that is implementation-specific.¶
This document makes no attempt to specify how an OpenPGP implementation discovers, enumerates, or operates external secret keys, other than to recommend that the hardware or comparable external subsystem should be identifiable by the secret key's corresponding public key material.¶
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.¶
The key words "PRIVATE USE" and "SPECIFICATION REQUIRED" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC8126].¶
"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 [RFC9580].¶
"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 [RFC9580]).¶
"External" 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 external mechanism is also expected to be able to produce the public key corresponding to the embedded secret key.¶
While this document talks about "external" in the abstract as referring to a cryptographic device embedding a single secret key, most actual hardware devices or other cryptographic subsystems 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 external subsystem may require for an action.¶
An OpenPGP Secret Key packet (Section 5.5.3 of [RFC9580]) indicates that the secret key material is stored in an cryptographic subsystem that is identifiable by public key parameters in the following way.¶
The S2K usage octet is set to TBD (252?), known in shorthand as External.¶
The remainder of the Secret Key packet contains a hint about how the implementation might be able to identify the external subsystem. This hint sequence is entirely advisory.¶
If the hint is empty (that is, if there are no bytes in the Secret Key packet following the External S2K usage octet, then the hint sequence is known as "best effort" (see Section 2.1).¶
If the hint is not empty, then the first octet of the hint describes the structure of the remainder of the hint, according to the "OpenPGP External Secret Key Locator Hints" registry established by this document. That registry is initially empty, with octet values 249-255 (inclusive) reserved for PRIVATE USE. Adding a new entry into that registry in the range 0-248 (inclusive) uses IANA policy SPECIFICATION REQUIRED.¶
Regardless of what the locator hint says, a consuming implementation MAY use the "best effort" approach to identify an external subsystem that can provide access to the secret key.¶
A producing implementation that does not know how to provide a meaningful locator hint SHOULD NOT include any trailing data in the rest of such a Secret Key packet.¶
A consuming implementation that does not understand any particular locator hint SHOULD ignore any trailing data in such a Secret Key packet.¶
The purpose of the hinting mechanism is to enable optimized access. For example, if an OpenPGP implementation has access to several dozen hardware tokens, and if querying each attached hardware token is expensive, a hint can be used to preferentially access a likely token, without probing each token.¶
This document does not describe any particular hinting scheme.¶
When no external locator hint is available, or when a consuming implementation does not understand a given locator hint, a consuming implementation uses a "best effort" strategy to identify the external subsystem that provides access to a a secret key that matches the corresponding public key material.¶
Each OpenPGP implementation might support different external subsystems. And, in some installations, the same external subsystem might be identified in different ways (for example, a USB smartcard might be connected to hub 2 at low speed, and in another, the same USB smartcard might be connected to hub 1 at high speed.¶
In some cases, no external subsystem can be identified that supports access to secret key material that corresponds to the associated public key. Or, the external subsystem might be available, but for whatever reason attempting to use it could fail (for example, the hardware might advertise the availability of the key, but deny access when the implementation tries to use it). In either case, an OpenPGP implementation that tries to use such an external secret key will fail. The implementation should fail in a similar way to how it might fail if it tried to use a typical software-backed secret key locked with a password, but the password is unavailable to the implementation.¶
External or hardware-backed secret keys promise several distinct security advantages to the user:¶
Often, the secret key cannot be extracted from the external 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.¶
Some hardware security devices can attest that key material has been generated on-card, thereby signaling that - barring a successful attack on the hardware - no other copy of the private key material exists. Such mechanisms signal that the key holder did not have a chance to mishandle (e.g.: accidentally disclose) the private key material.¶
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.¶
External secret keys present specific usability challenges for integration with OpenPGP.¶
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.¶
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.¶
This document asks IANA to make three changes in the "OpenPGP" protocol group.¶
Add the following row in the "OpenPGP Secret Key Encrpytion (S2K Usage Octet)" registry:¶
| S2K usage octet | Shorthand | Encryption parameter fields | Encryption | Generate? |
|---|---|---|---|---|
| TBD (252?) | External | External Locator Hint, see Section 2 of RFC XXX (this document) | no data | Yes |
Modify this row of the "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:¶
| ID | Algorithm |
|---|---|
| TBD (252?), 253, 254, and 255 | Reserved to avoid collision with Secret Key Encryption |
Establish a new registry, "OpenPGP External Secret Key Locator Hints", with the following columns and initial range:¶
| ID | Shorthand | Description | Reference |
|---|---|---|---|
| 0-191 | Unassigned | RFC XXX (this document) | |
| 249-255 | Private Use | RFC XXX (this document) |
Assigning a new codepoint to this registry uses SPECIFICATION REQUIRED.¶
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.¶
The OpenPGP Transferable Secret Key used for this example. It includes (unencrypted) private key material for both its primary key and one subkey:¶
-----BEGIN PGP PRIVATE KEY BLOCK----- xVgEZgWtcxYJKwYBBAHaRw8BAQdAlLK6UPQsVHR2ETk1SwVIG3tBmpiEtikYYlCy 1TIiqzYAAQCwm/O5cWsztxbUcwOHycBwszHpD4Oa+fK8XJDxLWH7dRIZzR08aGFy ZHdhcmUtc2VjcmV0QGV4YW1wbGUub3JnPsKNBBAWCAA1AhkBBQJmBa1zAhsDCAsJ CAcKDQwLBRUKCQgLAhYCFiEEXlP8Tur0WZR+f0I33/i9Uh4OHEkACgkQ3/i9Uh4O HEnryAD8CzH2ajJvASp46ApfI4pLPY57rjBX++d/2FQPRyqGHJUA/RLsNNgxiFYm K5cjtQe2/DgzWQ7R6PxPC6oa3XM7xPcCx10EZgWtcxIKKwYBBAGXVQEFAQEHQE1Y XOKeaklwG01Yab4xopP9wbu1E+pCrP1xQpiFZW5KAwEIBwAA/12uOubAQ5nhf1UF a51SQwFLpggB/Spn29qDnSQXOTzIDvPCeAQYFggAIAUCZgWtcwIbDBYhBF5T/E7q 9FmUfn9CN9/4vVIeDhxJAAoJEN/4vVIeDhxJVTgA/1WaFrKdP3AgL0Ffdooc5XXb jQsj0uHo6FZSHRI4pchMAQCyJnKQ3RvW/0gm41JCqImyg2fxWG4hY0N5Q7Rc6Pyz DQ== =lYbx -----END PGP PRIVATE KEY BLOCK-----¶
The same OpenPGP Transferable Secret Key with the S2K Usage Octet set to 252? (External) for both the Primary Key Packet and the Subkey Packet. This format omits all data following the S2K Usage Octet:¶
-----BEGIN PGP PRIVATE KEY BLOCK----- xTQEZgWtcxYJKwYBBAHaRw8BAQdAlLK6UPQsVHR2ETk1SwVIG3tBmpiEtikYYlCy 1TIiqzb8zR08aGFyZHdhcmUtc2VjcmV0QGV4YW1wbGUub3JnPsKNBBAWCAA1AhkB BQJmBa1zAhsDCAsJCAcKDQwLBRUKCQgLAhYCFiEEXlP8Tur0WZR+f0I33/i9Uh4O HEkACgkQ3/i9Uh4OHEnryAD8CzH2ajJvASp46ApfI4pLPY57rjBX++d/2FQPRyqG HJUA/RLsNNgxiFYmK5cjtQe2/DgzWQ7R6PxPC6oa3XM7xPcCxzkEZgWtcxIKKwYB BAGXVQEFAQEHQE1YXOKeaklwG01Yab4xopP9wbu1E+pCrP1xQpiFZW5KAwEIB/zC eAQYFggAIAUCZgWtcwIbDBYhBF5T/E7q9FmUfn9CN9/4vVIeDhxJAAoJEN/4vVIe DhxJVTgA/1WaFrKdP3AgL0Ffdooc5XXbjQsj0uHo6FZSHRI4pchMAQCyJnKQ3RvW /0gm41JCqImyg2fxWG4hY0N5Q7Rc6PyzDQ== =3w/O -----END PGP PRIVATE KEY BLOCK-----¶
The (primary) Secret-Key Packet of this key looks as follows, in this format:¶
0000 c5 packet type: Secret-Key Packet 0001 34 packet length 0002 04 version 0003 66 05 ad 73 creation time 0007 16 public-key algorithm: EdDSALegacy 0008 09 curve OID length 0009 2b 06 01 04 01 da 47 curve OID 0010 0f 01 0012 01 07 EdDSA public key Q MPI length 0014 40 94 b2 ba EdDSA public key Q MPI 0018 50 f4 2c 54 74 76 11 39 0020 35 4b 05 48 1b 7b 41 9a 0028 98 84 b6 29 18 62 50 b2 0030 d5 32 22 ab 36 0035 fc S2K usage octet¶
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:¶
The people acknowledeged in this section are not responsible for any proposals, errors, or omissions in this document.¶
define the external locator hinting mechanism¶
re-format hexdump of test vector secret key packet¶