Start updating spec

Author: sander

draft-dijkhuis-cfrg-hdkeys.md

@@ -39,9 +39,7 @@ normative:
         author:
             - organization: ISO/IEC
         date: 2019-09
-    RFC7800:
     RFC8017:
-    RFC8235:
     RFC9180:
     RFC9380:
     SEC2:
@@ -94,6 +92,9 @@ informative:
             (EU): 2024/1183
         date: 2024-04
     I-D.draft-bradleylundberg-cfrg-arkg-02:
+    I-D.draft-irtf-cfrg-signature-key-blinding-07:
+    RFC7800:
+    RFC8235:
     Verheul2024:
         title: Attestation Proof of Association – provability that attestation keys are bound to the same hardware and person
         target: https://eprint.iacr.org/2024/1444
@@ -145,9 +146,9 @@ Solutions MAY omit application of the remote functionality. In this case, a unit
 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.
 
 ~~~
-                          +----+
-Confidential static data: |seed|
-                          +-+--+
+                          +----+ +--+
+Confidential static data: |seed| |pk|
+                          +-+--+ +--+
                             v
                           +----+ +----+
 Level 0 HDKeys:           |hdk0| |hdk1|
@@ -162,15 +163,15 @@ Level 2 HDKeys at hdk01:     |hdk000| |hdk001| ...
                              +------+ +------+
 ~~~
 
-The unit computes a Level 0 HDK at the root node using a deterministic function: `(bf0, salt0) = hdk0 = HDK(seed, 0)`. The HDK consists of a first blinding factor `bf0` and a first byte string `salt0` to derive next-level keys. Using `bf0` and the device key pair, the unit can compute blinded public and private keys and proofs of possession.
+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 `(bf, salt)` using the same deterministic function: `(bf', salt') = hdk' = HDK(salt, index)`. The function takes the previous-level `salt` as input, and an `index` starting at 0. The function returns a new HDK as output, which can be used in the same way as the root HDK.
+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.
 
 ### 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], but not the same since ARKG does not enable distributed proof of possession with deterministic hierarchies. This makes it difficult to implement with cryptographic devices that lack specific firmware support.
+This approach is similar to Asynchronous Remote Key Generation (ARKG) [I-D.draft-bradleylundberg-cfrg-arkg-02], but not the same since ARKG does not enable distributed proof of possession with deterministic hierarchies. These hierarchies can be used for example to enable remote parties to derive keys from previously derived keys. Not supporting these makes it difficult to implement with cryptographic devices that lack specific firmware support.
 
 To enable remote derivation of child HDKeys, the unit uses the parent HDKey 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.
 
@@ -180,7 +181,7 @@ Locally derived parents can have remotely derived children. Remotely derived par
 
 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 = (bf, salt)`. 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.
+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.
 
 ~~~
 +------------------+ +--------+
@@ -225,45 +226,98 @@ The parameters of an HDK instantiation are:
 - `ID`: A domain separation tag, represented as a string of ASCII bytes.
 - `Ns`: The amount of bytes of a salt value with sufficient entropy.
 - `H`: A cryptographic hash function.
-  - H1(msg): Outputs `Ns` bytes.
-- `BL`: An asymmetric key blinding scheme with opaque blinding factors and algebraic properties, consisting of the functions:
-  - BL-Generate-Blinding-Key-Pair(): Outputs a blinding key pair `(pk, sk)`.
-  - BL-Derive-Blinding-Factor(msg, ctx): Outputs a blinding factor `bf` based on two byte string inputs, message `msg` and domain separation parameter `ctx`.
-  - BL-Blind-Public-Key(pk, bf): Outputs the result `pk'` of blinding `pk` with `bf`. This again is a blinding public key.
-  - BL-Blind-Private-Key(sk, bf): Outputs the result `sk'` of blinding `sk` with `bf`. This again is a blinding private key.
-  - BL-Combine-Blinding-Factors(bf1, bf2): Outputs a blinding factor `bf` such that for all blinding key pairs `(pk, sk)`:
-    - `BL-Blind-Public-Key(pk, bf) == BL-Blind-Public-Key(BL-Blind-Public-Key(pk, bf1), bf2)`
+  - H(msg): Outputs `Ns` bytes.
+- `D`: An digital signature algorithm or shared secret creation algorithm based on public key cryptography, consisting of the functions:
+  - D-Generate-Key-Pair(): Outputs a key pair `(sk, pk)`.
+- `BL`: An asymmetric key blinding scheme for `D` as defined in [I-D.draft-irtf-cfrg-signature-key-blinding-07], with opaque blinding factors and algebraic properties, consisting of the functions:
+  - BL-Derive-Blind-Key(ikm): Outputs a blind key `bk` based on input keying material `ikm`.
+  - BL-Derive-Blinding-Factor(bk, ctx): Outputs a blinding factor `bf` based on a blind key `bk` and an application context byte string `ctx`.
+  - BL-Blind-Public-Key(pk, bk, ctx): Outputs the result `pk'` of blinding public key `pk` with blind key `bk` and application context byte string `ctx`. This again is a public key in `D`.
+  - BL-Blind-Private-Key(sk, bf): Outputs the result `sk'` of blinding private key `sk` with blinding factor `bf`. This result is a private key in `D`, such that if `bf = BL-Derive-Blinding-Factor(bk, ctx)` for some `bk` and `ctx`, the associated public key in `D` equals `BL-Blind-Public-Key(pk, bk, ctx)`.
+  - BL-Combine(bf1, bf2): Outputs a blinding factor `bf` such that for all key pairs `(pk, sk)` in `D`:
     - `BL-Blind-Private-Key(pk, bf) == BL-Blind-Private-Key(BL-Blind-Private-Key(pk, bf1), bf2)`
 - `KEM`: A key encapsulation mechanism [RFC9180], consisting of the functions:
     - KEM-Derive-Key-Pair(ikm): Outputs a key encapsulation key pair `(sk, pk)`.
     - KEM-Encap(pk): Outputs `(k, c)` consisting of a shared secret `k` and a ciphertext `c`, taking key encapsulation public key `pk`.
     - KEM-Decap(c, sk): Outputs shared secret `k`, taking ciphertext `c` and key encapsulation private key `sk`.
-- `Authenticate(sk_device, reader_data, bf)`: Outputs `device_data` for use in a protocol for proof of possession, taking a BL blinding private key `sk_device`, remotely received `reader_data`, and a BL blinding factor `bf`.
 
 An HDK instantiation MUST specify the instantiation of each of the above functions and values.
 
-An HDK instantiation MUST define Authenticate such that the `device_data` can be verified using the blinded public key `pk = BL-Blind-Public-Key(sk, bf)`. 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.
+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.
 
-## The HDK function
+An HDK implementation MAY leave BL-Blind-Private-Key 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.
+
+## 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 HDK-Create-Context(index):
+    ctx = ID || I2OSP(index, 4)
+    return ctx
+~~~
 
-A local unit or a remote party deterministically computes an HDK from a salt and an index. 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.
+## 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 HDK-Derive-Salt(salt, ctx):
+    salt' = H(ID || salt || ctx)
+    return salt'
+~~~
+
+## 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:
-- bf, the blinding factor at the provided index.
+- 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(salt, index):
-    msg = salt || I2OSP(index, 4)
-    bf = BL-Derive-Blinding-Factor(msg, ID)
-    salt' = H1(msg)
-    return (bf, salt')
+def HDK(index, pk, salt, bf = Nil):
+    ctx   = HDK-Create-Context(index)
+    salt' = HDK-Derive-Salt(salt, ctx)
+
+    bk  = BL-Derive-Blind-Key(salt)
+    pk' = BL-Blind-Public-Key(bk, ctx)
+    bf' = if bf == Nil:
+        BL-Derive-Blinding-Factor(bk, ctx)
+    else:
+        BL-Combine(bf, BL-Derive-Blinding-Factor(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 BL-Combine in the HDK function enables reconstruction of the blinding factor with respect to the original private key, enabling application of for example BL-Blind-Private-Key.
+
+If the unit uses the blinded private key directly, the unit MUST use it within the secure cryptographic device protecting the device private key.
+
+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 BL-Combine-Blinding-Factors to obtain values to compute this association.
+
 ## The local HDK procedure
 
 This is a procedure executed locally by a unit.
@@ -272,38 +326,36 @@ To begin, the unit securely generates a `seed` salt of `Ns` bytes and a device k
 
 ~~~
 seed = random(Ns) # specification of random out of scope
-(pk_device, sk_device) = BL-Generate-Blinding-Key-Pair()
+(sk_device, pk_device) = D-Generate-Key-Pair()
 ~~~
 
 The unit MUST generate `sk_device` within a secure cryptographic device.
 
 Whenever the unit requires the HDK with some `index` at level 0, the unit computes:
 
 ~~~
-(bf, salt) = HDK(seed, index)
+(pk, salt, bf) = HDK(index, pk_device, seed)
 
-pk = BL-Blind-Public-Key( pk_device, bf) # optional
 sk = BL-Blind-Private-Key(sk_device, bf) # optional
 ~~~
 
-Now the unit can use the blinded key pair `(pk, sk)` or derive child HDKeys.
+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 = (bf, salt)` with blinded key pair `(pk, sk)` at level `n`, the unit computes:
+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:
 
 ~~~
-(bf', salt') = HDK(salt, index)
+(pk', salt', bf') = HDK(index, pk, salt)
 
-pk' = BL-Blind-Public-Key( pk, bf') # optional
 sk' = BL-Blind-Private-Key(sk, bf') # optional
 ~~~
 
-Now the unit can use the blinded key pair `(pk', sk')` or derive child HDKeys.
+Now the unit can use the blinded key pair `(sk', pk')` or derive child HDKeys.
 
 ## 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 blinding key pair `(pk, sk)` generated using the local HDK procedure.
+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:
@@ -312,47 +364,30 @@ As a prerequisite, the unit possesses a `salt` of `Ns` bytes associated with a p
 # 2. Unit shares with issuer: (pk, pk_kem)
 
 # 3. Issuer computes:
-(salt, kh) = KEM-Encap(pk_kem)
+(salt_kem, kh) = KEM-Encap(pk_kem)
 
 # 4. Issuer shares with unit: kh
 
 # Subsequently, for any index known to both parties:
 
 # 5. Issuer computes:
-(bf, salt') = HDK(salt, index)
-pk' = BL-Blind-Public-Key(pk, bf)
+(pk', salt', bf') = HDK(index, pk, salt_kem)
 
 # 6. Issuer shares with unit: pk'
 
 # 7. Unit verifies integrity:
-salt' = KEM-Decap(kh, sk_kem)
-(bf, salt'') = HDK(salt', index)
-pk' == BL-Blind-Public-Key(pk, bf)
+salt_kem = KEM-Decap(kh, sk_kem)
+(pk_expected', salt', bf') = HDK(index, pk, salt_kem)
+pk' == pk_expected'
 
 # 8. Unit computes:
-sk' = BL-Blind-Private-Key(sk, bf)
+sk' = BL-Blind-Private-Key(sk, bf) # optional
 ~~~
 
-After step 7, the unit can use the value of `salt''` to derive next-level HDKeys.
+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.
 
-## Combining blinding factors
-
-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 unit needs to combine parent blinding factor `bf1` with child blinding factor `bf2` before blinding the parent private key `sk`:
-
-~~~
-bf = BL-Combine-Blinding-Factors(bf1, bf2)
-~~~
-
-Subsequently, the unit can apply the Authenticate function to the parent blinding key. The unit can combine multiple blinding factors in the HDK path.
-
-If the unit uses the blinded private key directly, the unit MUST use it within the secure cryptographic device protecting the device private key.
-
-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 BL-Combine-Blinding-Factors to obtain values to compute this association.
-
 # Generic HDK instantiations
 
 ## Using elliptic curves
@@ -370,12 +405,12 @@ Instantiations of HDK using elliptic curves require the following cryptographic
   - hash_to_field(msg, count): Outputs `count` EC Elements based on the result of cryptographically hashing `msg` (see [RFC9380], Section 5.2).
 
 ~~~
-def BL-Generate-Blinding-Key-Pair():
+def D-Generate-Blinding-Key-Pair():
     sk = EC-Random()
     pk = EC-Scalar-Base-Mult(sk)
-    return (pk, sk)
+    return (sk, pk)
 
-def BL-Derive-Blinding-Factor(msg, ctx):
+def BL-Derive-Blind-Key(ikm, ctx):
     bf = hash_to_field(msg, count) with the parameters:
         DST: ID || ctx
         F: GF(EC-Order()), the scalar field

prototype.lisp

@@ -92,7 +92,6 @@
   (i2osp (getf (crypto:ec-destructure-point (scalar-mult (ec dh) pk-y sk-x)) :x)
          (output-length dh)))
 
-;;(defmethod generate-blind-key ((bl ec-bl)) (random-scalar (ec bl)))
 (defmethod derive-blind-key ((bl ec-bl) ikm)
   (let ((h2c (make-instance 'h2c :ec (ec bl) :h (hash bl) :dst (id bl))))
     (i2osp (hash-to-field h2c ikm) 32)))