Wallet Logo

BC Vault One

🔍 Last analysed 10th December 2021 . No source for current release found

Jump to verdict 

Help spread awareness for build reproducibility

Please help us spread the word discussing transparency with BC Vault One  via their Twitter!

Do your own research!

Try out searching for "lost bitcoins", "stole my money" or "scammers" together with the wallet's name, even if you think the wallet is generally trustworthy. For all the bigger wallets you will find accusations. Make sure you understand why they were made and if you are comfortable with the provider's reaction.

If you find something we should include, you can create an issue or edit this analysis yourself and create a merge request for your changes.

The Analysis 

Private keys can be created offline

Yes. BC Vault uses “nondeterministric wallets”. This is a short snippet of BC Vault’s security overview. It does not use seed phrases.

To ensure the generation of truly random numbers BC Vault uses input from the built-in hardware gyro sensor and various timings. BC Vault solves the problem of random number generation using a truly random number source: the human shaking the device in a unique way. Each wallet generated on the BC Vault is totally unique and not linked to any other wallet on the same or any other device. This is called a nondeterministic wallet.

This is important, because even if you are completely compromised, with passwords, pins, and your device or backup in the possession of an attacker, all your future wallets on the same device will not be affected. The attacker would have to get the backup again every single time you create a new wallet (if you don’t use wallet passwords or pins, in which case the attacker would also need that!).

Some other crypto wallets do not use this approach but use BIP39/44 deterministic wallets. The crucial difference is that wallet/private key entropy is only calculated once for all wallets past, present or future. This allows users a convenient backup system using 24, 12 or 8 words to encode all private keys. One serious drawback of this approach, and why we decided against it is that the attacker only needs these 24 words for total control of your wallets past, present and future.

Private keys are not shared

From the main page of BC Vault:

Private keys are stored encrypted in a state of the art storage medium called FRAM that has full data retention for over 200 years (at +35°C) and is not affected by magnetic fields.

The raw private keys can be shared with the owner in its raw hexadecimal form but only upon downloading version 1.3.2 of the firmware. It’s worth noting that this is not an intended feature of the device and was only allowed due to user demand.

Backups

Backups can be performed using a MicroSD card or by printing a paper QR code backup.

They did mention potential downsides to printing the QR code on a piece of paper.

Device displays receive address for confirmation

The BC Vault can display the public address both on the PC and on the device. This can be seen in this demonstration video. The confirmation of transaction details are possible via the large display the device provides.

Interface

From their homepage

Each initiated transaction from the desktop application has to be approved on the device itself. All transaction details can be seen clearly on the OLED for confirmation.

Reproducibility

The hardware wallet is closed source and only has 2 repositories bc-js - a Javascript API for integrating BC-Vault, and bc-vault-wallet-provider - A wallet provider for web3-provider-engine, on its GitHub page.

(ml, dg)

Verdict Explained

Without public source of the reviewed release available, this product cannot be verified!

As part of our Methodology, we ask:

No Source!

Is the source code publicly available?

If the answer is "no", we mark it as "No source for current release found".

A wallet that claims to not give the provider the means to steal the users’ funds might actually be lying. In the spirit of “Don’t trust - verify!” you don’t want to take the provider at his word, but trust that people hunting for fame and bug bounties could actually find flaws and back-doors in the wallet so the provider doesn’t dare to put these in.

Back-doors and flaws are frequently found in closed source products but some remain hidden for years. And even in open source security software there might be catastrophic flaws undiscovered for years.

An evil wallet provider would certainly prefer not to publish the code, as hiding it makes audits orders of magnitude harder.

For your security, you thus want the code to be available for review.

If the wallet provider doesn’t share up to date code, our analysis stops there as the wallet could steal your funds at any time, and there is no protection except the provider’s word.

“Up to date” strictly means that any instance of the product being updated without the source code being updated counts as closed source. This puts the burden on the provider to always first release the source code before releasing the product’s update. This paragraph is a clarification to our rules following a little poll.

We are not concerned about the license as long as it allows us to perform our analysis. For a security audit, it is not necessary that the provider allows others to use their code for a competing wallet. You should still prefer actual open source licenses as a competing wallet won’t use the code without giving it careful scrutiny.

The product cannot be independently verified. If the provider puts your funds at risk on purpose or by accident, you will probably not know about the issue before people start losing money. If the provider is more criminally inclined he might have collected all the backups of all the wallets, ready to be emptied at the press of a button. The product might have a formidable track record but out of distress or change in management turns out to be evil from some point on, with nobody outside ever knowing before it is too late.