This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
stand_alone: true ipr: trust200902
title: The Asynchronous Remote Key Generation (ARKG) algorithm abbrev: "ARKG" lang: en category: info
docname: draft-bradleylundberg-cfrg-arkg-00 submissiontype: IETF # also: "independent", "editorial", "IAB", or "IRTF" number: date: consensus: true v: 3 area: Security workgroup: CFRG keyword:
- KDF venue: group: CFRG type: Individual github: Yubico/arkg-rfc
author:
-
role: editor fullname: Emil Lundberg organization: Yubico street: Kungsgatan 44 city: Stockholm country: SE email: emil@emlun.se
-
fullname: John Bradley organization: Yubico email: ve7jtb@ve7jtb.com
contributor: fullname: Dain Nilsson organization: Yubico
normative: hkdf: RFC5869 RFC2104: RFC2119: RFC3279: RFC4949: RFC6090: RFC5869: BIP32: target: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki title: BIP 32 Hierarchical Deterministic Wallets author: - name: Pieter Wuille date: 2012 SEC1: target: http://www.secg.org/sec1-v2.pdf author: - org: Certicom Research date: 2020 title: SEC 1 Elliptic Curve Cryptography
informative: Clermont: target: https://www.cryptoplexity.informatik.tu-darmstadt.de/media/crypt/teaching_1/theses_1/Sebastian_Clermont_Thesis.pdf author: - name: Sebastian A. Clermont - org: "Technische Universität Darmstadt" date: 2022 title: "Post Quantum Asynchronous Remote Key Generation. Master's thesis" WebAuthn-Recovery: author: - name: Emil Lundberg - name: Dain Nilsson title: "WebAuthn recovery extension: Asynchronous delegated key generation without shared secrets. GitHub" date: 2019 target: https://github.com/Yubico/webauthn-recovery-extension Frymann2020: author: - name: Nick Frymann - name: Daniel Gardham - name: Franziskus Kiefer - name: Emil Lundberg - name: Mark Manulis - name: Dain Nilsson title: "Asynchronous Remote Key Generation: An Analysis of Yubico's Proposal for W3C WebAuthn. CCS '20: Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security" date: 2020 target: https://eprint.iacr.org/2020/1004 Frymann2023: author: - name: Nick Frymann - name: Daniel Gardham - name: Mark Manulis title: Asynchronous Remote Key Generation for Post-Quantum Cryptosystems from Lattices. 2023 IEEE 8th European Symposium on Security and Privacy date: 2023 target: https://eprint.iacr.org/2023/419 Wilson: author: - name: Spencer MacLaren Wilson - org: University of Waterloo, title: "Post-Quantum Account Recovery for Passwordless Authentication. Master's thesis" date: 2023 target: http://hdl.handle.net/10012/19316
--- abstract
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other.
This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future.
--- middle
Asymmetric cryptography, also called public key cryptography, is a fundamental component of much of modern information security. However, even the flexibility of asymmetric cryptosystems is not always enough for all applications. For the sake of privacy and forward secrecy it may be necessary to frequently generate new keys, but it is not always feasible for the holder of the private keys to be available whenever a new key pair is needed. For example, this is often the case when using a hardware security device to hold private keys, where the device may be detached or locked at the time a new key pair is needed.
The Asynchronous Remote Key Generation (ARKG) algorithm enables the holder of private keys to delegate generation of public keys without giving access to the corresponding private keys. This enables a public key consumer to autonomously generate public keys whenever one is needed, while the private key holder can later derive the corresponding private key using a "key handle" generated along with the public key.
The algorithm consists of three procedures: (1) the delegating party generates a seed pair and emits the public seed to a subordinate party, (2) the subordinate party uses the public seed to generate a public key and a key handle on behalf of the delegating party, and (3) the delegating party uses the key handle and the private seed to derive the private key corresponding to the public key generated by procedure (2). Procedure (1) is performed once, and procedures (2) and (3) may be repeated any number of times with the same seed pair. The required cryptographic primitives are a public key blinding scheme, a key encapsulation mechanism (KEM), a key derivation function (KDF) and a message authentication code (MAC) scheme. Both conventional primitives and quantum-resistant alternatives exist that meet these requirements. [Wilson]
Some motivating use cases of ARKG include:
-
Efficient single-use signing keys. The European Union has proposed a digital identity system which, in order to protect users' privacy, needs a unique key pair for each authentication signature. In online usage the system could relatively easily create a key on demand, submit it to a certification authority to have a single-use certificate issued for that key, and then submit that certificate with an authentication signature to a third party to access a service.
However, the proposed system also includes offline use cases: A user might for example need to use the system in a location with poor or no internet connectivity to present a digital driver's license or authorize a payment. For this, the system may need to pre-emptively generate a large amount of single-use certificates to be used offline.
One candidate implementation under evaluation to provide signing and key management for this system is the W3C Web Authentication API [WebAuthn] (WebAuthn), which requires a user gesture whenever a WebAuthn operation is invoked. A WebAuthn-based implementation of the proposed digital identity system could use ARKG to pre-emptively generate key pairs for offline use without the need to prompt for a user gesture for each key pair generated.
-
Enhanced forward secrecy for encrypted messaging. For example, section 8.5.4 of RFC 9052 defines COSE representations for encrypted messages and notes that "Since COSE is designed for a store-and-forward environment rather than an online environment, [...] forward secrecy (see [RFC4949]) is not achievable. A static key will always be used for the receiver of the COSE object." Applications could work around this limitation by exchanging a large number of keys in advance, but that number limits how many messages can be sent before another such exchange is needed. This also requires the sender to allocate storage space for the keys, which may be challenging to support in constrained hardware.
ARKG could enable the sender to generate ephemeral recipient public keys on demand. This may enhance forward secrecy if the sender keeps the ARKG public seed secret, since each recipient key pair is used to encrypt only one message.
-
Generating additional public keys as backup keys. For example, the W3C Web Authentication API [WebAuthn] (WebAuthn) generates a new key pair for each account on each web site. This makes it difficult for users to set up a backup authenticator, because each time a key pair is created for the primary authenticator, another key pair also needs to be created for the backup authenticator, which may be stored in a safe but inconvenient location.
ARKG could enable the primary authenticator to also generate a public key for a paired backup authenticator whenever it generates a key pair for itself, allowing the user to set up the pairing once and then leave the backup authenticator in safe storage until the primary authenticator is lost.
{::boilerplate bcp14-tagged}
The ARKG algorithm consists of three functions, each performed by one of two participants: the delegating party or the subordinate party. The delegating party generates an ARKG seed pair and emits the public seed to the subordinate party while keeping the private seed secret. The subordinate party can then use the public seed to generate derived public keys and key handles, and the delegating party can use the private seed and a key handle to derive the corresponding private key.
The following subsections define some notation and the abstract instance parameters used to construct the three ARKG functions, followed by the definitions of the three ARKG functions.
The following notation is used throughout this document:
-
The symbol
||
represents octet string concatenation. -
When literal text strings are to be interpreted as octet strings, they are encoded using UTF-8.
-
Elliptic curve operations are written in multiplicative notation:
*
denotes point multiplication, i.e., the curve group operation;^
denotes point exponentiation, i.e., repeated point multiplication; and+
denotes scalar addition modulo the curve order. -
Random(min_inc, max_exc)
represents a cryptographically secure random integer greater than or equal tomin_inc
and strictly less thanmax_exc
.
ARKG is composed of a suite of other algorithms. The parameters of an ARKG instance are:
-
BL
: An asymmetric key blinding scheme [Wilson], consisting of:-
Function
BL-Generate-Keypair() -> (pk, sk)
: Generate a blinding key pair.No input.
Output consists of a blinding public key
pk
and a blinding secret keysk
. -
Function
BL-Blind-Public-Key(pk, tau) -> pk_tau
: Deterministically compute a blinded public key.Input consists of a blinding public key
pk
and a blinding factortau
.Output consists of the blinded public key
pk_tau
. -
Function
BL-Blind-Secret-Key(sk, tau) -> sk_tau
: Deterministically compute a blinded secret key.Input consists of a blinding secret key
sk
and a blinding factortau
.Output consists of the blinded secret key
sk_tau
. -
Integer
L_bl
: The length of the blinding factortau
in octets.
pk
andpk_tau
are opaque octet strings of arbitrary length.tau
is an opaque octet string of lengthL_bl
. The representations ofsk
,sk_tau
andL_bl
are an undefined implementation detail.See [Wilson] for definitions of security properties required of the key blinding scheme
BL
. -
-
KEM
: A key encapsulation mechanism, consisting of the functions:-
KEM-Generate-Keypair() -> (pk, sk)
: Generate a key encapsulation key pair.No input.
Output consists of public key
pk
and secret keysk
. -
KEM-Encaps(pk) -> (k, c)
: Generate a key encapsulation.Input consists of an encapsulation public key
pk
.Output consists of a shared secret
k
and an encapsulation ciphertextc
. -
KEM-Decaps(sk, c) -> k
: Decapsulate a shared secret.Input consists of encapsulation secret key
sk
and encapsulation ciphertextc
.Output consists of the shared secret
k
on success, or an error otherwise.
pk
,k
andc
are opaque octet strings. The representation ofsk
is an undefined implementation detail.See [Wilson] for definitions of security properties required of the key encapsulation mechanism
KEM
. -
-
MAC
: A message authentication code (MAC) scheme, consisting of:-
Function
MAC-Tag(k, m) -> t
: Generate a message authentication tag for a given message using a given key.Input consists of the shared MAC key
k
and the messagem
.Output consists of the MAC tag
t
. -
Function
MAC-Verify(k, m, t) -> { 0, 1 }
: Verify a message authentication tag.Input consists of the shared MAC key
k
, the messagem
and the MAC tagt
.Output is 1 if and only if
MAC-Tag(k, m) = t
. -
Integer
L_mac
: The length of the MAC keyk
in octets.
k
is an opaque octet string of lengthL_mac
.m
andt
are opaque octet strings of arbitrary length. The representation ofL_mac
is an undefined implementation detail.See [Frymann2020] for definitions of security properties required of the message authentication code scheme
MAC
. -
-
KDF
: A variable-length key derivation function with the signature:KDF(info, ikm, L) -> okm
Input consists of a domain separation parameter
info
, input key materialikm
and output lengthL
.Output consists of output key material
okm
of lengthL
in octets.info
andikm
are opaque octet strings of arbitrary length.okm
is an opaque octet string of lengthL
.L
is an integer with undefined representation.See [Frymann2020] for definitions of security properties required of the key derivation function
KDF
.
A concrete ARKG instantiation MUST specify the instantiation of each of the above functions and values.
The output keys of the BL
scheme are also the output keys of the ARKG instance as a whole.
For example, if BL-Blind-Public-Key
and BL-Blind-Secret-Key
output ECDSA keys,
then the ARKG instance will also output ECDSA keys.
Instantiations MUST satisfy the following compatibility criteria:
-
The output shared secret
k
ofKEM-Encaps
andKEM-Decaps
is a valid input key materialikm
ofKDF
. -
Output key material
okm
of lengthL_bl
ofKDF
is a valid input blinding factortau
ofBL-Blind-Public-Key
andBL-Blind-Secret-Key
.It is permissible for some
KDF
outputs to not be valid blinding factors, as long as this happens with negligible probability - see section [Design Rationale: Using a MAC]. -
Output key material
okm
of lengthL_mac
ofKDF
is a valid input MAC keyk
ofMAC-Tag(k, m)
andMAC-Verify(k, m, t)
.It is permissible for some
KDF
outputs to not be valid MAC keys, as long as this happens with negligible probability - see section [Design Rationale: Using a MAC].
We denote a concrete ARKG instance by the pattern ARKG-BL-KEM-MAC-KDF
,
substituting the chosen instantiation for the BL
, KEM
, MAC
and KDF
parts.
Note that this pattern cannot in general be unambiguously parsed;
implementations MUST NOT attempt to construct an ARKG instance by parsing such a pattern string.
Concrete ARKG instances MUST always be identified by lookup in a registry of fully specified ARKG instances.
This is to prevent usage of algorithm combinations that may be incompatible or insecure.
This function is performed by the delegating party.
The delegating party generates the ARKG seed pair (pk, sk)
and keeps the private seed sk
secret, while the public seed pk
is provided to the subordinate party.
The subordinate party will then be able to generate public keys on behalf of the delegating party.
ARKG-Generate-Seed() -> (pk, sk)
Options:
BL The key blinding scheme chosen for the ARKG instantiation.
KEM The key encapsulation mechanism chosen for the ARKG instantiation.
Inputs: None
Output:
(pk, sk) An ARKG seed key pair with public key pk and private key sk.
The output (pk, sk) is calculated as follows:
(pk_kem, sk_kem) = KEM-Generate-Keypair()
(pk_bl, sk_bl) = BL-Generate-Keypair()
pk = (pk_kem, pk_bl)
sk = (sk_kem, sk_bl)
This function is performed by the subordinate party, which holds the ARKG public seed pk = (pk_kem, pk_bl)
.
The resulting public key pk'
can be provided to external parties to use in asymmetric cryptography protocols,
and the resulting key handle kh
can be used by the delegating party to derive the private key corresponding to pk'
.
This function may be invoked any number of times with the same public seed, in order to generate any number of public keys.
ARKG-Derive-Public-Key((pk_kem, pk_bl), info) -> (pk', kh)
Options:
BL The key blinding scheme chosen for the ARKG instantiation.
KEM The key encapsulation mechanism chosen for the ARKG instantiation.
MAC The MAC scheme chosen for the ARKG instantiation.
KDF The key derivation function chosen for the ARKG instantiation.
L_bl The length in octets of the blinding factor tau of the key blinding scheme BL.
L_mac The length in octets of the MAC key of the MAC scheme MAC.
Inputs:
pk_kem A key encapsulation public key.
pk_bl A key blinding public key.
info Optional context and application specific information
(can be a zero-length string).
Output:
pk' A blinded public key.
kh A key handle for deriving the blinded
secret key sk' corresponding to pk'.
The output (pk, sk) is calculated as follows:
(k, c) = KEM-Encaps(pk_kem)
tau = KDF("arkg-blind" || 0x00 || info, k, L_bl)
mk = KDF("arkg-mac" || 0x00 || info, k, L_mac)
tag = MAC-Tag(mk, c || info)
pk' = BL-Blind-Public-Key(pk_bl, tau)
kh = (c, tag)
If this procedure aborts due to an error,
for example because KDF
returns an invalid tau
or mk
,
the procedure can safely be retried with the same arguments.
This function is performed by the delegating party, which holds the ARKG private seed (sk_kem, sk_bl)
.
The resulting secret key sk'
can be used in asymmetric cryptography protocols
to prove possession of sk'
to an external party that has the corresponding public key.
This function may be invoked any number of times with the same private seed, in order to derive the same or different secret keys any number of times.
ARKG-Derive-Secret-Key((sk_kem, sk_bl), kh, info) -> sk'
Options:
BL The key blinding scheme chosen for the ARKG instantiation.
KEM The key encapsulation mechanism chosen for the ARKG instantiation.
MAC The MAC scheme chosen for the ARKG instantiation.
KDF The key derivation function chosen for the ARKG instantiation.
L_bl The length in octets of the blinding factor tau of the
key blinding scheme BL.
L_mac The length in octets of the MAC key of the MAC scheme MAC.
Inputs:
sk_kem A key encapsulation secret key.
sk_bl A key blinding secret key.
kh A key handle output from ARKG-Derive-Public-Key.
info Optional context and application specific information
(can be a zero-length string).
Output:
sk' A blinded secret key.
The output sk' is calculated as follows:
(c, tag) = kh
k = KEM-Decaps(sk_kem, c)
mk = KDF("arkg-mac" || 0x00 || info, k, L_mac)
If MAC-Verify(mk, c || info, tag) = 0:
Abort with an error.
tau = KDF("arkg-blind" || 0x00 || info, k, L_bl)
sk' = BL-Blind-Secret-Key(sk_bl, tau)
Errors in this procedure are typically unrecoverable.
For example, KDF
might return an invalid tau
or mk
, or the tag
may be invalid.
ARKG instantiations SHOULD be chosen in a way that such errors are impossible
if kh
was generated by an honest and correct implementation of ARKG-Derive-Public-Key
.
Incorrect or malicious implementations of ARKG-Derive-Public-Key
do not degrade the security
of a correct and honest implementation of ARKG-Derive-Secret-Key
.
See also section [Design Rationale: Using a MAC].
This section defines generic formulae for instantiating the individual ARKG parameters, which can be used to define concrete ARKG instantiations.
TODO: IANA registry? COSE/JOSE?
Instantiations of ARKG whose output keys are elliptic curve keys
can use elliptic curve arithmetic as the key blinding scheme BL
. [Frymann2020] [Wilson]
This section defines a general formula for such instantiations of BL
.
Let crv
be an elliptic curve.
Then the BL
parameter of ARKG may be instantiated as follows:
-
Elliptic curve points are encoded to and from octet strings using the procedures defined in sections 2.3.3 and 2.3.4 of [SEC 1][sec1].
-
Elliptic curve scalar values are encoded to and from octet strings using the procedures defined in sections 2.3.7 and 2.3.8 of [SEC 1][sec1].
-
N
is the order ofcrv
. -
G
is the generator ofcrv
.
BL-Generate-Keypair() -> (pk, sk)
sk = Random(1, N)
pk_tmp = G^sk
If pk_tmp equals the point at infinity, abort with an error.
pk = pk_tmp
TODO: Also reject G?
BL-Blind-Public-Key(pk, tau) -> pk_tau
If tau = 0 or tau >= N, abort with an error.
pk_tau_tmp = pk * (G^tau)
If pk_tau_tmp equals the point at infinity, abort with an error.
pk_tau = pk_tau_tmp
TODO: Also reject G?
BL-Blind-Secret-Key(sk, tau) -> sk_tau
If tau = 0 or tau >= N, abort with an error.
sk_tau_tmp = sk + tau
If sk_tau_tmp = 0, abort with an error.
sk_tau = sk_tau_tmp
TODO: Also reject 1?
Instantiations of ARKG can use ECDH [RFC6090] as the key encapsulation mechanism.
This section defines a general formula for such instantiations of KEM
.
Let crv
be an elliptic curve used for ECDH.
Then the KEM
parameter of ARKG may be instantiated as follows:
-
Elliptic curve points are encoded to and from octet strings using the procedures defined in sections 2.3.3 and 2.3.4 of [SEC 1][sec1].
-
Elliptic curve coordinate field elements are encoded to and from octet strings using the procedures defined in sections 2.3.5 and 2.3.6 of [SEC 1][sec1].
-
Elliptic curve scalar values are encoded to and from octet strings using the procedures defined in sections 2.3.7 and 2.3.8 of [SEC 1][sec1].
-
ECDH(pk, sk)
represents the compact output of ECDH [RFC6090] using public key (curve point)pk
and secret key (exponent)sk
. -
N
is the order ofcrv
. -
G
is the generator ofcrv
.
KEM-Generate-Keypair() -> (pk, sk)
sk = Random(1, N)
pk_tmp = G^sk
If pk_tmp equals the point at infinity, abort with an error.
pk = pk_tmp
TODO: Also reject G?
KEM-Encaps(pk) -> (k, c)
(pk', sk') = KEM-Generate-Keypair()
k = ECDH(pk, sk')
c = pk'
KEM-Decaps(sk, c) -> k
pk' = c
k = ECDH(pk', sk)
If elliptic curve arithmetic is used for key blinding and ECDH is used as the KEM, as described in the previous sections, then both of them MAY use the same curve or MAY use different curves. If both use the same curve, then it is also possible to use the same public key as both the key blinding public key and the KEM public key. [Frymann2020]
TODO: Caveats? I think I read in some paper or thesis about specific drawbacks of using the same key for both.
Let Hash
be a cryptographic hash function.
Then the MAC
parameter of ARKG may be instantiated using HMAC [RFC2104] as follows:
MAC-Tag(k, m) -> t
t = HMAC-Hash(K=k, text=m)
MAC-Verify(k, m, t) -> { 0, 1 }
t' = HMAC-Hash(K=k, text=m)
If t = t':
return 1
Else:
return 0
Let Hash
be a cryptographic hash function.
Then the KDF
parameter of ARKG may be instantiated using HKDF [RFC5869] as follows:
KDF(info, ikm, L) -> okm
PRK = HKDF-Extract with the arguments:
Hash: Hash
salt: not set
IKM: ikm
okm = HKDF-Expand with the arguments:
Hash: Hash
PRK: PRK
info: info
L: L
This section defines an initial set of concrete ARKG instantiations.
TODO: IANA registry? COSE/JOSE?
The identifier ARKG-P256-ECDH-P256-HMAC-SHA256-HKDF-SHA256
represents the following ARKG instantiation:
BL
: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter:crv
: The NIST curvesecp256r1
[SEC2].
KEM
: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter:crv
: The NIST curvesecp256r1
[SEC2].
MAC
: HMAC as described in section [Using HMAC as the MAC] with the parameter:Hash
: SHA-256 [FIPS 180-4].
KDF
: HKDF as described in section [Using HKDF as the KDF] with the parameter:Hash
: SHA-256 [FIPS 180-4].
L_bl
: 32L_mac
: 32
The identifier ARKG-P384-ECDH-P384-HMAC-SHA384-HKDF-SHA384
represents the following ARKG instantiation:
BL
: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter:crv
: The NIST curvesecp384r1
[SEC2].
KEM
: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter:crv
: The NIST curvesecp384r1
[SEC2].
MAC
: HMAC as described in section [Using HMAC as the MAC] with the parameter:Hash
: SHA-384 [FIPS 180-4].
KDF
: HKDF as described in section [Using HKDF as the KDF] with the parameter:Hash
: SHA-384 [FIPS 180-4].
L_bl
: 48L_mac
: 48
The identifier ARKG-P521-ECDH-P521-HMAC-SHA512-HKDF-SHA512
represents the following ARKG instantiation:
BL
: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter:crv
: The NIST curvesecp521r1
[SEC2].
KEM
: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter:crv
: The NIST curvesecp521r1
[SEC2].
MAC
: HMAC as described in section [Using HMAC as the MAC] with the parameter:Hash
: SHA-512 [FIPS 180-4].
KDF
: HKDF as described in section [Using HKDF as the KDF] with the parameter:Hash
: SHA-512 [FIPS 180-4].
L_bl
: 64L_mac
: 64
The identifier ARKG-P256k-ECDH-P256k-HMAC-SHA256-HKDF-SHA256
represents the following ARKG instantiation:
BL
: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter:crv
: The SECG curvesecp256k1
[SEC2].
KEM
: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter:crv
: The SECG curvesecp256k1
[SEC2].
MAC
: HMAC as described in section [Using HMAC as the MAC] with the parameter:Hash
: SHA-256 [FIPS 180-4].
KDF
: HKDF as described in section [Using HKDF as the KDF] with the parameter:Hash
: SHA-256 [FIPS 180-4].
L_bl
: 32L_mac
: 32
The identifier ARKG-Ed25519-X25519-HMAC-SHA256-HKDF-SHA256
represents the following ARKG instantiation:
BL
: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter:crv
: The curveEd25519
[REF?].
KEM
: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter:crv
: The curveX25519
[REF?].
MAC
: HMAC as described in section [Using HMAC as the MAC] with the parameter:Hash
: SHA-256 [FIPS 180-4].
KDF
: HKDF as described in section [Using HKDF as the KDF] with the parameter:Hash
: SHA-256 [FIPS 180-4].
L_bl
: 32L_mac
: 32
The identifier ARKG-X25519-X25519-HMAC-SHA256-HKDF-SHA256
represents the following ARKG instantiation:
BL
: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter:crv
: The curveX25519
[REF?].
KEM
: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter:crv
: The curveX25519
[REF?].
MAC
: HMAC as described in section [Using HMAC as the MAC] with the parameter:Hash
: SHA-256 [FIPS 180-4].
KDF
: HKDF as described in section [Using HKDF as the KDF] with the parameter:Hash
: SHA-256 [FIPS 180-4].
L_bl
: 32L_mac
: 32
TODO?: Define COSE representations for interoperability:
- ARKG public seed (for interoperability between different implementers of
ARKG-Generate-Seed
andARKG-Derive-Public-Key
) - ARKG key handle (for interoperability between different implementers of
ARKG-Derive-Public-Key
andARKG-Derive-Secret-Key
)
TODO
TODO
TODO
The ARKG construction by Wilson [Wilson] omits the MAC and instead encodes application context in the PRF labels, arguing this leads to invalid keys/signatures in cases that would have a bad MAC. We choose to keep the MAC from the construction by Frymann et al. [Frymann2020] for two purposes.
The first is so that the delegating party can distinguish between key handles addressed to it
and those addressed to other delegating parties.
We anticipate use cases where a private key usage request may contain key handles for several delegating parties
eligible to fulfill the request,
and the delegate party to be used can be chosen opportunistically depending on which are available at the time.
Without the MAC, choosing the wrong key handle would cause the ARKG-Derive-Secret-Key
procedure to silently derive the wrong key
instead of returning an explicit error, which would in turn lead to an invalid signature or similar final output.
This would make it difficult or impossible to diagnose the root cause of the issue and present actionable user feedback.
The MAC also allows ARKG key handles to be transmitted via heterogeneous data channels,
possibly including a mix of ARKG key handles and similar values used for other algorithms.
The second purpose is so that the delegating party can be assured that no errors should happen
during the execution of ARKG-Derive-Secret-Key
, such as out-of-range or invalid key values.
For example, key generation in ARKG-Derive-Public-Key
might be done by randomly testing candidates [NIST.SP.800-56Ar3]
and retrying ARKG-Derive-Public-Key
until a valid candidate is found.
A MAC enables ARKG-Derive-Secret-Key
to assume that the first candidate from a given pseudo-random seed will be successful,
and otherwise return an explicit error rejecting the key handle as invalid.
ARKG-Derive-Public-Key
is likely to run on powerful general-purpose hardware, such as a laptop, smartphone or server,
while ARKG-Derive-Secret-Key
might run on more constrained hardware such as a cryptographic smart card,
which benefits greatly from such optimizations.
It is straightforward to see that adding the MAC to the construction by Wilson
does not weaken the security properties defined by Frymann et al. [Frymann2020]:
the construction by Frymann et al. can be reduced to the ARKG construction in this document
by instantiating KEM
as group exponentiation
and instantiating BL
as group multiplication to blind public keys and modular integer addition to blind secret keys.
The MAC
and KDF
parameters correspond trivially to the MAC and KDF parameters in [Frymann2020],
where KDF1(k) = KDF(k, l1) and KDF2(k) = KDF(k, l2)
with fixed labels l1 and l2.
Hence if one can break PK-unlinkability or SK-security of the ARKG construction in this document,
one can also break the same property of the construction by Frymann et al.
TODO
TODO
TODO: Ask authors for canonical reference addresses
--- back
ARKG was first proposed under this name by Frymann et al. [Frymann2020], who analyzed a proposed extension to W3C Web Authentication by Lundberg and Nilsson [WebAuthn-Recovery], which was in turn inspired by a similar construction by Wuille [BIP32] used to create privacy-preserving Bitcoin addresses. Frymann et al. [Frymann2020] generalized the constructions by Lundberg, Nilsson and Wuille from elliptic curves to any discrete logarithm (DL) problem, and also proved the security of arbitrary asymmetric protocols composed with ARKG. Further generalizations to include quantum-resistant instantiations were developed independently by Clermont [Clermont], Frymann et al. [Frymann2023] and Wilson [Wilson].
This document adopts the construction proposed by Wilson [Wilson], modified by the inclusion of a MAC in the key handles as done in the original construction by Frymann et al. [Frymann2020].
The authors would like to thank all of these authors for their research and development work that led to the creation of this document.
TODO
-00 Initial Version