Maintaining security while juggling burning dependencies
We need invulnerable software systems, and we need them today, even if they are ten times slower than our current systems. Tomorrow we can start working on making them faster.
– Daniel J. Bernstein
Recently, an npm “event-stream” vulnerability was found. Many apps were affected, including Copay.
In the times where I trust others’ people code to handle my money, and more important, other people trust mine, I can’t stop thinking about how can we fight unavoidable vulnerabilities. I thank Bernstein for his insight into whether it’s something wrong with the way we code, not with the code itself.
Security! Security! Security!
In the quote above, D. Bernstein proposes to give up the speed to the security. But what if we go deeper and say:
Let’s put security first, even if it means worst user experience at first glance? And tomorrow we will start working on making it frictionless.
What security level could be reached if we dared to change user flow, and then think if there is a way to improve it?
Secure my Bitcoin!
Minimizing privilege is not the same as minimizing the amount of trusted code, and does not move us any closer to a secure computer system… The defining feature of untrusted code is that it cannot violate the user’s security requirements.
When we study crypto wallets, we can notice that the code goes into two buckets: one that needs and works with private keys, and one that needs them not. Why then have them on the same device in the first place?
Why don’t write a dead-simple signer app, reduce its’ input and output to the minimum, test it thoroughly and use it instead of using the big crypto wallet app with an Internet connection, many features, many extra dependencies and many unknown bugs?
Divide and conquer
It’s impossible to read through all of the dependencies’ code. But you don’t need to. Back to Bernstein, he calls this “trusted” and “untrusted” code.
The defining feature of untrusted code is that it cannot violate the user’s security requirements.
Take all your heavy-load features away from the app, even away from the device that stores private keys, build any numbers of features, using any kinds of dependencies: your private keys are still secure.
That’s what we do at flightwallet.org.
A little note: to successfully make any crypto transaction (Bitcoin, Ethereum), you need to undergo three steps:
Key thing is that your private keys are required only on the second step. And the next great thing is that you don’t need internet access there.
To interact with the outside world, the app uses QR codes and one-way channels (e.g. push service). App’s manifest file forbids it an access to the Internet.
The amount of code you need to review is literally one file*. Even if it has bugs, mostly they will break the app flow, but not violate user security, as the data integrity is double-checked.
* this is an oversimplification, of course we should put crypto libraries into “trusted” zone. But these are simple, too.
Look above the horizon
As times go, security requirements won’t go lower, and probably they will rise. We need to find the right way to build secure systems before that.
Join our experiment: Flightwallet is now in public beta test. If you are willing to contribute to the development, you can visit GitHub. If you’d like to have a chat our test a prototype, here’s our telegram chat and public iOS beta.
We are all humans and make mistakes, but we can build a strategy that protects us from them.
Now, when tomorrow we arrive at the security destination, we will start improving UX.
