1

6.858 Final Project: Distributed Authentication on theEthereum Blockchain

Michael Shumikhin, Sarah Wooders, and Ryan Senanayake

Abstract— We introduce KeyChain, a trust-less authentication system which stores user-name to public-key mappings on the Ethereumblockchain. Keychain includes ann account re-covery feature, where users set up a “web oftrust”, where users can authenticate other usersvia the mapping and recover their accounts ifk of n members of their web of trust approve.We implement a prototype of Keychain usingan Android app to control a user’s accountand store keys, a Node.js app as an exampleapplication to authenticate with KeyChain, andthe Ethereum blockchain to record name/keymappings and the user’s web of trust.

I. INTRODUCTION

The current state of digital authenticationrequires significant trust in 3rd parties. Usersneed to trust websites to store their pass-words safely. Websites need to trust users tochoose secure unique passwords, which themajority of users will not do. And even forthe minority of users who do, their accountcan still be compromised by trusting recoveryemails, computers with malware, companies,etc. KeyChain aims to improve upon currentauthentication systems with the following fea-tures:

• Trust-less authentication Users do notneed to trust KeyChain or any websitesthey authenticate with.

• No passwords: Confirmation on a trusteddevice provides access.

• One account: One KeyChain account al-lows for access to all website accounts

• Safer recovery: Users can recover for-gotten private keys or revoke access forcompromised keys without compromis-ing their security by relying on recoveryemails or security questions.

Recoverability is a crucial aspect of a useableauthentication system. If it is too difficult fora user to recover from losing or forgetting a

secret, there will be no adoption of a systemeven if it is more secure. This is an issue withpublic-private key encryption, which offers noability to recover from a lost private key file.

Below is outlined a comparison of our sys-tem with a few different methods of authenti-cation:

A. Website stores hash of password

A User has to trust the website to storetheir password correctly, which often is notthe case and results in key compromise. Web-sites also trust that users will choose unique,high-entropy passwords, which for the largemajority of users is not the case. Additionally,many sites will provide a forgot your passwordoption, which relies on security questions ora recovery email, both of which may be evenless secure than the password.

B. Sign in with Google, Facebook, etc

This requires trusting the company behindthe authentication platform, which may not bea big deal for the majority of users, but itdoes mean that there will likely never be onesolution that everyone uses. For example, Ap-ple would probably not like the idea of trust-ing Google for their authentication system.Additionally, these systems still rely on theuser picking a unique, high-entropy password.Best practices also dictate that a user makethese hard to remember passwords different.While it is easier for a user to make one goodpassword, it is often easier for a user to make amemorable username which may be protectedwith public key cryptography.

C. Providing public key to website

While this is a much more secure system, ifyou lose your private key it is not possible torecover. Furthermore, this is not a prevalent

2

means of authenticating to a website as itrequires a separate challenge and responseclient on the device to respond to authenti-cation requests from the website. Allowingmultiple private keys to authenticate a publicuser/record provides significantly more flexi-bility.

D. Secret Sharing

Secret sharing allows for a private key tobe distributed in pieces to form a web-of-trust like recovery mechanism. This could beused in conjunction with providing a publickey to the website to allow for recovery fromlosing a private key. A significant disadvantageof this system, however, is that if a privatekey becomes compromised, there is no way tochange the private key. Therefore, an attackerwould still have full access to the account.

E. NameCoin

Namecoin allows users to claim identifiers,associate public keys with those identifiers.Namecoin allows users to purchase ownershipof any number of unclaimed names for aset fixed fee per name. KeyChain addressesseveral usability and adoption shortcomings inNamecoin. The primary usability limitation isthat if users ever lose the private key used toregister an identifier , they will permanentlylose control over that identifier. With Key-Chain’s web of trust, recovery is possible andbuilt into the system. Similarly, if a key iscompromised, an identifier can be permanentlyand irrevocably hijacked. In keychain this isavoided by allowing any associated key (priorto web of trust recovery) to revoke the set ofassociated keys for an identifier. Thus, Key-Chain requires significantly less key manage-ment effort and are not excessively burdenedby responsibility. As any Ethereum addresscan participate in the KeyChain authenticationsystem and since Ethereum is significantlymore utilized than Namecoin, we believe Key-chain is more amenable to adoption.

II. THREAT MODEL

Our primary goal is to provide robustusername-based authentication without expos-ing private keys or relying on 3rd parties.We assume that users store their keys on a

trusted device and that private keys are onlyexposed for the signing of challenge-responseand at least n-k of designated recovery usersare trustworthy. We assume the attacker cancompromise the website, the network, andfewer than k recovery users for a given user.

We develop Keychain system based on amobile app for the user-facing side, similar tothe DUO mobile app.

III. APPROACH

A. Authentication

We build a prototype for Keychain withthree main components: A mobile app foraccount management and key storage, a smartcontract for interfacing with data stored onthe blockchain, and a dummy webapp whichcontains a KeyChain authentication form. Anew user will create a KeyChain account bydownloading the KeyChain android app andmaking an account, which will generate keysto be stored on their mobile device. Key-chain is based off Elliptic Curve cryptogra-phy, making the assumption that users willhave an Elliptic Curve private key securelystored on their physical devices (e.g. phone orcomputer). Users can then authenticate witha web application by clicking “Login withKeyChain” on the website, which will redirectthem to a QR code page. The user scansthe QR code from their mobile device, whichprovides them with a nonce and callbackURL to the webapp. The callback URL iscalled from the mobile device to send datacontaining the user’s public key, the signednonce, and keychain ID to the webapp. Thewebapp verifies the keychain ID to public keymapping with the Ethereum blockchain as wellas that the nonce was signed by the public key.Once this is verified, the web server providesan access token to the client’s browser. Anoverview of the system can be seen in Figure1.

B. Web of Trust

Whoever is trusted by k out of n members(where k is chosen by the user) of the webof trust is defined to be the correct user of anaccount. Our system does not account for amalicious web of trust. When the user createsan account, they designate an initial web of

3

Fig. 1. The user downloads the Keychain mobile appto register an account, create a web of trust, change theirkeys, or revoke their account. The authentication processis as follows: 1.) A user requests to log into a webapp,and is shown a QR code. 2.) The user scans the QRcode with their mobile app. 3.) The mobile app sendsthe signed nonce and Keychain ID to the web server. 4.)The web server verifies the public key to Keychain ID.5.) If verified, access token provided to client.

trust as well as a starting public key. Once thisis formed, the user no longer has the power tochange their web of trust. The web of trustshould be able to elect a new web of trust(though this is not in the current smart contractimplementation).

Once this trust anchor is established, theweb of trust can at any time vote to wipethe user’s account and start fresh with a newpublic key. Any user with a public key thatwas added since the last web of trust votealso has the power to force a web of trustvote by freezing the account (see section 5.5to see how this helps mitigate the effects of acompromised key). Note that even a public keythat was removed and therefore does not havelogin access can still force a vote. A publickey with current login privileges is allowed toadd or remove other public keys to allow forthe user to add other devices or delete a publickey when they lose a device.

IV. IMPLEMENTATION

We provide the details for the three maincomponents of Keychain. We implement themobile app as an Android app, our smartcontract using Solidity for the Ethereumblockchain, and a dummy webapp usingNode.js.

A. Android App

The Android is the primary method foraccount management. Users create their Key-chain account using the Android app. Userscan import an existing Ethereum wallet keyfile into the app (this file is always transmittedencrypted by a user-known password. A futureimplementation would also allow the user togenerate a new key pair within the app soit does not leave the device. Importing anEthereum wallet provides the convenience thatthis wallet is already funded and therefore canpay for the transaction fees on the network.We experimented with methods that did notrequire the user to pay transaction fees, how-ever, we think that this is important to preventname-squatting. We think that this problemwill be less severe in Keychain than in Name-coin as the meaning of identifiers don’t haveintrinsic value unlike domain names.

Once the user creates an account, they areprompted to add other users to their “web oftrust”. Once they are logged in, they can votefor a reset of another account’s public keyvia the web of trust. They can also authorizenew public keys for use on different devices.All of these interactions are transmitted to anEthereum node run by Infura, which sendstransactions to interact with the smart contract.The most heavily component of the Androidapp is the QR scanner that will send theresponse to the callback URL. We had adifficult time replicating the Ethereum elliptic-curve cryptography operations on Android andhad an even harder time making sure thatour node.js library was accepting the sameencoding of the signature as Android wascreating. However, we were able to do this byusing cryptography operations provided by athird-party library and sending the componentsof a signature separately to the web server.

B. Ethereum Smart Contracts

We implement a smart contract in Solidityto store a trusted mapping from user ids toa set of authorized public keys and manageaccounts and keys. We include the followingmethods:

Do_add_key(bytes32 user, addressnew_key);

Do_add_key(bytes32 user, addressnew_key);

4

Fig. 2. Users can register and account, add membersof their web of trust, and revoke their account using theKeychain Android app.

Do_recover_address(bytes32 user,bytes32 recovery_user, addressnew_address);

Do_recover(bytes32 username,address new_address);

Do_revoke(bytes32 username);

New users are added to KeyChain us-ing the Create_username method. TheDo_add_key function is used to associatemore keys with a username. The trustlessstorage/computation offered on the ethereumblockchain is able to make updates to thisstate. A user-id can map to many public-private key pairs and likewise a public-privatekey pair can map to many user-ids. Thisprovides a user with a significant amount offlexibility to silo user-ids by device, public-key pair, and 3rd party service.

Recovery users are stored as an immutablearray of user-ids whose constituent public keyscan designate a new public key for a com-promised user-id. If any of a user’s privatekeys are compromised then members of theuser’s recovery group can designate a newrecovery public key for the user by callingthe Do_recover_address function witha new recovery address. Once a pre-specifiedk of n majority of recovery users have des-ignated a recovery public key, the contractre-assigns the user-id to public key map-pings to the new key after anyone runs theDo_recover function. The contract is ableto revoke the set of key pairs associated withany key currently associated to a user-id usingthe Do_revoke function.

C. Node.js Front End

We create a dummy website that usesKeychain authentication. We use the web3

library for Javascript to interface with anethereum node run on Infura. This nodeallows us to interface with the Soliditycontract. Users authenticate with the webappby clicking "Log in with Keychain", whichdirects them to a QR code image containsa nonce and callback URL for sending databack to the web server. On receiving thisQR image, the browser receives a signedtoken by the website that authorizes it foruse of this nonce. The web server ensuresthat it gives unique nonces to each request.The mobile app scans this image and thensigns {nonce,KeychainID}. The mobileapp then sends this signed message aswell as the public key used to sign to thecallback URL. Once the web server receivesthis request, it verifies that the nonce wassigned by the public key. Then, it verifiesthe Keychain ID and public key by callingQuery_user_keys(bytes32 username)from the Solidity contract. Once verified, theclient can send its signed token and exchangeit for a typical authorization token for thatuser’s account.

V. EVALUATION

KeyChain is built to be secure without re-lying on trusting any centralized entity. Weoutline some of the threats that we are mostworried about in this section.

A. Compromised Website

A typical threat that affects passwords con-sists of an attacker who has gained access toa website that the user has an account with.Depending on how the password is stored, theattacker may be able to recover the user’s pass-word and have access to all accounts that sharethe same password. This relies on trustingthe website to store your password correctly.Ideally users would use different passwordson each website, but realistically this does nothappen.

In KeyChain, the attacker can only recoverthe user’s KeyChain id. With this information,the attacker can only discover the user’s publickey, which does not compromise any otheraccounts owned by the user. In addition, weassure some level of confidentiality as anattacker is only able to associate this account

5

with other sites that make the uncommonchoice to make the user’s KeyChain ID public.

B. Phishing

Among the most common and costly attackstoday, phishing is a persistent problem formost services. Certificates, spam filters, andanti-phishing images/codes have been able toprotect many users, but inherently visiting acompromised or similar-looking website al-lows for a MITM attack to the real website thatthe user intends to authenticate with. As thewebsite has a trusted mapping between usersand public keys, this allows for a secure chan-nel to be created with the user that cannot beMITM’d. This will not work with the Androidapp, but would work with a browser extension(not included in current implementation) thatcan decrypt the received token for the browser.

C. Altering the KeyChain ID to public keymapping

If an attacker was able to alter this mapping,they could substitute their own public key andproceed to take control of a user’s account. Ina centralized service, we would worry a lotabout mechanisms for user’s to check the in-tegrity of this central database, but we can relyon the immutability property of blockchainsto protect this mapping. As long as our smartcontracts are implemented correctly, changingthis mapping would require a cryptographicattack on a user’s public keys.

D. Brute-force attacks

We use the same cryptography scheme asEthereum and so if a cryptographic attackwas possible on our public keys, then everywallet on Ethereum could be compromised bythe same attack. We maintain the same brute-force resistance as any other Ethereum key-pair based on the secp256k1 elliptic curve andKECCAK-256 hash function.

E. Physical access to a user’s device

While we are most worried about low-cost remote attacks, KeyChain also guaranteessome security from an attacker with physicalaccess to a user’s device. On Android, theprivate key is stored as an Ethereum wallet file

and encrypted with a password on disk. Thispassword is stored securely by the applicationand used to decrypt the wallet once the userhas provided their fingerprint or device pincode.

We are still worried about an attacker us-ing the user’s device to add a new publickey to their KeyChain ID then could thenremove the victim’s public key so that thatthey become locked out of their account. Thiswould require an attacker having possession ofa user’s device and knowing their pin, pattern,or fingerprint to authorize the creation of asignature. With this information an attackerwould also have access to the user’s emailaccounts which they could use to change thepassword on all websites that use this as arecovery email.

We also provide the ability to recover fromthis attack. Our smart contracts allow for anypublic key that was ever added to an account(even if it was removed by an attacker) tofreeze the account. This revokes all currentpublic keys associated with the user’s account.Once this has occurred, the user must requestthe web of trust to create a new public key.Therefore, even if the attacker has a compro-mised private key, they only have access tothe user’s account until the victim notices theattack and locks their account. This is muchbetter than a scheme where the user directlyprovides their public key to a service as in thisscheme the attacker becomes indistinguishablefrom the victim and therefore has unboundedaccess to their account.

F. Attacker on the network

As the response is coming from a differentdevice than is being logged in, extra care mustbe taken to ensure that an attacker does notauthenticate herself with an existing challengeresponse. As an example, a possible attack is:

1) The user attempts to login and creates achallenge

2) The user’s browser starts polling theserver for the result of the challenge

3) An attacker starts polling for the samechallenge response

4) The user completes the challenge5) Both the attacker and user are logged in

To prevent this attack, the NodeJS IntegrationLibrary ensures that each random nonce is

6

only provided to one user and is given a signedtoken to prove that it should be signed inwhen the challenge completes. As long as thistoken is transmitted over a secure channel, thisensures that the system is no longer vulnerableto this attack.

G. Compromised Application Code

An attacker could potentially introduce vul-nerabilities in our application code and dis-tribute this to users if they obtain our pub-lishing keys for the Android and Chrome appstores as well as our publishing account infor-mation. Publishing keys will be kept offlineto help deter this threat. We will also beopen sourcing all of our code so that anyonecan choose to build their own versions of theapplications. Finally, our applications are onlyreference implementations and anyone couldchoose to make their own implementation,which can still interact with our smart con-tracts.

VI. CONCLUSION

Our design addresses flexible user-id recov-ery, key revocation, phishing resistance, and isMITM resistant. We believe that the privacy ofuser-ids and associated recovery users can beimproved upon in future iterations using hash-ing for privacy or a similar method. A weak-ness of our design is that users/services cannoteasily transition to use KeyChain and thattransactions require Ethereum to fund whichis not easily available to end-users. Overall,we hope our design provides advantages inthe area of user authentication compared tocurrent alternatives.