Schneier on Security

Clive Robinson • May 29, 2015 1:29 AM

@ SeriousQuestion,

Is it possible to have undecryptable encryption?

Yes, quite easily, use a One Time Pad and then throw away the Pad. You can easily prove that all the information is still there, BUT is unreachable because all messages of equall length are equiprobable.

Which gives rise to a question in return which is “Why would you wish to do it?”, I can think of a few but it would be interesting to know why you thought about it?

Clive Robinson • June 4, 2015 6:47 AM

@ Steve,

You need to ensure you have an offline back up, detect attacks quickly and have real time CSIR.

I thought about what we now call ransomware a couple of decades ago, and the current methods we are seeing is what you might call stage 1 of the possabilities.

The trick is to not make a quick attack, because the damage would be minimall to the victim and they might just say 5cr3w it and wipe and start again rather than pay the ransom.

As I’ve indicated on this blog before, if you want maximum effect you need to be in for quite a while doing the damage, such that the pain threshold is so high the victim will do as they are told.

Thus “backup systems” are the target to get APT on. Due to the failings if humans in corporates backups tend to be centrally managed, thus the backup system is visable to all connected computers, and available to be attacked.

Due to the same human failings backups are rarely tested and even then often they are not tested properly. So getting appropriate malware on the backup system has a low probability of being detected, because people don’t “test the tapes” on independent systems… Thus if your malware transparently encrypts the backup tapes, puting the tape in the infected machine to check it is not going to show the tape is encrypted.

The malware could also find out what the backup max cycle time is, thus it waits for a period longer than that before infecting and encrypting all the client machines then throwing the encryption keys away.

At various times employers have wondered why I made it a condition that I kept independent backups before developing code and hardware for them. I explained that I’d seen two companies get into real trouble because of poor backups and one had gone to the wall whilst another only survived because the disks I kept in my draw had enabled them to pull back six months of work on the then current projects I was managing. Subsiquently my policy has saved another companies engineering projects because although they had backups they were not tested and whilst admin and other more static systems got backed up the engineering systems that changed faster than projects, were not, and it was these high end systems the thieves had targeted…

Then there is insider attacks, it’s not hard to find on the internet examples of employes putting in “deadmens” switches and the like. One that comes to mind was the employee who made an entire US regeions medicins issuing database unavailable.

The problem with backups is not just knowing how they could be got at but activly finding ways to test them in a reliable way and that is both difficult and a thankless task. So usually backups gets given as almost a punishment task to a junior IT person, who will see no funding to improve it and no help, encoragment or employment credit / increment from doing so.

Not all organisations are like this those with fiduciary and legal liability tend to take things more seriously. But even then you will find organisations “doing it to audit” for the likes of cost offseting / externalisation via insurance…

So I forsee plenty of milage yet in ransomware, and it will move from penny&dimes on personal users to kings ransoms larger than some third world countries GDP when larger corporates get hit. It’s one of the reasons why I don’t think the SPE hacking was realy anything other than a bunch of insiders out for revenge via embarrassment rather than extortion.