Category Archives: Bitcoin

Attacker Mind Map for Bitcoin

Leave a reply

When thinking about how to protect something its useful to think about who you are protecting from. This normally starts with brainstorming categories of attackers along with their capabilities and motivations. From there you often move on to defining persona’s for the attackers that help personalize and more granularly categorize their skills, resources and motivations.

This is just a quick stab at a Mind Map of who potential attackers are for a Bitcoin business, you may also be interested in the post I just did on Bitcoin itself. Both are far from complete but they might be useful to you when thinking about how to to protect your systems and prioritize appropriately.

Bitcoin Attacker Capabilities and Motivations

A Bitcoin Risks Mind Map

Leave a reply

This morning I spent some time putting down some the risks relating to Bitcoin that I considered before I made the switch to focusing my efforts on this space.Mind Maps are a great way to collect your thinking and XMind is a great tool to create them with.

This map is far from complete but maybe it will spark your imagination.

Bitcoin Risks

Hardware Based Key Management and Bitcoin

Leave a reply

Hardware based key management solutions like Smart Cards and Hardware Security Modules provide a lot of value. Probably the most important being that the keys are moved out-of-process into a totally separate computer. This goes a long way towards protecting keys from being stolen via by malware or exposing keys to an attacker via software defects like happened with Heartbleed.

Depending on the device you choose you may also get:

  1. Third-party assurances that their cryptographic implementations and random number generators are sound which is incredibly hard to be sure of when you just pick something up blindly off the Internet.
  2. A verifiable supply chain with third-party assurances and audit trails the devices have not been tampered with.
  3. Hardware that makes it obvious it has been tampered with and is resistant to such attacks.
  4. Protection from side channel attacks such as Differential Power Analysis, Electromagnetic Leakage and Timing Attacks.
  5. Basic policy enforcement mechanisms like preventing keys from being exported, limiting which users can use them and requiring M of N users approve.
  6. Mechanisms to securely clone keys from one device to another to improve survivability of failure and compromise.
  7. Some devices support the concept of “Remote Pin Entry Devices” so that the cryptographic device can be stored in one location but the tokens used to approve an operation to happen with the keys managed by it can be located anywhere on the globe.

Despite how valuable these solutions are they are not without their shortcomings one of which is that for the last twenty years they have not changed much short of getting faster and adding support for newer mandated algorithms.

One of the reasons these devices have not changed is that Common Criteria (CC) and FIPS 140-2 verification, the standards they must conform with to be sold to their largest customers, make it excruciating hard to change and as such the incentive model is set up to discourage innovation and often encourage bad behavior.

These restrictions also have resulted in them not supporting algorithms not mandated by these standards this means in the case of Bitcoin the decision to use secp256k1 in the protocol precludes their use or limits their use to a limited feature set and significantly reduced performance.

Additionally since PKCS#11 (the library one uses to work with these devices) doesn’t specify how to generate a secp256k1 key any code written to use such device ends up being proprietary.

The net-effect of this is if you buy one of these devices your going to be spending $5,000 for a device that gives you some of the above properties that you can write custom software on that would be able to do about 24 secp256k1 operations a second.

This is more than enough for a personal wallet but nowhere near enough for an exchange or payment provider; which means these vendors, are not using these sorts of techniques to keep your keys safe.

There have been a number of solutions that have been started by individuals to bring some of these protections to Bitcoin to-date they are all incomplete, unusable, unmaintained or not available.

The most promising being the Trezor but based on what we know of these systems its seems very unlikely they will provide the kind of protection one gets from a commercial hardware security module or many of the other features these devices often have.

And even if they do since they are for the most part by individuals with limited resources who knows if they will be around or available a year from now? If you have lots of Bitcoin in these devices and the vendor goes down or the device fails what are you to do?

That is not to say this these projects are not good, in-fact I will order a Trezor once they start taking orders again but they should be thought of as a Wallet and not a Safe or Vault as they will not protect from a well healed attacker and without much more work are not appropriate for cold-wallet storage of large amounts of Bitcoin.

If you don’t hold it, you don’t own it

Leave a reply

If you know anyone who invests in precious metals you have probably heard the phrase “if you don’t hold it, you don’t own it”.

This old adage comes from the risks you are exposed to through use of services that practice things like fractional reserve banking and non-segregated storage of assets. Though personally think these practices can result in significant value for the depositor one can not reasonably argue that they do not come with risks.

This is particularly interesting for Bitcoin; not for political or dogmatic reasons but ones of practicality. Today Bitcoin is in many countries considered “property”, that it has a market capitalization of over 5 billion as of today and that the top 500 Bitcoin addresses control over 30% of all Bitcoin it seems there is quite a lot that these high-net worth users can learn from people who have invested significantly in precious metals.

With that in mind I thought it was worth talking about a set of guidelines people can consider when answering the question of “how should I hold my bitcoin”

Invest proportionally to the risk; if you have forty million dollars worth of Bitcoin you should use different strategies than someone with twenty thousand dollars in Bitcoin additionally the your ability financially to survive the loss must be considered.

Plan for the worst; as they say, “locks keep honest people honest” and “to error is human” as such we must have ready plans on how to handle attacks and compromises when and if they occur. 

Trust but verify; verify the claims and that the technology and service providers you use provide and regularly check on your assets and ensure they are still accesible.

Understand your risks; it’s near impossible to devise a security strategy that will effectively secure anything without having a solid understanding of the risks you are exposed to.

Don’t rely on technology alone; while technology hold promise in securing these assets we in many cases the path of least resistance is to just take physical control of them.

Learn from the past, design for the future; while we all may enjoy pointing out the ridiculousness of the TSA’s reactive strategy of threat analysis understanding attacks that have come before is key to understanding how to physically secure your assets.

Diversification, Diversification, Diversification; whatever approaches you take don’t put all your eggs in one basket. You do not want a failure of a single mechanism to result in the loss of your stored assets.

You can’t hack what you can’t find; though security through obscurity isn’t exactly a solid security design strategy it’s origins come from physical security where it has much more value. Keeping your location and control mechanisms confidential makes it harder for your attacker.

With that in mind you have a few choices to base your strategy on these include:

  • Residential quality home safe
  • Commercial quality safe
  • Bank safe deposit box
  • Bitcoin vaulting service
  • Private vault
  • Depository facilities

If you’re leveraging secret sharing chances are you will use several of these in your final solution. This helps quite a bit in that when it comes to physical storage using a third-party your biggest risk is that facility.

Of course even when you distribute your shares to multiple facilities you have the question is how you secure the secrets that are used to protect those shares.

By ensuring both the shares and the secrets that protect them are geographically distributed and under the control framework of different third-party facilities you reduce your risks significantly.

I am hopeful that within the next few years we will also see increased adoption of P2SH and hardware security modules / smart cards designed around cold wallet scenarios; these have the potential to raise the bar even further but do not replace the need for proper physical storage.

PiperWallet First Impressions

1 Reply

So I just got my PiperWallet. For those of you not yet familiar with it the PiperWallet is an open-source hardware bitcoin wallet based Electrum running on a RaspberryPi paired with a built in thermal printer in what looks like a 3D printed chassis.

The basic idea is that managing cold wallets is hard and it doesn’t have to be.

Even though I have only started to play with the device overall I am impressed. Here are my initial observations:

  1. It was packaged well considering the volume in which they are produced;
  2. The quality of the casing is also good considering the volume;
  3. The cut outs are a little rough and are larger than the connectors they expose;
  4. The primary “indicator LED” that is used to show that the device is booting is not terribly bright;
  5. Without reading the instructions (or waiting a sufficiently long time) it’s not  obvious when the device is ready;
  6. The print button LED is bright and of excellent quality;
  7. There is no positive feedback when the print button is pressed.

So far I am happy with the purchase though I need to do some more playing with it before I make any final conclusions.

With that said here are the things I think I would change if it were my product:

  1. Make the serial numbers on the paper wallets randomly generated; you un-necessarily leak information by using monotonically generated serials;
  2. Add tamper evident seals to the casing so that if the device is opened during shipping it is obvious;
  3. Add tamper evident seals or “plugs” over the ports exposed on the device, possibly even dummy plugs with seals so its clear nothing happened to the device as part of shipping;
  4. Add per-device fixed wallet keys to be used as a serial number to the back of each case (there is a wallet address but I believe this is an address of the Piper team);
  5. Use per device passwords shipping them on a form similar to the one I provided here;
  6. Replace the indicator LED with one with a similar brightness and quality to that used in the “print button”;
  7. Add a small LCD display that can be used to provide real-time feedback and status so it’s easier to use when headless;
  8. In the documentation included have the steps to verify what software is running on the device along with hashes to do so.

Verifying a Bitcoin Wallet Address

Leave a reply

Before sending someone a large sum of money on the internet via a irreversible transaction you better make sure you are sending the funds to the right address.

There are a few ways to go about doing this and depending on who you are sending funds to, how accessible their keys are and what the capabilities and behavior of their wallet software is you may need to choose different solutions.

Have the recipient sign a message using their wallet key

If we assume the recipient has the key associated with the target wallet online (aka not in cold storage) and that that the software they use for that wallet supports message signing with wallet keys this can be a viable option.

Unfortunately there is not currently a standard for the format of signatures using bitcoin keys with that said thankfully there appear to only be two common formats in-use today.

The first format being in-essence no formatting; client simply present you the three values you will need to verify a message and you do with them as you see fit, for example:

  • Wallet Address: 18neTpQ5MWnXg4n4rpoK5TgxXjEVcg2MYR
  • Message: [email protected] – my voice is my passphrase authenticate me
  • Signature: G0d6BnQem1gT4nd9esfsEyn1k/GfYAxDkNJmkNvmz8wCOI2Ncw9DvIcyP7OJcEvWbUHQNIBFK3V8wYdnhEFhYHI=

This format leaves a little be desired. For one you have to pass these values independently and then you also have issues around introduction of white-space which can invalidate signatures.

There is another increasingly common format that leverages ASCII armor and some codified rules to address these issues. This style of formatting originated in a project called Privacy Enhanced Mail (PEM), it was one of the first proposals for how to sign and encrypt mail on the Internet and was later adopted by PGP (RFC https://tools.ietf.org/html/rfc4880).

But don’t confuse this format with these other formats they follow some different rules when it comes to encoding.

What this means is that depending on the implementation of the wallet software the recipient uses you may not be able to validate the signature they produce without some manipulation of the text.

As for what this format looks like, its fairly straight forward:

-----BEGIN BITCOIN SIGNED MESSAGE-----
[email protected] - my voice is my passphrase authenticate me
-----BEGIN SIGNATURE-----
18neTpQ5MWnXg4n4rpoK5TgxXjEVcg2MYR
G0d6BnQem1gT4nd9esfsEyn1k/GfYAxDkNJmkNvmz8wCOI2Ncw9DvIcyP7OJcEvWbUHQNIBFK3V8wYdnhEFhYHI=
-----END BITCOIN SIGNED MESSAGE-----

The core differences with this format (as specified in this thread and the PGP rule-set are:

  • No “empty-line” delineator between the headers and message;
  • Beginning and end whitespace / newlines ignored excluded when verifying the signature;
  • Length of rows are not limited to 80 characters;
  • No concept of header values (like versions).

The reason I point this out is that since there really isn’t a standard for this signature format and the format diverges from what has been used historically you may still encounter interoperability issues when validating messages between clients that have not been tested with each other.

With that said when you have managed to successfully verify a message like this you know that whoever produced the message owns the key associated with the wallet associated with it.

To address the risk of a message substitution the sender would need to communicate a challenge out of band to the recipient. For example you may notice in my message above I included “my voice is my passphrase authenticate me”. My inclusion of this message (presumably exchanged out of band) helps assure the sender that it was me who signed the message.

To make this process a little easier Andrew Yanovsky and I put together a simple site that can validate both formats, it’s all client side so you can save the files locally and run without the dependency on the website if you like.

NOTE: It is worth noting that this workflow does not accommodate P2SH and multi-signature wallets both of which will see increased use as time progresses.

Do a micro-transaction

The simplest way to verify an address is to simply send a small amount of money to that address and verify out of band with the recipient that they confirm seeing it in their balance. This is what most online payment services but again this requires the keys to be accessible to the sender they can perform the transaction.

There are a few things to keep in mind if you go this way, specifically:

  1. Don’t send less that .0001 BTC because the transaction may get “stuck” and not be processed.
  2. Be sure to include some transaction fee even if tiny so it doesn’t stay unprocessed for too long.

Once the transaction has been sent and you use a tool like blockchain.info to see that the transaction has been confirmed you can verify out of band with the address owner again that they see the funds as well.

This approach unlike the wallet signing key approach can also work with multi-signature and P2SH wallets which will be in use increasingly as clients better support these techniques.

Verify the wallet address two times via out of band channel

If they keys are offline (in cold storage) the only viable option is to carefully validate each character of the address via an out of bound secure channel, I would personally not rely on this approach for large sums but if both parties are careful it can work. By doing the check twice you reduce the chance of human error but mistakes can happen and in this case they can not be undone so use this approach with caution.

None of these solutions are perfect and moving forward I expect we will see services like OneName.io and exchanges with authenticated account profiles will become the way that we solve these problems but in the mean time you can reasonably manage the transaction workflow via these two mechanism.

Why shouldn’t you use safe-deposit boxes to store Bitcoin?

Leave a reply

Banks are not exactly what they used to be. I don’t know exactly when it changed but as a boy I remember banks being these massive buildings with large vault doors, armed guards and cameras everywhere but it seems increasingly they are located in strip malls right next to a Great Clips with nothing more an alarm and a small safe in the back. Frankly most don’t even offer safe deposit services any longer.

The lack of security of these facilities offer is not why I don’t recommend their use; it is because they can’t be trusted to keep your valuables safe. Not only can the federal government seize the contents of these safe deposit boxes at will increasingly the state governments are doing so as well as a means to shore up their own finances via their unclaimed property programs.

You can mitigate some of these risks by using techniques like Shamir Secret Sharing to split your keys up into M of N parts or by utilizing multi-signature wallets where the parts or keys are stored at different facilities reducing the likelihood of these events impacting you (which you should do regardless) but as a general rule I recommend use of private facilities instead.

Private facilities have a number of value propositions above and beyond banks, these include:

  1. Not regulated which makes it more difficult for the contents to be frozen or seized
  2. Identification is often not a requirement to open an account making targeting assets in the vault more difficult
  3. Not subject to bank holidays (for example during 9/11 banks were closed in the US)
  4. May offer:
    1. Insurance that would protect you from loss;
    2. Improved security protections and procedures;
    3. 24x7x365 access to the facility;
    4. 24x7x365 armed guards;
    5. The use of “ceremony rooms” where you can privately perform transactions.

Above these value propositions a few things to keep in mind when looking at these facilities are:

  1. Do they offer dual key control? This is when they keep one key and you keep the other. This helps mitigate the risk of your key being stolen.
  2. Did they their ceremony rooms offer you sufficient confidentiality and space to perform your transactions?
  3. Do they limit how many people can be in the vault at a given time?
  4. Is the construction of the facility done in such a way that physical compromise would be difficult?
  5. Do they have adequate camera coverage and keep the recordings long enough to be useful to identify compromise?
  6. Do they follow strict procedures or are they overly lax?
  7. Do they have any attempted thefts and if so how were they handled?
  8. Have their ever been any legal claims from their customers?
  9. What are the BBB & Yelp reports for the facility?

Regardless of which facilities you choose to store your Bitcoin assets its also important to remember the old adage of “Trust but verify” and periodically access the assets to ensure their integrity and availability.

 

Bitcoin Paper Wallets and Digital Backups

Leave a reply

The folks working on Armory have done a wonderful job thinking about many of the risks associated with Bitcoin and Paper Wallets. The have even gone as far to consider the risks of a compromised printer with a feature they call SecurePrint™.

In the Certificate Authority world when managing secrets that can not be kept within a Hardware Security Module (HSM) we go a further by using similar key management tools on Tempest hardware physically located in Faraday cage under rigorous ceremonies designed to ensure every single step performed is confidential, verified and audited.

For the individual moderate Bitcoin holdings Armory provides a robust story for managing wallet keys and producing paper wallets especially when paired with something like the PiWallet. That said since once doesn’t need to physically take your Bitcoin (they can just take a copy of it) make it their own how you store it is also important.

For valuable secrets that must be stored on paper a Certificate Authority would fold the corresponding paper in half taping each of the open ends close using tamper evident seals.

They would then place each sealed paper into their own opaque tamper evident bags keeping inventory of the bag and seal serial numbers, who was present and then storing the bags and inventory in separate secure locations.

This not only makes it possible to detect what has happened with the stored paper but protects it from water as well. Consideration is also given to what kind of paper and toner is used; for most scenarios one would use archival quality paper and high quality toner. But paper burns and toners are made of organics that can break down in heat so electronic copies are often also kept.

When it comes to those electronic records the choice of what media you use to store those values is important, as many types of media are not reliable for long-term storage. Today I would use the MDISC which effectively engraves the data into a disc that is still readable by modern DVD and BluRay players promising the disc to be readable for 1,000 years.

Even though most data being stored would already be cipher-text one never wants to rely on a single point of failure and for this reason another layer of crypto would typically be used. Commonly this is as simple as using GPG or TrueCrypt with a password to encrypt the data you are going to write to the disc in-turn managing the security of that password carefully.

At this point your down to being concerned with the physical protections your storage facilities offer and ensuring you have long term access to the hardware and software necessary to use the artifacts captured above.

Keeping long-term passwords secured

Leave a reply

We all know that passwords should be changed regularly to reduce the value to an attacker and that they should be stored in ways that they can not be easily compromised which is why generally people are encouraged not to write passwords down.

The reality is that the human brain can only retain so much information and the less often you use something the more likely it is that you will forget it.

This is true regardless of how memorable your password happens to be.

This is especially true for passwords used in key management ceremonies. Imagine being there when the first keys were generated for the first root CA on the Internet, this is a key that will exist for decades and the implications for loosing access to this key are huge. More over the passwords involved in these ceremonies do not bellong to an individual, they belong to an organization.

For these reasons key management ceremonies use password record forms; I have attached an example form to this post for your reference.

These forms once filled out are stored securely, how securely being dependent on the security needs of the scenario. For example if the password was associated with a share in a Shamir Secret Sharing scheme (M of N set of keys) one would transport and store them securely in facilities geographically distributed under lock and an dual lock control scheme.

Periodically these stored values are retrieved and changed, as part of a process to ensure continued access to systems and keys is possible.

While not something the average person needs to deal with it is relevant to those doing paper key management for large amounts of Bitcoin, important DNSSEC keys or maybe keys embedded into some device that has been mass produced.

Protecting Bitcoin keys with hardware

Leave a reply

One of the most important things you can do to keep your Bitcoin keys safe is to get them off of your general-purpose computer and onto a single use device that is designed to perform cryptography or Bitcoin operations.

This protects you from a number of different attacks that could result in the compromise of your keys but it does so at an expense — it makes it more difficult for you to spend your Bitcoin.

This is of course not unique to Bitcoin; in the Certificate Authority world we think of utility keys (e.g. OCSP and Time-stamping) differently than we think of the keys associated with issuing certificate authorities (the ones used to sign subscriber certificates) which we think of differently than keys associated with root certificate authorities. As such we apply different key management techniques and policies to each of them.

The same is true for your bank accounts; you keep less cash in your checking account than you do your savings. This is in part because you have a bankcard and checks tied to the checking account which makes it easier for an attacker to access your funds.

If you manage your Bitcoin holdings in a similar way by having wallets for your “spending money” and wallets for your “savings” then you make it possible to apply security measures that balance convenience and security while managing your risk. These are commonly referred to as “hot” and “cold” wallets.

Additionally those people with large cash assets limit how much they keep in each account so they stay within the liability limits that their financial institutions offer (for example $250,000 USD in the case of FDIC insured institutions).

Traditional banks do the same sort of things; for example a bank with $80,000,000 USD is required to keep $8,000,000 liquid they then use the remainder in fractional reserve banking as a working asset to fund the bank. This also has the side effect of distributing the risk the bank is exposed to by distributing that capital into many different investments each with their own risk profiles.

So how does this all translate to Bitcoin and hardware key management? For most online wallets such as Coinbase are a fine way to manage the funds you spend regularly but for your savings its advantageous to manage these keys yourself instead of being part of a much larger target like an online wallet.

That takes us to Bitcoin key management solutions; Since its introduction there have been many proposed solutions. Most of these being based on either specially hardened and dedicated computers using LiveCDs like this one built on Ubuntu and this one in Tails, these images use wallets like Armory and Electrum to in these clean-room environments to perform Bitcoin operations.

The processes used here are logically equivalent to what Certificate Authorities do with “ceremony computers” where they use specially prepared Tempest rated computers in Faraday Cages with no visibility from the outside that have isolated power (protecting against Differential Power Analysis) to generate and perform operations with sensitive keys.

During these ceremonies ridged processes and controls are used to configure the machines using known software verifying every binary is as its expected to be, auditing every action under camera with multiple people auditing the activities taking place. Also when keys are generated they are protected using secret sharing schemes such as Shamir Secret Sharing and the shares are distributed to different parties who then travel separately and move those shares to secure storage facilities that are geographically distributed.

Obviously there are lots of dials you can “tweak” to control the time / complexity tradeoff involved in the above process but for those with moderate Bitcoin holdings the above would broadly be considered too onerous to even consider.

This is where turnkey products come into play while there have been a number of promising proposals producing something that is secure, usable and affordable is no small task and most of these projects have failed to achieve sufficient market penetration to succeed.

At this time the most promising solutions that are (to varying degrees available) are PiperWallet which is an Open Source printer with embedded RasberryPi that can be used to create paper wallets, based on its claims it has thought about all the right problems (quality of random numbers, etc.)

Another solution is the Open Source PiWallet, this isn’t terribly different than the PiperWallet conceptually (through it does not make any claims about the quality of its random numbers) but it doesn’t include any input or display without an added display and keyboard.

One of the most promising offerings in this space is the Trezor this is a custom designed device designed not only to be useful for cold wallet storage but for actual personal hot wallet use as well. I am looking forward to getting a chance to use one once it becomes generally available.

On the high end of the equation one could also use a Thales nCipher or a SafeNet while these devices are not Bitcoin specific they can be used along with a ceremony computer and a modified Bitcoin wallet to secure the keys used in your wallets.

Above and beyond these solutions there are a half a dozen half-done not maintained smart card solutions (1 ,2 , 3) that have potential but unless you’re a JavaCard developer and/or Smart Card Professional these are frankly not viable options yet.