BC Vault uses a local HTTP/S proxy server called a daemon to allow third party web applications to communicate with the device. We are working with many partners that will soon provide additional services for BC Vault users.
These services must be provided in a secure way, with exactly the same security measures taken as the desktop application. This means that your public addresses or any other information from BC Vault are not visible to any website without you entering your global password and PIN to unlock the BC Vault. As the daemon is running and is accessible solely on your local computer (localhost – 127.0.0.1) there is no need for HTTPS communication (which is used to verify the integrity of remote connections). We use HTTPS in the daemon because some browsers (IE, Safari) do not allow HTTP access to localhost from websites using HTTPS. This means that the BC Vault daemon would only be accessible from Firefox and Chrome, and only on newer versions. Not an ideal situation for users.
HTTPS requires a certificate signed by a trusted certificate authority to be trusted by browsers, this means you cannot just generate your own certificate for bc-vault.com and claim it as legitimate. Unfortunately, this leaves the daemon with no other option for compatible communication. It must be HTTPS. The private key MUST be available to the application for HTTPS to work. Initially we opted to use a CA signed certificate with the private key shipped in the BC Daemon binary. We considered the possible threat vectors from releasing this and could not determine any potential attacks as the hostname in question points to 127.0.0.1, or the local machine.
This private key was encrypted with the following message to the potential “attacker”:
“If you find a private key for localhost.bc-vault.com please remember that it’s only valid for a DNS record that resolves to 127.0.0.1 This is done so that browsers can communicate with the daemon without ssl errors.”
There is one scenario where a certificate like this could be used maliciously, but that would require successful DNS Spoofing or phishing attacks, where a user would be tricked into entering passwords, pins, or backups into a website claiming to be from BC Vault. This website would have the URL https://localhost.bc-vault.com. The only benefit of an attacker obtaining the private key to this certificate would be that they could use the URL https://localhost.bc-vault.com to trick users or redirect daemon communication to their servers, but without the ability to get anything more than passwords. Even if they would succeed in executing a very well timed DNS spoofing attack, an attacker would have no way of communicating with a local BC Vault device from a remote server. There are no other security implications for users.
As the regular BC Vault workflow does not involve any inputs to the browser, we currently do not think that such an attack would be useful at all. A malicious attacker could more easily register a similar domain name like secure.bc-vault.mydomain.com, buy a universally trusted certificate for a small amount or even for free, and get the same or very similar results even without DNS Spoofing if the user is not careful enough. This is called phishing and is not unique to BC Vault but affects all internet services like Gmail, Facebook, Twitter etc.
We have since revoked this certificate to alleviate concerns from some outspoken members of the community and are working on a different solution that involves uniquely generated certificates for each installation. This is exactly the same end result and both are considered a de facto industry standard (Read more: https://letsencrypt.org/docs/certificates-for-localhost/ ), the private key still needs to be stored locally on the user’s machine. The only difference is that each user has a unique certificate. The security implications for the user remain the same. Users should note that the only thing the daemon will ever ask you for directly in your browser is your password, as it is required to access your BC Vault. It is very important to never enter your PIN or send your backup to any website.
We knew about this approach beforehand but opted not to use it to avoid needing administrator permission to install BC Vault, as we have to add a self-generated certificate to the operating system’s certificate store. These certificates will only be valid for localhost, no more localhost.bc-vault.com. They will NOT have root CA permissions and do not impact the security of any other websites.
This is how the password prompt for the BC Vault daemon currently looks like in the Chrome browser:
Users should take care to verify these elements:
- The address should be ‘localhost.bc-vault.com’ (versions <= 1.3.3) OR ‘localhost’ (versions >= 1.3.4)
- The port (specified with a colon ‘:’ after the address) should be 1991
- You should have initiated some sort of action on the website (i.e. clicking a button that needs your wallet information)
- Nothing else is required to be input but your password. The daemon will NEVER ask you for your PIN or Backup.
If users so wish they can also completely disable the daemon and lose web functionality, should they not need it. This option is available in the BC Vault application settings.
