[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:
- 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.
- 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.
- 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