2FA on Ethereum
Open-source security infrastructure for Web3.0
This article describes a “2nd-factor” authentication framework built on top of the Ethereum public blockchain. This cryptoeconomic primitive aims to provide an important infrastructure piece that can be added to the existing set of tools that help engineers and organizations globally build and deploy decentralized applications. It’s important to consider that the suggested identity authentication mechanism itself can also be implemented on any smart contract technology platform (including EOS, NEO, Stellar, Hedera, Dfinity) and provide that infrastructure service to the respective ecosystem.
Summary: Technical Architecture and Economy Setup
In a nutshell — a decentralized network of economic actors provide IT infrastructure for a decentralized identity authentication algorithm. In this authentication mechanism, a session ID (provided by an independent 3rd party) is encrypted with the public key of a User. The User has to decrypt the “encrypted session ID” using its private key. If the session ID provided by the 3rd party is the same as the session ID declared by the User, then a User’s identity has been successfully authenticated. The economic actors in this game are:
- Users (U): Consumers who require different levels of identity authentication to purchase goods and services
- 3rd Party Service (3PS): Firms looking to sell goods and services that require different levels of KYC authentication
- Session ID Providers (SIP): Nodes in the network that provide session IDs (used to authenticate the identity of Users)
- Validators (V): Stake tokens within SIPs and validate the authenticity of their session IDs
Generating Asymmetric Key Pairs
Mobile App and Biometric Algo
A mobile application uses a set of biometric algorithms to recognize a User’s fingerprint. The biometric algorithm uses minutiae (the specific points such as ridges endings, bifurcations in a person’s thumb) where the position and direction of these features are stored in the signature product itself. This pattern matching algorithm takes the general shape of the fingerprint and divides it into small sections, both the phase and the pitch are extracted and stored into 16 unique points.
Deriving Private/Public Key Pair from Biometric Algo
Sha256 is applied to the alphanumeric 16 point fingerprint ID number and thus generating a private key for the User. The discrete logarithm setting is used to generate a public key from this private key. A User will need to scan its biometric information (fingerprint) to release a private key in order to sign messages and/or decrypt information. The signing of messages takes place locally on a User’s phone. Signed or encrypted messages are then sent via WiFi direct, WiFi or any other transmission protocol. Private keys never touch the web.
Identity Authentication Mechanism
In summary — a proxy smart contract will handle the authentication requests, the authentication algorithm and the token economic incentive.
“Authentication Request” Proxy Contract
Whenever a 3rd Party Service requires a User to authenticate his or her transaction, the 3rd Party Service can call a function within a proxy contract with a fixed address. This function publishes a message to the distributed ledger (network of nodes) indicating a 3rd Party Service is requesting an identity authentication, this message also contains: the public key of the User (who will be authenticated), the public key of the 3rd Party Service, and other token bounty metrics (eg. amount of token, symbol). The bounty is considered to be a fee paid to the Session ID Provider (SIP) and Validator (V) for successfully providing the authentication service. This bounty is released to the SIP and Validator upon the successful authentication of the User.
Process Flow
Any SIP in the network that receives the “Authentication Request” broadcasted by the proxy contract, can provide the authentication for the 3rd Party Service:
- 3rd Party Service broadcasts a message through the proxy smart contract indicating a User needs to be authenticated. Message contains: M (User public key) and token bounty information
- A SIP node generates a random session ID (X) and publishes it to the proxy contract
- The User uses ECC signature to sign the session ID (X) on the proxy contract
- Validator node validates the private key (identity) of the User by using the session ID, public key of User and signature
- Once validated, the proxy contract releases the bounty (authentication fee) to the SIP and validator
Proxy Contract Methods
- authenticationRequest: Is called by the 3rd Party Service and deploys an authentication request message and its respective parameters (Q,M, fee). The bounty (fee) is held by the proxy contract in escrow.
- signatureRequest: Is called by the SIP providing the authentication for the 3rd Party Service. This method deploys a randomly generated session ID to the proxy contract.
- signatureProof: Is called by the User, where the User’s private key is used to deploy an ECC signature to the proxy contract.
- messageValidation: Is called by a Validator, the node validates the authentication using HMAC ( the session ID, public key of User and signature).
Proxy Contract Events
- userAuthentication: Is triggered whenever signatureProof is successfully called by the User.
- bountyRelease: Is triggered whenever messageValidation is successfully called by the Validator, and releases the fee held in escrow to the SIP.
Foundational Token Economics
Objectives
- Incentivize systematic authentications (submission of stochastically generated session IDs)
- Reduce the number of malicious actors (dishonest SIPs)
Mechanism: Authentication Incentive
Aligned with “Objective #1: Incentivize systematic authentications”, the aim of this mechanism is to incentivize SIPs to provide randomly generated session IDs. In this process SIPs submit a bounty (or authentication fee) that is then released to the SIP node for successfully providing the authentication through the submission of the session ID. As a reward, the SIP receives 2/3 of the authentication fee. SIPs are required to hold a minimum number of native tokens within their node in order to be considered an official SIP capable of receiving bounties (transaction fees).
Note: There is a cost for running a server (although small) and having a script that is listening to the incoming userAuthentication events. The accrued amount of fees in a month must outweigh the costs running that server. There is a threshold to be determined, in order to establish the minimum number of tokens that need to be held in order to receive fees.
Mechanism: Validator Staking
Aligned with “Objective #2: Reduce the number of malicious actors”, the aim of this mechanism is to filter out SIPs which are not providing randomly generated session IDs. In this process, Validators are able to stake the native settlement token within the SIP node in order to receive 1/3 of the bounty (authentication fee) after successfully validating the signature of the User and calling the messageValidation function. Once HMAC has been used to prove the identity of the User, Validators may challenge SIP nodes and the authenticity of their session IDs.
Note: There has to be a threshold that determines the minimum amount of native tokens staked in the node in order to receive bounty rewards (transaction fees).
Mechanism: Margin Loss
Aligned with “Objective #2: Reduce the number of malicious actors”, the aim of this mechanism is to discourage dishonest SIPs and Validators in the network. Both SIPs and Validators have tokens held or staked within the SIP node. SIPs that are not submitting randomly generated session IDs lose the tokens found bonded (either held or staked) within the node. This mechanism incentivize Validators to only support SIPs that are known to be truthful. Ultimately, the amount staked at margin loss should be greater than the value of the average of breaching a User’s ID.
Note: There are certain limitations since the Ethereum ledger is a state machine with a “read only” capability, meaning the state itself can’t examine itself and filter out the malicious actors. The “Margin Loss” mechanism should still be applicable at a late stage in other upcoming distributed VM projects that are adding this capability.
Q&A
Here are some interesting questions and thoughts that came up while designing this architecture:
Is this application compatible with other identity providers?
Although the approach where a biometric algorithm is used to generate the key pair is safer, app users should be able to conveniently plug-in their Civic or Uport KYC’d identity. Alternatively, a user could also upload their own private/public key pair and use the fingerprint functionality to release the private key and sign messages.
Can other biometric data be used to generate the public/private key pairs?
Yes, although another algorithm would have to be developed in order to generate a unique ID from facial or eye data. Perhaps CNNs and other machine vision techniques can be used to statistically prove a person’s identity. But the short answer is yes, a new algo ought to be developed to generate a unique ID similar to the 16 points in the fingerprint scanner.
Why and how would this even work in practicality?
- First, the value of bounty rewards (authentication fees) should outweigh the costs of running a server for both the Session ID Providers (SIPs) and Validators.
- Second, setting up a SIP or Validator should be as easy as simple downloading an environment to a server, uploading a script (for either a Validator profile or SIP profile) and assigning a wallet address where authentication fees are sent to.
Do you see any token economic variations in the future?
Short answer is yes, I will write a follow-up post in the near future to discuss some of the token economic variations where the desired outcomes of the incentive mechanisms can still be valid within sidechains, state channels and sharding.
If this is the “2nd-Factor” authentication mechanism, what is the first?
Likely to be your username and password, unless it’s a multi-factor authentication security system. However, this solution could also be used to simply scan your finger and deploy transactions, once you have successfully logged in to your asset management software (wallet, exchange).
Mathematical limits in terms of costs of running this architecture?
I believe the upper limit (maximum price) per authentication is going to be similar to the aggregate cost of running nodes for the network (server/hardware +electricity+WiFi). If we breakdown this sum 30 days and divide that cost by the average amount of authentications per day. On the other side of the equation we find an asymptote in the lower limit, as the price of electricity generation and internet supply is being reduced down to zero due to exponential technologies.
Can a 3rd Party Service (3PS) setup a Session ID Provider (SIP) node?
Yes! Great question, 3rd Party Services can also setup a Session ID Provider (SIP) node. It would make sense since the fees generated from providing the unique session IDs outweigh the costs of running a server.
Why can’t the 3rd Party Service (3PS) provide the session IDs themselves?
There are 2 reasons why the 3PS is not also the SIP:
1) Malicious actors within a 3rd Party Service may generate fake/invalid session IDs, this is problematic as it may lead to identity theft or fraud. Incentivizing stochastically generated session IDs and keeping that activity external solves this form of attack.
2) From a functional stand point, this token economic model has been designed to provide the 2FA service to a broader audience including P2P transactions (ex. landlord verifying my identity before signing a lease). SIPs are designed to respond to all authentication requests, without preference.
Twitter: https://twitter.com/acvlls
Linkedin: https://www.linkedin.com/in/albertocevallos/
Contact me at: alberto@keter.io
