Category Archives: Thoughts

Bitcoin adoption in payments

Leave a reply

If you talk to someone about using Bitcoin as a payment technology your surely going to hear about how governments are classifying it as an asset and not a currency and what the corresponding tax implications are.

While I think the current tax situation is unfortunate and hope this trend changes I don’t think this is the largest issue (just look at the sales online retailers are seeing despite this change as a proof point). In-fact there is so much slop in the payments system it might even be reasonable to cover the tax implications through the efficiency improvements Bitcoin can bring to the ecosystem.

I think the larger issues are in-fact that the incentive models for the incumbents are such that it’s not likely they will be the ones driving this change.

Just consider that we have been using technology known to be grossly insecure for card-present transactions for over twenty years and even though viable alternatives exist they have not been adopted.

That despite the massive shift to online sales these incumbents have not presented the market a payment solution designed to work well for the Internet.

The rational for not doing so makes sense; when you are the incumbent you resist change as it has potential to weaken your position and the costs of the security issues (as long as measurable) can simply be passed on to the merchant as long as the buyers keep buying.

Simply put they have little incentive to change.

Despite this change is on the horizon; as more and more goes online the relevance of card present transactions diminish (link to retail buying trends) the world also becomes a smaller place and these incumbents start to face competition from governments with their own payments infrastructure like in Singapore and other countries.

This means customers are starting to have choices and as such there is a prime opportunity to see a seismic shift in the way these incumbents look at their businesses.

This shift may provide the impetus to the incumbents to modernize and address these competitive risks. One way that modernization could manifest would be through their own adoption of a virtual currency like Bitcoin or acquire the new entrants with solutions in these space; for example:

  • Payment processors could go out and buy large private mining concerns as their role is in Bitcoin is essentially the same.
  • Card Networks or issuing banks might go out and buy online wallets like BitGo and Blockchain.
  • Acquiring banks could go and buy payment providers like CoinBase and BitPay.

Regardless of how such a migration happens the use of a virtual currency as a foundational payments technology has the potential to reduce the number of entities involved in each transaction making transactions more secure and cheaper. If embraced by the incumbents in the payment ecosystem this could even align with their logical view of the world.

Bitcoin and the credit card ecosystem

Leave a reply

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

Leave a reply

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

Leave a reply

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…

Leave a reply

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.

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.

The bias of experience and ignorance of youth

Leave a reply

It was really security (well pirate and BBS’s and IRC channels) that first got me seriously into computers. It was a place where I was surrounded with brilliant people and super interesting problems to explore. It did not take long for me to discover cryptography. I remember the first time I encountered the concepts; I was working on cracking a game and the publisher actually had encrypted some of the instructions and I had to figure out what it was they had used, how it worked and how to work around it.

At that moment I was hooked. Since then nearly every professional experience I have had has been in computer security — simply put I love this stuff.

As it turns out most of the last two decades I have ended up working on authentication systems of one sort of another; these end up being interesting applications of protocol design, performance design patterns and cryptography.

The nature of these spaces also resulted in me working on operating systems and security services which in turn led me to have a strong bias against the “web developers” who I viewed largely as script kiddies with no understanding of computer science fundamentals let alone security. So much so I discouraged my son from learning many of the associated technologies because “real programmers” don’t bother with such things.

There has been an amazing shift over the last decade and even if at one point I was right for the above position I certainly would not be today. Not only have the technologies that are used to make up the web evolved to the point that they are as impressive and powerful as many of their native counterparts but many of the engineers working with them have become world-class as well.

This has led to some interesting trends the most poignant being the adoption of Javascript as a language for use outside of the browser like in Node.JS and the Tessel. This has been enabled by a competitive race to build the fastest experience on the web, which has become totally dependent on Javascript.

As a technologist I love this as it makes technology more approachable, it makes it easier for things to be rapidly be built and creates portability of skill across the layers of an engineering project.

As a security practitioner it gives me pause; those of you who know me one of my favorite sayings is “Just because you can, doesn’t mean you should” and since this approachability and increased speed of innovation has obvious and natural negative implications when securing systems I am hesitant still to embrace it fully.

I take solace in this dichotomy because of something my mom would always tell me – You’re not learning if your not falling.

As we look at the features in HTML 5 and their support of things like WebCrypto, WebSockets and (god forbid) WebGL I try to remind myself how important it is not to let our personal biases hold back innovation while holding onto the rational and caution approach of my inner security practitioner.

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.