Posted on 1 Comment

Sigsafe: The Future of Wallet Security?

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.


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.

Posted on 4 Comments

Using OneName for Bitcoin Addresses

If you’ve been paying attention to the Bitcoin space recently you’ve noticed the start of trend to swap out Bitcoin Addresses in the user interface with human readable identities using a decentralized key store (such as Namecoin). The first wallet to implement this (at least that I’m aware of) was RushWallet. I recently put out a video showing off a wallet I’ve been working on with Alon Muroch which more or less does the same thing. In my conversations with people I’ve been fairly surprised at the number of skeptics and harsh critics of this concept. So with this post I’m going to address the critics and go into much more detail of my ultimate vision for this technology.

The Problem

How do you currently communicate your Bitcoin addresses to people so they can send you coins? If you are physically standing next to someone, you can have them scan your QR code. That would be the most secure way to go about it. But what if you don’t have physical contact with people? How do you communicate your addresses over the internet? If you’re like most people you probably just copy and paste your address and drop it in an email, Facebook message, Reddit post, etc. Whether you realize it or not, this is a terribly insecure way to communicate your address.

When you send a Facebook message, the message first gets sent to Facebook’s servers then routed to the recipient. Any malicious server admin or employee could fairly easily swap out your Bitcoin Address for their own before forwarding the message along to the recipient. The end result is the bitcoins get sent to a thief and not to you. So anytime you use this method for communicating your address, you are placing 100% trust in the server not to be malicious. With other methods of communication such as email or reddit post, there is an additional line of attack. Since these methods don’t secure the communication with the server with SSL the way Facebook does, you are exposing yourself to a Man-in-the-middle attack (MITM). Anyone with the right capabilities (such as your ISP) can intercept your traffic to the server, swap out your Bitcoin address for their own, and forward it along to the server.

Thus far we’ve been rather lucky these types of attacks really haven’t occurred. This is likely because it’s just easier to hack people’s computers and steal their coins that way. But should Bitcoin become more common place, you can rest assured all avenues for attack will be exposed.

A Solution

Earlier this year the core developers unveiled the BIP70 Payment Protocol. Using this protocol you would send a signed payment request, including your address, to the recipient. The recipient’s wallet would check the signature against your public key to make sure the request is valid. If so, the address can be trusted to be legitimate. But how do you acquire the public key needed to verify the signature? The transmission of the public key can be MITMed just as easily as the address. Here the protocol employs X.509 certificates. A X.509 certificate is basically a public key which has been signed and independently verified by a trusted third party (a certificate authority). When you receive the certificate, your wallet will verify the certificate authority’s signature then proceed to verify the signature on the payment request.

But this seems like infinite regress. How do we acquire the public key of the certificate authority (the root certificate)? The answer here is it usually ships with your operating system. The wallet will verify the certificate authority’s signature against the root certificate in your OS’s root store. So to make the whole thing work, you have to trust both Certificate Authority as well as your operating system. In the vast majority of cases this level of authentication will be good enough as it’s fairly difficult to attack.

Right now, the payment protocol has caught on with the Bitcoin payment processors. If you’ve ever made a purchase from a merchant using, say, BitPay, with a compatible wallet (Bitcoin Core, Android Bitcoin Wallet, Hive) you’ve likely noticed the signed payment request. It works really well, and there’s a good reason to believe this will likely become the default payment mechanism for paying merchants.

My fear however, is that individuals are going to find it too cumbersome to sign up for X.509 certificates and will continue passing around addresses in emails, Facebook messages, etc. If I’m wrong here, then everything is fine. If I’m correct, we should probably come up with a more secure way for individuals to pay each other.

How About Web of Trust?

The problem of securely acquiring public keys isn’t new to Bitcoin. In PGP users have the option to use ‘web of trust’ to verify the validity of public keys. Imagine a scenario where Alice has downloaded Dan’s public key to send him an encrypted message, but she doesn’t know if she can trust it (it could have been MITMed). Charlie also has Dan’s public key and knows for sure it really is his (maybe he acquired it in person). Charlie can sign Dan’s key attesting to its validity. But this doesn’t help Alice at all because she doesn’t know or trust Charlie. But suppose Bob does know Charlie and has signed his key, and Alice knows Bob and trusts his key. Now Alice has a chain of trust that leads from her Dan and can trust Dan’s key.

The problem here is this sucks in practice. It’s very difficult (and a lot of work) to make enough trusted connections with people to verify all the keys you want to acquire. In the Bitcoin world where we want making payments to be seamless, this is unusable.

OneName as a Potential Solution

OneName is currently the most popular implementation of the concept of a distributed identity protocol. The basic idea is that you can take identity information (which can include a Bitcoin Address) and embed it into a block chain. Only the person in control of the private key can make changes and the data can then be downloaded from the block chain and acquired in a trustless manner. OneName is built on top of Namecoin, which is rather starved for development, but the alt coin isn’t of great importance. Another coin, such as Ethereum, could prove to be better for this purpose.

The idea here is that when you go to make a transaction, instead of entering someone’s Bitcoin address, you will type in a human readable name. The wallet will then use that name to query the blockchain and return the corresponding address. Here’s what it looks like in my wallet:


Looks great, but we aren’t without problems. First, currently the only way to get data out of the Namecoin block chain is to run a full heavyweight Namecoin node. This isn’t a viable option for most wallets (including mine) which are built to be lightweight and easy to use. Currently, what we do (this is pre-alpha mind you) is just query the OneName server, which in turn queries the blockchain and returns the address. But this brings us back to where we started ― placing 100% trust in a server. Just a little more fancy.

So we need to better way. What we can do here is to use the same Simplified Payment Verification (SPV) that lightweight wallets use. If you don’t know how this works, it was described by Satoshi in his white paper:


So what I would like to see is for either to guys running the OneName server, or someone else looking to improve on the idea, to implement SPV into the server. A wallet could query the server for the block headers. Then when querying for an address the server could return the full Namecoin transaction, the block it’s included in, and the Merkle proof. This would allow us verify the address really is in the block chain, and that the server didn’t just lie to us. I would build it myself, but I’m extremely busy with the wallet and authenticator.

Using SPV would eliminate just about all the trust in the server, but we still have problems. SPV only allows us to check if a transaction severed up to us is in the blockchain, but the server could still lie by omission. That is, refuse to serve up the latest transactions. In a Bitcoin wallet, this is semi-problematic. It basically amounts to a denial-of-service, but you don’t actually lose any money. You only fail to learn of some coins you actually received.

Lying by omission would be worse in the OneName context. It could mean that you might update your address in the Namecoin blockchain, and the server only tells other people of your old address. I don’t have a great solution here. I think the best we can do is make it a known rule that you need to retain the private keys for all addresses you upload into the block chain. If the server lies by omission, the payment still gets sent to an address for which you control the key. If you lose a private key, you will need to junk your name and create a new one to avoid placing trust in the server.

Who Am I Paying?

With most of the difficult stuff behind us, we still have the final issue of knowing who we are paying. How do I know that the +Mike I just sent coins to really is the Mike Hearn and not an impostor? Ideally Mike would tell me his OneName ID himself, preferably in person or over a secure communication channel. As long as he tells it to me, it doesn’t matter how many impostors are out there, I will still send the coins to the correct address.

But what if Mike doesn’t tell me his ID and I have to go searching for it? Well, this could be risky, but there are still things we can do to mitigate the risk. Right now OneName allows you to upload social media proofs to your profile. You can make a Twitter, Facebook, GitHub post basically saying “On OneName I’m +Mike”.


An impostor wouldn’t be able to fake that without access to your social media accounts. The impostor could post a fake URL to the proof such as:

But any wallet worth its salt would automatically check the proof and throw up a flag if it isn’t valid. We could even check that person has abandoned an ID this way. If you want to change IDs, delete your social media posts. The wallet will detect that the proofs are no longer valid.

In addition to social media verification, we could also do email verification. We’re all familiar with how email verification works. You enter your email into a website and it sends you an email with a link you need to click. OneName already does this when you sign up for name. The devs could easily sign your email address with their key and you could put the signature in your profile. The wallet could check the signature against their public key and prove your email is valid. This would require a trusted third party (a quasi certificate authority), but it would add an additional level of trust beyond just the social media proofs.

The only way someone could get scammed by an impostor after all this would be if they searched for a name (rather than having the person tell it to them) and didn’t personally know any of the social media accounts and proceeded to send the coins anyway. Obviously, it would be a best practice not to do that.

Stealth Addresses

The final piece of the puzzle is stealth addresses. Everything I just mentioned above would work, but would have the major downside of requiring you to reuses addresses. For privacy reasons, we are trying to nudge people away from address reuse, not encourage it. For OneName to be viable, we have to get stealth addresses up and running. If you don’t know how stealth addresses work, they basically allow you to post a single public key (a stealth address) which the sender’s wallet uses to generate a new (regular) bitcoin address for which only you have the corresponding private key. The sender’s wallet sends the payment to that new address making the payment unlinkable to your stealth address in the block chain.

Full clients can be configured to work with stealth addresses with a little work, but the problem remains making them work with lite clients. Bitcoind nodes are not configured to serve up data related to stealth address. You could configure a server to work with stealth addresses ― this is the Dark Wallet approach ― but you need to take care to properly implement a prefix filtering scheme that will preserve the privacy of users. I’m not familiar with how Dark Wallet implements prefix filtering (if at all at this point), but I tend to be somewhat partial to this proposal by Greg Maxwell.

What I would really like to see is Bitcoin Core upgraded to handle stealth address, even if it’s just as a service bit, that way wallets can remain purely P2P and don’t have to resort to querying a server for the stealth transaction data.


I hope you can see that we’re a long ways from a viable implementation of OneName in wallets. Those who criticizing it are doing so extremely prematurely. But I believe I’ve laid out a mildly compelling case for how we can swap out addresses for human readable identities for individual payments and do it in a trustless and fairly secure manner. Hopefully I’m wrong about BIP70 and signed payment requests become the norm for individual payments, but if I’m not, this proposal should be a good substitute.

Feel free to comment with issues/security concerns.

Posted on 1 Comment

Cold Storage: Brain Wallets – Security Methods Part III

Brain wallets are one of the most futuristic methods for securing bitcoin. They seem like the kind of thing that will be plot devices of heist movies in the future. They are very real but very risky especially if you have a lot of bitcoins in them. That being said, it can be super fun to have a brain wallet with just a little money.

A brain wallet is a Bitcoin address whose private key doesn’t exist anywhere digitally or physicallyonly in your mind. It’s a wild concept to us, but this means that you can go anywhere in the world, across any national borders, with your bank account safely in your memory.

So how does it work?

While it might be possible to memorize the alphanumeric characters of your private key, it would take forever and suck the fun right out of having a brain wallet. Instead, you can use an algorithm that converts a passphrase of your choice into a key pair. There are lots of websites that will generate these, but works just fine for brain wallets as well. It’s recommended that your passphrase:

  • includes letters, numbers, and punctuation marks
  • is longer than an average password (the longer the better)
  • doesn’t appear in anything published, ever…ever.
  • includes random mistakes or alterations (“…50 yOu’r3 t3LL!ng mE Th3re’s A chanC3…” instead of “…so you’re telling me there’s a chance…”)

It’s important to take these recommendations seriously. There are some disconcerting posts on Reddit written by people who had their bitcoins stolen because they used passphrases that weren’t strong enough.  The more random the better!

There are probably some exceptional situations in which it would be advantageous to keep a lot of money in a brain wallet. Maybe if someone was persecuted where they lived and needed a place to store their money that would be immune to web-wallet seizure, device confiscation, or having your house burned down and your paper wallets with it. Aside from that, it is not recommended to keep any significant amount of bitcoins in a brain wallet. The risks of forgetting your passphrase or dying before you can tell your family what it is are too great.

That being said, it is pretty fun to come up with a cleverly disguised passphrase and know that a small amount of your money is safely tucked away in your mind.

This article was originally published in a 3 part series on Linked here are parts one and two. Follow EveryDayBitcoin on twitter for more.