Security Considerations while designing Hexa
Our goal behind building Hexa was to offer something that’s both secure and easily usable by people who are new to the cryptocurrency ecosystem. We had considered different attack vectors which could be used by bad actors and thought about how Hexa would handle each scenario. The following post details our intuition and thinking behind the choices we made in Hexa.
But First..
A major issue with self sovereignty is losing your credentials and as a result, potentially losing your life savings. This isn’t an attack vector since this is solely caused by user action (or inaction) but this is the primary cause of loss and Hexa seeks to address this by creatively making use of Shamir’s Secret Sharing and Multi-signature schemes.
Hexa backs up the seed by building on Shamir’s Secret Sharing (SSS) scheme and applying it in the context of Bitcoin seeds and other credentials (for more, checkout our technical whitepaper). By distributing parts of the seed to multiple peers in a secure way, Hexa improves resistance to loss.
Hexa offers two types of accounts — a Regular Account and a Secure Account. The regular account is meant for day-day transactions, one can imagine it as being similar to your wallet (or credit card) that you carry around everyday. The Secure Account is meant for saving (hodling) bitcoin, similar to your bank’s savings account. Hexa also backs up all metadata associated with your account in a secure (Hexa doesn’t know what data is being backed up) and decentralised (It is not stored on Hexa’s Servers or AWS, etc) way by using the same SSS scheme described above.
Now that we understand what Hexa offers, we can dive into the attack vectors. Attack vectors are broadly split into two categories:
- Attacks requiring user action
1. Physical theft
2. Phishing attacks
3. Malware attacks
4. Network attacks - Attacks not requiring user action
1. SIM Swapping attacks
2. Dependency attacks
3. Co-Signer attacks
4. Government Seizure
We explore each one of these attacks and look at how we think Hexa might be able to mitigate these.
1. Physical theft / coercion
Physical theft in Hexa’s context is when a user’s phone is stolen. For this, we offer two layers of protection — the first is the PIN that is needed to unlock Hexa. Even if an attacker is able to unlock the user’s phone, they would still need to know the pin to unlock the app. The second, which is exclusive to the secure wallet, is two factor authentication. Hexa strongly advises its users that the 2FA app be on a separate device and as a result only if an attacker gains access to both devices, they would be able to move funds from the secure account.
Physical coercion is when another person forces a Hexa user to give up his password or PIN. In such a scenario, the regular account would be affected but the secure account’s threat model remains the same as explained above. As a thumb rule, we believe the regular account should only hold funds that the user wants to spend in the short term and we expect our users to use the regular account in a similar manner.
2. Phishing attacks
Phishing attacks are when an attacker impersonates Hexa and tries to gain information that could be used to compromise the user. As such, Hexa doesn’t even know your email / phone number, so such an attack vector is impossible. Hexa also doesn’t reach out to you for marketing or product update messages, so any email that looks like it originated from Hexa should be treated as spam (including those sent by team members, whose accounts could have been potentially compromised).
3. Malware attacks
Phone Malware is another attack vector where someone installs malware on a target user’s phone. While the regular account is vulnerable to such malware, the secure account stays isolated since it requires that malware be installed onto a secondary device as well. For regular accounts, this is one piece of the puzzle that we’re still actively looking into, and would welcome any suggestions that work towards mitigating this.
4. Network attacks
All of Hexa’s requests are made through https and end-end encrypte, and a MITM server / attacker wouldn’t be able to make out what requests Hexa makes to the Oracle. Communication between Hexa’s users is upto the users of Hexa — this could be Whatsapp or any popular messaging platform.
5. SIM Swapping attacks
SIM Swapping attacks have been on the rise and it has become clear that phone based authentication is unreliable. That is why Hexa never relies on an SMS or a message based scheme — all of Hexa’s communication is end-end encrypted in-app and our two factor authentication scheme is app based (like Google Authenticator). Things like secret sharing which require out of band communication can be done through QR codes or with an OTP encryption on other channels.
6. Dependency attacks
Recently, hacking packages on npm and distributing malicious versions has become a popular way to cheat users of their money. The way this would work is a malicious user would gain commit access to a popular npm package and force push a malicious version whose version number matches with the previously legitimate version number.
Hexa aims to tackle this in a couple ways. Firstly, for our release versions, we aim to refer packages by their hash version. A malicious entity can’t publish a new version with the same hash and we assume that this is infeasible. The second is that for our release version, we aim to bring all packages that have not been updated in the past 12 months in house. This way, unmaintained packages are under our control and new malicious versions can’t be pushed to the npm repository. We do note here that this isn’t a silver bullet and attackers will continue to adapt as solutions arise but we will make to implement cutting edge suggestions made by experts in the field to keep our users and app safe.
7. Co-Signer attack
Hexa relies on a signing server in order to sign secure account transactions. If an entity hacks the signing server (or gains access to one of the server admin’s SSH keys), they only gain access to encrypted blobs that are stored against a user’s wallet ID. An entity could configure the server to track ips but we believe we will be notified before then and take necessary action.
Another possible attack is when communication with the server is blocked. In this case, Hexa falls back to QR code base communication and nothing is affected. In the event the server is permanently down, users can use the popular ga-recovery tool to restore funds from their secure account.
In the event our hosting provider (Google Cloud Platform) is hacked, we believe Google will notify us of the same and we can (again) setup a new server somewhere else. A potential solution of running our own servers is in the works and once we have our own distributed server system, Hexa would be immune to this class of attack.
8. Government Bans / Seizure
There are multiple ways for the government to prevent users from using Hexa — preventing the app from being in the App Store, DNS hijacking and more. We believe that if the government bans an app from the app store, users can install the app through other means. For DNS hijacking and other means, using VPNs or something similar could help mitigate these issues but we assume there would be bigger problems and implications if an attack of such scale were to happen.
Our mission was to create Hexa in a way that it was easily usable without compromising on security or other features. These attack vectors are only a small part of the design decisions we think about at BitHyve, and more articles will follow, explaining each part of our design process.
Hexa is a non custodial, bitcoin only wallet focused on expanding the reach of bitcoin to everyday users. Checkout hexawallet.io to know more about the wallet and our GitHub repo to learn more about what we’re building.
