Grant Application - MFKDF2

Hi Zcash Community!

We’re Colin and Vivek from Multifactor, a public-benefit cryptography research comany dedicated to improving zero-trust security for the modern web. We’re excited to share our proposal for MFKDF2, a trustless, next-generation client-side key derivation algorithm that has the potential to significantly improve the usable security of Zcash wallets, applications, liberated payments, and more.

The original Multi-Factor Key Derivation Function (MFKDF), which was published in USENIX Security '23 and won the Best Artifact Award, changed our understanding of usable key management by, for the first time, enabling client-side key derivation from multiple, commonly-used authentication factors, such as passwords, HOTP/TOTP (e.g., Google Authenticator), and hardware tokens (e.g., YubiKeys), without needing trusted hardware, MPC, or committees.

A large user study published in ACM CHI '24 demonstrated that users of all experience levels significantly prefer the experience of cryptocurrency wallets built on MFKDF over all existing alternatives, because they inherit the familiar UI and UX of custodial wallets like Coinbase while in fact being completely decentralized and self-custody.

The original MFKDF proved the feasibility of this approach as well as showing clear demand and usability benefits, but was ultimately just a research prototype that was not ready for production use. Therefore, we are proposing the development of MFKDF2, a free, open-source, production-ready version of MFKDF, rearchitected from the ground-up in Rust for use in Zcash. We have a concrete plan to make MFKDF2 more secure, feature-rich, and compatible with more types of authentication factors (including passkeys and biometrics) than the original MFKDF, and we’ll conduct the robust security proofs and independent auditing required for real-world use.

Zcash is poised to be one of the largest beneficiaries of MFKDF2 because its privacy-oriented design makes overreliance on custodial wallets by novice users particularly counterproductive. MFKDF2 has the potential of making novice Zcash users more comfortable with moving to self-custody by eliminating the need for seed phrases and other cumbersome manual key management strategies, allowing those users to experience the full privacy benefits of Zcash for the first time. We’ve therefore structured our proposal around working closely with Zingo and other Zcash wallet developers to ensure the Zcash community directly benefits from MFKDF2 as soon as we’re confident that it’s production-ready.

We’re asking for a reasonable $39,000 grant to support research, develpoment, and independent cryptographic auditing, and would greatly appreciate the support of the Zcash community to make MFKDF2 a reality. Thank you for considering our proposal, and we’re happy to answer any questions.

9 Likes

(Hi, I’m not involved with the Zcash Community Grants committee—just an interested Zcash community member.)

Hi there! Thanks for offering to help the Zcash project! :smiling_face: I’m interested in usability and security, and I looked into MFKDF a little, and I have some questions.

It seems to me that passkeys are going to become the universal standard way to authenticate. They’re more secure than the current alternatives, but their increased security comes with easier usability rather than harder. And they are already supported in almost every client (phone OS, password manager, etc) and the majority of the biggest services (Google, etc).

As a user, I prefer to switch to passkeys from the other alternatives (passwords, out-of-band authentication, TOTP like Authy, hardware keys, etc…) because I know things will be easier and quicker for me after I make the switch, and I feel increased “peace of mind” since the underlying cryptographic protocol is more secure.

So what I personally want is to take the same local, loyal user agent that cryptographically controls all of my accesses to services and accounts (by signing my login requests with the private key of the appropriate passkey key pair), and have that thing also control access to my Zcash.

However, this is as far as my thinking and experimenting has gone. I don’t know much more about how that would work, other than that it would probably involve trade-offs that different users would make differently, and that it would involve a ton of hard engineering work by Zcash wallet devs (of whom I am not currently one).

So, questions for you:

  1. Does that idea even make sense, technically? Seems like you’re probably experts on this.
  2. Do you think it is a good idea? Any interesting trade-offs you would call out? Would you personally use something like that?
  3. Could you help make it possible for Zcash users to do that, either with MFKDF2, or in a completely separate project, assuming you could get help from some Zcash wallet builders or other developers like the Blockchain Commons folks?

Thanks for your attention! Hope this half-baked idea turns out to be useful.

10 Likes

One of the important to check is whether the secure enclave is compatible with Zcash signatures, which is rather unlikely since it is ecdsa on secp256r1… I suggest consulting a cryptographer to make sure it makes sense.

1 Like

Hello @zooko and @hanh!

Awesome, we love passkeys, and you’ve hit on one of the main improvements on MFKDF2, which is support for passkeys in a way that’s not possible in the original MFKDF.

We have a concrete roadmap attached to our proposal that uses the PRF extension of the WebAuthn API, which is already supported by most hardware tokens, to derive factor material from passkeys. This will make passkeys a fully-supported factor in MFKDF2, and a co-equal citizen to existing factors like passwords, HOTP/TOTP, and more. Regardless of which factors are being used (passwords, soft tokens, hard tokens, etc.), MFKDF-based wallets still operate more like classic soft wallets (just with a much better UX!), than like hardware-based wallets.

Of course, one passkey alone would be scary to use for a cryptocurrency wallet, because the loss of a single device could cause a total loss of funds. However, with passkey factors in MFKDF2, passkeys can be used together with threshold key derivation or policy-based key derivation to combine multiple passkey options, or different types of authentication factors, into one key derivation policy, creating custom pathways for account recovery if some of the factors are lost.

Our goal with MFKDF2 is not to tell Zcash users or wallet developers which factors to use or how to combine them into a policy. Rather, we aim to provide a flexible, general-purpose primitive that supports a wide variety of popular authentication factors and allows users to combine them into a cryptographically-enforced key derivation policy in whichever way is best for them. Our 5th milestone is specificially focused on working with Zcash wallet devs to make sure that option is available to users soon. Hope that helps!

6 Likes

We’re excited to work with Multifactor as part of our strategy to focus on building the most resilient Zcash UX possible.

7 Likes

I am sorry but I don’t see how the prf extension will help you update on a different curve. Could you clarify?

2 Likes

Sure! Sorry for not explaining everything properly. The PRF extension will allow us to derive deterministic key material from a passkey, enabling it to be used as an input factor in MFKDF2 along side other types of already-supported factors, such as passwords, software tokens (HOTP/TOTP), out-of-band, etc., and then the MFKDF2-derived key can be used as the private key for a wallet. Of course, this will not magically turn a software-based wallet into a hardware wallet, but it will allow soft wallets to support new types of factors for key management and recovery than just passwords or seed phrases, which we know many users will appreciate. Hope that helps clarify, and happy to discuss further if you’d like to chat with us! :slight_smile:

— Colin & Vivek

2 Likes

Awesome, we’re super excited to work with Zingo as well! And more broadly, any Zcash wallet provider who is interested in optimizing for usable security is someone we’d love to support with this project.

4 Likes

Ah I see. When passkeys are synced across devices, would that be equivalent to having the wallet seed key synced to the cloud?
Sorry for being particularly paranoid about who can access my wallet.

6 Likes

You are asking the right questions that are important to the entire community. And I’m personally grateful for those questions because it’s important for me to know all the possible vulnerabilities that may exist.

ZCG members attended the first meeting with Colin & Vivek as part of their presentation of this proposal and on behalf of ZCG I can say that they made a very good impression on all of us. They are great enthusiasts with huge experience in this area, with an impressive level of knowledge on the subject. So I am sure that all the questions on the topic are an important part for us as well as for them, because they can demonstrate their level.

I am truly glad that this team approached us and that Zcash and our wallets can be the platform for the MFKDF2 integration.

6 Likes

Good question! Passkeys are usually protected by a secure hardware element, meaning that they are theoretically inaccessible to the cloud provider even when synced between devices via the cloud.

However, what you’ve hit on (any individual factor having weaknesses) is exactly why passkeys are much more useful when used as an input factor for MFKDF2, where they can be combined with multiple other factors from different sources, rather than just using passkeys alone.

1 Like

Thanks for your kind words, @artkor! We have really enjoyed working with the ZCG team so far, and are looking forward to continuing to do so under this proposal. Our sincere thanks to the Zcash community for being leaders in this space.