KeySphere: Simpler self-custody 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)

KeySphere simplifies seed phrase management, replacing paper with encrypted, replicated backups. Decryption keys are held in hardware on user-controlled Yubikeys, making users fully self-sovereign.

[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

Much of KeySphere will be "source-available" to allow for public review and audit, but it's license will not be OSI approved. This could change in the future as we navigate how to build a company on open source.

[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. This allows a great deal of protection from losing your seed phrase over time, even if you lose one or more Yubikeys.

Proposed combinations:

• Any one Yubikey + passphrase
• All Yubikeys + no passphrase (passphrase recovery)
• (Future/TBD) Any one Yubikey + no passphrase (forgotten) + 2 of 3 centralized recovery services verifying your identity*
• (Future/TBD) No Yubikeys (all lost) + Passphrase + 2 of 3 centralized recovery services (in separate legal jurisdictions) verifying your identity*
• (Future/TBD) 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 create hardware-backed public/private keypairs, 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://www.keysphere.ai/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://www.keysphere.ai/catalyst/app-instructions.

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://www.keysphere.ai/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 (like in Ukraine or Gaza)? 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. Even so, these do not protect in cases like Gaza where entire buildings are rubble. Even if you could return home, could you find your seed phrase in the rubble of a 10 story building? What are the odds someone else will come across them before you do? Will you rush back before it's safe in hopes no one will find it before you?

KeySphere helps, even in extreme cases like Gaza: 1) the decryption keys are on secure hardware, so even if someone finds a Yubikey before you they can't access anything; 2) seed phrases are safely replicated geographically- they are not on the Yubikeys, so there's less need to return home; 3) because you're used to carrying one of your Yubikeys (as recommended by the app- on a keychain, etc.), you're likely to have one with you even if you fled quickly; 4) even if you didn't, the centralized recovery options (optional) can protect in some cases. KeySphere would be a great help in cases like these.

So now consider: in a future world where your entire life (medical records, house title, access to websites, communication platforms, etc.) and livelihood (savings, money, tokenized assets, etc.) depend on your ability to securely hold your keys, would you want to be protected in such cases? I would. It seems worthwhile to explore the idea (and Catalyst seems like a great place to do so.)

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-sovereignly holding their own keys- from millions today to billions tomorrow. The current lack of a solution is a hindrance to the adoption of cryptocurrency, DeFi, and decentralized identity in Cardano and the industry at large.

My hope is that KeySphere will be a catalyst (pun intended) that enables millions of people to enjoy the benefits of the entire Cardano ecosystem.

By lowering the difficulty of self-sovereignty on the Cardano blockchain, KeySphere helps expand the "top of the funnel", increasing the number of people able to use Cardano and products in the Cardano ecosystem.

[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 capable of securely caching protected health information (PHI). It passed 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 being judicious with regard to conservative use of 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?

Deliverables:

• Non-production build of Android app that allows:
• Walking through the setup process
• Encryption/decryption of simple text fields to show encryption and decryption work end-to-end.

AC:

• The app build must allow:
• Setting up three Yubikeys and a recovery phrase
• Encrypting a message (of any sort, not necessarily a seed phrase)
• Using the recovery phrase and any 1 Yubikey to decrypt the message.
• It does not need to persist data locally at this stage. An in-memory test app is sufficient.
• The Yubikeys should be configured securely once setup is complete:
• Pins should be set so they're not using the default
• PINs should use the key derivation function (KDF) feature of the OpenPGP Card spec so they are not transferred over the air
• Max pin attempts should be set appropriately
• Curve25519 should be used on each Yubikey

Not part of Milestone 1 AC:

• Account registration.
• Syncing of data to a backend.
• Backup file (or API) format specification.
• Recovery if the recovery phrase is lost.
• No need for extensive error handling:
• Basic error dialogs that exit setup early (without recovery logic) are sufficient for these edge cases:
• 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.

Deliverables:

• File format draft specification containing details of the file format.
• Non-production build of Android app that generates all the info that will be required to generate an account (random account number, PINs for Yubikeys, etc.), even if it's not connected to a real API.

AC:

• There must be a document containing a draft specification of the file format. 
• 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 number.
• Write that account number to each Yubikey during setup.
• Generate random PINs for each Yubikey
• At the end of setup, this app version should output (on screen) or log the account number and random PINs at the end of setup so it's easy to verify they were created during setup.

Deliverables

• Non-production build of Android app that allows for:
• Yubikey setup
• Generation of BIP-39 seed phrases using BIP-85
• Initial draft design for privacy-preserving backend API.

AC:

• After setup is complete, it should be possible to create new BIP-39 seed phrases from the BIP-85 root seed.
• 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.
• Document for the initial draft design for privacy-preserving backend API.

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.

AC:

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

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.

Launch of "Public Beta"

Note that this is a limited beta release to a limited number of people. I may hold back from a wider release until the code goes through security audits, etc. (likely after Catalyst, or as a new proposal in a future Catalyst fund.)

Deliverables:

• Catalyst Project Close-out Report and Project Close-out Video
• 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 existing code mostly supports Kotlin Multiplatform (only NFC connectivity is not yet ready as of this writing). I'd love to ship with support for iOS, and possibly desktop (MacOS/Linux), but these are stretch goals.

[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://www.keysphere.ai/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 - ₳130,000

Salary for software engineering and development.

Cryptography consulting - ₳46,500

Budget for consulting and review of the cryptography design backing KeySphere.

Design - ₳41,000

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

Yubikeys for early testers - ₳11,000

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

Web development / Branding / Marketing - ₳13,500

Budget for web design for an informational web site.

Legal - ₳27,000

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

Copywriting and editing - ₳6,000

Budget for copywriting for the web site, marketing, 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 and Atala Prism 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.) My intent is to launch the MVP, get feedback, then reconfigure these pieces until it's something users truly love.