Sep 082014
 

Today on Reddit we saw a demo video of product called Sigsafe ― a small NFC tag containing a private key that can be used to sign transactions. As a developer in the wallet security space I figured I’d take a chance to talk about my first impressions and maybe compare it to the project I’m working on.

Better than a hardware wallet?

I have to admit the concept is pretty cool. An NFC tag would cost substantially less than a full blown hardware wallet like the Trezor, making this technology much more accessible to the masses. It also seems like it would provide a better user experience. There are no USB cables hanging off your device. No buttons to push. You just simply tap the tag against your device when it comes time to sign and you’re done. At the moment it looks like the design is fairly primitive, just one private key is stored on the device meaning you would be reusing the same address. But the Sigsafe whitepaper suggests more complex arrangements, such as Bip32, are possible.

Despite the positive initial impressions there are some issues, however, that might hold this technology back. As a number of people mentioned on Reddit, there isn’t a screen on the device. What that means is you never know what you are signing. Malware could, theoretically, hijack your wallet and swap out the destination addresses in the transaction before you tap to sign. Since you can’t verify what you are signing, you could end up signing away all your coins to a hacker. At the moment, no such malware exists but you would have to think if NFC devices like this became widely used, malware would certainly evolve.

I’ve encountered a similar issue with the software I’m developing. Mind you Android devices do have a screen, but my initial implementation didn’t show the transaction fee when prompting for authorization. Malware wouldn’t have been able to swap out the addresses without you seeing, but it could have burned all your coins in transaction fees just to spite you. Fixing this problem is still on my list of things to do, and doing so requires some clever hacks because you typically can’t calculate the fee for the transaction without access to referenced input transactions as well. I give this example just to show that you can’t write off malware authors. If something can be done, you have to assume they will do it.

The solution to this problem the Sigsafe developers have come up with is a bit of a hack, but might prove to be ‘good enough’. Basically, you could program the device to never sign transactions that send more that a certain number of bitcoins ― say 1 BTC. So if you did get hit with malware, presumably you would notice the coins didn’t end up at the right destination and would conclude your computer is not secure ― capping your losses at 1 BTC. You could set the threshold lower, but you would have to make multiple transactions every time you wanted to spend over that threshold. As I said, this isn’t a perfect solution, but it could be good enough for its purpose.

Another potential problem that I haven’t heard anyone talk about is entropy. How are the private keys generated? To maximize security, ideally we would want them generated entirely on the device. Most applications pull randomness (entropy) from the computer’s operating environment and run it through pseudo-random function. The technical specifications call for the tag to have a microcontroller ― basically an extremely tiny computer with its own processor and memory. But are microcontrollers capable of generating entropy sufficient for cryptographic applications? I didn’t know the answer to this questions so I just briefly skimmed some academic papers on the topic. From what I gathered, it looks like the answer is no for your typical microcontroller, but there are some varieties where it is theoretically possible.

In either case, it doesn’t look like that is approach Sigsafe is taking. From what I gathered from the whitepaper it looks like the keys are to be generated outside the tag and then loaded on it. The major problem here would be loading the keys securely. The only really secure method would be to use a permanently air-gapped computer ― which most people don’t have. Barring that, you could boot into a temporary operating system to try to isolate your work environment from malware. This is basically the same approach to creating a secure paper wallet, which if you’ve been around Bitcoin long enough, you know is way beyond the capabilities of an average person. So my concern here would be, if the average person has to securely generate and load their own keys on the tag, they almost certainly will screw it up eliminating much of the benefit of using a hardware device. The devs would need to find a way to generate enough entropy on the device to make it useful to the average person.

But overall it’s pretty cool and shows some potential. For the dirt cheap price it would likely provide a “good enough” level of security or at least it would be an improvement over a straight hot wallet.

Bitcoin Authenticator

So with that let me compare it to a project that I’ve been working on. Instead of requiring you to buy a separate device, either a hardware wallet or a NFC tag, it uses one that you already have ― your phone. A second set of keys are generated entirely on the phone and you get prompted for approval whenever you make a transaction. Stealing your bitcoins would require an attacker to compromise both your desktop computer and your Android phone.

In the default operating mode the mobile app communicates with your wallet over an encrypted TCP connection, meaning both devices do have to be connected to the internet. Given that, you may be tempted to say this type of security solution is more vulnerable than a hardware device where the keys are kept offline. That’s likely true, but only marginally so. Android tends to be a very secure operating system, especially for your typical user who likely doesn’t know how to disable Android’s defenses. The diagram below shows Android’s multiple layers of defense.

android_defense1

By default Android doesn’t allow the installation of any software that doesn’t come from the Google Play store ― all of which is screened before being added to the store. You can disable this block by going into settings>security and checking “Allow installation of apps from sources other than the Play Store”. Your typical user doesn’t even know this option exists, and neither do they have much of a need for it. I personally, only use it to test out alpha or beta versions of bitcoin software before they are released.

When you allow unknown applications, it doesn’t mean malware can just install itself without your knowledge ― Android will always warn you before anything unknown is installed and will only install it after you consciously authorize it. Even then, Android will cross-check it against Google’s list of known malware and scan it again at run-time. Finally, the software is sandboxed and only has those permissions which you explicitly give it. The bottom line is you really need to go out of your way or do consciously do something really stupid to get malware on your phone.

If you’re still paranoid about your keys sitting on a device connected to the internet, you can turn an old phone into a quasi-cold storage device. This is more or less my plans for my Nexus 5 after I upgrade to the Nexus 6. The Bitcoin Authenticator app will be capable of communicating with your wallet over Bluetooth (in place of TCP). So you can remove your SIM card and permanently disable your WiFi and now you have an offline storage device. The only communication to the wallet will be over Bluetooth. Could a virus on your Desktop use the open Bluetooth channel to infect your phone? So long as you didn’t have pre-exiting malware on your phone, it shouldn’t be able to. The only Bluetooth permission your phone will have at that point would be the Bitcoin Authenticator app, which can only handle very specific types of communication. And you could always wipe your phone and re-install Android if you are paranoid about malware.

So there are my initial impressions of the Sigsafe and how it stacks up against my projects. The best part about all of these projects is we are rapidly moving away from the old single-key hot wallet model that cost so many people a lot of Bitcoin in the early days. Good riddance.

Chris Pacia

Chris Pacia has been studying (and has continued to study) economics and political philosophy in his spare time for about 10 years. Formally, he has studied finance and marketing at Rutgers University (MBA). Chris is a Bitcoin Enthusiast and privacy Advocate. His writings and insight have been published on Liberty.me, FreedomsPhoenix eZine and AntiWar.com. You can find more of his writing at Escape Velocity. Tips Welcome at Onename.io/ChrisPacia

  No Responses to “Sigsafe: The Future of Wallet Security?”