Seed phrase backup using Yubikeys

[GENERAL] Name and surname of main applicant

[GENERAL] Are you delivering this project as an individual or as an entity (whether formally incorporated or not)

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

[GENERAL] Summarize your solution to the problem (200-character limit including spaces)

This proposal protects keys from physical loss, theft, fire, flood, and war by encrypting them with HW-bound keys on multiple Yubikeys, then replicating them geographically. The MVP is an Android app.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”

No dependencies.

[GENERAL] Will your project’s output/s be fully open source?

[GENERAL] Please provide here more information on the open source status of your project outputs

I answered "no" so that I'm not committed to it, but I do want to open source most or all of the code. I'm learning in this space and actively seeking advice on how to run a company based on open source.

My current thinking is that source is likely to be dual licensed (possible example: GPL + commercial) and possibly include restrictions on companies like AWS running the backend services (example: Business Source License). It will also be Redhat-like, where logos, trademarks, etc. are not open source.

Overall, I want all source to be open source, but I also want to create a sustainable business so the product's evolution becomes self-sustainable for the long-term. This will help the product become better over time and reach as many people as possible.

[SOLUTION] Please describe your proposed solution.

Big idea

I want to make self-custody of private keys for cryptocurrencies and digital identities easier by making physical security of seed phrase backups easier. Users encrypt their backups using hardware-backed keys on three or more low-cost hardware security modules (for now: Yubikeys), then use multiple encryption (think Russian nested dolls...) to ensure only certain combinations can recover the original seed phrase. Proposed combinations:

• Any one Yubikey + passphrase
• All Yubikeys + no passphrase (passphrase recovery)
• (Future) Any one Yubikey + no passphrase (forgotten) + 2 of 3 centralized recovery services verifying your identity*
• (Future) No Yubikeys (all lost) + Passphrase + 2 of 3 centralized recovery services (in separate legal jurisdictions) verifying your identity*
• (Future) No Yubikeys (all lost) + No Passphrase (forgotten) + 3 of 5 centralized recovery services (in separate legal jurisdictions) verifying your identity*

By encrypting the seed phrase with keys held on Yubikeys, it reduces the amount of physical security required to secure seed phrases. For example, you could have a family member hold a copy for you without worrying that they could recover your seed phrase.

* The combinations are highly adaptable. The centralized recovery options are not required, but I think there's a path to making that work with a reasonably low risk to self-sovereignty (for many people's needs, at least.) and also in a way that protects users from themselves (even if they lose one or more Yubikeys.)

The MVP is a mobile app, but long-term (not part of this initial proposal) I want to run this on secure hardware, possibly on a new generation of hardware wallets (made by us, or others, as an open standard.)

What I've built so far

This idea hinges on giving users low-cost hardware security modules. To make the MVP easier, I'm starting by using the Yubikey 5 series' support for the OpenPGP card standard. This means I don't need to build new hardware.

I've built the backend code to communicate with Yubikeys over NFC and talk to the OpenPGP card application. I can configure the Yubikey, generate keys (X25519 keys generated in hardware, unable to be exported), and use the public key to encrypt data only the Yubikey can decrypt. I can also decrypt the data with the Yubikey. To encrypt, I'm using libsodium, X25519, and XChaCha20-Poly1305-IETF.

This was the largest technical hurdle to clear. It works end-to-end: I can communicate with Yubikeys, I can communicate with the Yubikey OpenPGP application, I can encrypt data, then decrypt it with keys held in Yubikey hardware. Next, I can add support for multiple Yubikeys, then build out the rest of the app according to the prototype: https://wipcrypto.com/catalyst/prototype-mobile.

Where you can find and play with it to verify

For the latest dev build and instructions on how to test, please see https://wipcrypto.com/catalyst/links.

What I intend to do as a result of this proposal

I'll be building an MVP capable of backing up seed phrases, encrypted with keys held on 3 (or more) Yubikeys. The initial designs can be seen in the Figma prototype here: https://wipcrypto.com/catalyst/prototype-mobile.

In-depth

Sometimes I think about a world where crypto wins. Where all value is tokenized on blockchains. What if my mom (not tech savvy) needed to secure her entire retirement savings? Would she be able to securely handle her seed phrase, when no one could help her if she lost it? What if someone broke in to her house and took her seed phrase? What if her house burned down? What if war erupted and she had to flee her home at a moment's notice, never to return (e.g. Ukraine, Gaza, etc.)? At such a difficult time, would she also lose access to communication apps and social media accounts attached to her digital identities/DIDs? The result would likely be permanent loss, with no recourse.

At global scale, all of these events happen every day. Without solving for them, self-sovereign key management (and decentralized identity) is incomplete and--in my opinion--unlikely to succeed.

While some of these are preventable with steel/titanium backup plates, this is highly technical and still requires the user to properly conceal their backups.

I strongly believe the lack of simpler and safer key management schemes will prevent mass adoption of crypto and decentralized identity. Solved well, it will enable them.

This project aims to:

1. Make it safe to replicate seed phrases online by encrypting them with 256-bit keys containing their full entropy; as opposed to the reduced entropy of password-based key derivation.
2. Solve the loss and disclosure of those keys by storing them on secure hardware and giving the user multiple copies that they can distribute among multiple physical locations.
3. Solve extreme edge cases (displacement due to war, etc.) by creating a system that's configurable enough to support (some day, not part of this proposal) centralized recovery, social recovery, and inheritance planning, while keeping a high degree of self-sovereignty.

There is much renewed interest in this space recently, with varying degrees of self-sovereignty built into their designs. This proposal intends to build a solution that is maximally self-sovereign and useful in a multi-chain world, with no need to trust anyone, even family/friends/neighbors/banks/etc. who might physically store one of your Yubikeys for you.

By funding this proposal, the Catalyst project can help get this fledgling idea to market, potentially enabling self-sovereign key management for millions of users in the future.

[IMPACT] Please define the positive impact your project will have on the wider Cardano community.

My goal is to increase the number of people capable of self-sovereign key management, from millions today to billions tomorrow. My hope is that this project will be a catalyst (pun intended) that enables millions of people to enjoy the benefits of the entire Cardano ecosystem.

Stated another way, my hope is for this project to lower the barrier to entry of self-sovereignty on the Cardano blockchain, expanding the top of the funnel.

Stated a third way, I want my mom to be able to securely--and self-sovereignly--use Cardano. There are currently too many sharp edges around key management (and especially physical security) for that to happen.

[CAPABILITY & FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

I've been a software engineer for about 15 years, working at a variety of startups as well as Amazon.

At Amazon, I worked on the app for Amazon Care, a HIPAA-compliant healthcare service, where privacy and security are critical. As part of that work, I designed and implemented on-device encrypted caching, passing security review on the first try (when common thought was that no such system could pass.)

At Amazon, I also I created a scalable internal-facing Maven proxy service that helped Android developers work more effectively. There was much pushback early on around the security of such a system (vs using Amazon's internal Brazil build system). I successfully built a multi-AZ system with a minimal attack surface that that passed review by Amazon's AppSec group, then passed pen-testing by an external vendor, with zero findings. This service has been in reliable service at Amazon for about four years.

Not that I am perfect, especially among a group at IOG who routinely use formal verification. However, I do have a reasonable background of secure and high quality implementation and using good judgement with regard to cryptography.

I also have a high bar for user experience, and a deep conviction around the importance of self-sovereignty. This proposal is a culmination of these qualities, and my own conviction 1) that key management is not "solved" yet, 2) that the user experience of writing down seed phrases is not ready for mass adoption, and 3) that a secure alternative is possible.

[Project Milestones] What are the key milestones you need to achieve in order to complete your project successfully?

Milestone 1: Initial app functionality

Deliverables:

• Non-production build of Android app that allows walking through setup of Yubikeys and encryption/decryption of simple text fields to show encryption works end-to-end.

AC:

• An early, non-production build for Android. that allows for setting up new Yubikeys and a password, then allows for encrypting a message locally (of any sort, not necessarily a seed phrase), then using the password and any 1 of N Yubikeys to decrypt the message. Does not need to persist data locally at this stage.
• Yubikeys configured securely. Set pins so they're not using the default, require PINs to use key derivation (KDF) so they are not transferred over the air, set max pin attempts, use Curve25519, etc.
• Only basic error handling. Basic error dialogs that exit setup early (without recovery logic) if: A Yubikey is already initialized. A Yubikey fails verification of attestation keys. Don't allow setup to continue if user does not have at least 3 uninitialized Yubikeys.

Not part of AC: Account registration. Syncing of data to a backend. Backup file (or API) format specification. Recovery if password lost. Error handling if a Yubikey is already in use.

Milestone 2: Continued app functionality

Deliverables:

• File format draft specification containing details of the file format.
• Proof that design services have started - Could be a signed contract, email, etc.
• Proof that cryptographic consulting has started - Could be a signed contract, email, etc.
• Non-production build of Android app that generates all the info that will be required to generate an account (random account ID, etc.), even if it's not connected to a real API.

AC:

• File format draft specification complete. When backing up to a file, we need to have a file format that is stable and forward-looking to support future features. It must not be tied to Yubikeys. It must support using >3 devices. It must support using public keys that aren't from HSMs (for future centralized recovery options). It must support flexible configurations (e.g. 1 of N yubikeys + password / N of N yubikeys + 1 centralized recovery (if password forgot) / 1 of N + 3 centralized recovery services (if password forgot) / etc. It must be flexible enough to support hybrid encryption for post-quantum encryption. It must be implementable without excessively large libraries so clients can read it without excessive dependencies, and without excessive memory use, etc. (it should be implementable on hardware wallets with low-power SOCs). It should support versioning, in case we don't get everything right in v1. The specification should have a few test vectors to help 3rd party implementations get things right. Ideally it would be fully encrypted, including headers, so malware and attackers can't scan for backup files (though this might not be possible because we may need to retrieve a salt value before decryption. TBD.)
• Cryptographic consulting begun. We should be engaging with our vendor to review our cryptographic design and provide professional feedback. I'm also open to review from the Cardano ecosystem as well, which has many cryptographers (p.s. it would be awesome if resources like this were part of Catalyst!)
• Mock account functionality in app. Even though we may not have an API yet, the app should do the following during setup to prepare for API support:
• Generate a random account ID.
• Write that account ID to each Yubikey during setup.
• Generate random PINs for each Yubikey (note: may use the same set of PINs for all Yubikeys for easier usability).
• Output / log the account ID and random PINs at the end of setup (this could later be used to make API calls and/or generate a 1Password-like "emergency kit" with this info.)

Milestone 3: BIP-85 support, early backend explorations

Deliverables

• Non-production build of Android app that allows for Yubikey setup and generation of BIP-39 seed phrases using BIP-85, including encrypted persistence via libsodium (even if only to a local file) not in the file format from Milestone 2. (Note: to go through setup, you'll need 3 Yubikey 5 series devices.)
• Share out progress of design work, even if still in-progress - Figma or PDF format
• Share out early feedback from cryptographic review - PDF format. Please note that this is the first review and that it's well before launch. I don't expect to get things perfect on the first try.

AC:

• After setup is complete, the app's main functionality should make it possible to derive keys for BIP-32/BIP-39 wallets via BIP-85. For example, there might be a button to create a new key, then you could choose a BIP-39 wallet (Ledger, etc.), and it would generate a key that you could restore onto that wallet.
• There must be test cases to confirm compliance with the test vectors in BIP-85.
• The test cases must run in CI, and should block PRs from being merged if the tests fail.
• It must be possible to save (and read) the state required for BIP-85 to the file format from Milestone 2 (BIP-85 requires you to remember, for example, whether it's 12/18/24 word seed phrase.)
• Initial draft design for backend. Must answer these questions:
• How do we propose to minimize user data? (SRP / OPAQUE / key based sign-in)
• How do we store data? (S3, etc.)
• How do we replicate data? (Multiple regions? Multiple continents? Multiple clouds?)
• How do we encrypt at rest?
• How do we protect infra against hacks that would give encrypted backups to hackers, etc? (2FA/Yubikeys)

How can a user run their own backend easily (single executable, Docker container, Cloudformation/Terraform)

• How do we securely build infrastructure?
• How might subscribers pay without connecting payment information / identity to their account? (payments service spits out a token, then used on accounts service to top-up. No logging account numbers on payments service. Maybe support crypto payments- BTC/Monero/ZCash/etc.)

Milestone 4: Largely complete app functionality, minus APIs

Deliverables:

• Non-production build of Android app that looks like the designs, allows for setup of Yubikeys, and allows for generating child seeds/keys with round-trip encrypted persistence in the draft file format. Near-feature-complete, minus any account functionality that requires backend work.
• Share out findings about backend research: is it feasible for me to build a public service that preserves privacy, Mullvad style? Is it advisable to do so (large honeypot of encrypted backups vs everyone using Google drive, etc.)? 

AC:

• App should look like the designs
• It should be possible to walk through setup to prepare the Yubikeys and generate account IDs/PINs/etc.
• It should be possible to generate sub-keys using BIP-85 and save the metadata required to generate each key in the file.

Milestone 5: Release to early testers and feedback

Deliverables:

• Alpha build distributed to private testers. Near feature-complete, ready for testing and early feedback.

AC:

• App should be near feature-complete.
• Delivery to closed group of alpha testers

Milestone 6: Launch of "Public Beta"

Deliverables:

• Website launch
• App .apk file for side-loading, or link to Play Store
• Blog post(s) about product

AC:

• Launch materials available (website, blog posts, etc.)
• Launch publicly (probably as a "beta" so the wider crypto community feels like they have the opportunity to give feedback)

Uncommitted / stretch goals:

• iOS support. The goal is to make as much of the code as possible support Kotlin Multiplatform. If we execute on this well, we'd love to ship with support for iOS, and possibly desktop (MacOS/Linux). I think this is a requirement (but not part of this proposal) for a future non-beta launch.
• Backend support. I'm still on the fence of whether it's advisable to build a backend service for replicating backups (client-side encrypted using Yubikeys), or whether I should direct users to use Google Drive, etc. On one hand, a centralized service might provide a honeypot for attackers. On the other, it would improve UX, and everything is encrypted client-side anyways (with a full 256 bits of entropy, with hardware-backed keys). It's also unclear (until Milestone 4) whether I can feasibly build a privacy-preserving backend such that I know almost nothing about customers (like Signal and Mullvad). Ideally, I'm hoping the answer will be that it's both feasible and a reasonable thing to do security-wise, because that'd make for an awesome product experience.

[RESOURCES] Who is in the project team and what are their roles?

Pete Doyle - Founder and engineer

I'm the founder and sole engineer for the MVP phase of this project. I've been an engineer for 15 years, mostly on Android, and have an affinity toward building beautiful products with a high degree of UX fit and finish.

I've followed Cardano closely since the 2017 bull market and have a high degree of respect for, and affinity toward, the engineering practices espoused in the Cardano project.

I've worked for well run San Francisco/Bay-area startups as well as the distinguished (and recently defunct) Grand Challenge at Amazon, which worked on moonshot ideas that aimed to be 10x better than existing solutions, with an ability to scale to 1% of the world's population (on the order of ~100 million people).

I've spent the past few months prototyping this project's interaction with Yubikeys. With communication, key generation, and encryption/decryption now working, the next phase is to add support for multiple Yubikeys and build a delightful, shippable product. Funding from Catalyst will allow me to focus full-time, and have a huge hand in enabling me to ship.

Resume: https://wipcrypto.com/catalyst/resume

LinkedIn: https://www.linkedin.com/in/petedoyle/

Twitter / X: https://twitter.com/nomadicpete_

[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources.

Engineering and development - ₳155,500 (~$58,000 USD)

Costs for copywriting for the web site, marketing, etc.

Design - ₳41,000 (~$15,000 USD)

Budget for design services such as visual and UX design, prototyping, design systems work, etc.

Yubikeys for early testers - ₳11,000 (~$4,000 USD)

Yubikeys for ~25 early testers so they can test and give their early feedback.

Web development - ₳13,500 (~$5,000 USD)

Budget for web design for an informational web site.

Copywriting and editing - ₳5,500 (~$2,000 USD)

Costs for copywriting for the web site, marketing, etc.

Branding / Marketing / Publicity / Promotion - ₳41,000 (~$15,000 USD)

Budget for initial branding / marketing ideation and ad spend.

Copywriting and editing - ₳5,500 (~$2,000 USD)

Costs for copywriting for the web site, marketing, etc.

Legal - ₳27,000 (~$10,000 USD)

Budget for legal services related to incorporation, contracts/IP clauses for working with vendors, privacy policies, etc.

[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

By funding this project, the Cardano community gets to take a "shot on goal" at making self-custody simpler and more forgiving of user error, especially for the hundreds of millions of people who do not have secure physical locations to store their seed phrases.

If we succeed, millions of people will be able to use Cardano more easily, without relying on trusted third parties (banks, exchanges, etc.) to manage their keys.

The cost of not succeeding may be the rise of alternative designs like Ledger Recover, which have a lower bias for self-sovereignty in their design. Alternatively, Bitcoin-focused products like Bitkey may make self-sovereignty much simpler, but only for Bitcoin.

Regardless of whether this particular project succeeds in making self-sovereignty easier, it's likely that the pieces of this design (but in a different configuration), will be a large part of one that does. (e.g. the ability to use USB/NFC to talk to ISO/IEC 7816 smart card applications, with hardware backed keys, potentially on multiple devices.)

[IMPORTANT NOTE] The Applicant agrees to Fund Rules and also that data in the submission form and other data provided by the project team during the course of the project will be publicly available.