Crypto Forum S. Q. Dijkhuis, Ed. Internet-Draft Cleverbase Intended status: Informational 19 January 2025 Expires: 23 July 2025 Hierarchical Deterministic Keys draft-dijkhuis-cfrg-hdkeys-05 Abstract Hierarchical Deterministic Keys enables managing large sets of keys bound to a secure cryptographic device that protects a single key. This enables the development of secure digital identity wallets providing many one-time-use public keys. Some instantiations can be implemented in such a way that the secure cryptographic device does not need to support key blinding, enabling the use of devices that already are widely deployed. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-dijkhuis-cfrg-hdkeys/. Source for this draft and an issue tracker can be found at https://github.com/sander/hierarchical-deterministic-keys. 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 23 July 2025. Dijkhuis Expires 23 July 2025 [Page 1] Internet-Draft HDK January 2025 Copyright Notice Copyright (c) 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions and definitions . . . . . . . . . . . . . . . 4 2. The Hierarchical Deterministic Key function . . . . . . . . . 4 2.1. Introductory examples . . . . . . . . . . . . . . . . . . 4 2.1.1. Local deterministic key derivation . . . . . . . . . 4 2.1.2. Remote deterministic key derivation . . . . . . . . . 5 2.1.3. Blinded proof of possession . . . . . . . . . . . . . 6 2.2. Instantiation parameters . . . . . . . . . . . . . . . . 8 2.3. The HDK context . . . . . . . . . . . . . . . . . . . . . 9 2.4. The HDK salt . . . . . . . . . . . . . . . . . . . . . . 9 2.5. The HDK function . . . . . . . . . . . . . . . . . . . . 10 2.6. The local HDK procedure . . . . . . . . . . . . . . . . . 11 2.7. The remote HDK protocol . . . . . . . . . . . . . . . . . 12 3. Generic HDK instantiations . . . . . . . . . . . . . . . . . 12 3.1. Using digital signatures . . . . . . . . . . . . . . . . 12 3.2. Using prime-order groups . . . . . . . . . . . . . . . . 14 3.2.1. Using additive blinding . . . . . . . . . . . . . . . 15 3.2.2. Using multiplicative blinding . . . . . . . . . . . . 16 3.3. Using elliptic curves . . . . . . . . . . . . . . . . . . 16 3.3.1. Using ECDH shared secrets . . . . . . . . . . . . . . 17 3.3.2. Using EC-SDSA signatures . . . . . . . . . . . . . . 18 3.3.3. Using P-256 . . . . . . . . . . . . . . . . . . . . . 19 4. Concrete HDK instantiations . . . . . . . . . . . . . . . . . 19 4.1. HDK-ECDH-P256 . . . . . . . . . . . . . . . . . . . . . . 19 4.2. HDK-ECDSA-P256add . . . . . . . . . . . . . . . . . . . . 20 4.3. HDK-ECDSA-P256mul . . . . . . . . . . . . . . . . . . . . 20 4.4. HDK-ECSDSA-P256 . . . . . . . . . . . . . . . . . . . . . 20 5. Application considerations . . . . . . . . . . . . . . . . . 20 5.1. Secure cryptographic device . . . . . . . . . . . . . . . 21 5.2. Trust evidence . . . . . . . . . . . . . . . . . . . . . 23 5.2.1. Wallet Trust Evidence . . . . . . . . . . . . . . . . 23 5.2.2. Issuer Trust Evidence . . . . . . . . . . . . . . . . 24 5.3. Applying HDK in OpenID for Verifiable Credential Issuance . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Security considerations . . . . . . . . . . . . . . . . . . . 24 Dijkhuis Expires 23 July 2025 [Page 2] Internet-Draft HDK January 2025 6.1. Confidentiality of key handles . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction This document specifies the algorithms to apply Hierarchical Deterministic Keys (HDKeys). The purpose of an HDK architecture is to manage large sets of keys bound to a secure cryptographic device that protects a single key. This enables the development of secure digital identity wallets providing many one-time-use public keys. The core idea has been introduced in [BIP32] to create multiple cryptocurrency addresses in a manageable way. The present document extends the idea towards devices commonly used for digital wallets, and towards common interaction patterns for document issuance and authentication. To store many HDKeys, only a seed string needs to be stored confidentially, associated with a device private key. Each HDK is then deterministically defined by a path of indices, optionally alternated by key handles provided by another party. Such a path can efficiently be stored and requires less confidentiality than the seed. To prove possession of many HDKeys, the secure cryptographic device only needs to perform common cryptographic operations on a single private key. The HDK acts as a blinding factor that enables blinding the device public key. In several instantiations, such as those using ECDH shared secrets (Section 3.3.1) and those using EC-SDSA signatures (Section 3.3.2), the secure cryptographic device does not need to support key blinding natively, and the application can pre- process the input or post-process the output from the device to compute the blinded device authentication data. This enables the application of HDK on devices that are already deployed without native support for HDK. This document provides a specification of the generic HDK function, generic HDK instantiations, and fully specified concrete HDK instantiations. Dijkhuis Expires 23 July 2025 [Page 3] Internet-Draft HDK January 2025 An HDK instantiation is expected to be applied in a solution deployed as (wallet) units. One unit can have multiple HDK instantiations, for example to manage multiple identities or multiple cryptographic algorithms or key protection mechanisms. This document represents the consensus of the authors, based on working group input and feedback. It is not a standard. It does not include security or privacy proofs. 1.1. Conventions and definitions 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 following notation is used throughout the document. * byte: A sequence of eight bits. * I2OSP(n, w): Convert non-negative integer n to a w-length, big- endian byte string, as described in [RFC8017]. 2. The Hierarchical Deterministic Key function An HDK instantiation enables local key derivation to create many key pairs from a single seed value. It enables remote parties to generate key handles from which both parties can derive more key pairs asynchronously. Additionally, an HDK instantiation enables securely proving possession of the private keys, such as required in [RFC7800], either in a centralised or in a distributed manner. Solutions MAY omit application of the remote functionality. In this case, a unit can only derive keys locally. 2.1. Introductory examples 2.1.1. Local deterministic key derivation The following example illustrates the use of local key derivation. An HDK tree is associated with a device key pair and initiated using confidential static data: a seed value, which is a byte array containing sufficient entropy. Now tree nodes are constructed as follows. Dijkhuis Expires 23 July 2025 [Page 4] Internet-Draft HDK January 2025 +----+ +--+ Confidential static data: |seed| |pk| +-+--+ +--+ v +----+ +----+ Level 0 HDKeys: |hdk0| |hdk1| +-+--+ +----+ v +-----+ +-----+ +-----+ Level 1 HDKeys: |hdk00| |hdk01| |hdk02| +-----+ ++---++ +-----+ v v +------+ +------+ Level 2 HDKeys at hdk01: |hdk000| |hdk001| ... +------+ +------+ The unit computes a Level 0 HDK at the root node using a deterministic function, taking the device public key pk and the seed as input: (pk0, salt0, bf0) = hdk0 = HDK(0, pk, seed). The HDK consists of a first blinded public key pk0, a first byte string salt0 to derive next-level keys, and a first blinding factor bf0. Using bf0 and the device key pair, the unit can compute blinded private keys and proofs of possession. The unit computes any Level n > 0 HDK from any other HDK (pk, salt, bf) using the same deterministic function: (pk', salt', bf') = hdk' = HDK(index, pk, salt, bf). The function takes as input the index starting at 0, an the previous-level HDK. The function returns a new HDK as output, which can be used in the same way as the root HDK. 2.1.2. Remote deterministic key derivation Instead of local derivation, an HDK salt can also be derived using a key handle that is generated remotely. Using the derived salt, the local and remote parties can derive the same new HDKeys. The remote party can use these to derive public keys. The local party can use these to derive associated private keys for proof of possession. This approach is similar to Asynchronous Remote Key Generation (ARKG) [I-D.draft-bradleylundberg-cfrg-arkg-02] when considered at a single level. However, ARKG does not enable distributed proof of possession with deterministic hierarchies. Such hierarchies can be used for example to enable remote parties to derive keys from previously derived keys. Secure cryptographic devices that support ARKG may therefore not support all features of HDK. Dijkhuis Expires 23 July 2025 [Page 5] Internet-Draft HDK January 2025 To enable remote derivation of child HDKeys, the unit uses the parent HDK to derive the parent public key and a second public key for key encapsulation. The issuer returns a key handle, using which both parties can derive a sequence of child HDKeys. Key encapsulation prevents other parties from discovering a link between the public keys of the parent and the children, even if the other party knows the parent HDK or can eavesdrop communications. Locally derived parents can have remotely derived children. Remotely derived parents can have locally derived children. 2.1.3. Blinded proof of possession The next concept to illustrate is blinded proof of possession. This enables a unit to prove possession of a (device) private key without disclosing the directly associated public key. This way, solutions can avoid linkability across readers of a digital document that is released with proof of possession. In this example, a document is issued with binding to a public key pk', which is a blinding public key pk blinded with the blinding factor bf in some HDK hdk = (pk', salt, bf). The unit can present the document with a proof of possession of the corresponding blinded private key, which is the blinding private key sk blinded with bf. The unit applies some authentication function device_data = authenticate(sk, reader_data, bf) to the blinding private key, reader-provided data and the blinding factor. The unit can subsequently use the output device_data to prove possession to the reader using common algorithms. Dijkhuis Expires 23 July 2025 [Page 6] Internet-Draft HDK January 2025 +------------------+ +--------+ | +--+ +---+ | | | | Unit |sk| |hdk| | | Reader | | +--+ +---+ | | | +---+--------------+ +----+---+ | | | | | 1. Request and | | reader_data | | <------------------ | | | +---+-------------+ | | 2. authenticate | | +---+-------------+ | | | | 3. Proof with | | device_data | | ------------------> | | | | +-----------+ | | | Document | | | | | | | | +---+ | | | | |pk'| | | | | +---+ | | | | | | +-----------+ The reader does not need to be aware that an HDK function or key blinding was used, since for common algorithms, the blinded public key and the proof are indistinguishable from non-blinded keys and proofs. When applied on HDK level n, the blinding private key sk is the device private key blinded with a combination of n blinding factors. These can either be combined within the secure cryptographic device, by subsequent computation of the blinded private key starting with the device private key, or outside of the secure cryptographic device, by combining the blinding factors outside of the secure cryptographic device. Blinding methods can be constructed such that the secure cryptographic device does not need to be designed for key blinding. In such cases, the computation of device_data is distributed between two parties: the secure cryptographic device using common cryptographic operations, and the unit component invoking these operations. Some blinded proof of possession algorithms can only be centralised. Dijkhuis Expires 23 July 2025 [Page 7] Internet-Draft HDK January 2025 2.2. Instantiation parameters The parameters of an HDK instantiation are: * Ns: The amount of bytes of a salt value with sufficient entropy. * H: A cryptographic hash function. - H(msg): Outputs Ns bytes. * BL: A key blinding scheme [Wilson2023] with opaque blinding factors and algebraic properties, consisting of the functions: - DeriveBlindKey(ikm): Outputs a blind key bk based on input keying material ikm. - DeriveBlindingFactor(bk, ctx): Outputs a blinding factor bf based on a blind key bk and an application context byte string ctx. - BlindPublicKey(pk, bk, ctx): Outputs the result public key pk' of blinding public key pk with blind key bk and application context byte string ctx. - BlindPrivateKey(sk, bf): Outputs the result private key sk' of blinding private key sk with blinding factor bf. This result sk' is such that if bf = DeriveBlindingFactor(bk, ctx) for some bk and ctx, (sk', pk') forms a key pair for pk' = BlindPublicKey(pk, bk, ctx). - Combine(bf1, bf2): Outputs a blinding factor bf such that for all key pairs (sk, pk): BlindPrivateKey(sk, bf) == BlindPrivateKey(BlindPrivateKey(sk, bf1), bf2) * KEM: A key encapsulation mechanism [RFC9180], consisting of the functions: - DeriveKeyPair(ikm): Outputs a key encapsulation key pair (sk, pk). - Encap(pk): Outputs (k, c) consisting of a shared secret k and a ciphertext c, taking key encapsulation public key pk. - Decap(c, sk): Outputs shared secret k, taking ciphertext c and key encapsulation private key sk. Dijkhuis Expires 23 July 2025 [Page 8] Internet-Draft HDK January 2025 An HDK instantiation MUST specify the instantiation of each of the above functions and values. Note that by design of BL, when a document is issued using HDK, the reader does not need to know that HDK was applied: the public key will look like any other public key used for proofs of possession. An HDK implementation MAY leave BlindPrivateKey implicit in cases where the blinding method is constructed in a distributed way. In those cases, the secure cryptographic device holding the private key does not need to support key blinding, and the value of the blinded private key is never available during computation. 2.3. The HDK context A local unit or remote party creates an HDK context from an index. Inputs: - index, an integer between 0 and 2^32-1 (inclusive). Outputs: - ctx, an application context byte string. def CreateContext(index): ctx = ID || I2OSP(index, 4) return ctx This context byte string is used as input for DeriveBlindingFactor, BlindPublicKey, and DeriveSalt (Section 2.4). 2.4. The HDK salt A local unit or remote party derives a next-level HDK salt from within an HDK context. Inputs: - salt, a string of Ns bytes. - ctx, an HDK context byte string. Outputs: - salt', the next salt for HDK derivation. def DeriveSalt(salt, ctx): salt' = H(salt || ctx) return salt' Salt values are used as input for DeriveBlindKey, DeriveKeyPair, and DeriveSalt. Dijkhuis Expires 23 July 2025 [Page 9] Internet-Draft HDK January 2025 Salt values, including the original seed value, MUST NOT be reused outside of HDK. 2.5. The HDK function A local unit or a remote party deterministically computes an HDK from an index, a parent public key, a salt, and an optional parent blinding factor. The salt can be an initial seed value of Ns bytes or it can be taken from another parent HDK. The secure generation of the seed is out of scope for this specification. Inputs: - index, an integer between 0 and 2^32-1 (inclusive). - pk, a public key to be blinded. - salt, a string of Ns bytes. - bf, a blinding factor to combine with, Nil otherwise. Outputs: - pk', the blinded public key at the provided index. - salt', the salt for HDK derivation at the provided index. - bf', the blinding factor at the provided index. def HDK(index, pk, salt, bf = Nil): ctx = CreateContext(index) salt' = DeriveSalt(salt, ctx) bk = DeriveBlindKey(salt) pk' = BlindPublicKey(bk, ctx) bf' = if bf == Nil: DeriveBlindingFactor(bk, ctx) else: Combine(bf, DeriveBlindingFactor(bk, ctx)) return (pk', salt', bf') A unit MUST NOT persist a blinded private key. Instead, if persistence is needed, a unit can persist either the blinding factor of each HDK, or a path consisting of the seed salt, indices and key handles. In both cases, the application of Combine in the HDK function enables reconstruction of the blinding factor with respect to the original private key, enabling application of for example BlindPrivateKey. If the unit uses the blinded private key directly, the unit MUST use it within the secure cryptographic device protecting the device private key. Dijkhuis Expires 23 July 2025 [Page 10] Internet-Draft HDK January 2025 If the unit uses the blinded private key directly, the unit MUST ensure the secure cryptographic device deletes it securely from memory after usage. When presenting multiple documents, a reader can require a proof that multiple keys are associated to a single device. Several protocols for a cryptographic proof of association are possible, such as [Verheul2024]. For example, a unit could prove in a zero-knowledge protocol knowledge of the association between two elliptic curve keys B1 = [bf1]D and B2 = [bf2]D, where bf1 and bf2 are multiplicative blinding factors for a common blinding public key D. In this protocol, the association is known by the discrete logarithm of B2 = [bf2/bf1]B1 with respect to generator B1. The unit can apply Combine to obtain values to compute this association. 2.6. The local HDK procedure This is a procedure executed locally by a unit. To begin, the unit securely generates a seed salt of Ns bytes and a device key pair: seed = random(Ns) # specification of random out of scope (skD, pkD) = GenerateKeyPair() The unit MUST generate skD within a secure cryptographic device. Whenever the unit requires the HDK with some index at level 0, the unit computes: (pk, salt, bf) = HDK(index, pkD, seed) sk = BlindPrivateKey(skD, bf) # optional Now the unit can use the blinded key pair (sk, pk) or derive child HDKeys. Whenever the unit requires the HDK with some index at level n > 0 based on a parent HDK hdk = (pk, salt, bf) with blinded key pair (sk, pk) at level n, the unit computes: (pk', salt', bf') = HDK(index, pk, salt) sk' = BlindPrivateKey(sk, bf') # optional Now the unit can use the blinded key pair (sk', pk') or derive child HDKeys. Dijkhuis Expires 23 July 2025 [Page 11] Internet-Draft HDK January 2025 2.7. The remote HDK protocol This is a protocol between a local unit and a remote issuer. As a prerequisite, the unit possesses a salt of Ns bytes associated with a parent key pair (sk, pk) generated using the local HDK procedure. # 1. Unit computes: (skR, pkR) = DeriveKeyPair(salt) # 2. Unit shares with issuer: (pk, pkR) # 3. Issuer computes: (salt_kem, kh) = Encap(pkR) # 4. Issuer shares with unit: kh # Subsequently, for any index known to both parties: # 5. Issuer computes: (pk', salt', bf') = HDK(index, pk, salt_kem) # 6. Issuer shares with unit: pk' # 7. Unit verifies integrity: salt_kem = Decap(kh, skR) (pk_expected', salt', bf') = HDK(index, pk, salt_kem) pk' == pk_expected' # 8. Unit computes: sk' = BlindPrivateKey(sk, bf) # optional After step 7, the unit can use the value of salt' to derive next- level HDKeys. Step 4 MAY be postponed to be combined with step 6. Steps 5 to 8 MAY be combined in concurrent execution for multiple indices. 3. Generic HDK instantiations 3.1. Using digital signatures Instantiations of HDK using digital signatures require: * DSA: A digital signature algorithm, consisting of the functions: Dijkhuis Expires 23 July 2025 [Page 12] Internet-Draft HDK January 2025 - GenerateKeyPair(): Outputs a new key pair (sk, pk) consisting of private key sk and public key pk. - Sign(sk, msg): Outputs the signature created using private signing key sk over byte string msg. - Verify(signature, pk, msg): Outputs whether signature is a signature over msg using public verification key pk. Using these constructs, an example proof of possession protocol is: # 1. Unit shares with reader: pk # 2. Reader computes: nonce = generate_random_nonce() # out of scope for this spec # 3. Reader shares with unit: nonce # 4. Unit computes: msg = create_message(pk, nonce) # out of scope for this spec signature = Sign(sk, msg) # 5. Reader computes: msg = create_message(pk, nonce) # out of scope for this spec Verify(signature, pk, msg) Instantiations of HDK using digital signatures provide: * BL: A cryptographic construct that extends DSA as specified in [I-D.draft-irtf-cfrg-signature-key-blinding-07], implementing the interface from Instantiation parameters (Section 2.2). While [I-D.draft-irtf-cfrg-signature-key-blinding-07] does not expose blinding factors, it provides public algorithms to compute these. In HDK, the computed blinding factors are applied in BL as follows: def BlindSign(sk, bf, msg): sk' = BlindPrivateKey(sk, bf) signature = Sign(sk', msg) return signature By design of BL, the same proof of possession protocol can be used with blinded key pairs and BlindSign, in such a way that the reader does not recognise that key blinding was used. Dijkhuis Expires 23 July 2025 [Page 13] Internet-Draft HDK January 2025 In the default implementation, BlindSign requires support from the secure cryptographic device protecting sk. In some cases, BlindSign can be implemented in an alternative, distributed way. An example will be provided below. Applications MUST bind the message to be signed to the blinded public key. This mitigates attacks based on signature malleability. Several proof of possession protocols require including document data in the message, which includes the blinded public key indeed. 3.2. Using prime-order groups Instantiations of HDK using prime-order groups require: * G: A prime-order group as defined in [RFC9497] with elements of type Element and scalars of type Scalar, consisting of the functions: - RandomScalar(): Outputs a random Scalar k. - Add(A, B): Outputs the sum between Elements A and B. - ScalarMult(A, k): Outputs the scalar multiplication between Element A and Scalar k. - ScalarBaseMult(k): Outputs the scalar multiplication between the base Element and Scalar k. - Order(): Outputs the order of the base Element. - SerializeElement(A): Outputs a byte string representing Element A. - SerializeScalar(k): Outputs a byte string representing Scalar k.` - HashToScalar(msg): Outputs the result of deterministically mapping a byte string msg to an element in the scalar field of the prime order subgroup of G, using the hash_to_field function from a hash-to-curve suite [RFC9380]. Instantiations of HDK using prime-order groups provide: Dijkhuis Expires 23 July 2025 [Page 14] Internet-Draft HDK January 2025 def GenerateKeyPair(): sk = GenerateRandomScalar() pk = ScalarBaseMult(sk) return (sk, pk) def DeriveBlindKey(ikm): bk_scalar = HashToScalar(ikm) bk = SerializeScalar(bk_scalar) return bk def DeriveBlindingFactor(bk, ctx): msg = bk || 0x00 || ctx bf = HashToScalar(msg) return bf Note that DeriveBlindingFactor is compatible with the definitions in [I-D.draft-irtf-cfrg-signature-key-blinding-07]. The function is almost compatible with the definitions in [I-D.draft-bradleylundberg-cfrg-arkg-02]: only in AKRG, the context string needs to be prefixed with 0x00. 3.2.1. Using additive blinding Instantiations of HDK using additive blinding use: * prime-order groups (Section 3.2) Instantiations of HDK using additive blinding provide: def BlindPublicKey(pk, bk, ctx): bf = DeriveBlindingFactor(bk, ctx) pk' = Add(pk, ScalarBaseMult(bf)) return pk def BlindPrivateKey(sk, bf): sk' = sk + bf mod Order() return sk def Combine(bf1, bf2): bf = bf1 + bf2 mod Order() return bf Note that all algorithms in [I-D.draft-bradleylundberg-cfrg-arkg-02] use additive blinding. Dijkhuis Expires 23 July 2025 [Page 15] Internet-Draft HDK January 2025 3.2.2. Using multiplicative blinding Instantiations of HDK using multiplicative blinding use: * prime-order groups (Section 3.2) Instantiations of HDK using multiplicative blinding provide: def BlindPublicKey(pk, bk, ctx): bf = DeriveBlindingFactor(bk, ctx) pk' = ScalarMult(pk, bf) return pk def BlindPrivateKey(sk, bf): sk' = sk * bf mod Order() return sk def Combine(bf1, bf2): bf = bf1 * bf2 mod Order() return bf Note that all algorithms in [I-D.draft-irtf-cfrg-signature-key-blinding-07] use multiplicative blinding. 3.3. Using elliptic curves Instantiations of HDK using elliptic curves use: * prime-order groups (Section 3.2) Instantiations of HDK using elliptic curves require: * DST: A domain separation tag for use with HashToScalar. * H2C: A hash-to-curve suite [RFC9380]. Instantiations of HDK using elliptic curves provide: * H: H from H2C. * Ns: The output size of H. Dijkhuis Expires 23 July 2025 [Page 16] Internet-Draft HDK January 2025 def HashToScalar(msg): scalar = hash_to_field(msg, 1) with the parameters: DST: DST F: GF(Order()), the scalar field of the prime order subgroup of EC p: Order() m: 1 L: as defined in H2C expand_message: as defined in H2C return scalar 3.3.1. Using ECDH shared secrets Instantiations of HDK using ECDH shared secrets use: * elliptic curves (Section 3.3) * multiplicative blinding (Section 3.2.2) Instantiations of HDK using ECDH shared secrets provide: * DH: The Elliptic Curve Key Agreement Algorithm - Diffie-Hellman (ECKA-DH) [TR03111] with elliptic curve G, consisting of the functions: - CreateSharedSecret(skX, pkY): Outputs a shared secret byte string Z_AB representing the x-coordinate of the Element ScalarMult(pkY, skX). Note that DH enables an alternative way of authenticating a key pair (sk, pk) without creation or verification of a signature: # 1. Unit shares with reader: pk # 2. Reader computes: (skR, pkR) = GenerateKeyPair() # 3. Reader shares with unit: pkR # 4. Unit computes: Z_AB = CreateSharedSecret(sk, pkR) # 5. Reader computes: Z_AB = CreateSharedSecret(skR, pk) Now with the shared secret Z_AB, the unit and the reader can compute a secret shared key. The unit can convince the reader that it possesses sk for example by sharing a message authentication code Dijkhuis Expires 23 July 2025 [Page 17] Internet-Draft HDK January 2025 created using this key. The reader can verify this by recomputing the code using its value of Z_AB. This is for example used in ECDH- MAC authentication defined in [ISO18013-5]. In this example, step 1 can be postponed in the interactions between the unit and the reader if a trustworthy earlier commitment to pk is available, for example in a sealed document. Similarly, ECDH enables authentication of key pair (sk', pk') blinded from an original key pair (sk, pk) using a blinding factor bf such that: sk' = BlindPrivateKey(sk, bf) = sk * bf mod Order() pk' = ScalarMult(pk, bf) In this case, the computation in step 4 can be performed as such: # 4. Unit computes: Z_AB = CreateSharedSecret(sk', pkR) = CreateSharedSecret(sk * bf mod Order(), pkR) = CreateSharedSecret(sk, ScalarMult(pkR, bf)) Note that the value of ScalarMult(pkR, bf) does not need to be computed within the secure cryptographic device that protects sk. 3.3.2. Using EC-SDSA signatures Instantiations of HDK using EC-SDSA (Schnorr) signatures use: * additive blinding (Section 3.2.1) * digital signatures (Section 3.1) * elliptic curves (Section 3.3) Instantiations of HDK using EC-SDSA signatures provide: * DSA: An EC-SDSA digital signature algorithm [TR03111], representing signatures as pairs (c, s). Note that in this case, the following definition is equivalent to the original definition of BlindSign: Dijkhuis Expires 23 July 2025 [Page 18] Internet-Draft HDK January 2025 def BlindSign(sk, bf, msg): # Compute signature within the secure cryptographic device. (c, s) = Sign(sk, msg) # Post-process the signature outside of this device. s' = s + c * bf mod Order() signature = (c, s') return signature 3.3.3. Using P-256 Instantiations of HDK using P-256 use: * elliptic curves (Section 3.3) Instantiations of HDK using P-256 provide: * G: The NIST curve secp256r1 (P-256) [SEC2]. * H2C: P256_XMD:SHA-256_SSWU_RO_ [RFC9380], which uses SHA-256 [FIPS180-4] as H. * KEM: DHKEM(P-256, HKDF-SHA256) [RFC9180]. 4. Concrete HDK instantiations The RECOMMENDED instantiation is the HDK-ECDH-P256. This avoids the risk of having the holder unknowingly producing a potentially non- repudiable signature over reader-provided data. Secure cryptographic devices that enable a high level of assurance typically support managing ECDH keys with the P-256 elliptic curve. 4.1. HDK-ECDH-P256 The HDK-ECDH-P256 instantiation of HDK uses: * P-256 (Section 3.3.3) * ECDH shared secrets (Section 3.3.1) The HDK-ECDH-P256 instantiation defines: * DST: "ECDH Key Blind" Dijkhuis Expires 23 July 2025 [Page 19] Internet-Draft HDK January 2025 4.2. HDK-ECDSA-P256add The HDK-ECDSA-P256add instantiation of HDK uses: * digital signatures (Section 3.1) * P-256 (Section 3.3.3) * additive blinding (Section 3.2.1) The HDK-ECDSA-P256add instantiation of HDK defines: * DST: "ARKG-BL-EC.ARKG-P256ADD-ECDH" for interoperability with [I-D.draft-bradleylundberg-cfrg-arkg-02]. * DSA: ECDSA [TR03111] with curve G. 4.3. HDK-ECDSA-P256mul The HDK-ECDSA-P256mul instantiation of HDK uses: * digital signatures (Section 3.1) * P-256 (Section 3.3.3) * multiplicative blinding (Section 3.2.2) The HDK-ECDSA-P256mul instantiation of HDK defines: * DST: "ECDSA Key Blind" for interoperability with [I-D.draft-irtf-cfrg-signature-key-blinding-07]. * DSA: ECDSA [TR03111] with curve G. 4.4. HDK-ECSDSA-P256 The HDK-ECSDSA-P256 instantiation of HDK uses: * EC-SDSA signatures (Section 3.3.2) * P-256 (Section 3.3.3) The HDK-ECSDSA-P256 instantiation of HDK defines: * DST: "EC-SDSA Key Blind" 5. Application considerations Dijkhuis Expires 23 July 2025 [Page 20] Internet-Draft HDK January 2025 5.1. Secure cryptographic device The HDK approach assumes that the holder controls a secure cryptographic device that protects the device key pair (sk_device, pk_device). The device key is under sole control of the holder. In the context of [EU2024-1183], this device is typically called a Wallet Secure Cryptographic Device (WSCD), running a personalised Wallet Secure Cryptographic Application (WSCA) that exposes a Secure Cryptographic Interface (SCI) to a Wallet Instance (WI) running on a User Device (UD). The WSCD is certified to protect access to the device private key with high attack potential resistance to achieve high level of assurance authentication as per [EU2015-1502]. This typically means that the key is associated with a strong possession factor and with a rate-limited Personal Identification Number (PIN) check as a knowledge factor, and the verification of both factors actively involve the WSCD. An example deployment of HDK in this context is illustrated below. +---------------------+ +----------------------+ |Issuer infrastructure| |User Device (UD) | | | | | |+-------------------+|OpenID4VCI|+--------------------+| ||Issuer service |<----------++Wallet Instance (WI)|| || || |++-------------------+| ||Optionally an || +-+--------------------+ ||ARKG subordinate || |Secure ||party || |Cryptographic |+-------------------+| |Interface (SCI) +---------------------+ +v-------------------+ |Wallet Secure | |Cryptographic | Internal Manages |Application (WSCA) | registry <-----------+ | |Optionally an | |ARKG delegating | |party | ++-------------------+ |Uses +v-------------------+ Protects |Wallet secure | Device keys <-----------+cryptographic | |device (WSCD) | +--------------------+ The WSCA could be a single program or could be deployed in a distributed architecture, as illustrated below. Dijkhuis Expires 23 July 2025 [Page 21] Internet-Draft HDK January 2025 +--------------+ |User device | |+------------+| ||WI || |++-----------+| | |SCI | |+v-----------+| ||WSCA agent || |++-----------+| +-+------------+ |WSCA protocol +v-----------+ |WSCA service| +------------+ In the case of a distributed WSCA, the UD contains a local component, here called WSCA agent, accessing an external and possibly remote WSCA service from one or more components over a WSCA protocol. For example, the WSCA agent may be a local web API client and the WSCA service may be provided at a remote web API server. In such cases, typically the WSCA service receives a high-assurance security evaluation, while the WSCA agent is assessed to not be able to compromise the system's security guarantees. The internal registry can be managed by the WSCA agent, by the WSCA service, or by the combination. When the user device is a natural person’s mobile phone, WSCA agent management could provide better confidentiality protection against compromised WSCA service providers. When the user device is a cloud server used by a legal person, and the legal person deploys its own WSCD, WSCA service management could provide better confidentiality protection against compromised Wallet Instance cloud providers. In a distributed WSCA architecture, the WSCA could internally apply distributed key generation. A description of this is out of scope for the current document. The solution proposal discussed herein works in all any WSCD architecture that supports the required cryptographic primitives: * In the case of HDK-ECDH-P256 (see Section 4.1): - P-256 ECDH key pair generation - P-256 ECDH key agreement * In the case of HDK-ECDSA-P256mul (see Section 4.3): Dijkhuis Expires 23 July 2025 [Page 22] Internet-Draft HDK January 2025 - P-256 ECDSA blinding key pair generation - P-256 ECDSA blinded signature creation * In the case of HDK-ECSDSA-P256 (see Section 4.4): - P-256 EC-SDSA key pair generation - P-256 EC-SDSA signature creation The other HDK operations can be performed in a WSCA or WSCA agent running on any UD, including hostile ones with limited sandboxing capabilities, such as in a smartphone's rich execution environment or in a personal computer web browser. 5.2. Trust evidence Some issuers could require evidence from a solution provider of the security of the holder's cryptographic device. This evidence can in the context of [EU2024-1183] be divided into initial "Wallet Trust Evidence" and related "Issuer Trust Evidence". Each is a protected document that contains a trust evidence public key associated with a private key that is protected in the secure cryptographic device. With HDK, these public keys are specified as follows. 5.2.1. Wallet Trust Evidence The Wallet Trust Evidence public key is the first level 0 HDK public key. To achieve reader unlinkability, the wallet SHOULD limit access to a trusted person identification document provider only. To prevent association across identities, the solution provider MUST before issuing Wallet Trust Evidence ensure that (a) a newly generated device key pair is used and (b) the wallet follows the protocol so that the HDK output is bound to exactly this key. For (a), the solution provider could rely on freshness of a key attestation and ensure that each device public key is attested only once. For (b), the wallet could proof knowledge of the blinding factor bf with a Schnorr non-interactive zero-knowledge proof [RFC8235] with base point pk_device. This would ensure that the root blinding key bf is not shared with the solution provider to reduce the risk of the solution provider unblinding future derived keys. Dijkhuis Expires 23 July 2025 [Page 23] Internet-Draft HDK January 2025 5.2.2. Issuer Trust Evidence The Issuer Trust Evidence public key can be any other HDK public key. The solution provider MUST verify that the wallet knows the associated private key before issuing Issuer Trust Evidence. The solution provider MUST ensure that sk_device is under sole control of the unit holder. To achieve reader unlinkability, the unit MUST limit access of Issuer Trust Evidence to a single issuer. Subsequent issuers within the same HDK tree do not need to receive any Issuer Trust Evidence, since they can derive equally secure keys by applying the remote HDK protocol to presented keys attested by trusted (other) issuers. 5.3. Applying HDK in OpenID for Verifiable Credential Issuance In [draft-OpenID4VCI], the following terminology applies: +===================+==========+ | OpenID4VCI | HDK | +===================+==========+ | Credential | document | +-------------------+----------+ | Credential Issuer | issuer | +-------------------+----------+ | Verifier | reader | +-------------------+----------+ | Wallet | unit | +-------------------+----------+ Table 1 HDK enables unit and issuers cooperatively to establish the cryptographic key material that issued documents will be bound to. For the remote HDK protocol, HDK proposes an update to the OpenID4VCI endpoints. This proposal is under discussion in openid/ OpenID4VCI#359 (https://github.com/openid/OpenID4VCI/issues/359). In the update, the unit shares a key encapsulation public key with the issuer, and the issuer returns a key handle. Then documents can be re-issued, potentially in batches, using synchronised indices. Alternatively, re-issued documents can have their own key handles. 6. Security considerations Dijkhuis Expires 23 July 2025 [Page 24] Internet-Draft HDK January 2025 6.1. Confidentiality of key handles The key handles MUST be considered confidential, since they provide knowledge about the blinding factors. Compromise of this knowledge could introduce undesired linkability. In HDK, both the holder and the issuer know the key handle during issuance. In an alternative to HDK, the holder independently generates blinded key pairs and proofs of association, providing the issuer with zero knowledge about the blinding factors. However, this moves the problem: the proofs of association would now need to be considered confidential. 7. References 7.1. Normative References [FIPS180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, June 2012, . [ISO18013-5] ISO/IEC, "Personal identification - ISO-compliant driving licence - Part 5: Mobile driving licence (mDL) application", ISO/IEC 18013-5:2021, September 2019, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, . Dijkhuis Expires 23 July 2025 [Page 25] Internet-Draft HDK January 2025 [RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380, DOI 10.17487/RFC9380, August 2023, . [RFC9497] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. Wood, "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497, December 2023, . [SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0", SEC 2 Version 2.0, January 2010, . [TR03111] Federal Office for Information Security (BSI), "Elliptic Curve Cryptography", BSI TR-03111 Version 2.10, June 2018, . 7.2. Informative References [BIP32] Wuille, P., "Hierarchical Deterministic Wallets", BIP 32, February 2021, . [draft-OpenID4VCI] Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for Verifiable Credential Issuance, draft 13", 8 February 2024, . [EU2015-1502] European Commission, "Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 on setting out minimum technical specifications and procedures for assurance levels for electronic identification means", (EU) 2015/1502, September 2025, . [EU2024-1183] The European Parliament and the Council of the European Union, "Amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework", (EU) 2024/1183, April 2024, . Dijkhuis Expires 23 July 2025 [Page 26] Internet-Draft HDK January 2025 [I-D.draft-bradleylundberg-cfrg-arkg-02] Lundberg, E. and J. Bradley, "The Asynchronous Remote Key Generation (ARKG) algorithm", Work in Progress, Internet- Draft, draft-bradleylundberg-cfrg-arkg-02, 27 May 2024, . [I-D.draft-irtf-cfrg-signature-key-blinding-07] Denis, F., Eaton, E., Lepoint, T., and C. A. Wood, "Key Blinding for Signature Schemes", Work in Progress, Internet-Draft, draft-irtf-cfrg-signature-key-blinding-07, 23 September 2024, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, . [Verheul2024] Verheul, E., "Attestation Proof of Association – provability that attestation keys are bound to the same hardware and person", 18 September 2024, . [Wilson2023] Wilson, S. M., "Post-Quantum Account Recovery for Passwordless Authentication. Master’s thesis", 24 April 2023, . Acknowledgements This design is based on ideas introduced to the EU Digital Identity domain by Peter Lee Altmann. Helpful feedback came from Emil Lundberg, John Bradley and Remco Schaar. Contributors Micha Kraus Dijkhuis Expires 23 July 2025 [Page 27] Internet-Draft HDK January 2025 Author's Address Sander Dijkhuis (editor) Cleverbase Email: mail@sanderdijkhuis.nl Dijkhuis Expires 23 July 2025 [Page 28]