Closed emlun closed 1 month ago
(Sorry, I hit Ctrl-Enter too early - previous comment has been edited)
Thank you for the thorough review @emlun!
ARKG also requires a novel hardware operation (
ARKG-Derive-Private-Key
).
See https://github.com/sander/hierarchical-deterministic-keys/issues/7#issuecomment-2138025616
With ARKG I don't think PoP for the root key is necessary, because the trusting party can instead verify that derived keys are correctly derived by the ARKG algorithm and therefore a PoP of the derived private key is also a PoP of the root key.
Upon issuance, the user will present a BL or ARKG public key to the issuer, along with a proof of possession of related private key (as per OpenID4VCI draft 13). Only after verifying that proof, the issuer will derive the batch of next-level PoP public keys using ARKG. If we’d omit the first proof, the issuer could not know if the BL private key is properly protected. For PID and wallet-bound QEAA this would be unacceptable.
Also, one important motivation for introducing ARKG to wallet solutions is to enable the wallet client to autonomously generate lots of unique keys, each to be associated with a single-use instance of a verifiable credential. If issuance of those credentials requires a signature by the private key whose public key is to be the proof key for the credential, then that undermines much of the point of introducing ARKG in the first place. Of course the issuer should authenticate the credential issuance request somehow, but it is critically important that the issuance flow not require a signature by the to-be-issued proof key.
Fully agreed, the issuer should not request PoP of the derived public keys. That would potentially create the usability horror that @ve7jtb mentioned.
Note that ARKG can also be constructed using non-EC cryptograhy (so private keys are not necessary "scalars"), including PQC algorithms.
Indeed, HDK as constructed now limits ARKG to the use with just EC cryptography. I expect that once WSCDs support non-EC cryptography for LoA High, we should revisit the need of HDK as a transitory scheme.
Using a digital signature algorithm for proof of possession
transcript
is not used?
Addressing this awkwardness in: https://github.com/sander/hierarchical-deterministic-keys/issues/8
Using threshold EC-SDSA for additive blind authentication
Requires specification of
BlindVerify
? So verifier can compute blindedvk
from basepk
?
The verifier will not learn the base pk
to achieve RP-Unlinkability. Instead, the verifier can just use PoP.Verify with the attested, blinded public key.
The other comments need to be fixed in the text:
pk_bl
is pk_root
at level 0, or an ARKG-derived public key at child levelsproof = PoP.Authenticate(sk_root, G.ScalarMult(challenge, sk_blind), info)
DST_ext = "ARKG-P256MUL-ECDH"
(was ADD
)draft-bradleylundberg-cfrg-arkg
into a normative reference, even if still an Internet-DraftThe verifier will not learn the base
pk
to achieve RP-Unlinkability. Instead, the verifier can just use PoP.Verify with the attested, blinded public key.
Hm, looking again at "Using threshold EC-SDSA for additive blind authentication", does this blinding method even work with ECDSA? I think something like this works for Schnorr signatures, but I don't think an ECDSA signature can be post-processed like this and remain valid (but under a new public key)?
Split-ECDSA works because before signing you replace e
by e' = e * b^-1
and after replace s
by s' = s * b
, so (s')^-1 = (s * b)^-1 = s^-1 * b^-1
, but you can't distribute the inverse like that for (s')^-1 = (s + r * b)^-1
(where r = c
, b = sk_blind
in the notation in this HDK section). I worked through the verification equation and got that the blinder needs to compute the blinding factor as b = d_A * k^-1
, which shouldn't be possible without knowledge of the private key d_A
. So how does this blinding method work?
(ARKG-Derive-Secret-Key doesn't have this problem since it indeed knows the base private key)
It also seems to me like the section "Using a digital signature algorithm for proof of possession" relies heavily on the specific underlying arithmetic of the DSA
scheme, so the abstract interface definition for DSA
doesn't seem very useful.
The verifier will not learn the base
pk
to achieve RP-Unlinkability. Instead, the verifier can just use PoP.Verify with the attested, blinded public key.Hm, looking again at "Using threshold EC-SDSA for additive blind authentication", does this blinding method even work with ECDSA? I think something like this works for Schnorr signatures, but I don't think an ECDSA signature can be post-processed like this and remain valid (but under a new public key)?
The blinding method under “Using threshold EC-SDSA for additive blind authentication” (EC-SDSA = Schnorr as standardised at ISO/IEC) indeed does not work with ECDSA. I’ve added a dedicated section “Using threshold ECDSA for multiplicative blind authentication” to mention that the spec does not include ECDSA blinding due to threshold ECDSA patent issues – SECDSA and possibly some related to threshold ECDSA.
Split-ECDSA works because before signing you replace
e
bye' = e * b^-1
and after replaces
bys' = s * b
, so(s')^-1 = (s * b)^-1 = s^-1 * b^-1
, but you can't distribute the inverse like that for(s')^-1 = (s + r * b)^-1
(wherer = c
,b = sk_blind
in the notation in this HDK section). I worked through the verification equation and got that the blinder needs to compute the blinding factor asb = d_A * k^-1
, which shouldn't be possible without knowledge of the private keyd_A
. So how does this blinding method work?
For SECDSA, another BlindAuthenticate definition would be needed that indeed performs pre-processing and post-processing. The reader can verify blinded signatures using the blinded public key, which is sufficient for HDK.
It also seems to me like the section "Using a digital signature algorithm for proof of possession" relies heavily on the specific underlying arithmetic of the
DSA
scheme, so the abstract interface definition forDSA
doesn't seem very useful.
The introduction and impl PoP(RNG, DSA)
seemed more generally applicable, no? Two alternative possible routes to take with the spec:
Regarding the last paragraph in my last comment: in 5ebb9be I have flattened the generic instantiation section and removed the intermediate “DSA” abstraction over ECDSA and EC-SDSA.
I’ve resolved all pending review comments as of 07d321b. Feel free to reuse this issue or open a new one for further discussion.
The blinding method under “Using threshold EC-SDSA for additive blind authentication” (EC-SDSA = Schnorr as standardised at ISO/IEC)
Oh, I missed the S there in SDSA. Ok, that makes much more sense then. The "(Schnorr)" clarification in the new draft also makes this much clearer. Thanks!
Here are my comments after reviewing the HDK draft. This review concerns the version as of commit
06bf2131
.ARKG also requires a novel hardware operation (
ARKG-Derive-Private-Key
).With ARKG I don't think PoP for the root key is necessary, because the trusting party can instead verify that derived keys are correctly derived by the ARKG algorithm and therefore a PoP of the derived private key is also a PoP of the root key.
Also, one important motivation for introducing ARKG to wallet solutions is to enable the wallet client to autonomously generate lots of unique keys, each to be associated with a single-use instance of a verifiable credential. If issuance of those credentials requires a signature by the private key whose public key is to be the proof key for the credential, then that undermines much of the point of introducing ARKG in the first place. Of course the issuer should authenticate the credential issuance request somehow, but it is critically important that the issuance flow not require a signature by the to-be-issued proof key.
Note that ARKG can also be constructed using non-EC cryptograhy (so private keys are not necessary "scalars"), including PQC algorithms.
I recently added a reference to [Shoup] for this in the ARKG draft, I suggest doing the same here.
info
is an input, not outputIs this correct? Or should this maybe be "input keys of ARKG"?
pk_bl
is not yet introduced?pk
is not used?transcript
is not used?Requires specification of
BlindVerify
? So verifier can compute blindedvk
from basepk
?Why is this needed outside ARKG? (Perhaps duplicate of #9)
This should use
DST_ext = "ARKG-P256MUL-ECDH"
instead, see also next commentWe should define this
ARKG-P256MUL-ECDH
instance in the ARKG spec (duplicate of #7)RNG
unused?Comments not related to a particular paragraph
draft-bradleylundberg-cfrg-arkg
seems like it should be a normative reference