Inspiration

We realized that the most common ways for DApps to securely interact with key pairs are to either download a pluggin, be on a trusted network, or carry around their hardware wallet. Being held to these options leads to a limited user experience. Both carrying around hardware wallets or requiring you to be at home for DApp interactions are not a reasonable expectations.

This prompted us to create a new user friendly way that allows transactions to occur securely, even if the user is on an un-secure or public network.

When we followed this logic, we realized the following advantages gained with this new process:

  • 3nable allows users to interact with DApps from any device or location in a user friendly way that feels familiar (3nable solution feels similar to 2FA)
  • Current solutions use APIs to pull private keys to local storages while 3nable keeps it in one non-custodial secure location
  • 3nable allows the DApp ecosystem to grow in a flexible way that doesn't limit DApps or Web 3.0 providers by network security constraints

What it does

3nable allows message (or transaction) signatures to occur in a secure environment instead of pulling keys into local browsers.

We accomplish this by creating a version of 2FA for DApps that enables users to connect to Web 3.0 by inputting a unique code. Users can retrieve this code by logging onto the 3nable site and copying the code into the DApp's 3nable login.

How we built it

We used Rust, Enigma.js, and Web3.js to built the core of 3nable - an Enigma Secret Contract. The flow is as follows:

When a user creates an account with 3nable, 3nable associates the user id with a private key and secures it privately in an Enigma secret contract.

Upon login on 3nable, a user can create a one-time (time-bound) access code that is linked to the user id and stored in a separate Enigma secret. This creates a one time link of private key <--> user id <--> code for a short time period.

DApp's that use 3nable for login (or signing transactions) will prompt users for this access code. When the code is provided to 3nable's login on the DApp, a function within the Enigma secret contract will retrieve the private key and use it to sign a message or a transaction within the Trusted Execution Environment.

After completion of this process, 3nable invalidates the linkage between the code and user ID, preventing any malicious actors from using that same unique combination.

Challenges we ran into

We were new to the both the Enigma tech stack and current Web 3.0 logins which required use to spend much time getting familiar these processes. As a result, we weren't able to complete integrations with either an 3nable app or a DApp 3nable login.

Additionally, due to internet capacity issues, it took longer than anticipated to compile and test the Enigma secret contracts.

Accomplishments that we're proud of

WE GOT THE ENIGMA CONTRACTS TO DEPLOY AND WORK!! We wanted to learn about the Enigma environment and understand new ways that data and keys can securely interact in the Web 3.0 world. Gaining experience with these solutions was our biggest goal.

What we learned

  • Developing Enigma Secret Contracts
  • How DApps interact with Web 3.0
  • Current Non Custodial Wallet Signature functions

What's next for 3nable

We want to finish the integration from the Enigma secret contract to the DApp and 3nable platform. After this, we can start to expand the functionality that could occur in the TEE. Additionally, we'd want to increase the security on how the users private keys are stored upon account creation.

Built With

  • enigma-js
  • rust
  • web3
Share this project:
×

Updates