The Binance Hack and Why Exchanges Are Not Secure
- September 8, 2019
- 8 minutes read
Blockchain is decentralized while the risk assessment is centralized
After a period of quiet within the blockchain industry, the storm finally hit. Binance — one of the most trusted and respected cryptocurrency exchanges by trading volume, fell victim to a security breach, resulting in 7,000 BTC being stolen. Factoring prices at the time of the hack (May 7th, 2019) the losses amounted to roughly $41 million dollars — thereby making this breach the sixth largest in crypto history. The methods used by the hackers were advanced, and they remain undetected.
While crypto analysts such as Larry Cermak predict that Binance can make $41M “back in 47 days”, it’s important to take a step back to try to determine what went wrong, and review preventative measures on how to re-manage a hacked system.
Blockchain Security 101
Blockchain is a highly decentralized data structure. That means that it doesn’t rely on a single central point of control, but holds the same data within different global networks, referred to as miners. The Bitcoin global network consists of over 100,000 different miners.
Miners are single processing units which run the blockchain consensus protocol, and each miner can be seen as a decentralized banker of the blockchain. The decentralization aspect itself assures that the blockchain will stay true and represent reality, so long as the majority of the miners are honest. This is done using different consensus algorithms, such as proof of work (Bitcoin), or proof of stake (NEO), among others. In order to break through, hackers would need to possess hundreds of thousands of networks, located in different locations around the world, to change the blockchain. It is a nearly impossible feat, requiring an intense amount of time, resources and dedication on their end, to pull off.
How Financial Institutions Manage Digital Assets (Almost) Without Blockchain
Crypto exchanges, and other large financial institutions holding digital assets over the blockchain, are predominantly centralized. They hold all of their clients’ assets by themselves, and manage the ownership of their customers’ assets in their internal databases.
This makes sense from a commercial standpoint. Going this route presents the opportunity to earn money, according to the philosophy that you should not communicate with the blockchain unless you are compelled to. Internal database communication is faster and much more affordable. Sending transactions to the blockchain costs the exchanges large amounts of miner fees per transaction.
In December 2017 the average transaction fee was $37.30. Instead of updating the blockchain immediately, an exchange can update the internal database with customers’ currency ownership status post-transaction, as well as when someone withdraws money, and update the blockchain only when commercially necessary. According to its level of traffic and its risk assessment, each exchange can decide when hedging risks at the blockchain is necessary. It mostly happens when customers withdraw their digital assets, which does not happen daily — and so actual blockchain transactions are reduced dramatically. Assuming a BTI-ranked top 10 exchange with an activity level of 300,000 users a day making transactions, managing digital assets ownership internally saves more than $10M a day.
The Binance Use Case: The Achilles Heel of Centralized Digital Assets Management
Most official bank structures require manual interactions for ETFs (Electronic Fund Transfers), whereas exchanges such as Binance allow their customers to create automatic transactions. In order to send messages such as transaction orders to the exchange, secured authentication is required.
Issues start to erupt when security protocols are combined with the automation process. The exchanges export API keys, among other forms of data, per all user registrations, so the messages sent to the server from the customer will be signed.
To make this clearer, I shall use the terms encrypt-decrypt to demonstrate the concept of signature-validation.
With API keys, every transaction sent to the exchange’s system is encrypted and decrypted by the exchange as it arrives, so no one is able to make a fake transaction unless they possess the key. Issues arise when API key pairs (private to encrypt and public to decrypt) are generated in a centralized location. Once hackers get access to the centralized server, they can sniff the keys. Sniffing can happen mostly if a hacker is there while the transaction is being created or, in the worst scenario — if the exchange does not have proper cybersecurity measures in place and stores the private keys after exporting them to the end user.
The cost-effectiveness for hacking such systems makes it very attractive for talented and motivated hackers. An additional point worth noting is that, unlike traditional banking systems, where agreements and human interactions can cancel transactions, there is no rollback in the case of blockchain transactions. Once transactions are created and encrypted, they are sent directly to the miner for approval, and the money is transferred to the addressee immediately. Moreover, a hacker can generate a new cryptocurrency address (such as Bitcoin) without notifying anyone, so that no one can really know who stands behind this sequence of letters and digits representing the new address now in control of the stolen money. This is why hackers prefer to hack blockchain digital assets rather than fiat money, which is inconvertible paper money.
How to Re-Manage a Hacked System — a Suggestion for Binance
Following the Binance fiasco, an interesting idea came to mind: to allow hacked centralized exchanges to recover themselves without making significant structural changes to their internal database, and letting them reevaluate their keys management to avoid future pitfalls.
We start with assuming that the system has been hacked: the exchange’s server holds public key no.1, the customer holds public key no.1, and the hacker holds private key no.1 as well.
Now, the customer can locally generate and encrypt key pair no.2, and send public key no.2 to the server, signed using private key no.1. The server then decrypts public key no.2 using private key no.1 to ensure that the message was sent by the customer.
From that moment on, the customer can be sure that he is the only one holding his private key! Not the hacker or any other party. Now the customer and the exchange’s server can communicate securely once again.
The Correlation to the Blockchain Private Key Management
The authentication architecture described is separate and not related to the actual communication exchanges that must take place with the blockchain — where the security challenges are even more complicated. The same method of signature-validation messages used by customer-exchanges while communicating is used when exchange-blockchain communications take place.
Such blockchain transactions occur among exchanges mostly while hedging risks, or when customers withdraw their digital assets. Automation processes are necessary, as financial institutions are eager to be responsive and scalable, without hiring thousands of employees — which is of course unreasonable.
In these cases, hot wallet, a computer program which holds the private key and is always connected to the Internet, is needed. This private key controls all the exchange’s blockchain assets for immediate use. In this scenario, the exchange’s server signs transactions using the hot wallet’s private key, while the blockchain’s miners validate it.
Hackers gaining access to the hot wallet’s system can create as many transactions as they desire on behalf of the exchange, and steal its money. It is essentially the same as stealing the API keys, and creating fake transaction orders between the customer and the exchange.
What is the Solution?
The most state-of-the-art solutions currently available attempt to solve the challenge of holding private keys using multi-signature or splitting keys.
Such methods are very much like automatic two-factor authentication, in which each party can decide by themselves automatically whether to approve transactions, and transactions are approved if, and only if, both parties approve. The automatic decisions are taken according to a policy created by the exchange and shared with its co-signer, which is an entity that automatically signs/declines transactions based on the policy verification. An example of a policy could be a rule stating that the exchange cannot transfer more than 100 Bitcoins a day.
This raises questions and challenges:
● Who the co-signers are;
● How to create and disseminate a policy to reduce cyber-attack vectors;
● How to make multiple smart back-up keys.
The answers to these questions available today are not good enough for enterprises holding significant amounts of funds — and this is where my team and I come in.
My name is Lior Lamesh, and I am a former officer in the special cybersecurity forces answering directly to the Israeli Prime Minister’s office. The company of which I am co-founder and CEO is a next-generation cybersecurity company currently developing a new product with the highest security standards for blockchain technologies. Our team is using our combined skill sets to create an innovative solution to allow crypto financial institutions to manage their digital assets while avoiding the most critical cyber-attack vectors.
We will release more details over the coming weeks as our game-changing tech emerges from stealth mode. We have spent two years quietly perfecting the product, and we’re currently choosing our customers very carefully. After many sleepless nights, we’re ready to make it live!