DPK attestation may create possible side channel attack on the batch key.

[ve7jtb]

For a normal attestation during make credential the batch key is always signing over a new public key, preventing an attacker from controlling the output.

In the DPK case the public key for a given credentialID is a fixed value. This allows an attacker to repeatedly request a signature with the batch key over the same value.

This may open a hardware authenticator up to a side channel attack on the batch key.

Some algorithms used in smart card environments like RSA and deterministic ECDSA might be vulnerable to this.

Non deterministic ECDSA likely would not be susceptible.

By not including an authenticator generated nonce in the output to be signed we are counting on the underlying crypto to be resistant.

We can :

1. make an authenticator generated nonce required.
2. make an authenticator generated nonce optional.
3. add sufficient security warnings for authenticators to use non deterministic algs, though that may turn out to be lmiting at some point in the future.

[equalsJeffH]

on 23-Feb-2022 call:
@agl: options 1 or 2 are ok.
@ve7jtb maybe do option 2 and leave it to authnr to add a nonce if the signature alg being used is not properly side-channel resistant.
@agl: also authnr can select nonce length (?)
@ve7jtb: maybe make length max 32 bytes could be less?
@agl: if rp gets same sig, then ok, if not same, then need to do verify
@ve7jtb: tho with non-deterministic ecdsa, will need to do verify each time even if nonce not included

@agl current design: authnr stores dpk attstn sig and replays it (when there's no nonce). adding nonce fine. RPs will need to validate sigs.