zkAuth

The Solution: zkAuth 🔐

We present zkAuth, a zero-knowledge and zero-trust based onchain 2FA inspired by ERC4337. For the sake of mass-adaptation, which we the web3 community strive for, our solution builds on the established TOTP standard, instead of providing an optimized solution which with high probability will get rejected by the public.

TLDR:

• Compatible with established TOTP apps (e.g. GoogleAuthenticator).
• The critical TOTP generator secret is only displayed to the user.
• Mentioned secret is generated randomly and does not get stored.
• Authentication is validated on-chain, thus cannot be corrupted and is transparent.
• Authentication can be invoked by smart-contracts by cross-calling the zkAuth contracts.
• The zkAuth contracts can be base-class to paymasters of 2nd generation wallets such as ERC4337.
• The generator secret can be recovered through social recovery (zk-protected&onchain-validated).

Zero-trust setup

Current TOTP 2FA solutions are based on a shared secret which generates a different password for every moment in time. The trusted validator uses the secret to verify the user.

Our approach removes the trusted validator. The secret is randomly generated on the frontend and displayed in form of a QR-code to the user only once. Before discarding the secret, passwords for 2**8 timestamps into the future are generated and hashed together with the corresponding time-step. A merkle tree is build on top of those hashed. Once the user authenticates, which proves that he scanned and hopefully securely saved the secret, a authenticator contract containing the merkle-tree's root gets deployed to the blockchain.

We chose the layer 2 solution OPTIMISM as our home-chain due to it's scalability, block-time of ~1sec, zero-gas fees and its seriousness.

Neither the merkle-tree nor the hashes which form the leaves of the tree, can be used to infer the secret, nor can an attacker back-propagate the corresponding generation-time of an password-hash.

To further make this solution invulnerable to brute-force attacks, we encrypt the tree with a key signed with the users public key, meaning this key can only by generated by this specific address.

The full merkle tree is necessary to parse the data needed for onchain authentication with the deployed merkle-tree root. Earlier implementations od this approach have stored the tree in the browsers local-storage. Needless to say that this solution is sub-optimal for multiple reasons. We choose for decentralized storage an provide the user the option to store and retrieve the tree from IPFS, specifically web3storage, or CERAMIC, a protocol for decentralized data composability.

Authentication can be invoked by any smart-contract, wallet or even token when used as modifier. The calldata is put on hold until the user authenticates. Authentication requests emit an event which get's indexed by theGraph, a decentralized blockchain indexing protocol. We use these events to inform the user about open authentications and the staged call-data.

The authentication step requires the user to access her/his TOTP generator and the corresponding merkle-tree. Once a TOTP is provided, it get's hashed together with the current time-step and compared to the leaves of the merkle-tree. If a matching hash is found, the same plus the additional branch-hashes necessary for verification are send to the blockchain. With the initially provided root, it can be verified that the merkle-tree has not been modified. This method is commonly used to prove the integrity of downloaded files and in internet protocols such as TSL to protect against man-in-the middle attacks.

Social recovery

Web3 is known for the fatal consequences of losing access to the personal private-key. Inspired by a talk of Vitalik we took a step further and implemented social recovery.

The user-specific authentication contract let's the user assign other wallets as trustees for recovery.

In the case that the user's wallet gets unaccessible or compromised, a recovery process can be initiated.

In a first step the user agrees off-chain (e.g. by phone-call) on trustee-specific and one personal passphrase. For each passphrases, a SNARK proof is generated and committed to the blockchain.

Each trustee has then the option to consent to the recovery-process by submitting s SNARK proof of his passphrase.

Once a predefined threshold (at least majority) of consents is reached, the user is able to recover his authentication contract by in a last step, providing the SNARK proofs of his personal passphrase.