PROJECT: Collaborative Seed Recovery (CSR)

[shannona]

Collaborative Seed Recovery, or CSR, is a new system intended to automate the recovery of seeds and other sensitive digital data in a way that is safe, secure, and simple to use. It is not a methodology to prevent compromise, but simply to add resilience to recovery in the case of failure or loss.

CSR allows for the recovery of seeds and other secrets by dividing responsibility for recovery up between multiple devices, some (but not all) of which will be necessary for recovery. Its baseline recovery mechanism uses self-sovereign recovery, while more advanced scenarios allow for social recovery. Backup is meant to be largely automated, especially in the baseline scenario, while recovery may require some user intervention.

CSR is built using SSKR to lock crypto-envelopes of data and to allow recovery using a variety of authentication methods.

Please see the CSR Overview for more information.

TODO: Documentation & Prep

• [x] Decide Who Will Be Involved at Each Principal Company
  • [ ] Share Individual Goals
• [x] Decide Shamir or VSS
• [x] Write Use Cases
• [ ] Write Cryptographic Design
• [ ] Write System Requirements
• [ ] Spec Out Automated crypto-envelope with multiple types of SSKR Permits (2 of 3 + 4 of 9) + metadata
• [ ] Spec out related crypto-requests
  • [ ] Update any necessary papers, test vectors, etc
• [ ] Create Reference App for Sending SSKRs
• [ ] Write White Paper
  • https://github.com/BlockchainCommons/Gordian/blob/master/Docs/CSR.md
  • [x] Clearly define: CSR does not defend the use of your keys, it simply makes recovery easy and minimizes SPOFs in recovery.
  • [x] Lay out how it works
  • [ ] Describe why Proxy, Bitmark, and other parties would support it.
  • [ ] Build a roadmap for a fall release.
  • [ ] Preview how this will lead to CKM in 2023.

TODO: Specification Work

• [ ] Design Hash Inclusion Proof for Envelope

TODO: Level 0

• [ ] Design Level 0 of CSR
  • [ ] User makes no decisions
  • [ ] One Share is stored in iCloud
  • [ ] Information on location of other shares is stored in iCloud
  • [ ] Other shares are stored on remote sites in an automated way
  • [ ] User must do no auth to recover, other than verify their iCloud login
• [ ] Develop Level 0 of CSR

TODO: Level 1

• [ ] Design Level 1 of CSR
  • [ ] User makes one choice for a share to be given to someone
  • [ ] Option: offline
  • [ ] Option: given to a friend running an app
  • [ ] Option: given to an online service
  • [ ] At least two shares for automated recovery are deleted
  • [ ] Auth is required for new share management
• [ ] Develop Level 1 of CSR

TODO: Post-Release

• [ ] Write test cases
• [ ] Choose a branding name
• [ ] Decide if there is a seal for this

This is expected to be a joint project of Blockchain Commons, Bitmark, and Proxy with a planned start date around July 5th.

Essential Links: CSR

• CSR Overview
• CSR & CKM Use Cases
• CSR Intro for RWOT
• CSR Intro Poster for RWOT

Essential Links: SSKR

• SSKR for Developers
• SSKR Test Vector
• Developing SSKR Share Scenarios
• The Dangers of Secret-Sharing Schemes

Essential Links: URs

• Uniform Resources (UR)
• UR Type Definition for Sharded Secret Key Reconstruction (SSKR)
• URs: An Overview
• A Guide to Using URs for SSKR
• A Guide to Using UR Request & Response
• Crypto-Request Test Vectors

[simonratner]

Documenting decision on Shamir vs VSS for future generations: VSS is not baked enough just yet.

[simonratner]

@ChristopherA can you link in the resources section the last draft of crypto-envelope, and of crypto-request if there are changes in the works from what's currently published?

[ChristopherA]

@ChristopherA can you link in the resources section the last draft of crypto-envelope, and of crypto-request if there are changes in the works from what's currently published?

@wolfmcnally Wolf is working on more concise docs and test vectors for the SSKR crypto-envelopes now.

[ChristopherA]

I've posted Wolf's presentation on crypto-envelope as an excerpt from our kickoff call yesterday at https://www.youtube.com/watch?v=3jPJHSAObOM

[wolfmcnally]

Thank you everyone for your kind reception of my presentation on crypto-envelope. I hope you'll take a moment to respond to this small request:

Now that we've opened the conversation about CSR in general and crypto-envelope specifically, the main question we at Blockchain Commons have for the community is: how can we help you implement CSR in the most efficient and compatible ways?

In particular, for the technologies Blockchain Commons develops we produce many sorts of intellectual assets including high-level designs, detailed specifications, reference libraries, example code, documentation, explainer videos, command line tools, and reference apps. Specifically regarding CSR, we'd like to know what your teams would find particularly useful in the short to medium term? What would help speed decision making and adoption? What questions would you still like to get locked down before proceeding at full speed? We'd like to remove any remaining barriers you might be facing, so please let us know where we ought to be putting our efforts!

[ChristopherA]

Some feedback that I'm needing from the community (in particular Bitmark & Proxy) on requirements are:

• Do you want us to write a reference library that abstracts everything (in: seed & metadata, out: shares), or a lower-level library where you do it more yourself, or mostly the specs and test vectors as you'll be wanting to write your own libraries?
• If we write a reference library, do you want to minimize dependence on our other libraries? We can create a reference library without a lot of flexibility but conforming to the spec (and not incidentally much easier to review the code), or build it on our more comprehensive "future-proofed" libraries that may have a lot of baggage that you don't need.
• For the MVP, how important is crypto-request and crypto-response?
• Do we want in our MVP (i.e. this fall) to secure crypto-response? At minimum, to do this would require crypto-request to offer an ephemeral public key, such that they could know that that the crypto-response was from the party they sent it to under a TOFU (an ssh-like policy), and for future sessions with that part. Clearly having this in our MVP has limitations until we have to be careful about persistent public keys until we can offer more v2.0 identifiers (2023 at best). If you have confidence that you will be using secure channels in 2022, wrapping crypto-response values (such as the return of a share) might be overkill.
• Are there any requirements that we've missed?

-- Christopher Allen

[anhnguyenbitmark]

Do you want us to write a reference library that abstracts everything (in: seed & metadata, out: shares), or a lower-level library where you do it more yourself, or mostly the specs and test vectors as you'll be wanting to write your own libraries?

I want a high-level library that abstracts the most complicated things if it doesn't require many dependencies. To me, the design is lean and I don't need a lower level than that.

If we write a reference library, do you want to minimize dependence on our other libraries? We can create a reference library without a lot of flexibility but conforming to the spec (and not incidentally much easier to review the code), or build it on our more comprehensive "future-proofed" libraries that may have a lot of baggage that you don't need.

I'd prefer as minimal as possible for the library. I think what we will face soon is to support multiple platforms. Finding compatible libraries on the other platform is always a challenge.

[ameba23]

This looks great! As a social recovery project we would love to see more standards, and we would consider adopting some of these for our current project.

In case its useful to anyone here, here is a write up of our recent need-finding research with a bunch of projects in the Ethereum space.

Would love to see the crypto-envelope standard / implementation once its finished.

--peg (from darkcrystal.pw - i met some of you at RWOT8)

[ChristopherA]

What agenda items would you like to discuss in today’s CSR meeting? Any demos of progress to date?

[wolfmcnally]

Since the last CSR meeting I have separated the dependencies necessary for supporting all the crypto-envelope functionality into its own new Swift package: BCSwiftSecureComponents. This includes many fundamental types, including UR, EncryptedMessage, Signature, SSKRShare, SealedMessage, Digest, and of course, Envelope. The direct link for the SecureComponents documentation is here.

The package this functionality was previously embedded in, BCSwiftFoundation, now uses SecureComponents as a dependency. The difference in focus is that SecureComponents is about general, composable, repurposable functionality for encryption, signing, encoding, and related activities, while BCSwiftFoundation is about all that and functionality that supports cryptocurrency specifically, like seeds, HD keys, PSBTs, and so on.

Both packages include extensive unit tests, which are also vital for anyone who wants to translate them to other languages or platforms.

[wolfmcnally]

Another new deliverable in the SecureComponents package is a set of test vectors for crypto-envelope. Previously I did a set of test vectors specifically for crypto-envelope using SSKR as the application is particularly relevant to the conversation around CSR. These new test vectors cover a number of more general use cases for Envelope.

Please note that while I don't expect the general implementation of Envelope or Secure Components to change much, it is still considered a DRAFT and subject to change due to further review and feedback. Please do not deploy products using this technology just yet, and please let us know if you're eager to adopt aspects of it so we can finalize them quickly for you.

[wolfmcnally]

The thing I'm working on right now is a proposal for a command-line tool envelope which, like our other command-line tools seedtool and keytool, demonstrates, exercises, and facilitates the use of Blockchain Commons technologies. I expect the initial draft of this proposal to be ready by the time of our meeting later today and will put the link up here when it is ready for review.

The first version of envelope could easily be written in Swift and directly use BCSwiftSecureComponents as its primary dependency. Alternately, we could go ahead and create a C++-based bc-c-secure-components library and then base an implementation of envelope on that. The primary tradeoffs being: 1) Using Swift means faster delivery but only runs on macOS (well, Swift can also target Windows now, but I have no direct experience with that) or 2) Using C++ would mean slower delivery but also a ready-to-deploy C++ implementation of SecureComponents and a command line tool that can easily be deployed anywhere. A third option would be to do the implementation for both the library and tool in Rust.

We'd definitely like the community's feedback on these options.

[wolfmcnally]

Here is the link to the envelope CLI tool proposal I mentioned above.

[lord-max]

I might risk an off topic flag here since you discussing OSS protocol rather than a commercial product, yet FYI vault12.com had been running an app for number of years now doing exactly that with mobile devices as storage nodes. Owner creates a “Vault” out of friends & family phones, and sends them Shamir’s shards of the seed for safekeeping. We have some pieces open sourced already (About/Tech) along with a few white papers on internals, you might find something useful in there to help your design process.

[ChristopherA]

Our next CSR call is Thursday October 13th at 6pm PDT, using zoom (contact me on signal for zoom link).

Agenda includes:

• Some new parties joining us for the first time. Introductions and status updates
• @Wolf McNally doing a walk-through of an actual working API for CSR including all message passing done with envelopes.
• Some envelope docs and videos demonstrating elision and Merkle inclusion proofs. https://www.youtube.com/playlist?list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG
• Thoughts based on presenting these topics at the last #RebootingWebOfTrust.
• Discussion on next steps, including getting security architecture review, what languages does the community need to port envelopes and SSKR to, and do we want to pursue W3C or IETF standardization.

If you have something you'd like to add to the agenda, or an announcement or demo that you'd like to make during the meeting, add them here.

-- Christopher Allen