ability to use m of n seeds for ledger

[thedavidmeister]

update: app-seed-tool

Looks like an app might be accepted.

#54 (comment)

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 LedgerHQ/ledger-live-desktop#1722

• [ x ] I have checked this feature was not yet requested.

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:

• https://www.reddit.com/r/ledgerwallet/comments/65b1zi/secure_your_seed_with_seedsplit/
• https://www.reddit.com/r/ledgerwallet/comments/67dtte/why_isnt_the_backup_seed_encrypted/
• https://www.reddit.com/r/ledgerwallet/comments/75z38d/safe_way_to_store_the_seed_words/
• https://www.reddit.com/r/ledgerwallet/comments/6ez4qs/ledger_nano_s_seed_utility_app_released/
• https://www.reddit.com/r/ledgerwallet/comments/8yzpcg/help_with_seed_splitting_ideas/
• https://www.reddit.com/r/ledgerwallet/comments/77zd29/how_to_create_nofm_backup_of_seed/
• https://www.reddit.com/r/ledgerwallet/comments/6e4a9i/best_way_to_encrypt_recovery_seed_words/
• https://www.reddit.com/r/ledgerwallet/comments/a6vked/seed_splitting_worksheet_employing_shamir_secret/

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]

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

skim reading... looks pretty sweet

[thedavidmeister]

@jonathancross done

[jonathancross]

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]

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

[LukeWheeldon]

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]

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]

@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]

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]

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

[liondani]

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

[thedavidmeister]

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]

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

[ensingerphilipp]

This would be awesome if supported by ledger!

[IAmV0id]

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]

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]

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:
BlockchainCommons/lethekit#38

[thedavidmeister]

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

[jonathancross]

@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]

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

BlockchainCommons/lethekit#38

[jonathancross]

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]

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

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" 😞

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

[jonathancross]

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]

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

[aido]

This comment:
BlockchainCommons/lethekit#38 (comment)
and discussion here:
trezor/python-shamir-mnemonic#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]

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]

pretty please?

[aido]

pretty please?

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

[AnonymousAard]

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]

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/

[aido]

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]

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

Loading

[wisefool769]

@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]

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]

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

Loading

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

[wisefool769]

@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]

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]

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]

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]

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]

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]

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]

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]

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]

(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]

@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]

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.

[dzid26]

Scroll up this chat and see comments on how SSKR can do a BIP39 -> SSKR -> BIP39 roundtrip and SLIP-39 cannot. This is important.

Yes I know.

Regarding Airgap, as I said earlier:

I think AirGap is still at the phase of planning to implement SSKR.

Anyway, I just gave the reasons why we probably will not see user Shamir's backups. In a different world where SSKR was first - maybe, but we have slip-39 in the wild and the whole thing will be confusing to users.

....
Although he said this. - but SSKR for typical ledger 256bit seed will take 46 words per shard. They may as well give up on the round-trip and go with 512-bit slip-39 and 59 words for existing keys and 20 words for new keys. Neither is great on a tiny screen. Maybe that will be a selling point for Ledger Stax

[InfiniteQE]

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/

This link is now broken.

I have tried adding app-sskr-check to Ledger Live, but was unsuccessful as this requires a .json file

I've tried compiling from source on OSX + homebrew + Docker but this fails to complete as there is no equivalent cross platform compiler.

Updated :

I have managed to install app-sskr-check on my NanoS (firmware SE 1.6.0, Microcontroller 1.12) but the app Seed Utilities on the NanoS freezes after the "This app is not genuine" -> hard freezes on confirming "Open Application".

Can you advise why ? is it because I need to add a self signed certificate to NanoS, or because the firmware version is too old ? or perhaps because ledgerblue is outdated ?

Installation steps for MacOSX 11.7.7 M1 ARM :

• Install Parallels Desktop 18.3.1
• Create New Debian GNU Linux 11.3 ARM64, and run it, set a password.
• Launch Terminal
• sudo apt-get update && sudo apt-get upgrade
• Install docker as per https://docs.docker.com/engine/install/debian/
• sudo apt-get install docker.io docker-doc docker-compose containerd runc (I skipped the missing podman install)
• Install pip, virtualenv, HWI, ledger's udev rules, ledgerblue
• cd ~/Downloads
• sudo apt install python3-pip -y
• sudo apt-get -y install virtualenv
• git clone https://github.com/bitcoin-core/HWI
• sudo apt install libusb-1.0-0-dev libudev-dev python3-dev
• cd HWI
• pip3 install .
• cd ~/Downloads/
• git clone https://github.com/LedgerHQ/udev-rules
• sudo ./udev-rules/add_udev_rules.sh
• Install Ledgerblue as per https://pypi.org/project/ledgerblue/
• virtualenv ledger
• source ledger/bin/activate
• pip install ledgerblue
• SECP_BUNDLED_EXPERIMENTAL=1 pip --no-cache-dir install --no-binary secp256k1 secp256k1
• Clone app-sskr (where half of the install instructions came from!), and app-sskr-check (the app binary we want)
• git clone https://github.com/aido/app-sskr
• sudo apt-get install -y libc6-dev-armel-cross (this is not available on OSX homebrew)
• git clone https://github.com/aido/app-sskr-check
• Plug in your NanoS, Unlock, then in the Parallels popup choose connect NanoS to Debian, then in Parallels click the USB icon and make sure NanoS is ticked
• Check your Debian can connect to NanoS with ./HWI/hwi.py enumerate (you should see your NanoS listed)
• Now following the instructions on https://github.com/LedgerHQ/ledger-app-builder,
• Install Ledger-app-builder-lite with
• sudo docker pull ghcr.io/ledgerhq/ledger-app-builder/ledger-app-builder-lite:latest
• To compile the app in Docker (not 100% certain this is necessary)
• cd ~/Downloads/app-sskr-check
• sudo docker run --rm -ti -v "$(realpath .):/app" --user $(id -u $USER):$(id -g $USER) ghcr.io/ledgerhq/ledger-app-builder/ledger-app-builder-lite:latest
• BOLOS_SDK=$NANOS_SDK make (if everything has gone to plan, this step should be a success)
• To load the app-sskr-check on NanoS make sure you have enough space, and run
• sudo docker run --rm -ti -v "$(realpath .):/app" --privileged -v "/dev/bus/usb:/dev/bus/usb" --user $(id -u $USER):$(id -g $USER) ghcr.io/ledgerhq/ledger-app-builder/ledger-app-builder-lite:latest
• BOLOS_SDK=$NANOS_SDK make load
• Approve the app install on NanoS, you should see an new app icon appear for Seed Utilities
• exit to leave the # docker container to go back to terminal $

This is where I am stuck now, I when I attempt to run the Seed Utilities app, the NanoS freezes

[aido]

Hi @InfiniteQE ,

See my response here:

aido/app-seed-tool#8 (comment)

[InfiniteQE]

Thanks, with your assistance I have app SSKR Check loaded and running on a different NanoS with Firmware SE 2.0.0, this appears to be the minimum firmware version requirement.

[aido]

Phase 3 of Ledger's Open Source roadmap states that Ledger plan to provide tools that will allow an individual to implement their own shard backup provider. This may or may not make app-sskr-check obsolete.

The Ledger Recover white paper shows that Ledger will be using a variant of Shamir's Secret Sharing called Pedersen Verifiable Secret Sharing.. My concern here is that Ledger will be the only hardware wallet using this flavour of Pedersen VSS so it may not be interoperable. Other standards already exist but Ledger now seem to have created their own non-interoperable one. One of the reasons for choosing SSKR for the app was because of its interoperability.

I will be slowing down or even pausing development of app-sskr-check until I get a better idea of how Ledger plan to allow individuals implement their own shard backup.

[aido]

Almost 5 years after this issue was raised there may be hope that an application for generating Shamir's Secret Shares on a Ledger device may soon be available.

The Seed Tool application that I wrote for generating Shamir's Secret Shares was recently function tested by Ledger. Apparently this went well so the next step in the process is a security audit.

As I cannot bear the cost of an external audit myself Ledger are trying to find a way to take charge of the audit. They have a very limited bandwidth though, so need to find a slot.

[jonathancross]

@aido Great to hear!

I see you are not using SLIP-39 but rather Sharded Secret Key Reconstruction (SSKR) -- which is great!

At this point I no longer support the SLIP-0039 approach as they missed the # 1 use case users are asking for: splitting a seed phrase into a reasonable number of shares and having the option to restore the original seed phrase.

PS: we might want to rename this feature request or open a new one if SLIP-0039 is no longer the goal.