Using low-cost HSMs (e.g. Yubikeys) for easier and safer self-custody

[GENERAL] Name and surname of main applicant

Peter ("Pete") Doyle

[GENERAL] Email address of main applicant

petedoyle@gmail.com

Additional applicants

None

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

6

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

No

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

No

[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?

No

[GENERAL] If NO, please describe which outputs are not going to be open source. If YES, please write “Project will be fully open source.”

I'd like to start a company around this key management product. For trustworthiness, the core encryption/decryption code will likely be open-source, but some of the application-level code may not be.

Wanting to run a business makes this a complicated matter- I'm still understanding how best to have an open source product that can also be a good company, without also being a hardware company (e.g. the Bitwarden model vs the Trezor model.)

Branding, design, and trademarks will not be open-source.

[METADATA] Category of Proposal

Other

[IMPACT] Please describe your proposed solution.

Sometimes I think about a world where crypto wins. Where all value is tokenized on blockchains. What if my mom, someone who is not adept with technology, needed to secure her entire retirement savings? Would she be able to securely store her seed phrase, when no one could help her if she lost it? What if someone broke in to her house and took it? What if her house burned down? What if war erupted and she had to flee at a moment's notice, never to return? At such a difficult time, would she also lose access to communication accounts attached to her DIDs? I fear she would lose everything, with no recourse.

At global scale, these events happen every day. While some are preventable with steel/titanium backups, this is a highly technical task and still requires the user to have enough physical security to properly conceal their backups.

I strongly believe the lack of simpler and safer key management 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 first encrypting them with hardware-backed keys held on Yubikeys. These keys contain a full 256-bits of entropy, as opposed to password-based key derivation.
2. Reduce the need for physical security by placing those keys on secure hardware (Yubikeys) and setting random PINs. This allows the user to physically distribute Yubikeys among multiple physical locations, even if they don't have perfect physical control of each location (e.g. a friend's house, a safe-deposit box, etc.)
3. Solve extreme edge cases (displacement due to war, etc.) by creating a system that's configurable enough (as part of this proposal) to support (some day, not part of this proposal) centralized recovery, social recovery, and inheritance planning, while retaining a high degree of self-sovereignty.

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

By funding this proposal, the Catalyst project can help get this idea to market, potentially enabling simpler and safer self-sovereign key management for many Cardano users in the future.

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

This proposal benefits the Cardano (and wider crypto ecosystem) by making self-custody simpler and safer for users, thus making Cardano easier to use.

It does so with a design that supports a multi-chain world, as opposed to something like Bitkey, which is Bitcoin only. This is important because, if Bitkey truly makes self-custody simple (and they're on a good path to do so), Bitcoin may become significantly simpler to self-custody (and use) than any other cryptocurrency.

The proposed solution consists of a mobile app (on Android, to start), three or more Yubikey 5 series devices, and a password.

The user experience (see prototype) is designed to be extremely simple:

1. Order a welcome kit, which includes three Yubikeys and brief instructions.
2. Use the QR code in the welcome kit to download the app.
3. Open the app and walk through a step-by-step setup flow:
4. Using NFC, tap each Yubikey to the phone to 1) verify it's authenticity, 2) verify it is not already in use, 3) generate new hardware-backed keys, 4) configure the Yubikey's metadata and security defaults, and 5) configure the Yubikey's PINs.
5. Generate a random account ID for the backend service and create an account (we aim to be like Mullvad and hold as little customer data as possible, ideally none, apart from temporarily for payments.)
6. NOTE: it is also acceptable if the app only stores backups in user-owned storage like Google Drive/iCloud.
7. Write down and/or store a passphrase (protects against edge-cases where someone is able to extract a key from one of your Yubikeys.)
8. Walk through some educational screens to help them know how to store their Yubikeys (e.g. to protect against fire, make sure you have them in an emergency, etc.)

Once the user finished setup, they can generate additional BIP-39 seed phrases for any hardware or software wallets they use. These are automatically encrypted in a way only the Yubikeys can decrypt, backed up, and replicated across multiple data centers to protect against their loss. This design keeps the user in control of their keys.

For the technically inclined, the app is effectively a stateful (but still state-minimized) companion to BIP-85, such that it can back up any of the user's keys. Ideally, some day--not part of this proposal--it may be possible to have an SDK that wallets can use such that, with a single set of Yubikeys, all of a customer's wallets, DIDs, etc. are safely replicated to protect against loss.

In the long future (also not part of this proposal), we hope to also have centralized recovery options that are significantly more preserving of self-sovereignty than, say, Ledger Recover.

Lastly, it gets the technical ball rolling on using smartcard protocols (the ISO/IEC 7816 family of standards) to help provide simpler key management, which may eventually lead to custom hardware that makes mass adoption cheaper than Yubikeys would allow. It also brings this expertise to the Catalyst ecosystem, which may be useful in future projects (e.g. tap to pay, etc.)

[IMPACT] How do you intend to measure the success of your project?

Immediate adoption is not a measure of success for this proposal. At this early stage, we want to prove that the idea is sound, can be implemented securely, and that customers like and trust it.

The aim is to build something that is secure, beautifully designed, user-friendly, and capable of operating at scale--all things that may help increase adoption.

Our main measures of success are:

1. Acceptance by cryptographers. I would love to have the design reviewed by cryptographers, to ensure the design is sound. Having a secure design is the foremost goal.
2. A complete implementation. By the end, there must be a mobile app and it must be possible to back up keys securely.
3. Ideally (but optionally, and uncommitted, as a stretch goal), this includes a backend that is privacy-preserving (ex: random account IDs using something like SRP or OPAQUE for authentication, not username/email/password, such that we don't know the customer's identity and can't be compelled to disclose data for any specific customer.)
4. A secure implementation. The implementation should pass independent security review from a security company like Doyensec.
5. Actually solving the problem. The design and UX should make key management easier and more forgiving of user error. Novice users should be able to pull it off, or we should gain additional clarity on work that might further simplify things (e.g. direct integration with hardware wallets, SDKs for software wallets or apps that use this product to manage keys for E2E encryption, etc.)
6. We must launch. We must launch publicly (if and only if 1-3 succeed), even if it's a soft launch/preview (similar to Bitkey). A soft launch might help deter aggressive pushback and give customers an opportunity to provide feedback.
7. Future funding. Ideally, the progress from this proposal would open options for future funding (from Catalyst, other chains, actual customer sales, SBIR grants, etc.) such that we can push toward our ultimate vision of enabling individuals to safely self-custody currency and use E2E encryption in more apps.
8. Bonus: Engage in nuanced conversation. Ideally, I'd love to have some in-depth resources (blog posts, whitepapers, etc.) that help people understand why replication online is safer than they think (when the prevailing wisdom is to never place private keys online.) There was a lot of pushback on Ledger Recover (rightfully so: 1, 2), and over the course of a few weeks a great deal of nuanced discussion occurred online. I think people are open to thinking more deeply around key management now, and highly value their self-sovereignty (which this proposal tries to preserve, to a much greater extent than Ledger Recover.)

[IMPACT] Please describe your plans to share the outputs and results of your project?

I'll be sharing all progress in this status document:

https://wipcrypto.com/catalyst/status.

Specifically, the Figma designs/prototypes/branding as they become available, and the first early Android APKs where some of the functionality is available (for example, as parts of Milestones 1-5.) I may also share draft blog posts for early feedback before being published publicly.

Many of these will also be shared publicly via our future website and blog.

I expect this project will result in true market-based feedback from real, potential customers, as well as the wider crypto community. Hopefully I will have done a good enough job to warrant funding for future development, ideally directly from customer sales, but maybe also from Catalyst, other chains, and VCs who have a vested interest in simplified self-custody in a multi-chain world.

[CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

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 passed review by AWS'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 yet "solved", 2) that the user experience of writing down seed phrases is not ready for mass adoption, and 3) that a secure alternative is possible.

[CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible?

Apart from the measures for success (above), my main goals are to successfully build all the pieces necessary to have a completely working system, and to know that it can be done securely. I believe that will prove that it's possible to make self-sovereign key management much easier.

To validate this approach is technically feasible, I have already spent the past few months building out the ability to communicate with Yubikey 5's OpenPGP application over NFC and USB on Android. That now works end-to-end. I am able to successfully talk to Yubikey 5 series devices and generate hardware-backed keys for Curve25519. I can also use ECDH via X25519 to generate a shared key that I eventually use with libsodium to encrypt distinct copies for each of the Yubikey's public keys. This works end-to-end, drastically reducing the technical risk of a successful delivery.

There's plenty left to do, but I now know the approach is technically feasible. It may not be perfect, but it's good, and capable of making key management easier. Future revisions (not part of this proposal) may use custom hardware to replace Yubikeys or provide a more secure computing foundation, helping reduce cost and increasing security.

[CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

Milestone 1: Initial app functionality (1 month after start)

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 (2 months after start)

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.)
• Design service engagement begun. We should be engaging with our design service by now to help solidify the app's initial feature set, UX, and branding. We'll also work with them on the educational screens (where to store your Yubikeys, etc.)
• Cryptographic design review engagement begun. We should be engaging with our vendor to review our cryptographic design. I'm also open to review from the Cardano ecosystem, 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 (3 months after start)

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 copy 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 (4 months after start)

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: Feature complete (5 months after start)

AC:

• App should be feature-complete, ready for testing and early feedback by alpha users.

Milestone 6: "Beta" Launch (6 months after start)

AC:

• Security review complete
• 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)

[CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

Milestone 1: 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.

Milestone 2: 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.

Milestone 3: 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 we're well before launch. We don't expect to get things perfect on the first try.

Milestone 4: 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.)?

Milestone 5: Deliverables

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

Milestone 6: Deliverables

• Proof of shipping publicly. Blog posts (if any), web site, Google Play link, etc. It's ok for this to be a "beta" as discussed above.

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 for me (but not part of this proposal) for a non-beta launch.
• Backend support. I'm still on the fence of whether it's advisable to build a backend service for replicating backups, 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.
• Post-quantum hybrid encryption. The long-term nature of encrypting and backing up seed phrases makes quantum computers a threat. I have plans to support Kyber, but I'm not sure how difficult this will be, or how key management will work on Yubikeys. I'm about 70% sure it's technically feasible, but I'll reach out and get advice during Milestone 2 when I have access to cryptography consulting.

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

Legal - $30,000 ADA

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

Design - $45,000 ADA

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

Web development - $30,000 ADA

Budget for web design for an informational web site.

Branding / Marketing - $45,000 ADA

Budget for initial branding / marketing ideation and spend.

Copywriting and editing - $21,000 ADA

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

Yubikeys for alpha testers - $12,000 ADA

We may purchase Yubikeys for our earliest alpha users, so they can test more easily.

Engineering and overages - $667,000 ADA

The remainder will be used as salary during development. Any additional costs not yet foreseen will deduct from salary.

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

For the cost of about 6 months of FAANG-level salary (plus some for contracted services), the Cardano community gets to take a "shot on goal" at making self-sovereign self-custody simpler and more forgiving of user error.

The cost of not doing so may be the rise of alternative designs like Ledger Recover, which have a lower bias for self-sovereignty in their designs. 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 (the ability to use USB/NFC to talk to ISO/IEC 7816 smart card applications, with hardware backed keys, potentially on multiple devices). Having this expertise and ability in the Cardano ecosystem will be a valuable thing.

[IMPORTANT NOTE] The Applicant agreed to Fund10 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.

I Accept