Criminal smart contract construction and defense
In the previous post I explained how smart contracts could make ransomware a lot more profitable and therefore a lot worse. However, the trustless key exchange model was oversimplified and has a fatal flaw. In this post, we’ll discuss the flaw, how criminals might get around it, and what we can do to mitigate those work-arounds.
In the example, the hacker creates a smart contract which contains the public key used to encrypt the victim’s hard drive. However, how does the victim know that the public key contained in the contract was the actual public key used to encrypt their data? The victim no longer has access to their unencrypted files, so they can’t run the encryption algorithm themselves on a subset of their data to make sure it works. If they have to trust the hacker that the public key contained in the contract is the same one used to encrypt their data, then there is no point in using a smart contract at all.
It would be nice if this meant smart contracts couldn’t be used for ransomware exchanges, but alas… there is a way a hacker can credibly demonstrate a victim’s data is intact and encrypted with the public key contained in the contract. Fortunately it’s a bit more complicated than the previous example, so criminals will have a harder time making it work.
Using a master key and derived segment keys
One of the best features of cryptography is the ability to prove you know things without leaking information about what you know. In this case, a person can create a master key pair and some sub key pairs and prove that the sub key pairs were properly derived from the master key pair. Thus, with the master private key, you can decrypt any information encrypted with one of the public sub keys. This can be used to reveal a subset of data to someone in order to prove it’s the real data, encrypted with a specified public key.
The method described below is adapted from Juels et al.’s Ring of Gyges paper on Criminal Smart Contracts. In their paper, they describe using this method to sell stolen data such as leaked films or books, but ransomware is likely a more profitable application. The main problem solved with this method is verifying an untrusted party’s claim that a collection of encrypted data contains some particular content. I describe the method in the following steps and in the diagram below.
- Hacker generates master private / public key pair
- The hacker generates N segment key pairs from the master key pair.
- Hacker takes control of the target’s computer and installs ransomware
- The ransomware divides up the victim’s data into N segments. It encrypts each segment with one of the public segment keys produced in step 2, all derived from the master key.
- The hacker creates a smart contract. The contract contains the master public key, and the derived segment public keys, along with a proof that the segment key pairs were properly derived from the master key pair. This ensures that if anyone has the master private key, they could decrypt all of the data.
- Now the hacker wants to demonstrate to the victim that the encrypted files are the real files and not a bunch of encrypted junk. The smart contract chooses some segments at random to decrypt. It can use a value from the hash of the previous block to generate a pseudorandom number.
- The hacker uploads the private segment keys corresponding to the segments the contract selected. The hacker didn’t choose these segments — they were generated randomly by the contract.
- The victim can then use the private segment keys from the contract to decrypt the randomly selected segments of their data. If they all check out, and the victim recognizes the decrypted data as segments of their real data, then it’s very probable that the data encrypted is the real data. Since the victim can look at the smart contract and verify that the segment keys were derived from the master key, they can be confident the master key will unlock their data.
- The victim commits the requested payment amount to the smart contract.
- The hacker submits the master private key to the contract.
- The smart contract verifies the master private key correctly corresponds to the master public key already contained in the contract, then releases the payment to the hacker.
- The victim can view the contract to get the master private key
This method is more complicated to implement that the naive version in the previous post, and requires more actions from each party. It also only provides a probabilistic guarantee that the data is all present. After all, an attacker could corrupt a very small subset of the encrypted data and it would be unlikely to be found in a randomly chosen segment.
In practice, an attacker wishing to profit from a ransomware attack and similar attacks in the future has no incentive to poison the well by corrupting a small subset of data. To do so both costs the attacker because of risk of discovery and because it would make future victims less likely to trust the ransomware operator. So even though this method cannot provide a 100% guarantee to the victim that their data is intact, the combination of the attacker’s incentive to return their data and the probabilistic guarantee from the legitimate decrypted segments would likely be enough to convince most victims.
Technical solutions to the criminal smart contract problem
In the Ring of Gyges paper, Juels et al propose three potential methods to prevent people from using smart contracts for crime:
The first is to use trustee-based tracing. This is a concept developed by the early pioneers of electronic cash. The idea is to allow a trusted third party to have real identity information for the users of the payment system. To do this on Ethereum, every user of the network would need to register their public key with a third party, rending their transactions transparent to that party. If law enforcement agencies could view the real identities of the transactors of smart contracts, criminals would be unlikely to use them.
On existing blockchains like Ethereum and Bitcoin, it would be next to impossible to retroactively verify identities of people who hold crypto assets. Future platforms could require some form of identity management, but no public blockchain project to date has required identity registration.
The privacy of public blockchains is already dismal, and identity registration would only make the problem worse. If the trusted third party that held a user’s identity information was compromised by an attack, then that attacker would get the transaction entire history of everyone along with the ability to identify the parties in future transactions. This is very undesirable. It is likely possible to design blockchain systems that implement trustee-based tracing with better protection of user privacy, but they do not yet exist.
A second proposed solution is to blacklist addresses known to be associated with criminal activity, as well as future addresses that receive assets from these accounts. There are several problems with this approach. First, it interferes with fungibility of digital assets. One Bitcoin does not equal one Bitcoin if some Bitcoin addresses are blacklisted. Furthermore, it would possible for an unfriendly actor to “poison the well” by sending a small amount of assets from a blacklisted address to an enemy’s address, effectively causing an innocent party to get blacklisted.
Address blacklisting fails as an effective countermeasure because it requires everyone to blacklist addresses in order to be effective. Someone with Bitcoin from a blacklisted address can run them through a mixer to get untainted Bitcoin, and blacklisters have no way of knowing which Bitcoin ended up with which party. Of course, they could choose to blacklist every Bitcoin that goes through a mixer, but then they might be required to blacklist a large fraction of Bitcoin addresses, reducing the usefulness of the currency and angering their customers.
Trustee-neutralizable smart contracts
Finally, the researcher’s propose the solution of trustee-neutralizable smart contracts. This would require a smart contract platform to designate a party or some set of parties which would have the power to disable a smart contract they found problematic. Like with trustee-based tracing, this is a feature unlikely to be implemented on Ethereum or other smart contract platforms that currently have no such a provision for this. Given their decentralized nature and commitment to censorship resistance, any attempted fork of Ethereum to include such a feature would likely be rejected by most miners.
Ethereum, Neo, Tezos, and most other popular smart contract platforms do not natively support trustee-neutralizable smart contracts. Contracts could be written by developers to be neutralizable by a third party, but any developer could choose not to include such a provision in their contracts. The EOS smart contract platform does include a mechanism in their protocol to freeze contracts with a 15/21 vote of block producers. This provision does not guarantee block producers will decide to freeze criminal smart contracts, but it at least provides a mechanism to do so. The EOS community should consider creating a governance procedure to determine when to freeze questionable contracts. Doing this before the platform launches their mainnet could go a long way towards keeping the EOS platform resistant to criminal use.
The road to safety
The Ring of Gyges paper was published over four years ago, and we still don’t have good ways to prevent criminals from using smart contracts for ransomware or worse applications. Existing platforms tend to ignore the problem, and given the lack of criminal smart contracts in the wild, this is understandable. The situation resembles the early days of the internet. Initially, there were very few security controls because few people were trying to exploit the network. Once it became popular, bad actors found ways to take advantage of the system for malicious purposes. We should expect to see the same trend in blockchain systems.
Trustee-based tracing and trustee-neutralizable smart contracts could both deter criminal use, but they come at the expense of privacy or censorship resistance. We currently don’t have robust governance mechanisms that allow us to neutralize bad actors in a decentralized fashion. Absent these, we either must trust a third party to intervene in extreme cases or we accept the costs that completely decentralized smart contract platforms will bring, ransomware and all. The only other choice is to go back to the drawing board and design systems that will neutralize criminal use without making unacceptable trade offs.