Month: January 2019

The economic security of blockchains— lessons from Ethereum Classic (part III)

[continued from part II]

Impact of KYC on exchange risk

Among those commenting on the incident, it did not escape notice that the Gate.IO, the exchange targeted in the attack, does not perform full identity verification on their customers. Given that this is one of the more controversial subjects in the cryptocurrency system, it’s worth exploring potential causal links between existence of KYC requirements and risk profile against attacks from customers. Looking back at the modus operandi for the attack discussed in the previous post and implemented in real-life against Ethereum Classic, one of the implications is that the perpetrator must be able to conduct trades on the targeted cryptocurrency exchange. So there exists some business relationship between the attacker and victim, and presumably some due diligence conducted by the exchange prior to accepting this person as customer. But the extent of that relationship and any recourse the exchange may have against fraudulent behavior on the part of the customer— surely double-spending violated some clause in the terms of use?— varies between exchanges.

On the one hand, there are exchanges that comply with Know Your Customer (KYC) regulations, with stringent identity validation prior to on-boarding customer. For online businesses without bricks-and-mortar presence, that usually involves uploading a picture of government-issued identity such as a passport or driver’s license, linking to existing bank accounts (effectively leveraging KYC work done by those institutions, which can usually perform strong, in-person validation at one of their bricks-and-mortar branches) and providing proof of residential address. They can also limit service based on the jurisdiction the customer is domiciled in, selectively turning away customers located in states or countries outside established areas of operation. On the other extreme are exchanges that require no proof of real-world identity and accept customers from anywhere in the world. Commonly those businesses can not accept fiat transfers since reputable financial institutions subject to KYC regulations are unwilling to act as  money transmitters for other institutions not bound by similar standards.

There are three plausible ways implementing KYC can reduce the counter-party risk an exchange faces from its own customers:

  1. As a deterrent. It’s common sense that people are less willing to commit fraud when their true identity is attached to that activity. Even for those undeterred by the prospect of living with a criminal record, identity verification can protect other exchanges from repeat offenders, since they can check criminal records before accepting a customer.
  2. As a tactical barrier to exploitation. Suppose some vulnerability exists in the way an exchange processes cryptocurrency transactions. (Concrete example: this subtle vulnerability from March 2018 related to how Parity represented partially reverted Ethereum transactions, confusing an exchange into accepting phantom deposits.) An attacker with knowledge of that vulnerability still could not exploit it for personal gain unless they were already authorized to trade on the exchange after having completed all of the ID verification requirements. This is a weaker argument, since it assumes that on-boarding is onerous and slow enough that it will delay the attacker enough to give the exchange an edge in the race to independently discover and patch the vulnerability. Considering that such delays also prevent the acquisition of legitimate customers, relying on the difficulty of on-boarding as a security measure makes no business sense.
  3. As an avenue for recovery. Knowing the identity of perpetrator, an exchange can go after them in court to recoup losses. This is probably the least convincing argument. Litigation is slow and expensive, with no guarantee that the attacker will have assets to compensate for damages even if the court does find in favor of the plaintiff.

Counter-arguments: the limits of identity verification

Does that theory hold up in real life? Gate.IO appears to fall somewhere along the middle of the spectrum. Support documents suggest the exchange permits trading & withdrawals up to some threshold out of the gate, but raising those limits requires a verified account. This is in the spirit of risk management: assuming those thresholds are chosen wisely, the exchange incurs some small risk of loss from random customers while having some assurance of the real-world identity of those engaged in larger transactions.

As of this writing, Gate.IO has not disclosed whether the alleged perpetrator had a verified account. One unexpected twist in the story is that the attacker has agreed to return at least some of their ill-gotten gains. It is unclear if this is the magnanimous gesture of a conscientious white-hat hacker who had only perpetrated the attack to make a point about blockchain security (as portrayed in some press accounts) or because they had a drastic change of heart after Gate.IO lawyers served them a nastygram, perhaps with a reminder about how much the exchange knows about them. But there are at least two a priori reasons to be skeptical about KYC measures alone being sufficient to mitigate these risks.

  • Identity theft. Deterrence only works if the attackers are worried about their own identity getting linked to fraudulent activity. But even the most stringent verification procedures are not 100% reliable. Given a robust underground market in stolen identities— complete with pictures of driver’s licenses, social security numbers and credentials to bank accounts— determined criminals could pass all customer verification requirements without placing their own identity at risk.
  • Account hijacking. Even if KYC procedures were perfected to yield zero false-positives, that does not eliminate another possibility: verified accounts can be hijacked after the fact. The legitimate owner of the account could unwittingly surrender their credentials to an attacker. (Note that commonly deployed 2FA schemes have no effect on phishing. Even with hardware tokens which are not susceptible to phishing, malware running on the user device can take over an existing session post-authentication.) This creates an unusual imbalance of incentives. Consider a dormant account that has been through KYC verification, but is otherwise unused, with no funds on deposit. There is very little at stake for that person from a breach of their account. But if the exchange places implicit trust in that account because of its KYC status, for example by raising limits on trading/withdrawals, the account becomes valuable for an attacker in a position to exploit that trust. Seen from another perspective, the account can do a lot more damage to the exchange than one can reasonably expect to recoup from the legitimate owner. Suppose Gate.IO had been exploited through a compromised account. As before, the legitimate customer who owns the accounts receives a nastygram from attorneys, demanding a return of the double-spent Ethereum Classic. Only this time the customer throws up their hands and says in effect, it was not them taking those actions, but some third-party who hijacked their account. If those statements can be corroborated (perhaps they have an alibi or logs show the relevant activity looks different than legitimate traffic from the same customer) it leaves the exchange with few good options. They can pursue the customer for negligence in failing to protect their own account but it is difficult to fault someone for not defending an account which had very little economic value for that individual.

These limitations suggest that strict KYC requirements can at best thwart opportunistic attacks. An adversary armed with one exploit, looking for any vulnerable target to cash-in quickly— recall that our Ethereum Classic double-spend attacker could have gone after any exchange with ETC/BTC order book— will prefer the path of least resistance among multiple targets. More determined attackers can take their time with target selection and prepare the battlefield by getting access to legitimate accounts at their preferred target.

CP

 

The economic security of blockchains— lessons from Ethereum Classic (part II)

[continued from part I]

Attacks and counter-attacks

At least one commentator suggested that affected exchanges immediately respond with a counter-attack, mining with overpowering hash rate on the original chain to undo the revisionist rewrite. Why would an exchange be motivated to behave this way? Because the cost of temporarily renting 51% hash-power to conduct another long reorganization is presumably much lower than the expected loss. This is an argument from symmetry: the attacker would not have bothered with the attack if their cost of mining the alternative chain was not outweighed by the benefits of swindling the exchange. At one level, this is damage control: by spending a small amount carrying out a successful 51% counter-attack, the exchange averts the higher loss it would otherwise incur if the double-spend is successful. At a deeper level, the strategy is intended as deterrence for future attackers. Assuming a successful counter-attack undoing the original chain reorganization, both the attacker and the exchange are in the red with nothing to show for it. The perpetrators wasted money on a short-lived 51% attack while the defenders wasted an approximately equal amount on reverting that. While the attacker can try again, so can the defender resulting in a game-theoretical stalemate. But that theoretical model suffers from two problems:

  • Assumption that costs are symmetrical. That defender can achieve 51% hash-rate at the same price as the attacker. There are many ways that can fail, the most obvious being one where the attacker is not merely renting hash power from an open market but is in possession of mining hardware, bringing down their costs. Second, even if both parties are bidding for hash power in a market such as NiceHash, the first mover may have an advantage: once demand for hash power for a particular PoW function increases, the next buyer may have to bid higher to achieve the same concentration.
  • More important, this model assumes that the perpetrator and targeted exchange are the only parties with a stake in the reorganization battle. Consider a different attack strategy: instead of simply sending funds back to herself on the alternative chain, Alice instead sends them to another exchange and carries out a second double-spend attack following the same modus operandi: convert all deposits into another cryptocurrency and withdraw those proceeds immediately. At this point, Alice does not care which version of blockchain history wins out. The two exchanges can duke it out all day long by orchestrating their 51% attacks & counter-attacks against each other; Alice comes out ahead in all cases. Even the exchanges cooperating will not change that: at best they can settle for some equitable distribution of losses. (There is one way for the second target to avoid this situation: halt processing of deposits if there is a “deep” blockchain reorganization observed.)

Parallels with ACH fraud: the original double-spend

This situation has interesting parallels with a far more mundane, low-tech type of fraud targeting cryptocurrency businesses: the reversible nature of most fiat transfers. Consider the ACH Network for transferring funds. Suppose a customer initiates an ACH transfer of US dollars to an exchange account and uses those funds to purchase bitcoin. The withdrawal of that bitcoin to a personal wallet is irreversible; once the transaction is mined and confirmed, it is not possible for the exchange to claw-back those funds. (Short of organizing a 51% attack— you can see where this is going.) Surprisingly the incoming ACH deposit is far from being cast in stone: consumer protection laws in the US give account holders several weeks to contact their bank and dispute transactions.

That means a dishonest consumer can in fact reverse the ACH transfer to keep their USD, while walking away with the bitcoin purchased using those same funds. This is effectively double-spending of fiat currency: eating your (USD) cake and having it (back) at the same time. The root-cause is a mismatch between the settlement characteristics of two disparate payment systems: ACH transfers are reversible, or more accurately take on the order of months to “confirm” due to generous 60-day dispute window, while Bitcoin transactions are cast in stone in a matter of hours. When processing incoming ACH transfers and allowing customers to trade using those funds, the exchanges must manage the counter-party risk associated with the reversal of fiat deposits.

What if we replace ACH by another cryptocurrency? It would appear these opportunities to claw back funds disappear because transactions would become irreversible on both sides, with no opportunity for the customer to “reverse” their deposit while walking away with the withdrawal. But as the ETC incident demonstrates, reversibility is a matter of degree: transaction are “final” only to the extent that a deep-enough blockchain reorganization can not rewrite history with an alternative version of events. In one sense, blockchains are more fragile than wire transfers— which can not be unilaterally recalled— or even ACH which has a finite duration for disputes. Given enough mining power, blockchain history can be reverted going back an arbitrary length of time. (On the other hand, ACH and wire transfers are still vulnerable to a different class of “attacker:” lawyers wielding briefs.)

Confirmation times reconsidered

Conventional wisdom holds that blockchain transactions are “safe” as long as participants wait a fixed number of blocks before acting on the outcomes, dependent on the particular economic characteristic of the blockchain. For Bitcoin this magic number has historically hovered between three and six, with an ongoing game of brinkmanship to streamline user experience by creeping closer to zero confirmations. These are motivated by statistical models calculating the likelihood that some transaction may be reversed, given an adversary controlling some percent of hash-power less than 50%. While that may well be the relevant threat model for Bitcoin, less-competitive blockchains have to contend with a different question: what if the adversary can temporarily achieve majority power? Temporary being the operative keyword: while all bets are off with permanent 51% control, even short-lived spikes allow targeted attacks to profit by double-spending some recent transaction.

In this model, the number of confirmations required can not be a magic constant. It depends on the value-at-risk: the notional value of the transaction. Buying a cup of coffee with a small number of confirmations on Ethereum Classic (not that ETC ever aspired to being a realistic alternative for retail payments) is still perfectly reasonable, even in the aftermath of the recent ETC incident. Large amounts on the other hand will require more careful risk management strategies, such as increased confirmation depths, gradually crediting the deposit over time as more blocks are confirmed instead of all at once, requiring additional funds as collateral or placing withdrawal restrictions. For example, a customer could be credited with the full amount of the deposit for trading purposes, but not permitted to withdraw the proceeds from those trades until additional time has elapsed to guard against chain reorganizations.

[continued]

CP

 

The economic security of blockchains: lessons from the Ethereum Classic attack (part I)

In early January, the Ethereum Classic blockchain experienced double-spend attacks created by deep reorganizations of the blockchain. While the perpetrators’ identity remains a mystery— although research from SlowMist suggests that exchanges involved in the incident may have additional information for locating them— there is enough information about the attack to draw general conclusions about the modus operandi and implications for other blockchains. This event has upended core assumptions made in previous economic analysis of blockchain security, defined as the cost/benefit calculus for mounting successful attacks against the integrity of the ledger.

Double-spending in the abstract

In one sense, there is nothing surprising or novel about the attack vector. The vulnerability of blockchains to hijacking by overwhelming mining power had always been acknowledged, even in the original Bitcoin paper by Satoshi. Such attacks have even been observed on other alt-coins in the wild, most notably Bitcoin Gold in May 2018. To recap how such a double-spending attack works in the abstract using the standard cast of cryptographic characters:

  1. Alice and Bob agree to trade using cryptocurrency.
  2. Alice pays Bob by broadcasting a transaction on the Ethereum Classic (ETC) blockchain
  3. Bob waits until this transaction has been “mined” and confirmed, getting buried several blocks deep in the chain history
  4. After the transaction is confirmed, Bob in return supplied Alice with a product or service, such as shipping her a painting or even giving her a bundle of USD cash.
  5. Unbeknownst to Bob at this stage, Alice had been secretly mining an alternative history of the ETC blockchain, with more hash-power than all other miners combined. In this parallel universe, the transaction sending ETC from Alice → Bob never happened.
  6. Given that Alice commands a majority of the hash rate on the network (so-called “51% attack”) her alternative chain will eventually catch up and overtake the existing chain, measured in terms of the objective metric used by all participating nodes to pick a winner among competing histories.
  7. When the blockchain “snaps” to this alternative version created by Alice, Bob no longer has possession of the ETC funds he believed Alice had sent; that transfer has effectively been erased from history.
  8. Alice meanwhile still has the cash Bob provided in exchange, in addition to her original ETC funds.

There is one technicality here: as stated, the transaction broadcast in step #5 would still be valid on the new, revisionist history orchestrated by Alice. That means Bob could try broadcasting it again, after Alice stops mining new blocks and control of the network reverts back to honest miners. To lock in the theft for good, Alice would include another transaction in her version of events to break compatibility. Even a seeming useless transaction sending the same funds back to herself (Alice → Alice) will do the trick; although, the scenario gets more interesting if the same funds are used for another third-party transaction, as we will shortly see. That is the origin of the slightly confusing term double-spending, since the same money is seemingly being used twice. Even though any single version of blockchain history only allows single spending, by creating temporary confusion about what the “true” version of history is, Alice convinces different people at different times that the funds are theirs.

Attacker perspective: ideal targets

Is this attack feasible? It depends on the relative cost of achieving 51% of hash-rate “temporarily,” compared to the expected benefits measured by the value of the goods/services purchased without having to fork over any Ethereum Classic. Hash-rate costs are subject to complex dynamics, involving the specific design of the proof-of-work function used in a blockchain and available spare capacity up for grabs for the higher-bidder on markets such as NiceHash. But assuming an attacker can assemble enough fire-power to revise blockchain history, there is a natural choice of target to go after, a stand-in for the character “Bob:” cryptocurrency exchanges. Alice can deposit ETC on an exchange, trade that to a different cryptocurrency such as Bitcoin (BTC) and withdraw BTC. Note that the 51% attack on ETC chain has no effect on BTC, short of any general market unease caused by an unrelated coin being attacker. (In fairness, there is strong correlation across different cryptocurrencies and past events such as the Ethereum DAO debacle have caused broad declines across the market, even in asset classes having nothing to do with buggy smart-contracts.) The attacker gets to keep the Bitcoin, while the exchange is out of ETC after the deposit is reversed. There is no doubt an interesting legal question here on whether the exchange will eat the loss or if those losses can somehow be passed on to counter-parties involved in the BTC/ETC trade. But that is immaterial for our purposes: the bottom line is that someone has been scammed.

This is the exact playbook observed in the ETC double-spend attack. One of the primary targets has been identified as the exchange Gate.IO, with the attackers converting the proceeds to bitcoin for withdrawal. To the extent there is any element of surprise here, is the fact that such an attack could involve a relatively major currency in the top 20 by market capitalization. It is one thing to prey on Bitcoin Gold or some other thinly-traded altcoin with negligible hash rate. It is another level of capability to amass enough hash-rate to overpower Ethereum Classic, with the unspoken question: which other cryptocurrencies are vulnerable to copy-cat attacks?

Wrong assumptions about costs and benefits

The existence of economic limits to the security of blockchains is not exactly news. It is an accepted risk that Bond villains with unbounded resources can amass sufficient hash-power to overwhelm any blockchain. Without disputing this fact, the standard response to these arguments has been around economic incentives: why would an attacker spend that much money if they can not recoup even greater value by carrying out the attack? Putting aside the fact that this is not an entirely comforting answer— some “attackers” may be motivated by ideology, with the standard example being governments willing to sabotage public blockchains for the greater cause of enforcing capital controls, even when that undertaking would be extraordinarily costly— it leads down the rabbit hole measuring costs and benefits.

Notable, this attack on ETC debunked two premises that go into these models:

  1. Attacker costs include devaluation of their own holdings. It has been an article of faith that miners would not collude to execute a 51% attack because doing so would lead to decrease of confidence in the currency, resulting in the notional value of their own mining rewards going down. In effect, 51% attacks are treated as short-sighted move that may temporarily boost returns but only at the cost of much greater losses down the road. This was rooted in an implicit assumption that perpetrators of the attack are still wedded to that particular cryptocurrency— after all, Alice in the example above is still holding ETC after her double-spend attack has been successfully executed. But the presence of public cryptocurrency exchanges with high liquidity in their order books voids that assumption. Alice can wash her hands clean of ETC, fully cashing out all of her holdings to some other cryptocurrency with nary a care for how far ETC plunges in the aftermath.
  2. Attacker costs also include the depreciation of their specialized mining equipment, which has zero value for any application except mining that specific cryptocurrency. Because the most efficient way to mine Bitcoin involves highly-specialized ASIC hardware that is useless outside that specialized application, the perceived “cost” for an attacker mounting 51% attacks would include both capital expenses to acquire those rigs and more subtly, depreciation for the equipment caused by decline in currency price. Recall that if the price of Bitcoin goes down and mining rigs are good for nothing besides producing more Bitcoin, the expected value provided by a rig over its lifetime also takes a dive. This may have been a reasonable assumption when Bitcoin was the only game in town. Today there are hundreds of alt-coins, including several “families” sharing the same proof-of-work function: mining rigs built for Bitcoin can be diverted to also mine Bitcoin Cash/Gold/Diamond/Tin/Scrap-Metal/etc.**

[continued]

CP

** The last two remain hypothetical at the time of writing, but can not be ruled out if forks continue to create value out of thin air.

Proof of nothing: why the January proof-of-keys ritual missed the mark

[Full disclosure: this blogger was formerly CSO for a cryptocurrency exchange.]

Imagine a country where confidence in the banking system has reached a nadir among the citizenry: no regulatory oversight, no lending standards, no requirement for public audits and no FDIC insurance to serve as backstop in the event of bank failure. Instead  consumers a coalition of consumers decide to take matters into their own hands with a grassroots campaign to verify the solvency of banks. How? By orchestrating a bank-run. Everyone is instructed to take out all of their money out of banks on the same day and deposit them back at a later time after observing to their satisfaction that all withdrawals have been processed successfully.

This is not an entirely far-fetched analogy for what happened in the cryptocurrency space earlier this month with the Proof of Keys event. There are of course key differences, no pun intended. Traditional banks operate a fractional reserve by design. It is no secret they would experience a liquidity problem if all customers showed up to demand 100% of their deposits at the same time, as epitomized in the bank-run scene from It’s a Wonderful Life. But cryptocurrency businesses operate under a different expectation, namely that they retain full custody of customer deposits at all times. No lending, no proprietary trading, not even parking those funds at an interest-bearing account offered by another financial institution lest it create counter-party risk. So on the face of it, there is some value to this withdraw & redeposit ritual: a custodian successfully satisfying every withdrawal was provably in possession of those customer funds.

But the reasoning is flawed for several reasons.

First, participation is voluntary. Even with viral propagation on social media and decent coverage in press outlets dedicated to cryptocurrency, only a small fraction of users representing an even smaller fraction of total funds will participate. (It is easier for retail investors to participate, compared to an institution such as hedge-fund. The latter typically have more stringent requirements around alternative places to keep funds. An off-the-shelf hardware wallet is an adequate solution for storing personal funds; it is a far cry from enterprise-grade storage with redundancy and multiple users for an institution.) While exact numbers are not available, mining fees and memory pool pressure statistics can be used as a gauge of participation. Assuming only 10% of funds were withdrawn from a given exchange, the campaign has only proven that at least 10% of funds are there.

Screen Shot 2019-01-03 at 6.18.53 PM.png

Zooming on mempool state on January 3rd shows a temporary spike, coinciding with morning hours in PST.

Screen Shot 2019-01-17 at 10.57.22 PM.png

Looking at 30-day view paints a different picture. There is nothing remarkable about the transaction volume or fees on January 3rd.

Second, pre-announcing a bank-run ahead of time somewhat defeats the point. It’s not a pop-quiz if the teacher announces that there will be a pop-quiz next Friday. Given enough advance warning, even custodians who were actively investing their deposits can convert all of the capital back to the expected currency.

Finally there is a more subtle reason why this stress-test for custodians fails: it is first and foremost a test of liquidity instead of solvency. In other words, it is subject to false negatives where even a cryptocurrency custodians with 100% of funds on deposit could fail to produce every last satoshi on demand, for a very good reason. Sound risk management for cryptocurrency dictates storing the majority of funds offline, in cold storage. By definition these systems are disconnected from the Internet and require manual steps—such as travel to an offsite location—to effect a withdrawal. Only a small fraction of funds are kept “online” in hot wallets, where they are instantly accessible for satisfying withdrawal requests.

This model is similar to how traditional banks manage cash. Even within a single branch, only a fraction of the cash present at that branch is loaded into the ATM. The remainder would be kept in an interior vault within the branch. Banknotes stuffed into the ATM are available 24/7 for customers to withdraw but also come with a downside: they are subject to heightened risk of theft. Blowing up an ATM or towing it away is easier than breaking into a steel vault. By keeping only sufficient money in the ATM to satisfy expected withdrawal volume, the bank manages its exposure while providing high degree of assurance that customers will have access to their funds. As long as projected liquidity requirements are not too far off the actual observed demand from customers— in other words, barring unexpected events that result in everyone rushing to the ATM at once—this is a good trade-off between security and liquidity.

Cryptocurrency custodians employ a similar strategy for managing the exposure of hot-wallets. If deposits exceeds withdrawals and there is a net influx of funds, the wallet may start running too “hot.” Excess risk is trimmed by sending funds to an offline wallet. Since the transfer is initiated from an online wallet accessible over a network, this step is easy. On the other hand, if withdrawals outpace deposits and there is a net outflow, the system risks running into a liquidity problem and must be replenished by moving funds back from an offline wallet. This step is more time consuming. By design, access to offline wallets is available from the same system operating the hot wallet; otherwise they would be subject to same risks as the lower-lower-assurance system.

Returning to the conceptual problem with the DIY proof-of-solvency, if enough customers actually participate in a coordinated effort to withdraw their funds at the same time, hot-wallets will bottom out and cease to provide liquidity until they are replenished from offline wallets. (Granted, knowing when the stress-test will occur creates additional options to prep. For example the custodian can deliberately bias the wallet distribution to maintain higher-than-usual fraction of funds online.) That means events such as January 3rd are not so much a proof of solvency as they are a proof of available hot-wallet liquidity or perhaps time-trial of how fast the custodian can access offline storage systems. The paradoxical part is that in any system with online/offline separation managed according to risk criteria, some delay in processing withdrawals would be fully expected. If anything, it is a bad sign if the custodian can instantly produce 100% of all funds on short notice. It means they are likely keeping 100% of cryptocurrency online in a hot-wallet, where they are most susceptible to theft. Ask Bitfinex how that turned out in 2016.

To be clear: this is not to trivialize security concerns with storage of cryptocurrency. Given that internal workings of exchanges and custodians remain opaque to most customers, it is completely reasonable to demand periodic assurance that funds deposited with are still accounted for. Considering that proof-of-keys suffers from conceptual flaws and indeed accomplished very little this time around (judging by observed withdrawal volume) the question becomes: what is an effective way for custodians to verify that a custodian is still in possession of their cryptocurrency deposits? A future blog post will look at some alternatives.

CP