WannaLie is a research project exploring designing more “fair” ransomware systems, inspired by this series of posts. As it stands, 1 in 5 small businesses infected with ransomware never get their data back. Attackers lose keys, screw up payment processing, and instill distrust in users (who don’t even try to go through with the decryption process and potentially forfeit precious data).

By leveraging homomorphic encryption and smart contracts, we can develop a mechanism whereby victims are able to 1) trustlessly verify that their files are encrypted by the public key that the attacker is claiming was used and 2) only pay when the private key corresponding to that public key is sent.

The first component is enforced by having a victim homomorphically encrypt their own (private from attacker) data with the public key that the attacker claims was originally used to encrypt the files (note that in practice ransomware attacks actually use symmetric key encryption to encrypt each file, and then encrypt that file-specific key using a public key from an asymmetric key encryption scheme). This ciphertext is combined with the encrypted contents of one of the victim’s files and this combination is given to the attacker to decrypt. Because this new ciphertext is a combination of one of the victim’s files as well as a piece of data known only to the victim, the attacker has no idea what they are decrypting and cannot cheat (e.g. using a lookup table populated during the original attack).

The attacker then passes the decrypted result (unreadable to them) back to the victim, who can undo the combination previously done (thanks to the homomorphic encryption scheme used). They are then able to verify the decrypted contents of the original encrypted file used as part of the combination and have increased their confidence that the original files were encrypted with the claimed public key (at least sure that this file was, and the file is “random” in a sense). Further trials can be done to increase confidence.

In developing the toy malware for testing, elliptic curve ElGamal over secp256k1 was used to encrypt AES keys (which were originally used to encrypt files). This is the same curve used by Ethereum, and ElGamal is homomorphic over certain operations (depending on implementation), allowing us to do the verification dance as described above. SJCL is one implementation that supports ElGamal over this curve.

The second component involves an Ethereum smart contract (KeyReleaser.sol). Essentially, the attacker specifies in the contract the public key that they claim to possess, along with the price they’re demanding. The victim then locks up the requested funds in the contract. When the attacker attempts to claim the funds with the supposed private key, the contract verifies that the submitted private key corresponds to the original public key (using jbaylina/ecsol) and only dispenses funds if the private key is valid. If no one submits the appropriate private key within a certain number of blocks (specified by the victim), the victim can withdraw their funds from the contract.