I would suspect that the keys would be different for each infection. But then considering this is software made by criminals, I would not expect even the most sensible or trivial of features and security precautions would be implemented.
The ransomware developers could use public-key cryptography by generating a local session key to encrypt the victim's files, and then encrypting a copy of that key with the developers' public key. The paid ransomware service would then consist of decrypting that particular session key on request.
Perhaps the ransomware developers don't understand this or thought it was too much work, or perhaps they want to provide a better user experience by sending a unilateral unlock code rather than requiring the victim to send any data to the attacker.
Congratulations to the people behind this collaboration for making progress on helping the victims.
> The ransomware developers could use public-key cryptography by generating a local session key to encrypt the victim's files, and then encrypting a copy of that key with the developers' public key. The paid ransomware service would then consist of decrypting that particular session key on request.
The private-key to generate the session-key has to exist somewhere -- you don't want it anywhere it can be traced back to you, so it would probably be on some automated control server - which tracks the payment addresses and forwards the decryption key on bitcoin payment receipt.
My guess best is that some of the keys got recovered in the C&C Server take-downs.
It would be possible to use bitmessage or another non-ip traceable method of communication to pass decryption keys and and keep the structure separate from the C&C servers.
> I would suspect that the keys would be different for each infection.
They are. CryptoLocker[1], which CoinVault is loosely based on, used per infection keys, and the warnings on the Kaspersky site make it clear they don't believe they got all the keys, which would mean there's more than a few keys.
> But then considering this is software made by criminals, I would not expect even the most sensible or trivial of features and security precautions would be implemented.
I'd advise against underestimating your enemy in this global age. These aren't petty thieves akin to digital purse snatchers, working haphazardly, but the work of a few motivated individuals, likely with ties to organized crime.
In my experience, most malware creators are pretty terrible. Even in 2015 it's common for malware to communicate with C&C servers that have classic SQL injection vulnerabilities.
More specifically on the topic of ransomware, have a look at this gem [1], which uses RSA, but the key is 128 ASCII digits. Very similar to the cryptocat disaster. [2]
Implementing this right is surprisingly hard, as the Debian SSL fiasco and the Java/Android's so called SecureRandom RNG have shown. Maybe they were using a defective RNG for the keys as well, so in total there is a very limited number of keys out there, making collisions probable?
I assume it's a low percentage of people that would take advantage of this, so they probably don't really care. They care about the big percentages, the low hanging fruit.
