Trust evidence, device binding

[mickrau]

After reading the documents, it's not entirely clear to me how it is ensured that all (sub) HD keys are bound to a legitime security device. For me everything starts with the HDK-Root and the Wallet Trust Evidence issued by the wallet solution provider that confirms that the HDK-Root is device bound. But how can the wallet solution provider check the device binding itself?

In the ECDH instance's HDK-Root function the public key P' is bound to the device public key P_dev by: P' = [sk'] P_dev where sk' is derived from a seed and P_dev

Can the wallet provider check that the wallet instance really calculates P' in this way, by given only P' and P_dev + key attestation?

[sander]

Good find – I think this was functionally described in the earlier use cases, but I accidentally removed it while editing the spec for simplification.

Indeed the wallet solution provider needs to be somehow assured that the HDK-Root is device-bound, and just receiving P', P_dev and the key attestation are insufficient. I see three solutions:

1. certify the wallet solution to make it so, without cryptographic verification (too expensive at EAL4+)
2. make the wallet instance share with the solution provider:
   • P'
   • P_dev
   • a key attestation of P_dev
   • a Schnorr non-interactive zero-knowledge proof of sk' with base point P_dev
3. make the wallet instance share with the solution provider:
   • P'
   • P_dev
   • a key attestation of P_dev
   • sk'

I think option 3 could work fine. Knowledge of sk' does not enable the solution provider to learn anything about the other blinding private keys. It may in some instantiations enable the solution provider to forge proofs of possession of the WTE key, but this would not provide more power than they already have as issuer of WTE.

What do you think?

[mickrau]

I also see no other option. For option 2 we need low level crypto operations, right?

Knowledge of sk' does not enable the solution provider to learn anything about the other blinding private keys.

To make sure?!:

• in local derivation this is true because seed / salt is kept secret
• in remote derivation this is true because kh is kept secret

[sander]

I also see no other option. For option 2 we need low level crypto operations, right?

Right.

Knowledge of sk' does not enable the solution provider to learn anything about the other blinding private keys.

To make sure?!:

• in local derivation this is true because seed / salt is kept secret
• in remote derivation this is true because kh is kept secret

Right for the local case.

Now that you made this explicit, a risk scenario for option 3 would be that kh and pk_kem leak to the solution provider, and the solution provider can use sk_bl = sk' to derive the next blinding private key. Using this, the solution provider could unblind public keys generated by other issuers. This seems like an unacceptable risk, since the likelihood of a kh leaking is substantial in a large wallet ecosystem.

[sander]

Discussed 2024-07-29: next step is to update the spec to define this interaction with the Wallet Provider for WTE issuance.