]> American Civil Liberties Union

125 Broad St. New York, NY 10004 USA dkg@fifthhorseman.net

int openpgp Internet-Draft This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored on a hardware device. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the OpenPGP Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 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 . An OpenPGP Secret Key Packet (see ) is typically used as part of a Transferable Secret Key () 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 ). 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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology "Secret key" refers to a single cryptographic object, for example the "56 octets of the native secret key" of X448, as described in . "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 ). "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 a single secret key, most actual hardware devices will embed and enable the use of multiple secret keys (see ). 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.

Hardware-backed Secret Key Material An OpenPGP Secret Key packet () 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.

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. 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 and ). In some cases, dedicated cryptographic hardware that generates a secret key internally may have significant flaws (see ). 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.

Usability Considerations Hardware-backed secret keys present specific usability challenges for integration with OpenPGP.

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 PKCS #11 URIs () or smartcard serial numbers (see ). 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.

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.

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. 3 bad PIN entries locks the device), so this approach reduces the risk of accidental lockout.

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.

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 usage octet Shorthand Encryption parameter fields Encryption Generate? TBD (252?) HardwareBacked none no data, see of RFC XXX (this document) 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

Aiven Proton AG Sequoia-PGP FSIJ This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. g10 Code Trusted Computing Group Masaryk University, Ca' Foscari University of Venice, Brno, Czech Rep Masaryk University, Brno, Czech Rep Masaryk University, Brno, Czech Rep EnigmaBridge, Masaryk University, Brno, Czech Rep Masaryk University, Brno, Czech Rep This memo specifies a PKCS #11 Uniform Resource Identifier (URI) Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries. The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token Interface Standard".

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

Test vectors

Example Transferable 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:

As a Hardware-Backed Secret Key The same OpenPGP Transferable Secret Key with the S2K Usage Octet set to 252? (HardwareBacked) for both the Primary Key Packet and the Subkey Packet. This format omits all data following the S2K Usage Octet:

The (primary) Secret-Key Packet of this key looks as follows, in this format: 00000000 c5 CTB 00000001 34 length 00000002 04 version 00000003 66 05 ad 73 creation_time 00000007 16 pk_algo 00000008 09 curve_len 00000009 2b 06 01 04 01 da 47 curve 00000010 0f 01 00000012 01 07 eddsa_public_len 00000014 40 94 b2 ba 50 f4 2c 54 74 76 11 39 eddsa_public 00000020 35 4b 05 48 1b 7b 41 9a 98 84 b6 29 18 62 50 b2 00000030 d5 32 22 ab 36 00000035 fc s2k_usage

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 responsible for any proposals, errors, or omissions in this document.

Document History

Substantive Changes from draft-dkg-openpgp-hardware-secrets-00 to draft-dkg-openpgp-hardware-secrets-01 Added test vector for experimentation Mention on-device attestation update OpenPGP card spec reference to 3.4.1