Keyvault - UCG Proposal

Astar Initiatives dApp staking applications
1

Introduction

keyvault is a blockchain-based password manager. This is a UCG proposal (converted from dApp staking proposal)for 2M ASTR tokens.

keyvault aims to let users actually own their passwords by removing the middleman (e.g. Google or 1Password) who can gate your access to whatever database your passwords live on.

Further, keyvault intends to add a social recovery mechanism for users to recover their lost encryption key for keyvault (think master password). Although I say “encryption key,” this feature can be utilized by users to safeguard their wallet’s private key or seed phrase.

Mission

We want to make sure everyone has access to their own passwords without requiring a middleman to be honest in keeping their passwords safe and accessible.

You might think you do, but, when you use a password manager such as Chrome’s built-in password manager or something like 1Password, you are subjecting yourself to their mercy. If they decide that you’ve somehow, potentially done something they don’t like, your access can be put in jeopardy. Even if they properly encrypted your passwords and can’t read it, they can still delete your passwords or prevent you access. Or, maybe they’ll just decide one day that, for your continued access, you now must pay 10x as much. We depend on them to be honest and play nice.

To get rid of the middleman, keyvault wants to take advantage of the Astar blockchain as a storage for encrypted passwords, so that users don’t have to worry about their passwords being corrupted or their access blocked.

keyvault is currently minimally viable.

Some screenshots:

Screenshot of me copying my gmail password using keyvault

image
image1036×1258 89 KB

Creating random passwords with specified requirements

image
image533×940 78.4 KB

Team:

I hope to use part of the grant to hire other developers to help speed up development.

keyvault architecture

There are 3 main components:

  • smart contract
  • browser extension (can only read from smart contract. responsible for encryption and decryption.)
  • webapp (submits encrypted entries to the smart contract)

Please note that read and write capabilities are purposely separated between the browser extension and the webapp.
This is done because transactions only need to be made when adding/updating/deleting a password and is not needed otherwise.

data structure

The smart contract is there to store encrypted data for the user in an append-only format. The append-only format is required to prevent any leakage of information about what websites a user visits or what usernames a user uses. The format looks like the following in solidity.

struct EncryptedEntry {
    string iv;
    string ciphertext;
}
mapping(address => EncryptedEntry[]) private entries;

Social recovery mechanism

The idea is to make use of Shamir Secret Sharing (SSS). See Youtube video for a 10 minute overview with visuals. Briefly, however, SSS is an algorithm for splitting a secret into, say, 5 shares such that any 2 of which can be used to reconstruct the secret.

So, if your encryption key is split into 5 shares and you distribute these 5 shares to your friends and family, then you can reach out to them to retrieve any 2 of those shares to recovery your encryption key.

What’s difficult is that your friends and family may well lose the share you entrusted onto them for safeguarding. And, if enough of them loses track of their share, you won’t be able to recover your encryption key. keyvault therefore intends to add a management layer on top of the base password management layer to make it easy for your friends and family to keep track of those shares.

Security considerations

  1. [Encryption occurs off-chain] All passwords are encrypted off-chain. This way, since the user becomes the only person able to decrypt the passwords. Without the encryption key, the passwords cannot be decrypted by anyone.
  2. [Everything password-related on-chain is encrypted] This way, potential attackers can’t even find out what website or username an encrypted password is for. Since the websites we visit and the usernames we use may help would-be attackers figure out our real-world identity, we it’s important that no such information be available.

Past Performance & Milestones

  1. Won 3rd place in Encode’s Polkadot ink! hackathon
  2. Finished working MVP

Roadmap

The following timeline is something I feel is ambitious for me but doable.

1st month

  1. add security measures to communication between chrome extension (can only read) and webapp (can submit txs to smart contract)
    • background: the chrome extension and webapp will at times need to communicate with each other and, while I don’t see how it’d benefit attackers, this task is to help prevent forged messages from being possible.
  2. set up RPC servers, so as to avoid congesting public RPC servers
  3. add autofill capability for destop browser
  4. update chrome extension so that user can choose their own RPC server (in case they want additional assurance of privacy)
  5. create extension for firefox and safari
  6. publish chrome extension on chrome marketplace

2nd month

  1. add social recovery capability (should largely be management layer on top of the password manager layer)
  2. add more user-friendly option of sharing encryption key between devices
  3. [stretch goal] add TOTP 2FA (think Authy or Google Authenticator)
  4. [stretch goal] add desktop app for 2FA

3rd month

  1. create mobile app for keyvault
  2. [stretch goal] create mobile app for 2FA

Competitors

Competitors come in 2 main forms:

  1. those built into browsers – these are tied to your browser accounts. Your usage of them is limited to within the browser.
  2. non-blockchain-based password managers – these include 1Password and LastPass as well as open-source alternatives such as KeePassXC. The main issue with these have to do with availability and censorship resistibility. The commercial ones gate your access to your passwords behind API servers and databases they control. The open source ones tend to be free but you’d have to store your password database behind your dropbox account or something similar, which then means dropbox (or whatever you choose) becomes the weak point as far as availability and censorship resistance is concerned.

Links

9 Likes
2

Just a note: this proposal was converted from the dApp staking proposal.

2 Likes
3

Thanks for your hard work in reworking the proposal.
I think it is very specific and excellent.
I support this proposal.

1 Like
4

It’s a perfect example of how Proposals should be made :clap: As mentioned earlier this dApp seems unique and I will support this UCG proposal :handshake: :star2:

1 Like
5

I fully support this proposal. I love the idea.
Your response in the previous thread was excellent, and I want to support your project.

1 Like
6

Thanks for the support you guys! Really means a lot :slight_smile:

1 Like
7

It is a different project with different perspectives. I would like you to be here, so I support it.

1 Like
8

This is an idea I would never have thought of. It’s a great proposal in terms of infrastructure and a fitting example for the UCG program.

I will also support this.

1 Like
9

As I mentioned in your previous post, you have my support in your wonderful project, I will support the proposal!

1 Like
10

Very interesting idea. Anyway, thank you very much for the proposal. =)

1 Like
11

Hi, quick update.

I’m gonna switch the smart contract from ink! to solidity. I dunno if anyone really cares to know this, but thought I should report it nonetheless for transparency’s sake. Also, I don’t expect this initial switch to take more than a few days.

The reasons for this switch are

  1. the service I was depending on to validate the ink! smart contract, polkaholic.io via ChainIDE, is currently down (The outage has apparently been noticed by others a while ago, but, since it’s still down, I don’t expect it to come back up anytime soon) and

  2. other services for verifying ink! smart contracts, as detailed in articles and blog posts, are also down.

Plus, given that I feel fairly familiar with solidity, I expect switching to solidity is gonna prove much less of a hassle.

– lousydropout

1 Like
12

Hello @lousydropout

As the 7-day minimum discussion period comes to an end, you can now open your UCG application proposal directly on https://astargov.com/.

If you need help creating your governance proposal for the vote, you can consult the official documentation or use this UCG proposal as an example.

Let us know if you have any further questions.

1 Like
13

@lousydropout
Sounds great about the migration, I like to think that you really care about the long term scalability of your product, it speaks well of you as a developer and founder.

As an ink! developer I would like to know more about this problem, do you think you can share links and resources about this?

1 Like
14

Hi @lousydropout
The contract verification tools is available from cargo-contract version 4.0.

Did you enconter some issue with this tool?

1 Like
15

hi @Juminstock, @GuiGou,

Although, yes, I am having difficulties with getting cargo contract build --verifiable to work well with cargo contract verify (I’ll show the details in a follow-up post to not clutter this post), I think there is another issue that’s just as problematic.

As listed in use.ink contract verification docs, there are 2 ways to verify an ink! contract. The following include my understanding of what the 2 options entail.

  1. “local bare-bones verification” – This is the running of cargo contract verify locally. However, I further imagine that this approach would require users to run the command if they want to verify the contract. However, I assume this would not provide a “verified contract” in the sense of a block explorer site publicly vouching for the verified status.
  2. “third-party service such as [Subscan/Sirato/Polkaholic]” – This means to upload the relevant contract and wasm files to the 3rd party service so that they can verify the build and officially vouch for the build on their site. This is, I imagine, what provides a verified contract that users can check on these sites. Here is where I’m running into issues.

There are/were 3 such services (block explorers of Astar network, wasm) that I’m aware of. Here are the issues I encountered with each:

  1. Sirato – This is the site that’s actually listed on the use.ink docs: Sirato | ink! documentation. The listed link, https://substrate.sirato.xyz/, results in a connection error. I think they’ve since taken down their block explorer service. So, this one is a no-go.
  2. Polkaholic – This is the verification service that ChainIDE uses. Unfortunately, https://polkaholic.io/ returns a 404. That is the address listed on their GitHub page. And, base on their issues page, it has been down for at least 3 weeks and shows no signs of coming back online.

image
image524×506 35 KB

The above image is the result I’m getting from using ChainIDE for building, deploying, and publishing verified wasm contracts. Unfortunately, it now results in an error, stating that it [f]ailed to connect to api.polkaholic.io/0.0.0.0:443. https://api.polkaholic.io/ results in a 404.

  1. Subscan – I think this one is manageable with time. Subscan is up and has a link for verifying wasm contracts: https://astar.subscan.io/verify_wasm_contract. The only issue is that their listed compilers only go up to version 3.2.0 whereas I’ve been using 4.1.1. Subscan does offer the option of contacting them to “add custom docker image[s]” for the compilation process. However, I imagine that’ll take a good amount of time and I’m also having difficulties with cargo contract build --verifiable and cargo contract verify steps.

Anyway, above detail some of my thought process and attempts. Maybe (hopefully?) I misunderstood something?

As for the articles/blog posts I mentioned, they were just the use.ink docs site and a few Medium articles where the author detail the steps for verifying ink! contracts with their, the author’s, preferred block explorer service. I can try to find them again if you like.

1 Like
16

cargo contract build --verifiable.

First, thanks for asking about the verification build process! Second, I would like to understand what’s going wrong even if I switch from ink! to solidity. So, any comment is very much welcomed.

Here’s a screenshot of me running the build process and trying to get the verification process working.

image
image1000×1084 122 KB

To help clarify what’s in the screenshot, let me note that there are 3 commands ran:

  1. cargo contract build --verifiable – appears to have ran successfully and states that the resulting contract artifacts are located in /home/lousydropout/src/astar/keyvault/keyvault/target/ink (mentioning for command 3),
  2. cargo contract verify – resulted in an error stating that I need to pass in either the --contract or --wasm argument, and, so,
  3. cargo contract verify --wasm /home/lousydropout/src/astar/keyvault/keyvault/target/ink/keyvault.wasm – resulted in a “Failed to verify authenticity of wasm binary”.

Some additional information:

  • within Cargo.toml, the specified contracts version is 5.0.0
    ink = { version = "5.0.0", default-features = false }
  • cargo contract --version prints 4.1.1
    image
  • the docker image used by cargo contract build --verifiable is of version 4.1.1, paritytech/contracts-verifiable:4.1.1
    image
    image950×378 105 KB
  • folder structure:
    image
    image716×99 24 KB
1 Like
17

Update: Just opened my UCG application proposal on AstarGov: keyvault UCG Proposal - Proposal in Townhall House Astar Network.

2 Likes
18

Thank you for your proposal.
I apologize for the delayed response.

I think it’s a proposal that is familiar within the web3 world. I am a bit concerned about the feasibility aspect, and just as it took a considerable amount of time for cloud systems to gain widespread trust initially, it is possible that it will take a similar amount of time to earn trust after release.

1 Like
19

Awesome proposal ser. I support it. Lets go.

1 Like
20

Hi Keyvault and @lousydropout , you have my support! Very excited to see this UCG proposal being approved!

1 Like