views:

233

answers:

6

Hi,

My application needs to use a couple of hard-coded symmetric cryptographic keys (while I know that storing a public key would be the only perfect solution, this is non-negotiable). We want the keys to be stored obfuscated, so that they won't be recognizable by analyzing the executable, and be "live" in memory for as little time as possible - as to increase the difficulty of a memory dump retrieving them in clear-text. I'm interested in using C++ features (using some sort of scoped_key comes to mind). The solution must be portable - Windows, Linux, MacOS -, so it cannot take advantage of the operating system crypto API.

How would you go about designing such a system? Thanks a lot.

+4  A: 

All you're going for here is security through obscurity. If you have one of us come up with an idea, you won't even have that.

John Skeet has a good article on this too.

Do something random is all I can say.

Spencer Ruport
+3  A: 

your scoped_key can be simply a KeyHolder object on the stack. Its constructor takes the obfuscated buffer and makes a real key out of it and its destructor zeros out the memory and deallocates the memory.

As for how to actually obfuscate the key in the binary, One silly choice you might try is put inside a much larger random binary block and remember its offset and size and probably XOR it with some short random sequence.

If you do the XORing thing you can actually avoid ever having the real key in memory. simply modify the decryption to read a byte from the key and before using it, to XOR it with the appropriate value.

*Add here disclaimer on how foolish security through obscurity is*

shoosh
Thanks for sparing the disclaimer - I am aware of that, but it _is_ better than no protection at all! The important thing is to keep in mind this is only a palliative, and any attacker who's both skilled and determined will work her way around it.
Pedro d'Aquino
A: 

If you do not take advantage of whatever platform you will run on, you cannot guarantee that you can effectively hide a symmetric cryptographic key in your program. You can assume that an attacker will have a debugger and will eventually figure out how to set a breakpoint in the function that has to use the key to decrypt. Then it's game over.

MSN
A: 

Why not look at steganography, as you can hide the key in an image. It is possible to find the key, but if the image doesn't follow an obvious pattern (such as an image of space would) then it may be harder. This can be cross-platform.

James Black
+1  A: 

You should look into Tamper Resistance software, such as Cloakware and Arxan.

TR is NOT cheap :)

ykaganovich
+3  A: 

Have you considered if this is actually the weak point in your program? Let's assume for the sake of argument that you're doing a license check - though other checks apply equally well. No matter how well hidden your key, and how well obfuscated your algorithm, at some point you have to do something like this:

if(!passesCheck()) {
  exit(1); 
}

Your potential adversary doesn't have to find the key, decrypt it, figure out the algorithm, or anything else. All they have to do is find the location in the code where you determine if the check succeeded, and replace the 'jnz' instruction with a 'jmp' to make the test pass unconditionally.

Nick Johnson
Thanks, Nick. The problem I'm facing is not one of license checks, or any other check for that matter. It's a software that comes up with some data, encrypts it and sends it back to a server.
Pedro d'Aquino
What's the goal here? If you're trying to prevent your users from reading the data, it's a moot point, since they can examine the data before it's encrypted. If you're trying to prevent them from modifying it, or prevent them from generating their own messages, you need to be aware that encryption on its own does _not_ guarantee integrity - you need either public key crypto or an HMAC for that.
Nick Johnson