Deterministic hardware wallet appPrivateKey generation

[kyranjamie]

To support hardware wallets in the Hiro Wallet, with the same functionality we do software wallets, we must return an appPrivateKey to a given app when authenticating.

This key is used by app to:

• Encrypt/decrypt data stored on Gaia
• Sign transaction request payloads
• other uses cases…

For software wallets, the appPrivateKey is derived from the "identities keychain", or the dataPrivateKey, from the m/888'/0' derivation path.

// Pseudo appPrivateKey generation
const salt = sha256(dataPublicKey);
const appPrivateKey = identitiesKeychain.deriveHardened(indexInferredFrom(sha256(salt + appDomain)));

See @stacks/wallet-sdk implementation →

This implementation relies on the dataPrivateKey, which is not accessible on a hardware wallets. Consequently, we need to consider alternate means to deterministically deriving such a key.

cc/ @kantai @zone117x @markmhx @andresgalante @beguene

[friedger]

@kyranjamie Which restrictions apply to hardware wallets? Which keys are available? Do different wallets support different derivation functions?

[kyranjamie]

Currently, there's a bug that prevents pulling keys from the m/888'/ derivation path.. There's a sign_msg function that uses a prefix, and it's likely that they'll add an arbitrary msg signing function, that we may use for this.

[kyranjamie]

📞 2022-04-14

@friedger @janniks @markmhx @aulneau and I had a call to run through the current approach to supporting hardware wallets, where we also discussed some ideas of how to support Gaia and appPrivateKeys.

Creating an accompanying software private key

• Shared in a similar fashion to current software wallets
  • Requires either:
    • user saving a separate mnemonic phrase
    • a method of deriving a deterministic key from some signing operation
• Managing Gaia encryption/decryption via the wallet methods
  • No key needs to be shared in the first place
  • A new proposal, requires SIP

Possibly deprecating auth v1

• Auth code is old, and not particularly well defined
• Has only partial use across the ecosystem
• Ethereum land uses message signing for auth
  • EIP-4361 defines an auth structure using a signed message in a given format
  • A SIP could define a similar auth scheme for Stacks
• Supporting v1 auth on Ledger requires signing a hash support
  • Zondax has already started looking into this implementation
  • @markmhx to get up to speed on Zondax Slack comms
  • Decision to be made whether to proceed with efforts to support v1 auth on Ledger sans-appPrivateKey
  • Hash signing support for Ledger may well have other utilities

RPC direction for Wallet protocol SIP

• Need alignment/collaboration on SIP to proceed with RPC-style API
• Hiro Wallet to implement equivalent of eth_requestAccounts

[friedger]

Re deprecating auth v1, 0.22.3 has support for hash signing.
SIP-018 lays the foundation for these auth message structures (stacksgov/sips#57)

How is v1 (signed JWT/stacksgov/sips#50) different to an alternative auth protocol?