Please describe your proposed solution

Abstract

KeySphere is a project focused on simplifying self-custody using Yubikeys. The project aims to address the problem of securely managing seed phrases for cryptocurrencies and digital identities.

The current practice of writing seed phrases on paper is highly secure from electronic attack, but leaves users with the burden of providing physical security for their seed phrases. This frequently leaves users vulnerable to loss from fire, flood, theft, natural disaster, war, and a litany of other risks. Today this process is so complex that SatoshiLabs estimates only 2% of crypto users self-custody their own keys. KeySphere substantially eases the physical security burden with a secure multi-layer, multi-key encryption design that leverages Yubikeys as small, portable, and (relatively speaking) low-cost hardware security modules (HSMs).

This multi-layer approach ensures that an attacker finding only one key cannot decrypt the seed phrase. And even if the attacker finds a Yubikey, they are highly unlikely to extract the actual key from the Yubikey’s secure (CC EAL 6+) hardware.

Importantly, an attacker finding only one key does not reduce at all the security level of the encryption scheme.

Key Features and Functionality:

• Yubikey-Based Encryption: The core of KeySphere lies in its use of Yubikeys to encrypt seed phrases. The seed phrase is encrypted with 256-bit keys that are generated and stored within each Yubikey's secure hardware.
• Multiple Encryption Layers: KeySphere utilizes multiple encryption layers, similar to Russian nesting dolls, to further enhance security. The seed phrase is encrypted in layers, with each layer requiring a separate key to unlock. The layers are ordered in such a way that only certain combinations can decrypt the seed phrase. This layered approach significantly increases the difficulty for attackers to steal the seed phrase because they need access to more than one key- i.e. finding one key is insufficient for an attack to succeed (unlike most paper backups.) This is the primary mechanism by which KeySphere reduces the need for users to have perfect physical security.
• Geographically-Distributed Storage: Once encrypted, the seed phrase is replicated and stored across multiple data centers in different geographic locations. This distributed storage model ensures redundancy and protects against data loss due to localized events like fire, flood, natural disasters, and even displacement due to war. Because both the Yubikeys and Recovery Key use keys with a full 256-bits of entropy (as opposed to something like passwords with key stretching which could provide 256-bit keys with substantially less than 256-bits of entropy), these seed phrase backups are as hard for an attacker to brute force as if they decided to brute force any address that is publicly available on a blockchain. This is what enables KeySphere to safely replicate these backups geographically, thus protecting against fire, flood, war, and other threats that occur when seed phrases are stored in a single location.
• Recovery Options: KeySphere offers flexible recovery options based on different combinations of Yubikeys and the Recovery Key. This allows users to choose a combination that suits their needs at time of recovery and provides redundancy in case of loss or compromise of any single key. The default decryption method is to use the Recovery Key and any one Yubikey. If a user loses their Recovery Key, they can recover it using all three Yubikeys. If a user loses both the Recovery Key and one or more Yubikeys, they are unable to recover. However, note that this is substantially more recoverable than losing a single piece of paper. Future developments could improve this further (see next bullet).
• Potential for Centralized Recovery Services: While not part of this Fund 13 proposal, KeySphere's design facilitates the future (and, importantly, optional) inclusion of centralized recovery services. These services could act as a further safety net for users who are unable to recover in the above scenarios. In cases where users still have at least one key (Yubikey or Recovery Key), this can provide an additional layer of encryption ensuring a centralized recovery service only has access to an encrypted copy, even after decrypting their layer. This substantially reduces the risk of using a centralized recovery service, and is a material improvement upon services like Ledger Recover. For full details, please watch this technical overview:

<https://vimeo.com/946890861?share=copy>What I’ve built so far:

• A technical prototype that proves Yubikeys can be used in this way, including:
• A Kotlin Multiplatform codebase that can connect to Yubikeys over NFC and talk to the OpenPGP card application.
• The ability to configure a Yubikey over NFC with a simple tap, including generating Ed25519 and X25519 keys in hardware, which never leave the Yubikey.
• Using the Yubikey's X25519 public key to encrypt data only the Yubikey can decrypt.
• Using the Yubikey's X25519 private key (hardware-bound) to decrypt the data.
• Using libsodium, X25519, and XChaCha20-Poly1305-IETF in this process.
• A Figma prototype (click to view.)
• A work-in-progress app that will eventually (in Fund 13) work like the Figma prototype.
• A work-in-progress API that supports multi-key signature-based authentication using Ed25519.

To de-risk this project, we’ve already completed the most technically risky work. What remains in Fund 13 is straight-forward by comparison.

What I intend to do in Fund 13:

In Fund 13, I'll be finishing this app so it matches the Figma prototype and works end-to-end as a potentially viable product. This will allow me to test with real customers and validate the idea more fully.

High level tasks include:

• Finishing the Mobile App: Complete the mobile app based on the Figma prototype, enabling full end-to-end seed phrase backup and management.
• Creating a Robust File Format Specification: A well-defined file format specification will ensure the secure and reliable storage, and long-term recovery, of encrypted seed phrase backups.
• Developing a Privacy-Preserving Backend API: The API will support multi-key signature-based authentication using Ed25519, and store backups with minimal user data. Our design is inspired by this remarkable blog post by Mullvad: <https://mullvad.net/en/blog/mullvad-vpn-was-subject-to-a-search-warrant-customer-data-not-compromised>.

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.

For a deeper dive, please watch this technical overview:

<https://vimeo.com/946890861?share=copy>Addendum: Potential future pairing with Decentralized Recovery (DeRec):

While KeySphere’s Fund 13 work focuses on self-sovereign recovery options, we see the potential benefits of pairing our design with solutions like Decentralized Recovery (DeRec). DeRec allows users to recover their keys using a network of trusted helpers, each holding a share of the seed phrase. In most cases, KeySphere users would be able to use KeySphere to recover without assistance from trusted helpers. In extreme cases where both the user’s KeySphere Recovery Key and one or more Yubikeys is lost, users could fall back to recovery with DeRec.

It's worth noting the times in which we're in: advances in AI voice and video are beginning to make identity verification over voice and video calls untrustworthy (ex: 1, 2, 3, 4). This will continue rapidly in the coming days, weeks, months, and years. This makes recovery with DeRec more difficult than it would be otherwise- instead of a quick call to ask helpers for help, it may require an in-person visit for sufficient security. With DeRec, this could mean visiting 5 or more people, which could be time consuming depending where they live. Having a self-service recovery option with KeySphere as a first line of defense may avoid the need for this in the vast majority of cases.

KeySphere users may also be able to use DeRec as part of a layered approach (like above) to ensure that helpers cannot recover their seed phrase, even in the slim chance that a majority of these helpers collude together with their shares of the seed phrase. This would improve self-sovereignty over users who only use DeRec. Users who use both together would have formidable protection in an extreme number of scenarios, making self-custody much safer than it is today.

Please define the positive impact your project will have on the wider Cardano community

KeySphere aims 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.

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 led the core infrastructure team for the Amazon Care Android app, 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 five 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.

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

Milestone 1: Milestone 1: Basic setup flow resulting in initialization of all three Yubikeys

Output:

1. Preview build of Android app that allows:
2. Walking through the setup process to initialize keys on each Yubikey.
3. Encryption/decryption of simple text fields to show encryption and decryption work end-to-end.

Acceptance Criteria:

The app build must allow:

1. Setting up three Yubikeys and a recovery phrase
2. Encrypting a message (of any sort, not necessarily a seed phrase)
3. Using the recovery phrase and any 1 Yubikey to decrypt the message.
4. It does not need to persist data locally at this stage. An in-memory test app is sufficient.
5. The Yubikeys should be configured securely once setup is complete:
6. PINs should be set so they're not using the default
7. PINs should use the key derivation function (KDF) feature of the OpenPGP Card spec so they are not transferred as plain text over the air.
8. Max PIN attempts should be set appropriately to prevent brute force attempts
9. Curve25519 should be used on each Yubikey (X25519 / Ed25519)

Not part of Acceptance Criteria:

(Added for clarity)

1. Entirety of setup flow, specifically not including:
2. Account creation / syncing of data to a backend
3. Extensive error handling for things like:
4. A Yubikey is already initialized.
5. Don't allow setup to continue if user does not have at least 3 uninitialized Yubikeys.

Milestone 2: Milestone 2: File format specification and near-complete setup flow

Output:

1. File format draft specification containing details of the file format.
2. Preview build of Android app that allows for:
3. Everything previously delivered, plus:
4. Generating all the info that will be required to create an account (random account number, PINs for Yubikeys, etc.), even if it's not connected to a real API.

Acceptance Criteria:

1. There must be a document containing a _draft_ specification of the file format.
2. Even though we may not have an API yet, the app should do the following during setup to prepare for API support:
3. Generate a random account number.
4. Write that account number to each Yubikey during setup.
5. Generate random PINs for each Yubikey
6. 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.

Milestone 3: Milestone 3: Ability to create new seed phrases

Output:

1. Preview build of Android app that allows for:
2. Everything previously delivered, plus:
3. Generation of many BIP-39 seed phrases using BIP-85.

Acceptance Criteria:

1. After setup is complete, it should be possible to create new (and multiple) BIP-39 seed phrases from the BIP-85 root seed.
2. There must be test cases to confirm compliance with the BIP-85 test vectors.
3. The test cases must run in CI, and should block PRs from being merged if the tests fail.

Milestone 4: Milestone 4: App UI for all screens, persistence for seed phrases

Output:

1. Preview build of Android app that allows for:
2. Everything previously delivered, plus:
3. UI for all screens shown in the Figma prototype, and the ability to navigate between them.
4. Round-trip encrypted persistence in the draft file format (locally on the phone, or to an API).

Acceptance Criteria:

1. App should look like the Figma prototype.
2. It should be possible to walk through setup to prepare the Yubikeys and generate account numbers/PINs/etc.
3. 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.

Milestone 5: Milestone 5: Alpha build released to private testers

Output:

• Alpha build of Android app. Near feature-complete, ready for testing and early feedback.

Acceptance Criteria:

• App should near feature complete with regard to the Figma prototype.
• Delivery to closed group of alpha testers.

Final Milestone: Milestone 6: Launch of "private beta" to gather real customer feedback

Output:

1. Launch in private beta to a small number of potential customers.
2. Catalyst Project Close-out Report and Project Close-out Video
3. App .apk file for side-loading, or a link / private beta invite to the Google Play Store.

(Note: A wider public "launch" is not part of this Fund 13 work. We may wait to do a full public launch until we can properly fund security audits, etc. (not a part of this proposal.)

Acceptance Criteria:

1. Above deliverables complete.
2. App works end-to-end, including persistence to either a file (e.g. saved on a phone's cloud storage) or an API (or both).
3. Launch materials available to beta participants:
4. Website
5. Blog post
6. Technical documentation (a small amount to help customers understand the design)
7. One or more means by which customers can give feedback (email, or in-app call-to-action, or surveys, or user interviews, etc.)

Uncommitted stretch goals:

• iOS support. The existing code uses Kotlin Multiplatform, and is close to having full iOS support. We hope to have this available by the final milestone, but it's an uncommitted stretch goal and not guaranteed as part of this proposal.

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

Pete Doyle - Founder and engineer

Pete is the founder and sole engineer for the Fund 13 phase of this project. He's been an engineer for 15 years, mostly on Android, and has an affinity toward building beautiful products with a high degree of UX fit and finish.

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

He's worked for well run San Francisco/Bay-area startups as well as the yet-to-be-announced Grand Challenge at Amazon, an incubator for moonshot ideas capable of scaling to 1% or more of the world's population (on the order of ~100 million people).

Resume: <https://www.keysphere.ai/catalyst/resume>

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

Twitter / X: https://twitter.com/nomadicpete\_

Please provide a cost breakdown of the proposed work and resources

Design and Marketing - ₳15,000

Basic visual design and UX tweaks, initial branding work (app logo, brand positioning, etc.)

Engineering and development - ₳95,000

Software engineering and development for 6 months of full-time development work.

Legal - ₳15,000

Basic legal services to craft a privacy policy, terms of service, etc. These will require custom text to handle of our (near) zero knowledge design, which is rare.

Yubikeys for early testers - ₳3,000

Yubikeys for ~5-6 early testers so they can test and give their early feedback.

No dependencies

How does the cost of the project represent value for money for the Cardano ecosystem?

The lack of a "safety net" for managing seed phrases is a major inhibitor to the healthy growth of Cardano, and all blockchains. It's exciting to see the recent work on DeRec, which aims to help solve this. KeySphere is highly complimentary to this work by making it possible to (also) recover in a fully-self-sovereign way, without the participation of trusted helpers. With both in use, it would allow users to easily recover in almost any situation, with minimal disruption. With key management finally "solved", I believe millions of new users will flood into the crypto ecosystem, benefiting the best chains, notably: Cardano!

If we succeed, millions of people will be able to use Cardano and Atala Prism (now Hyperledger Identus) 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.