zk 2FA | Infinito Labs

Inspiration

The hot Wallets of both Rishabh and I have been compromised, and the hacker stole all our funds. In fact, billions of dollars have been stolen from hot wallets.

But people still end up using hot wallets for convenience, which comes at the cost of security.

Since hot wallets are always online, it's more convenient to use. To do the same action by cold wallet, users need to find a device (typically a computer) in which to plug their cold wallet, then move the requisite amount of cryptocurrency to a hot wallet, and then perform the action. In addition, while hot wallets are usually free, cold wallets can cost you between $50 and $200.

What it does

We are enabling users to authenticate transactions with a second layer of security while maintaining privacy. Users have to provide a second factor in the form of a pin generated on google authenticator to validate a transaction.

So even if the private keys of the user are compromised, the hacker will not be able to execute any transaction.

User flow

Setup:

Start the setup process by confirming a tx. A secret key is generated with a Merkle tree.
Scan the generated QR code using google authenticator. Tx authentication: After the user initiates a tx in the wallet, and if the tx involves a value to be sent.
Open the Google Authenticator app to get the 6-digit pin
The user is prompted to enter the 6-digit pin and verify

How we built it

We are enabling these features using a smart contract wallet, ERC 4337 describes a way how we can have account abstraction in the current Ethereum protocol without making changes to the consensus layer. And account abstraction allows us to implement all sorts of arbitrary and custom logic into our wallets compared to what’s currently possible with just a standard private key or seed phrase.

Two-factor authentication is done by providing a Zero Knowledge Proof-based two-factor authentication system. The advantage of using ZKP is that we can proof of our identity without revealing the secret information we have (here, secret info is OTP) to the verifier system. We can prove that we know the information, and verification of the proof takes place on the chain.

Then, a secret is generated in the front end using ChainLink VRF. This secret is now used to generate two things:

The QR code displayed in the front end: This QR code is scanned by the user using his Google Authenticator to generate time-based OTP every thirty seconds.
Leaf nodes of a Merkle Tree(MT) which is used to generate the full Merkle tree. MT is a hash function which is used to verify the information stored in leaf nodes in an efficient manner.

When OTP is entered in future the Merkle root is calculated in a ZK manner. This root value is now stored in the smart contract wallet and verified along with the proof generated.

After this gets verified, the user can make his transaction.

Challenges we ran into

The Bundler provided by the eth-infitism team was broken, and it was really challenging to set up a local RPC bundler. It took a lot of conversations with people of the ETH Foundation to figure out how it would be working.
Various ZK libraries like snarkjs were giving a lot of errors in the frontend. It took a lot of time and extensive research to find how every component would work together.
Lack of proper documentation of Account abstraction SDK made it a lot difficult to interact with the abstract ether provider and signer.