LedgerHQ / ledger-nano-s

Ledger Nano S, a personal security device from Ledger (blockchain / bitcoin / ethereum / FIDO)
Apache License 2.0
277 stars 40 forks source link

ability to use m of n seeds for ledger #54

Open thedavidmeister opened 5 years ago

thedavidmeister commented 5 years ago

update: app-seed-tool

Looks like an app might be accepted.

https://github.com/LedgerHQ/ledger-nano-s/issues/54#issuecomment-1854524464

https://github.com/aido/app-seed-tool

update: SLIP-0039 support

there is an emerging standard for shamir secret sharing for mnemonic codes SLIP-0039

https://github.com/satoshilabs/slips/blob/master/slip-0039.md

it would make sense to adopt the standard here

see the comments below for more information

original request

originally posted https://github.com/LedgerHQ/ledger-live-desktop/issues/1722

i would like to be able to setup an m of n seed for my ledger using shamir secret sharing using a new, dedicated application on the ledger

i found this repo: https://github.com/oed/seedsplit

and these reddit threads:

but all the options offered require setting up an airgapped device and running 3rd party unaudited code

it makes sense to me that m of n seeds be able to be generated by the ledger itself, using audited code, without the seed needing to leave the device

without this option we must choose between a risky technical process or a physical risk in the storage of the seed

an official m of n seed would facilitate much more secure physical setups for many more users

i understand that this is a fairly advanced feature for most people, so probably shouldn't be the default behaviour, but would help others sleep better at night :)

ideally, once the m of n seed is created on the ledger, the seeds can be stored in physically separate locations, then the ledger wiped to remove even pin access, producing a very secure cold wallet

Part of the application

new application for ledger

thedavidmeister commented 5 years ago

i did see some social medias around SLIP-0039 but am not familiar with it

skim reading... looks pretty sweet

thedavidmeister commented 5 years ago

@jonathancross done

jonathancross commented 5 years ago

Thanks @thedavidmeister I'm going to remove my comments to help reduce the noise in this feature request. Feel free to do the same and remove everything not directly related to the request. Cheers!

jonathancross commented 4 years ago

Support is growing, there is now a browser based implementation.

LukeWheeldon commented 3 years ago

Hello - I understand this is a complex request but it would be great if someone could post an update on the current status, what are the barriers to implementation if any, etc. Thank you.

thedavidmeister commented 3 years ago

yknow... it would almost be worthwhile as a standalone small device that performs cryptography on inputs and throws away the outputs after use or when powered off

basically just to do the compute for paper wallet management, with no networking

jonathancross commented 3 years ago

@thedavidmeister : Let's try to keep this focused on one topic (getting an app for SLIP-39). Devs are unlikely to even read (much less work on) a long feature request full of hopes, dreams and opinions.

That being said, a wallet restored from SLIP-39 mnemonics on a Ledger Nano X, used to sign and then wiped is already what you are talking about.😉

thedavidmeister commented 3 years ago

devs aren't going to ignore a good idea just because there is a little noise in a github thread, if anything they tend to ignore 'stale' issues

securitygeneration commented 3 years ago

I'd also be interested to see the ability to do n-of-m secret sharing

liondani commented 3 years ago

I wonder how many buy a Trezor just for that backup option?

thedavidmeister commented 3 years ago

https://www.youtube.com/watch?v=pNK6UaZ6XjI short discussion re: multisig from around 30 mins in

still... why no protection on the seed itself?

liondani commented 3 years ago

Any ETA on when shamir secret sharing will supported? Why so much of delay?

ensingerphilipp commented 3 years ago

This would be awesome if supported by ledger!

IAmV0id commented 3 years ago

Any update on Shamir backup implementations? Devs said on the subreddit that they're working on the UX, but that was 6 months ago.

thedavidmeister commented 3 years ago

other than a Trezor, has anyone used a hardware device that does shamir?

partly because it's good to reference prior art when developing something new here, and partly because i want to buy something right now and it's been 2 years with no meaningful developments from ledger here

aido commented 3 years ago

Hi.

There seems to be some recemt discussion on this issue here: https://www.reddit.com/r/ledgerwallet/comments/mcltmd/can_we_get_an_update_on_the_slip0039_support_i_am/

Note: https://github.com/BlockchainCommons/bc-lethekit/issues/38

thedavidmeister commented 3 years ago

is there an option for m of n seeds that doesn't have vendor lockin?

jonathancross commented 3 years ago

@thedavidmeister what vendor lock in are you talking about? There are Open Source tools for working with the SLIP-39 shards, recreation of the wallet seed, etc.

thedavidmeister commented 3 years ago

@jonathancross from the thread linked in the comment above mine:

Screenshot from 2021-07-20 10-51-11

https://github.com/BlockchainCommons/lethekit/issues/38

jonathancross commented 3 years ago

It is really unfortunate that they did not make the seed phrases compatible between the two standards.

I don't see this as vendor lock-in though -- all code is Open Source as well as the SLIP-39 spec. There are several software implementations as well (eg Electrum). So nobody is locked into using something from 1 company, but we are lacking hardware device support.

This feature request is to get an app for the Ledger that supports SLIP-39 so users have multiple hardware devices that support it (reducing vendor lock-in risk).

It may turn out that the community comes up with a better specification than SLIP-39 for doing sharding, but this is the best I know of so far.

thedavidmeister commented 3 years ago

@jonathancross you telling me what my own feature request is for? :laughing:

whatever you call it, "not interoperable", "vendor lockin", @btchip the cofounder of ledger is publicly stating SLIP-39 will not be supported any time soon because of this compatibility issue

if SLIP-39 is the best option great, but i don't really care as long as i get any reasonable airgapped "m of n" option

it's been 2.5 years already with "no progress" :disappointed:

frigging ridiculous to go to all this effort and have my seed sitting around in plain text somewhere

jonathancross commented 3 years ago

reasonable airgapped "m of n" option

Yeah I understand and agree!

IMO, It seems like the future is multisig for m of n. Once Taproot is activated, they won't be any more expensive or less private than a normal single key transactions with the added security benefit that no single device ever holds all the key information.

thedavidmeister commented 3 years ago

i pretty much only use ethereum, looking for a hw level chain agnostic solution here :)

aido commented 2 years ago

This comment: https://github.com/BlockchainCommons/lethekit/issues/38#issuecomment-967242980 and discussion here: https://github.com/trezor/python-shamir-mnemonic/issues/40 seems to reach the conclusion that SLIP39 does not support BIP39:

But the same comment also proposes a BIP39/SLIP39 integration that uses BIP39 mnemonics for Shamir's algorithm instead of SLIP-0039 master secrets: https://github.com/alandefreitas/python-shamir-bip39

jonathancross commented 2 years ago

SLIP39 does not support BIP39

Correct, SLIP39 isn't designed to restore a BIP39 seed phrase. I don't know how SL could have overlooked this as THE feature most important to users.

cruzdanilo commented 2 years ago

pretty please?

aido commented 2 years ago

pretty please?

If not SLIP-0039 there's always BCR-0011.

AnonymousAard commented 2 years ago

Has there been any progress on this? It will likely be the deciding factor on my next hardware wallet choice.

In the meantime I have queried this in the subreddit as a possible workaround for SLIP39 on the Ledger:

Any reason not to use this as SLIP39 solution for Ledger?

aido commented 2 years ago

Any reason not to use this as SLIP39 solution for Ledger?

See here: https://www.reddit.com/r/ledgerwallet/comments/ibkls4/does_ledger_have_plans_to_implement_shamir_secret/

and here: https://github.com/BlockchainCommons/lethekit/issues/38

and maybe also here: https://www.reddit.com/r/ledgerwallet/comments/vmk3gw/splitting_bip0039_mnemonic/

AnonymousAard commented 2 years ago

Any reason not to use this as SLIP39 solution for Ledger?

See here: https://www.reddit.com/r/ledgerwallet/comments/ibkls4/does_ledger_have_plans_to_implement_shamir_secret/

and here: BlockchainCommons/lethekit#38

and maybe also here: https://www.reddit.com/r/ledgerwallet/comments/vmk3gw/splitting_bip0039_mnemonic/

Those links were helpful, thanks. One of the Ledger founders also just replied on reddit to say there would likely be an update.

In the meantime, can you please tell me if you know of some way I can apply one of the SLIP39 shards <--> BIP39 entropy <--> BIP39 mnemonic workaround methods for Ledger so that it will also store a BIP39 passphrase, or good practice for using a passphrase with these backups? I could manually store my passphrase with each shard though it seems like there must be a better way.

aido commented 1 year ago

There seems to be very little progress on this so I have started working on a Ledger app for SSKR. See here: SSKR Check App

The plan is to have an app that builds upon the recovery check app adding some SSKR options. One opton will be to take a BIP-39 phrase as input, verfy that input against the master seed on the Ledger device and if the BIP-39 input is valid then the Ledger device will output SSKR byteword shares i.e. BIP-39 to SSKR conversion. Another option will be to validate SSKR byteword phrases against the master seed of the Ledger device. With these options the Ledger device will be able to check, generate and use SSKR phrases to restore a Ledger device similar to how the recovery check app does with BIP-39.

aido commented 1 year ago

Hi,

First release of the SSKR Check App is now available. As mentioned above I built this app using the recovery check app as a base. I have added a "Generate SSKR" option to the 'BIP39 Check' menu. This will generate a group of 2-of-3 Shamir's Secret Sharing (SSS) shares. This app takes advantage of SSKR's ability to do a BIP39 -> SSKR -> BIP39 roundtrip which Trezor's SLIP-0039 is unable to do. The user is prompted to enter their BIP39 recovery phrase, this is then validated against the Ledger devices root key and if it is valid the app will then generate the Shamir Secret Sharing shares.

The app has been tested using Speculos on Nano S, Nano S+ and Nano X. Using the seedtool-cli confirms that SSKR shares generated by the app can all be converted back to BIP39., confirming the BIP39 -> SSKR -> BIP39 roundtrip.

Next step is to add another menu to the app that prompts the user to confirm their SSKR shares against the Ledger devices root key and then generate the BIP39 phrases needed for device recovery,

See the app TODO list

mkoese commented 1 year ago

HI @aido, are you working together with the Ledger team?

aido commented 1 year ago

are you working together with the Ledger team?

No, not at the moment. I wanted the app to be more or less working fully before approachig the Ledger team.

With the latest release v1.1.0 the app is now woking the way I want and tested on Nano S, Nano X and Nano S Plus. I will look to see what is involved in submitting an app to Ledger for approval...or rejection :-).

Further improvements can be made e.g. changing the m-of-n threshold dynamically rather than the current hardcoded 2-of-3 threshold. But for now hopefully the app is good enough for submission to Ledger.

aido commented 1 year ago

The latest v1.2.0 release of the app-sskr-check Ledger app adds the ability to set the threshold and number of Shamir's Secret Shares generated. The app is now feature-complete.

Here's a pretty little diagram showing the flows through the apps menus:

---
title: SSKR Check App Flow
---
flowchart LR
    1 --- 2 --- 3 --- 4
    subgraph 1[BIP39]
        direction TB
        1.1[Check BIP39]
        1.1 --> 1.2.1[Enter 12 Words] --> 1.3{Validate BIP39 Phrases}
        1.1 --> 1.2.2[Enter 18 Words] --> 1.3
        1.1 --> 1.2.3[Enter 24 Words] --> 1.3
        1.3 --> |Valid BIP39| 1.4
        1.3 --> |Invalid BIP39| 1.3.1[Quit]
        subgraph 1.4[Generate SSKR Shares]
            direction TB
            1.4.1[Select number of shares] --> 1.4.2[Select threshold] --> 1.4.3[Generate SSKR Shares] --> 1.4.4[Display SSKR Shares] --> 1.4.5[Quit]
        end
    end
    subgraph 2[SSKR]
        direction TB
        2.1[Check SSKR] --> 2.2[Enter SSKR Shares] --> 2.3{Validate SSKR Shares}
        2.3 --> |Valid SSKR| 2.4
        2.3 --> |Invalid SSKR| 2.3.1[Quit]
        subgraph 2.4[Generate BIP39 Phrases]
            direction TB
            2.4.1[Generate BIP39 Phrases] --> 2.4.2[Display BIP39 Phrases] --> 2.4.3[Quit]
        end
    end
    subgraph 3[Version]
        direction TB
        3.1[Version]
        end
    subgraph 4[Quit]
        direction TB
        4.1[Quit]
    end
wisefool769 commented 1 year ago

@aido Great work! do you reckon your app is ready for use? I'm shocked that it's only got 2 stars (one of which is me).

As I understand it, your seed will not leave your Ledger. However, for the typical user, it would appear insane to install a little-known third-party app to perform this function. A clear explanation of installation instructions and threat model would go a long way -- including things like how to verify the hash on the binary etc.

aido commented 1 year ago

Hi @wisefool769 ,

do you reckon your app is ready for use?

Yes, I think my app is ready for use. I am still making small tweaks and minor changes from time to time but nothing that will break or change functionality too much

As I understand it, your seed will not leave your Ledger.

Correct

However, for the typical user, it would appear insane to install a little-known third-party app to perform this function.

I agree. I have announced the app on Ledger's Discord server and this has been passed on to Ledgers firmware team. I have also filled out Ledger's app submission form but do not expect much to come from this. I have also had some feedback from Blockchain Commons, the creators of SSKR. They may review and test but we'll see: https://github.com/orgs/BlockchainCommons/projects/7?pane=issue&itemId=26620615

A clear explanation of installation instructions and threat model would go a long way -- including things like how to verify the hash on the binary etc.

Threat model? ... hmmm, one identified threat is "never trust an app written by a random guy on the internet". :-) But you've obviously spotted that one already. The compiled binaries are provided on the release page and the code freely available for review. The code that built the binaries is viewable by all to see that nothing nefarious is being done; if you can understand the code. The binaries were automatically built using GitHub Actions and a security scan also performed by CodeQL. Binaries and code provided as is. A trusted, reputable third party is free to review the code if they wish. Hashes are created automatically by the Ledger build process but to be honest, I haven't yet figued out what the hashes are as they don't seem to be for the binaries. The hashes are also on the release page. If after all that you still wish to load the app on your device there are various instructions on the internet for "sideloading" an app onto a Ledger device. There is also this instruction on the Ledger dev website: https://developers.ledger.com/docs/embedded-app/load-linux/

aido commented 1 year ago

To add, having gotten Shamir's Secret Sharing working on Ledger devices I now plan to expand the app-sskr-check app and turn it into a "Seed Utility" tool.

The app currently does BIP39 check, SSKR Check and SSKR Generate. In the future I also plan to add BIP85 funtionality so I can generate something like this.

---
title: One Seed to rule them all - Multi wallet
---
flowchart TB
    1.1 --> |Backup| 1.2
    1 --> |BIP85 Child 0| 2.1.1
    1 --> |BIP85 Child 1| 2.1.2
    1 --> |BIP85 Child 2| 2.2.1
    1 --> |BIP85 Child 3| 2.2.2
    1 --> |BIP85 Child 4| 2.3.1
    1 --> |BIP85 Child 5| 2.3.2
    1 --> |BIP85 Child 6| 2.4.1
    1 --> |BIP85 Child 7| 2.4.2
    subgraph 1[Parent]
        direction TB
        1.1[Root Seed]
        subgraph 1.2[2-of-3 Shamir's Secret Shares]
            direction BT
            1.2.1[Share 1]
            1.2.2[Share 2]
            1.2.3[Share 3]
        end
    end
    subgraph 2[Children]
        direction TB
        subgraph 2.1[Cold Wallet]
            direction LR
            2.1.1[BIP39 #1]
            2.1.2[Password #1]
            end
            subgraph 2.2[Hardware Wallet]
            direction LR
            2.2.1[BIP39 #2]
            2.2.2[Password #2]
            end
            subgraph 2.3[Lightning Wallet]
            direction LR
            2.3.1[BIP39 #3]
            2.3.2[Password #3]
            end
            subgraph 2.4[Phone Wallet]
            direction LR
            2.4.1[BIP39 #4]
            2.4.2[Password #4]
            end
    end

But that is off topic and beyond the scope of this issue.

wisefool769 commented 1 year ago

@aido What would your proposed "Seed utility tool" offer over something like the Seedtool CLI, which has had a few more eyes on it.

aido commented 1 year ago

I haven't thought that far ahead. But yes, maybe a subset of the tools provided by Seedtool CL ... but on an airgapped, secure device/hardware wallet.

wisefool769 commented 1 year ago

Oh I see, your "utility tool" would still run on-device. That makes sense. Also @aido, this discussion is pretty funny in light of recent moves by Ledger.

aido commented 1 year ago

Also @aido, this discussion is pretty funny in light of recent moves by Ledger.

Indeed it is. It would seem by the level of negative feedback on Reddit, Discord etc. that Ledger may have shot themselves in the foot with this one.

app-sskr-check mitigates nearly all the concerns people seem to have about Ledger Recover. In light of Ledger's latest move I may have to reconsider app-sskr-check and my approach to Ledger in general.

thedavidmeister commented 1 year ago

Here are some insane remarks from Pascal Guethier, CEO of ledger, for anyone reading this who would like context on why this thread is now "funny"

Ledger is preparing to launch a new service called Ledger Recover that splits a wallet recovery phrase—basically, a human-readable form of the private key—into three encrypted shards and distributes them to three custodians: Ledger, crypto custody firm Coincover, and code escrow company EscrowTech.

If somebody loses their recovery phrase, two of the three shards can be combined—pending an ID check—to regain access to the locked funds.

Essentially, Ledger Recover is an additional safety net; for the price of $9.99 a month, it takes the jeopardy out of crypto’s version of stuffing dollars under the mattress.

https://www.trustnodes.com/2023/05/16/ledger-update-will-send-out-the-private-key

I'm genuinely wondering what the point of a Ledger even is now. Even if I don't enable the "service", nobody else knows whether I did or did not, so could reasonably assume it's worthwhile to attempt to steal my identity as long as they believe I have funds on a Ledger device.

The side channel attacks on Trezor hardware always spooked me, but here we have closed source firmware that can export private keys, from a company that is openly selling corporate access to private keys, and (in my experience) periodically the devices seem to inexplicably brick themselves without firmware updates.

@aido i really appreciate your hard work on this one ... where can we go from here? 😞 I'm tempted to just close this issue out and migrate to Trezor before this "convenience" becomes "default" and then "paywall".

It's really sad that Ledger must have implemented SSS or something like it in the process of releasing this garbage, but still don't seem to be offering a simple M of N option for physical seed backups.

I guess it will be even more difficult to get approval from that app submission now, if it is perceived as a competitor to a subscription service offered by the same company.

aido commented 1 year ago

Hi @thedavidmeister,

I am not sure where to go from here either. I suggest leaving this issue open for now until the dust settles.

aido commented 1 year ago

I may start looking into AirGap insted of continuing with the sskr-check app.

AirGap implements SSKR AND BIP85 which are two of the things I was trying to implement in a Ledger app ... until yesterday's announcement from Ledger,

dzid26 commented 1 year ago

I think AirGap is still at the phase of planning to implement SSKR. Their current Shamir implementation is probably incompatible with SSKR and I don't see signs of progress.

Ledger still has the advantage of supporting certain good coins Airgap doesn't, e.g Monero and whatnot... I am thinking Trezor would be more natural to move to. And just be aware of the possibility of glitch attacks. Annoyingly Trezor doesn't support SSKR

aido commented 1 year ago

Ledger are using Shamir's Secret Sharing as part of their Ledger Recover serrvice, I saw a comment somewhere that eventually the shards generated for Recover may be backed up using other methods. I really, really hope Ledger are not creating their own version of SSS that only works on Ledger devices i.e. vendor lock in. Ledger really should use an open, interoperable standard for SSS but I know they won't.

dzid26 commented 1 year ago

(Ignoring the fact that we have trust issue with Ledger having access to keys) the situation is still not great and I can see why they didn't make it the consumer feature - because:

  1. if they follow true slip39 then existing customers would need to use 59 words shards
  2. If they follow SSKR, then mnemonics are not compatible between two major hardware wallet manufacturers and some people will fund wrong wallets and will loose or think they lost money

As far as I can tell there is no easy way to discriminate between the two backups. ...Correct me if that is not the case, because it would be ideal to support two standards and semi-automatically choose between them during the restore process.

EDIT: seems like SSKR always starts with tuna acid epic.

aido commented 1 year ago

@dzid26 As SSKR is an improvement on SLIP-39 and is interoperable and supported by others wallets (e.g. AirGap) I do not see the need to support SLIP-39 also. Scroll up this chat and see comments on how SSKR can do a BIP39 -> SSKR -> BIP39 roundtrip and SLIP-39 cannot. This is important.

aido commented 1 year ago

EDIT: seems like SSKR always starts with tuna acid epic.

Yes, that is part of the CBOR header that identfies the data as a SSKR share.