0

I've been doing a deep dive into how products like Web3Auth work under the hood and wonder if this is a viable approach to building applications where a user can have the convenience of using oAuth to generate and manage a private key. Additionally no party, except for the client, would know what the final private key is.

My high level understanding of how this works is that a user goes through the usual oAuth2.0 flow to login to their social account (e.g. Google) and gets an ID token. Client passes the ID token individually to a group of independent nodes for authentication. The nodes then use a distributed key generation (DKG) process to calculate a new private key for the user.

The private key can be split into a minimum of 2 shares using shamir secret sharing (SSS). client share is kept by the user (e.g. on client device or their cloud backup) and node share is further split amongst the group of independent nodes. On login the user passes the ID token to all the independent nodes to reconstruct node share. They then combine node share with client share to get the private key again.

This whole process (if my understanding is correct) seems like it's combining a lot of already complex security systems into something even more complex. However the potential upside is that users get the convenient UX of social login to generate a private key in a zero-knowledge way which would be great if true.

However it might be naive of me to think that a system like this is completely fool proof, and I'm wondering what are the trade-offs here? Some of the vulnerabilities I could think off are:

  • Whichever company issued the ID token in the oAuth process could potentially gain access to node share. However as long as client share is kept on a separate system (e.g. login with Apple and NOT using iCloud), then private key is still safe.
  • One bad node could prevent users from accessing node share. In which case the user would be screwed unless nodes had redundancy in the reconstruction threshold or there was a third redundancy share kept somewhere else.
  • If the storage mechanism for client share was compromised then the user would be screwed unless there was again a third redundancy share kept somewhere else.

All the individual protocols (oAuth, DKG, SSS) seem solid on their own. So it seems the risks lie in how these shares are accessed and handled or am I missing something crucial here?

user3458571
  • 1

1 Answers1

2

You are producing a really convoluted system for very little gain. And you will have an issue if the client is provided an evil javascript library by the the servers.

Have a look at how WebAuthn works. It's a W3C standard. It provides no knowledge of the key to other parties. With no need of distributed key generation or shamir secret sharing.

Ángel
  • 17,578
  • 3
  • 25
  • 60
  • Thanks for the reply. I agree with your criticism regarding the convoluted nature of this system. I'm interested to know why you think the gain is very little though? Do you mean the security/UX gain is not worth the potential security flaws from added complexity? – user3458571 Aug 19 '22 at 06:48
  • @user3458571 I was comparing it with WebAuthn which would cover -in a better way- the same use case, is more secure, and standard. Had it not existed, I would probably have been more open to complex alternatives like that, and given more thought to your proposal. I may have been a bit harsh in the answer. – Ángel Aug 21 '22 at 21:59