Add EIP 1024 APDUs

[btchip]

Implement EIP 1024 privacy APIs

Test snapshot pending Speculos merge (https://github.com/btchip/speculos/tree/x25519_goodenough) - js support merged in ledgerjs 6.24.0

[cseguret-ledger]

Some changes to ask.
However it does not have a test

[cseguret-ledger]

@btchip this PR is linked to this issue? : #189

[btchip]

Yes, it's related to this PR, but comes from a business need identified recently

[btchip]

Ping. Rebased & modified according to review. Synaps is launching Anima soon (https://synaps.io/did-protocol/) and need this feature as soon as possible.

[krasi-georgiev]

IIUC this implements eth_decrypt and eth_getEncryptionPublicKey methods for the eth ledger app right?

[btchip]

@krasi-georgiev that's correct

[krasi-georgiev]

@btchip thanks,
will be really interesting in testing it, hope @cseguret-ledger finds the time to do the final review soon.

[firnprotocol]

hi @btchip + all, many thanks for the work. i noticed that MetaMask just deprecated this feature (i.e., for non-ledger accounts; it never supported it for ledger accounts).

can i ask whether the version/spec implemented here is identical to that which MetaMask used to support? if not, how does it differ?

it would be very nice if y'all could coordinate with MetaMask, in order to get (a consistently implemented) version of this feature implemented and non-deprecated across both normal and Ledger accounts in MetaMask. happy to help any way I can. thoughts?

[kdenhartog]

The reason Metamask deprecated this was because reuse of key material across different curves and for different operations (sign with secp256k1 and KEM with curve25519) goes against best practices in crypto and the design wasn't provably secure. I spent some time looking into this and it seems that this implementation is doing the same thing.

There is a few papers that have studied private key material reuse and found some combinations that are secure, but this one hasn't been studied. There's likely a simple way to solve this by inputing the node path data into an HMAC with different data to generate a different private key point, but we'd want to agree that's the path we want to take forward if that's how we'll go.

Who's best on the Ledger team for me to keep in contact with as I write up a new EIP to achieve some similar functionality?

[btchip]

I'll link this issue to our team cryptographer tomorrow

[rdubois-crypto]

Usually in Cryptography, it is recommended to avoid a duplicate use for the same key, for example the ANSSI recommands that no common key shall be used (here, page 21, first 'rule of use' https://www.ssi.gouv.fr/uploads/2014/11/RGS_v-2-0_B2.pdf, excuse my french).

In this case a master key must be used with a key derivation function (KDF) to derivate distinct keys.
A standardized KDF is described here, section 5.1 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf.

PRF may be instantiated using HMAC, thus the resulting construction is equivalent to your suggestion. Being compatible with the standard could benefit the reuse of existing functions in some existing libraries/HSM.