Shamir's secret sharing for seed

[wisefool769]

Our seed vault is only as secure as our seed backup itself. Currently, many crypto users keep the full seed backed up in their house -- which is vulnerable to physical attack. Others might naively split their seed up into pieces and store them in different places, which severely reduces the entropy of their seed if part of it is compromised.

The best practice for seed backup is to split your seed into n shares using Shamir's secret sharing -- such that you can recover the full seed if you recover any k of the n shares. In this case, k and n would be user-configurable with some sensible defaults. Then, you can keep one of the shares in a bank vault, one of them with a friend, etc etc.

There are a couple of interesting standards for how to do this, and Solana Mobile should probably adopt one of them rather than rolling their own. Relative to rolling your own, adopting a standard will

1. increase interoperability
2. make it more likely that key shares will have a working software implementation for recovery
3. make it friendlier for adoption by users of other blockchains.

There's this standard that is affiliated with Trezor, but it has some severe deficiencies: https://github.com/satoshilabs/slips/blob/master/slip-0039.md . Namely, you can't recover a BIP-39 mnemonic seed if you make a roundtrip, splitting it up and recovering it.

BCR-0011 is better, and I think this would be the way to go for Solana: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md . This is a discussion on the Ledger forum, which mentions this feature: LedgerHQ/ledger-nano-s#54 . Here's an example third-party implementation for Ledger: https://github.com/aido/app-sskr-check .

It would be awesome if you added an optional workflow during initial setup where a user can generate Shamir shares and validate that recovery is working properly -- while retaining the protections of the seed vault.

[0xBlockPay]

Hi :)
I created brach with a POC with Shamir secret sharing and AES for seedDetails encoded.
0xBlockPay@cd0e7e8#diff-334cb620844305ff880d3498303064b12a80c6ed1f765f2ae1385fcabe27a1e3

1. SeedDetails is converted to JSON String.
2. JSON String is encoded by AES with passphrase.
3. Encoded SeedDetails is splited on shards.

Shards can be converted to hex string format and exported out of the vault.
If you are interested in such a solution please write here :)

[wisefool769]

I think it's pretty important for the exported shards to use ie BRC-0011 . Among other things, this would mean the exported shards are human-readable, which really helps with error-checking relative to exporting hex.

[0xBlockPay]

Oki, I found good source of BRC-0011 code in java https://github.com/BlockchainCommons/bc-libs-java/tree/master and https://github.com/BlockchainCommons/jc-sskr.

[sdlaver]

Thanks @wisefool769 & @0xBlockPay. We're always considering what the right interfaces to expose for Seed Vault are, but one challenge here is that this PoC only applies to the SV simulator. On Saga (currently, the sole full and secure implementation of SV), the key material never leaves the TEE. It's a highly constrained runtime environment. Calculating Samir shares in the TEE is definitely possible, but we would require audited native libraries (C or C++) with minimal dependencies, or a direct reimplementation of the Shamir secret share calculation in the trusted applet source code (C). Also, it would require build-out of new Secure UI screens, which is a large undertaking.

We'll keep this issue open for feature request tracking purposes though. Thanks!

[0xBlockPay]

Hi :) thank you,
maybe it will be useful: please check this repo https://github.com/BlockchainCommons/bc-sskr-rust or https://github.com/BlockchainCommons/bc-sskr in C

Rust also is good for TEE app in Android https://android.googlesource.com/trusty/app/sample/+/refs/tags/platform-tools-35.0.1/rust-hello-world/