Bitcoin and the credit card ecosystem

We use our credit cards every day yet most of us don’t really understand what happens when we swipe a credit card at a merchant. Did you know there are no less than six different players (above and beyond the consumer and the merchant) involved in a typical transaction?

Acquiring Banks – These are the retail banks that serve the merchant, you can think of them as the entity managing the bank account where deposits go for the merchant.

Payment Processors – These are actually the entities that really make credit cards work, they ensure everyone gets paid in accordance with the associated agreements. Some of the largest players here are FirstData, Heartland, Chase and Bank of America.

Issuing Banks – These are the banks that serve the consumer by providing them credit cards. They not only evangelize and sell the cards but own the customer relationship.

Service Providers – It used to be the only way to take credit cards was to work with your “acquiring bank” but now consultants handle this work for the banks.

Hardware Providers – Those clunky credit card terminals come from somewhere as to the point of sale terminals stationed in every retail establishment you visit. One of the largest is Verifon.

Credit Card Networks – This is Visa, Mastercard, American Express and Discover these guys don’t really clear transactions they instead establish the rules by which the system works and establish the technological standards the system uses.

Each one getting a piece of every transaction performed with that card, that cut can range from 2% to 3% of a transaction; if we assume the low end for a $100 transaction this looks something like this:

Merchant  $98.00
Issuing Bank  $1.50
Card Network  $0.15
Split between payment processor, Service Provider and Acquiring Bank  $0.35
 $100.00

This is of course before currency conversion fees, interest, card-fees, credit card rewards, charge backs and the numerous other variables at play in these transactions.

Some reports suggest in 2013 there were more than $4 trillion in these card-based transactions in the US alone. It’s also worth noting that in the US more than many other countries cards are being used for smaller and smaller transactions and this trend is likely to expand as cash becomes less convenient.

Startups like Square and Level-up are trying to disrupt these card-present transactions like Paypal has done for the card-not-present transactions and by doing so they are really going after a share of the that .35c that is currently split between the various players and the money the hardware providers get out of the merchant.

This is a great business but the sheer number of players involved in the system makes it hard to make ends meet. These players try to game the system by building additional products based purchasing behavior and batching transactions but the current system is so complicated with and has so many players its simply hard to get the slop out.

More over the standards set by the credit card networks are weak, the technologies these systems are based on are easily compromised and even their more secure counterparts based on chip-and-pin don’t live up to their security promises.

Then there is the question of usability of these systems which are far from optimum, we have all tried swiping our cards or entering the pin finding the readers unable to work with the cards or seen someone swipe the card the wrong way.

NFC has long been touted as the solution to some of these problems but despite being over 10 years old, has its own security issues, has hardly been deployed and at best is just a new hardware layer on the already overly complicated system.

One way to address these problems is to setup a separate system that runs along side this existing framework. This system would be designed to be more secure, easier to use and have fewer moving parts. Such a system if done right could get the slop out of the payments system, merchants could get paid quicker, keep more of their profits, consumers and merchants alike could experience less fraud and we could even have a more usable system.

Bitcoin has the potential to be the catalyst and foundation to make this happen; I don’t think we will see card-present transactions based on efficient models of bitcoin use in the near future but I do think it will happen.

If this approach can simply half the current cost structure of the payments that would put 1%-1.5% back in the merchants pockets, if along the way it reduces charge backs, currency conversion fees, and the other miscellaneous charges that infect this system it can foundationally change the way we look at commerce.

Bitcoin has this potential and I for one am excited to see what the next few years have in-store.

Proving assets under management is important but it is not an audit

Recently Bitstamp did a public display of assets under management and while I think its important they and others (like Kraken and the Vault of Satoshi) do this it does not an audit make.

Just look this video where Roger Ver attests things look good at Mt. Gox or what happened with Neo&Bee.

Don’t get me wrong what Bitstamp, Kraken and Vault of Satoshi are doing is great but they are not “audits” at least useful ones.

au-dit : an official inspection of an individual’s or organization’s accounts, typically by an independent body.

What kind of litmus test must be passed for me to consider something a useful “audit”?

  1. Does it look at evidence in balance? For example if someone has a million dollars in the bank but has signed first right debt agreements for two-million your still likely out of luck in the event they go under.
  1. Does it look at the complete picture? Its entirely possible an entity has all of its assets under its control and is debt free but the principals have unobstructed access to the funds or that the security and engineering practices are so lax that at any given moment a system can be compromised without detection.
  1. Does it measure practices to a standard? Audits are performed to some standard, for example the Sarbanes Oxley audits use a standard set of criteria that help assure financials are being tracked published accurately. While the WebTrust for CA audits ensures that certificate authorities are following common minimum standards for securing their operations.
  1. Is the standard relevant to the business in question? The risks in each system are different even if only subtly; there are many things in a WebTrust for CA audit that might be relevant to a bitcoin exchange but there are just as many things that are not the same is true for a SOX report. For an audit to be valuable it has to be one that was designed to prove something relevant.
  1. Is it performed by an independent third-party? Conflicts of interest are abound and when money is involved people often do the wrong thing. While the use of celebrity people from the community in a pinch is fine (and no disrespect intended) these individuals have a vested interest in the success of bitcoin.
  1. Is it performed by a qualified individual or group? Often times the “low bid” auditor wins but these are the same auditors who ask for stupid things.

So to-date has there been a single usfull bitcoin audit? I think its safe to say no. I would go so far to say that the practices of most Bitcoin entities are not actually audit-able because one has to design processes and procedures to ensure that they are and this slows down the “innovation train”.

In Coindesk post about Bitstamp’s “audit” Mike Hearn was quoted as saying “It’s a bit early to be setting standards yet” I would respond by asking the question if not now when? In my opinion this is exactly the right time to be tackling this problem.

These standards take time to be developed and have impacts on the way businesses operate and starting now not only ensures that the rapid growth in the Bitcoin ecosystem takes into consideration meeting some shared requirements on liquidity, solvency, audibility, transparency and security but by doing it now the requirements end-up being defined by the Bitcoin community instead of thrust upon it.

Regardless we need to be honest about what’s being shown when these events occur, they do little more than prove an entity has an amount of Bitcoin but nothing more.

Liquidity risk and management in Bitcoin

In finance, liquidity risk is the risk that a given security or asset cannot be traded quickly enough in the market to prevent a loss (or make the required profit). 

This of course begs the question how liquid do you need to be? Surely the answer is at least partially tied to the volatility of the asset in question and what your individual exposure to the potential loss might be.

When it comes to Bitcoin, at least more so than with physical assets, the more liquid you are the more at risk you are in that liquidity also means that the corresponding wallet keys are easily accessible.  And the more accessible the corresponding keys are the more at risk they are.

One can manage these risks a number of ways the most simple being not keeping “all your eggs in one basket” by keeping only the funds that must be readily available “online” and then using schemes like P2SH and Shamir Secret Sharing to manage the associated keys.

The Bitcoin ecosystem has clearly embraced these things as concepts, at least in the abstract in that “cold wallet” and “hot wallet” are synonymous concepts in the ecosystem. With that said the strategies you use to mitigate risk when you hold $10,000 USD should be different than when you hold $100,000 USD and this is not something individuals have had to take responsibility for historically.

One of the most fundamental changes Bitcoin represents today is that you, the principal are now also principally responsible for keeping your funds safe. Despite this we are still faced with the problem people struggle to understand the risks they are exposed to on the digital realm.

This is why in Bitcoin’s short history we find case after case of individuals putting their assets in the hands of under funded practically anonymous entrepreneurs with no real experience in finance or computer security.

The recent influx of capitol into the Bitcoin ecosystem has the potential to change this but it will also change the nature of Bitcoin at least in-part. The technology has been painted as the Libertarian’s dream and in many respects it might be but for broad acceptance it needs to embrace some level of regulation if it’s to see adoption outside that niche.

Liquidity risk management is a great example; How much of their assets should an exchange keep online? How quickly do they need to settle transactions? Should they be required to have 100% of the funds associated with their internal ledgers? Should they keep their assets and liabilities private or make them public? Should they be mandated to have security and fraud-analytics in place so they can detect abuse and market manipulation? Should they be required to carry insurance to protect consumers from negligence?

It is my belief that requirements like the above would strengthen the Bitcoin ecosystem and make it a more viable means for the less technical and the financial ecosystem to adopt Bitcoin.

 

SWIFT, CHIPS, ACH, Fedwire and Bitcoin…

Bank transfers, especially international bank transfers, can be incredibly complicated with many players both directly and indirectly involved.

As you might imagine its actually even more complicated and nuanced than it looks on the surface; in fact banks often times maintain accounts with each others to accelerate transfers as well.

This on the surface makes lots of sense but when you consider that in the US alone there are around 6,800 federally insured financial institutions and that there are over 200 sovereign nations that this quickly becomes an unworkable approach.

This is why there are these clearing-house entities; they act as brokers of these relationships.

Something else that many don’t realize is that not all banks belong to these organizations. As a result there is a routing problem that’s not dissimilar to the routing problems on the internet — there are many ways those funds might get transferred from one location to another each with their own cost and performance penalties.

But if only some banks belong to these organizations and every bank doesn’t have an account with each other how do they facilitate the interbank transactions? Through intermediaries of course; often via larger banks just like how the smaller banks outsource credit cards to third-party card issuers.

Over the years numerous attempts have emerged to modernize the banking system but interests are entrenched and something as fundamental as banking doesn’t change overnight. The efforts that have been successful have either looked like new products for banks to sell or solve immediate and tactical cost structure issues in their businesses.

Unfortunately this often results in more transactional intermediaries and not less, this is why in 2014 when we have global internet connectivity can still take a week (or more) for interbank transfers to actually settle.

One of the reasons I like Bitcoin is it represents a model where this slop and inefficiency can be removed which can dramatically speed up the financial system at the same time it has the potential to significantly reduce costs to all the players in the ecosystem and in the process kick off a new wave of innovation.

The largest hurdles are certainly regulatory and resistance to adopt technologies not under their direct control but like the ban on export of strong cryptography from the United States any restrictions that are put in place will only last for a limited time because its impossible to stop to use of the associated concepts and when their critical mass represents a competitive disadvantage the financial ecosystem would jump in near unison to take advantage of them.

Beyond Builders, Defenders, and Breakers

There are lots of different types of Security Practitioners out there. At a high level they can all be thought of as Builders, Defenders or Breakers.

Another taxonomy commonly used categorizes them into more role-focused categories:

  • Operations Security (OPSEC)
  • Communications security (COMSEC)
  • Counter-intelligence
  • Information security (INFOSEC)
  • Signal Security (SIGSEC)
  • Transmission security (TRANSEC)

Unfortunately neither of these taxonomies does an effective job at expressing areas of focus nor skill-set.

That is not to say these taxonomies are not valuable but the leave me wanting. It also seems if I tell someone I work in “computer security” they either immediately ask me if I can hack someone’s Facebook account or they ask me about what antivirus they should run; this of course isn’t how I think about security either.

So how do I think about security practitioners? I try to categorize them based on their areas of specialty and professional focus and for me this looks something like this the bellow mind-map.

Security Practitioner

 

 

 

 

 

 

 

 

Attacker Mind Map for Bitcoin

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

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

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

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.

Effectiveness of security controls in physical security

Lately I have been giving some thought to effectiveness of security controls in relationship to physical security.

To do so requires a definition of what one will consider “effective”. If we can accept that an appropriately motivated and well-funded attacker can bypass all mitigations our definition of effectiveness must be based on the skill and motivation of our attacker.

This also means we must give thought to how quickly we can respond when we become aware of an attack.

This is in essence the same approach we take when designing secure software systems. The core difference being we also have to consider the physical properties of the space we are protecting along with the human factors of the design of the system.

On the topic of physical properties of the space we have to consider the materials it was constructed with. One of my favorite examples here is how in the movie Sneakers Robert Redford’s character bypasses a security keypad by kicking the door down.

In this case even if appropriate door hardware was in place he could have simply gone through the wall like in this case of the recent burglaries of some Best Buy stores.

The state of affairs with home security is even in worse shape. Locks on doors are often of low quality and are trivially bump-able the plethora of home alarms that are installed typically use wireless sensors that can be bypassed with just a few dollars of electronics, garage doors can often be bypassed with nothing more than a bent hanger and if that wasn’t enough just throw a rock through a window.

So given this sorry state of affairs what should we do? First we need to be realistic about what the risks, the assets we have to protect and the value to the attacker. Then we should only invest proportionally to those variables.

To do this we need to develop a solid plan of what intrusions we have a chance of detecting, when we do detect them how quickly we can do so and then what our response will be in each of those cases.

For this reason a good quality alarm system is very important but they don’t do much good if they are not activated. Once activated we need to think about how long it takes for the monitoring service to be called, once contacted what do they do and how long does it take? Also In some cases the police will refuse to respond to a call that has not been confirmed by someone on-site and if they do often times responses can take hours. With that said knowing what the response time is is invaluable to understanding how long your mitigations will need to withstand attack.

But if as they say “Locks are for honest people” why do we bother at all?

The answer is that well-thought out mitigations do act as meaningful deterrents that can significantly reduce your risk but more importantly having proactively considered the risks and built the corresponding mitigations you are positioned to reduce your exposure (see my recent posts on Why shouldn’t you use safe-deposit boxes to store Bitcoin? and Insurance and Bitcoin) and ensure that such events are survivable.