Every Bitcoin conference is unique in itself — no BS, interesting discussions and most importantly, cool attacks. This year’s breaking bitcoin had attacks on hardware wallets, discussions on best wallet practices and much more to learn from. However, in the context of Hexa, two things caught our eye:
The first attack is pretty simple — you can head over here for the talk but the gist of it is pretty simple:
A. There was a linear correlation between the two coefficients of the quadratic polynomial generated for SSS (ie) while generating a and b for the polynomial y = ax² + bx + c, a and b were linearly dependent. This causes the system to fall from a 3/5 scheme to a 2/5 scheme (the talk explains more math). This would mean that two parties could collude with each other and retrieve the user’s seed and reduces resistance against collusion attacks.
B. Zion seeded the PRNG with a static value which can be reverse engineered from the app, compromising cryptographic security. This means anyone who possesses one of the shares and reverse engineers the PRNG value can recover the user’s seed, effectively making the system a 1/5 scheme (hence the clever name to the attack: Shamir Secret Sending, you share your seed in an indirect way to all your contacts).
Hexa relies on grempe/secrets.js to generate shares (and as a result, the polynomial). This package uses a PRNG according to the environment it is being run in (eg crypto.RandomBytes for nodejs). We assume that the implementation of crypto.RandomBytes, a standard library in node.js is cryptographically random and hence attack 1 is taken care of.
The PRNG is initialised in secret.js when a polynomial is required to be generated. There are no secret constants defined either in secrets.js or in Hexa and hence we believe there is no potential for an attack similar to attack 2 above. The potential vulnerability described by Bryan Bishop is with unmaintained node_modules and how that can affect the security of an application. A thing which we’ve always wanted to do but postponed until release is to review all our dependencies and catch ones which are outdated and not used. We have 138 dependencies in total (not counting sub dependencies):
- 1 dependency last updated in 2013
- 5 dependencies last updated in 2015
- 4 dependencies last updated in 2016
- 13 dependencies last updated in 2017
- 38 dependencies last updated in 2018
- 74 dependencies last updated in 2019
- 1 dependency is not on Github (only package published to npm)
- 2 dependencies are not on npm or the package’s name has changed since last used
Based on the analysis above, we will be making changes in Hexa to ensure that there are no packages older than 2017 used within the application. We have also set a stretch goal to make sure there are no packages older than 2018 which are being imported within Hexa. For detailed package wise analysis, checkout the gist here.
Another thing brought up by Bryan during the talk was to import dependencies using their hashes since package owners can force push a new (and potentially malicious) version to npm with the same version number. We will be making sure all dependencies in Hexa’s
package.json uses this format to prevent any entity from pushing malicious packages. While we would like to bring all dependencies in house to ensure greater control, the nature of Hexa as a mobile wallet makes it difficult to do so. We believe that staying up to date on ways to prevent vulnerabilities and taking measures to not import old npm packages is the best way to protect Hexa against malicious packages.
Thanks to Charles, Bryan and all the amazing people involved with the Breaking Bitcoin conference for ensuring the bitcoin community stays up to date on potential vulnerabilities.