Ledger-compatible key derivation in subkey

[toholdaquill]

Background to current problem: The key derivation function Ledger uses is different from all other places (built on top of our Rust or JS libraries): it's a hardware limitation of Ledger's and there's little we can do about this.

Feature request: Add a Ledger compatibility layer in Subkey — basically a CLI mode where you type in a Ledger phrase and get back a json file with a key which you can import in other places.

The goal is to be able to use subkey to convert a Ledger seedphrase into a format you can later import into, say, PolkadotJS.

Why this feature request is important: If you're using Ledger to store DOTs, and there's been a Polkadot runtime upgrade incrementing the transaction_version, and the upgraded firmware still hasn't been reviewed, Ledger users will stuck with their funds inaccessible.

Having a "fallback option" of using subkey to derive the key from the seedphrase in a Ledger-compatible way and then put that into a JSON file you can import in PolkadotJS extension seems to be the most straightforward way to make those users unstuck.

[toholdaquill]

@kirushik

[kirushik]

To get more context on how Ledger does key derivation the discussion in Zondax/ledger-polkadot#39 would be a good start

[burdges]

We're only talking about hard derivations of course. What key types? All?

We could add ledger compatible hard derivations for ed25519 to https://github.com/w3f/hd-ed25519/ although admittedly that crate gets a bit sloppy, and as extra methods to https://github.com/w3f/schnorrkel/blob/master/src/derive.rs if applicable to sr25519.

There is zero chance I'll find time to look into this myself, but I'll happily merge PRs with reasonable code quality and test vectors.

[burdges]

I suppose subkey handles hashing the seed words itself, so maybe this needs to live there. If so, could maybe someone extract that functionality into a stand alone crate?

[Cryptomainly]

We're only talking about hard derivations of course. What key types? All?

We could add ledger compatible hard derivations for ed25519 to https://github.com/w3f/hd-ed25519/ although admittedly that crate gets a bit sloppy, and as extra methods to https://github.com/w3f/schnorrkel/blob/master/src/derive.rs if applicable to sr25519.

There is zero chance I'll find time to look into this myself, but I'll happily merge PRs with reasonable code quality and test vectors.

Could I ask is there a standard Kasuma Derivation Path? I am trying to import my account using a seed but the address generated by the new wallet is different and so I cannot access my funds? Thank you, Lee

[kirushik]

What key types? All?

We'd better check this in the Ledger app code, but AFAIR it only supports ed25519.

[burdges]

We'll happily place gitcoin bounties to pay for this once people can figure out what needs doing on what repo and make the issues.. assuming the person doing it is not a parity or w3f employee.

I should say "test vectors with citations" but of course the citation could be some script or something.

[nuke-web3]

People were recently asking in our public channels about a desire to recover seeds from ledger. I know there was also discussion around best practice for people to recover (with on-a-par short-term security guarantees^1) likely would be parity signer . I wonder if there should be a linked issue there? Possibly prioritized over subkey as the recovery via that route would be more secure (in theory)?

^1 assuming you have a new HDWallet on order and recover there, and then destroy the keys on the non-HDWallet device afterwards.

[burdges]

Nah. I doubt any particular platform warrants special focus here. If you're doing one-off recovery then you just buy a fresh laptop, install required software, airgap it before handling key material, and then transfer to some key on a cheaper more desirable platform. Zero reasons for destroying anything once you transfer the funds. If the funds are staked, then you'll want the laptop to stay airgapped for 28 days.

[nuke-web3]

Yes - a better answer for sure @burdges. Move the funds immediately, but that means you need to somehow relay that tx. How do you from an air-gaped machine with our present set of GUI tools?

That said, you may not be able to move those funds. Staking as you mention but many other systems may have you deeply locked up - in DeFi for instance, or a resisted DID that is irrevocable on a key derived from it. So some may choose to accept the risk of keeping the same seed, as it's difficult or impossible to migrate.

The scenario we want to enable is some safe way to very quickly use a Ledger seed to derive the keys you need, and IMHO asking them to get another laptop that is completely air-gaped is not a good solution and would be ignored by most. Nor is buying a phone just for this in that moment.

Best recommendation IMHO? have a backup device that is known to be untampered with to recover to. But not everyone will have that, and without a better way, will try stupid things that could get their seed revealed. I would hope that we decide to support better GUI first ways to do this.

[burdges]

I agree parity signer initialized from a ledger gives a reasonable backup strategy, likely simpler than thresholds, ala https://github.com/paritytech/banana_split or w3f/schnorrkel#11
but..

We take ages doing anything fancy with parity signer, parity signer devs need working crypto code before starting, and subkey makes debugging easier, so asking for parity signer first amounts to delaying the functionality everywhere.

How do you from an air-gaped machine with our present set of GUI tools?

Individual use USB sticks work fine for transporting signatures for recovery, which is the topic here. Almost anything competently designed has some revocation or key replacement path, perhaps with delays. I do know exceptions, but only rarely within this domain, and mostly low value keys.

We care about two DID designs, (1) validating public statements by polkadot/kusama stakers about polkadot/kusama governance, along with anything similar for parachains, and (2) ring VRFs that deSibel users. Anything attribute based like the W3C's Verifiable Claims projects, Sovrin, or hyperledger's identity stuff are highly unethical (no privacy, racist and classist). We should actively discourage anyone from building or using anything similar.