Slashdot Mirror
Building Deception Into Encryption Software
holy_calamity writes "MIT Technology Review reports on a new cryptosystem designed to protect stolen data against attempts to break encryption by brute force guessing of the password or key. Honey Encryption serves up plausible fake data in response to every incorrect guess of the password. If the attacker does eventually guess correctly, the real data should be lost amongst the crowd of spoof data. Ari Juels, who invented the technique and was previously chief scientist at RSA, is working on software to protect password managers using the technique."
TFA was murky, but generating bogus data? If one is brute forcing a data blob, how can it make stuff up?
Actually, it wasn't murky. That it cannot work for arbitrary data types is spelled out towards the end. This is for data of which the encryption system knows the data type well enough to fake it, and the encryption system has to be built to target the specific data type. The examples given are credit card numbers or passwords.
For instance imagine a password manager that, for every decryption attempt with a wrong master password, returns a different set of bogus but plausible passwords. How would a brute force attack automatically determine which one is the "real" set of passwords of the user, even if it can guess the right password?
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
I'd been looking into this in a slightly different context. Recently, at Hacker Dojo, someone demonstrated an Android mod to me which dealt with applications that demand too many privileges. It has the usual "disable privileges" option, but for apps that won't run with privileges disabled, it sends fake info.
The demo showed generation of fake phone serial numbers and such. That's easy. Apps that improperly try to upload your address book, though, require generation of a plausible, but fake, address book. That's wasn't in the demo, but it's worth doing. Location data should probably be sent as a random walk from some random starting point.
If enough people do this, it will garbage marketing databases.
Why would an attacker be using the enemy-provided 'honey' program to try to brute force the decryption?
Surely he'd use a program that isn't known for serving up fake results.
No sig today...
I guess it DOES have some benefit, huh?
People misunderstand what "security through obscurity" means. Most (all?) encryption relies on security through obscurity at some level.
Hiding your house key under a loose floorboard in your back deck is the kind of security through obscurity that can really work, assuming that there are no other clues that lead to the hiding place. However, hiding the prybar that you use to pry up the floorboard under the belief that hiding the method of access makes your key safer is not the kind of obscurity that works because if the attacker can find your hiding place, he can figure another way to get to the key.
Similarly, hiding or not writing down your password is security through obscurity that works. But trying to hide the implementation details of your cipher algorithm does not, because cryptoanalysis can break your encryption even without access to your encryption algorithm.
So, obscuring your real password among an endless number of fake passwords is the kind of obscurity that can work -- even if the attacker knows that your password is somewhere among the billions of fake ones, unless he has some clue to tell him what your real password looks like, just knowing that fakes are there doesn't help him.
There is XPrivacy, which uses the XPosed framework. That doesn't disable permissions, but rather sends fake data to the app.
Sure I sold you robot insurance. But you were attacked by a cyborg. Not covered.
The criminal doesn't care, as long as their goal is met (get a valid card - it doesn't have to be yours). If we're talking about "invalid" data, then we need some mechanism to validate the generated data before it's returned.
If you are worried about a random credit card generating algorithm generating real credit card numbers via this method, you should be just as worried about attackers using the same random number generator on their own!
Consider a case of a credit card number. A CC# consists of 15 digits plus a check digit for 16 digits total.
Now, in encrypting, validate the check digit and then drop it. Take the remaining 15 digits and express them as a binary value. It should be around 50 bits. XOR it against a 50-bit mask, and that will be your ciphertext value.
To decrypt, XOR against that same value and recompute the check digit.
Any incorrect value will produce a number that passes basic validation (as long as it doesn't exceed 2^15).
For bonus points, you can probably encode the first digit in only 2 bits, because most cards begin with 3, 4, 5 or 6, depending on the issuer.
Now, is this a good encryption scheme? Maybe not, but it does at least demonstrate the concept.
www.wavefront-av.com
Many a years ago I had a phone that included a password storage application. You gave it a 4 digit pin and it would show you a checkword, then list all your passwords (key->value). If the pin was wrong, it would still give you a checkword, but different from what your correct word get and then list all the same keys, but different passwords.
Was a pretty nice application, but can't remember the make of the phone, probably a Sony-Ericsson.