Keyvault - dApp Staking Proposal

Astar Initiatives dApp staking applications
1

Introduction:

keyvault is a blockchain-based password manager.

Project Overview:

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.

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.
For it to be more usable, we intend to extend the capabilites to include

  • social recovery of passwords
  • MFA capabilities
  • passkey capability

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:

Security:

  • All passwords are encrypted off-chain, on the Chrome extension, using 256-bit AES-GCM. No unencrypted data is sent out of the Chrome extension.
  • The encryption key is stored via the chrome.storage API. Note that data in chrome.storage is namespaced by Chrome extension and can only be accessed by that Chrome extension. Data in chrome.storage is not accessible by any website or even other chrome extensions.

Past Performance & Milestones:

  • Won 3rd place in Encode’s Polkadot ink! hackathon
  • Finished working MVP

Roadmap:

  1. Extend Chrome extension to other browsers such as Firefox and Safari.
  2. Build mobile app version
  3. Add TOTP (Time-based One-time Password) feature (think Google Authenticator or Authy). To cut out the middleman, this feature needs this project (keyvault) since we need a way to safely keep track of the various MFA accounts, again, without relying on a middleman. Note: the tech for TOTP is available and well known. The task should mainly be incorporating it into keyvault.
  4. Add social password recovery so that, even if you lose your encryption key, it can be recovered with the help of trusted friends. The idea to use Shamir Secret Sharing to create multiple shares of your encryption key so that it can be recovered by combining 2 (or 3 or 4…) such “shares” together. keyvault here largely acts as a place for your friends to safely store their “share” of your password. So, need to build a management layer.
  5. Build Passkey authentication capability. (Note: I only have a vague idea for this one and think of it as another asymmetric encryption application. My impression is that FIDO2 is what we call Passkeys and specifications and existing implementations can be found.)

dApp Staking Reward Usage Breakdown:

  • RPC node for dApp
  • dApp audit
  • hire UX designer to help with design
  • continue developing tasks on roadmap

Appendix:

7 Likes
2

Hello there! How does keyvault plan to ensure the security and reliability of its password management system while eliminating the need for a central authority?

2 Likes
3

Hi!

From my perspective, the existence of a central authority in a password management system does not improve/worsen the security but does weaken the reliability.

The reliability is worse with a central authority simply because they have write access even if their policy is to restrict access.

As for security, the only secure approach (with or without a central authority) is to leave the encryption key with the user and the user alone. We kinda have to do this for keyvault, but, in the case of a central authority, not doing this means “security == how unhackable is their system,” which is not very reassuring we know even the NSA has been hacked in the past.

1 Like
4

Now, for a more in-depth response regarding how keyvault ensures security and reliability:

TL/DR:

  • security: This is dealt with by simply encrypting everything, only transmitting encrypted data out of the Chrome extension, and storing anything unencrypted in a storage that’s only accessible by the Chrome extension in question. So, in part, keyvault also relies on Chrome properly securing chrome.storage.
  • reliability: This is dealt with by making creates/updates/deletes append-only and by tying all modifications to the sender’s address.

Long version:

  1. All transactions regarding passwords are mappend directly to the sender so that no one else, not even the owner, can modify those passwords.

  2. Almost all transactions (1 exception) concerning the passwords are append-only. As such, it’s not possible for even the user to accidentally overwrite an entry. (Note: the sole exception is for when the user “resets” the account, in which case the smart contract essentially deletes the user’s data.)

    To provide a sense of the append-only approach, the unencrypted version of each entry contains a pointer called prev. The idea is that new entries have a prev == -1 but modifications (i.e., updates and deletes) have a prev that points to the previous version.

  3. Only encrypted data is ever sent outside of the Chrome extension.

  4. The encryption key used to encrypt and decrypt (symmetric encryption) lies solely on the browser in chrome.storage (in the chrome extension’s namespace) where website and other chrome extension are not access. This storage, depending on what the Chrome extension can do, could allow for some script injection. However, for keyvault, there is currently no way for you to accidentally run some hacker’s malicious code simply because users are not able to share data/text/code among each other and so no way to accidentally view and run some malicious code.

    (I don’t expect this to change for the items in my roadmap, but can’t say for certain. I’ll have to be careful about not accidentally allowing this in the future.)

3 Likes
5

Really nice product… I would like to hear more about the tech and the security aspects of the protocol - I will wait for tech questions from other agents.

Also, could explain it in a less technical way, please?

Thanks

2 Likes
6

Sure, let me give it a shot :slight_smile:

  1. In essence, keyvault ensures security by using military-grade encryption (which makes it essentially impossible for even Google to figure out your encryption even if they spend the next billion years trying).

    • That is to say, the 256-bit part of the phrase 256-bit AES-GCM encryption was the important part but simply means “it’s vitually impossible to crack.”

  2. The safest yet convenient place to store sensitive information on the Chrome browser is in chrome.storage (the name isn’t important). Hence, keyvault stores the encryption key there.

    • As an example, suppose “Chrome extension 1” decides to write some random message A into chrome.storage. Then, only “Chrome extension 1” will be able to retrieve/read that message in chrome.storage. “Chrome extension 2,” for example, would not even know of message A’s existence. Chrome, the browser, won’t let anyone else access or even know about what other write/store.

Please let me know if I simplified it enough, too much, or not enough :pray:

1 Like
7

Hello @lousydropout, thank you for wanting to develop your product on the Astar network!

I definitely like the proposal a lot, it’s definitely something that I haven’t heard of another team developing. The thing is that I have a lot of doubts regarding the product:

  1. The most worrying thing for me is the loss of the password, although in the current password managers, the master key is the main key for everything, there is a recovery mechanism, in your case you mention the social recovery, how will you do it? Account abstraction? Tree architecture with substrate?

  2. From what I see you plan to develop the product to be used as a browser extension, which means it can be just as vulnerable as our wallets when we sign a fraudulent transaction, is that correct?

  3. What exactly will be stored in blockchain, the password encryption and then queried with google API?

I ask this because I am interested in learning more about your project :smiley:

3 Likes
8

Yeah, thanks for the interest :slight_smile:

Let me answer the questions one at a time.

Answering question 1:

TL/DR: Not account abstraction nor tree architecture with substrate. The idea is to make use of Shamir Secret Sharing (more details in bullet point 2)

  • Regarding existing password managers: I would say that they password recovery system depends on which one you’re talking about. Here are 2 to demonstrate the variety.

    • Google/Chrome password manager: This one, I believe, is tied to your Google account. So long as you can log in, you’red good. However, the fact that Google is able to “recovery” your account when you’ve lost/forgotten your password means Google had access to your unencrypted password the entire time.

    • 1Password: Their approach is similar to keyvault’s. For them, if your master password is truly lost, then your passwords are lost (assuming you’re not part of a “team” with a “Recovery Group”).

      AgileBits has no ability to decrypt your or your team’s data, nor do we have the ability to recover or reset passwords. The ability to recover or reset the account password or Secret Key would give us (or an attacker who gets into our system) the ability to reset a password to something known to us or the attacker. We therefore deny ourselves this capability. What this means for you is that you must not forget or lose the secrets that you need to access and decrypt your data.

      – from 1Password Security Design, page 12.

  • Shamir Secret Sharing is technique that allows you to take a secret, split it into n different shares (just think “pieces”) and be able to recover the original secret so long as you have at least m <= n shares. Cool thing here is that failing to meet the threshold, i.e. gathering less than m shares reveals nothing about your secret. (Here is a YouTube video that, I think, explains Shamir Secret Sharing nicely and with visuals: https://www.youtube.com/watch?v=K54ildEW9-Q .)

    • The difficulty is in how to distribute those shares to people you (sorta) trust and how to make it such that those people don’t lose said shares.

      So, my idea is to have a management layer on top of keyvault so that the shares to your encryption key is itself encrypted. Then, when you need to recovery your encryption key, you can reach out to your friends and be able to piece back together your encryption key so long as enough of your friends still have access to their keyvault account.

1 Like
9

Answering question 2:

Short answer:

No.

Longer answer:

First, know that keyvault is split into 2 main parts: a browser extension (does not have wallet access and so cannot sign txs) and a webapp component (this can connect to wallet and so can sign txs). The only time you need the webapp is for letting the blockchain know about your new/updated/deleted password(s).

So, the way to trick someone into signing a fradulent transaction is hijack the domain blockchainkeyvault.com and replace the transaction with a malicious version.

This is to say:

  • Yes, it is possible to trick users into signing fraudulent transactions, but would require the blockchainkeyvault.com being hacked without the user being aware.
  • No, it’s not as vulnerable as with wallet extensions.

I don’t know what gaurdrails I can implement to help prevent users from being tricked even if the domain blockchainkeyvault.com is hacked, but your question is definitely making me think. Maybe an announcement on Discord or telegram? I’m not sure, but am thinking.

1 Like
10

answering question 3:

The smart contract contains a Mapping/Hash Table where the key is the sender’s address and the value is a tuple of the form

(iv, ciphertext). The iv (initialization vector) along with the encryption key allows the user to decrypt the ciphertext.

The plaintext (decrypted ciphertext) will look like the following:

{
    "url": "<url>",
    "username": "<username>",
    "password": "<password>",
    "description": "<description>",
    "idx": "<previous version's index>",
    "timestamp": "<when this cred was last updated>",
    "deleted": <true if deleted; false if not>
}

What the user would send to the blockchain, or receive from the blockchain, is the (iv, ciphertext) pair which will look like

(
    'gaW9DL1Z4jzWpaSt',
    'Y+3qYp3eru8UZMIUoli0OHHbYdX06NDJSnaTyRe5NgRj21T+VBhl++8ZAl6pB+OYebYD+qXbHoT7A91K6L9ok/9i6Ds/a0WEV4/H62uroS+LRT2nh46mcznhfKnY3YvNtominEurNZG2Cnx2sxfSJNCD6TY6xjEDuIwF5saWkv/q5039KGVlZx9BqkIvVBRq1hhvwb3rpttlDMw='
)

(actual encrypted password btw).

The smart contract just stores the above data in an append-only array. So, something like

[
    (iv_1, ciphertext_1),
    (iv_2, ciphertext_2),
    (iv_3, ciphertext_3),
    ...
]
1 Like
11

Hi, thanks for the proposal.
That is a very interesting dApp. I have not seen this type before and think it is a good blockchain use.

I am not a technical person so I honestly don’t know if the security strength etc. is adequate.
So I would have to read the actual UX and documentation to get feedback, but this part seems to be missing at the moment.

I suppose I could test it locally since the code is available on Github, but the basic policy for dApp Staking is that it should be publicly available and usable.
So UCG may be suitable.

2 Likes
12

Hi, thanks for checking out my proposal :slight_smile:

I was actually confused by your comment about keyvault not being publicly available since… it is, just not yet on the Chrome Web Store. Then, I realized I neglected to list the website with the (half-complete) documentation on the proposal. Whoops.

The site is https://blockchainkeyvault.com. For the installation process of the Chrome extension, you can check out the steps listed either in https://www.blockchainkeyvault.com/docs#getting-started or https://github.com/lousydropout/password-manager-extension/releases/tag/beta-1.

As for keyvault’s suitability for UCG, I’m afraid I don’t understand the difference between UCG and dApp staking for developers even after reading what little I can find on UCG.

13

@lousydropout

Thanks for the thorough explanation about the project, I really enjoyed learning about this very interesting topic that would be implementing a password manager on blockchain, I am excited about how the project works.

From my side I see it as a fully functional project and as you yourself mentioned, with the minimum viable.

While it needs a more experienced person than me to review it, such as an auditor and a security leader, I see it as a project worthy of dApp staking, very innovative and capable.

Thanks for proposing this excellent project at Astar!

1 Like
14

Don’t worry @lousydropout, I’ll explain briefly:

Dapp Staking: is an Astar Network’s own program that is based on supporting developers in the development of their products or services, they earn a percentage of the rewards of the dApp staking blocks. The main requirement is that the product is minimally functional and deployed in Astar.

UCG: is a program to support developers who do not have a functional product yet, but have good ideas supported by the community. In this program you request 2M $ASTR from the community treasury and staking your dApp in the dApp staking, during 3 months you must use these earnings to build your product and move to the dApp staking program (this is being discussed to improve it).

In your case I see viable to move at once to the dApp staking because you already have a functional product, you just have to deploy it in Astar Network.

3 Likes
15

Thank you!
With this information, I do not see a problem with listing on dApp Staking.

When I refer to “publicly available,” I mean a state where general users can access and utilize the information without needing to view this Forum. If there is a web page and documentation available, then I believe the condition is met.

@Juminstock , thanks for explaining UCG!

1 Like
16

Always available to add value to the community :saluting_face:

2 Likes
17

Hi @lousydropout,
It seems to me very interesting and thanks for all detailed explanation.
Your project reminds me of another one: PhaPass.
Technically, the approach is little bit different but maybe you can find inspiration in it.
You have my support for your proposal.

1 Like
18

Oh, that’s neat! Thanks for sharing it with me :slight_smile:

It seems our different approaches also led to different complications in implementation.

I just contacted him over LinkedIn. Might be fun to discuss our design choices with each other.

Thanks again!

1 Like
19

Glad to connect the builders :handshake: :computer:

1 Like
20

This is a wonderful idea. I would like to try this service.
Since it’s a service where security is important, I’m curious about how audits are conducted and managed. Also, I think it would be helpful to have a visualized image of the mechanism when using the service.

1 Like