0

I need to store a key (symmetric-key cryptography) within my C++ application binary (based on OpenCV) so that the key as unidentifiable as possible. Can someone help me choose the key so that is secure and it will be difficult for an attacker to find the key in the binary?

If I choose plain text (regardless of length) then this will be saved as text in my binary and will be easily identifiable, am I right? So I probably want to select a key that looks like a generic binary content.

I guess having multiple keys that will be used in predefined order may also make it more secure since the attacker has to find all the keys (which may be stored in different places within binary).

I need to choose this type of protection because of the nature of my application. I accept the risk of an attacker finding the key - in such case I will use new key and new application binary - but I do not want to do this very often (hopefully never).

I know it is impossible to have 100% key security this way but I want a basic level of security so that the attacker needs to have some knowledge at least.

Kozuch
  • 209
  • 1
  • 7
  • As text? Were you planning on storing the key in its hexadecimal text form, or as the binary bits that the text represents? – Technophile Sep 08 '19 at 17:29

3 Answers3

9

Basically, you can't.

What you look for is DRM by any other name, and history has shown time and time again that DRM isn't effective. Any skilled attacker in possession of the binary is therefore also in possession of the key, regardless of how well you hide it.

Even if you were to store the key on your server and load it dynamically from the internet, the attacker can either intercept it as it is being transmitted, or dump the key from memory once it has been loaded.

In fact, the attacker doesn't need the key at all, since once it is being used to decrypt some data, the attacker can just dump the decrypted data from memory, once decryption has finished.

  • I just added a paragraph that I know it is impossible to have 100% key security this way but I want a basic level of security so that the attacker needs to have some knowledge at least. Would you have a quick recommendation to have a basic level security by choosing a non-trivial key? – Kozuch Sep 04 '19 at 09:53
  • 1
    @Kozuch I could recommend you any number of things, but they would all be snake-oil ultimately. I can't ethically recommend any kind of obfuscation, knowing that it's purpose is to give a false sense of security. But let me ask the other way around: Why do you want to encrypt data for a user and selectively decrypt it for the user? What exactly are you trying to prevent? –  Sep 04 '19 at 09:55
  • I will sell USB devices (3D sensors) which each is calibrated and want to protect my calibration procedure by encrypting the calibration data (this data is specific to every device). There are about 10 pcs or more of float type values (real number) to protect. I can choose not to encrypt but make my "binary data format" instead - but this will not add any "security" either. Maybe add some "false" floats for confusion. The C++ application is non trivial (some math, analytic geometry...) so it will be hard to reverse engineer anyways. The product of the application is a stream of 3D point cloud. – Kozuch Sep 04 '19 at 10:14
  • 3
    @Kozuch "I want to prevent competitors from stealing my work" is a legal problem, not a security problem. You'd be much better off contacting a lawyer and check your options that way. This would be a *way* better option than adding a few pieces of obfuscation. Or let me phrase it this way: I'm pretty certain Sony could make a new PlayStation that can play Xbox games as well, if they tried. Guess what is holding them back? It's not obfuscation, that's for sure. –  Sep 04 '19 at 10:17
  • @MechMK1 I am not sure that the Sony PlayStation is a good example here, as this would be large corporations interacting in a very public way. Not much good to Sony to support XBox if they didn't tell their potential customers about it. I don't think that's a close match to someone copying this USB device. – Technophile Sep 08 '19 at 17:21
  • While I agree there is no such thing as 100% secrecy for a publicly deployed piece of software, you can make it pretty hard to reverse engineer it with some basic tactics. If your secrets aren't so important as to attract the super-talented hackers, then this is an effective strategy. I suspect that skilled hackers would not be interested in wasting their time reverse-engineering software to access this individual's calibration data on some sensors, since they can't make money from such an endeavor. – deltamind106 Feb 04 '22 at 23:42
  • @deltamind106 I can simply debug your application live. Once your key is deobfuscated and used to decrypt the data, I can simply look at the decrypted data once available. –  Feb 05 '22 at 14:09
  • @MechMK1 Yes you and I can both do that. However the point I'm making is that we (and others like us) won't bother doing that. Because the value of the the thing being hacked in this case isn't worth the effort. Skilled hackers spend time on things that have meaningful value. If this person were securing a popular game or an API key that has monetary value, then that would be completely different. All I'm saying is that if you're trying to keep secrets from your kid sister you can use simple security, and if you're trying to keep secrets from major governments then you can't. – deltamind106 Feb 07 '22 at 13:29
  • @deltamind106 "Keeping secrets from your sister" and "Keeping secrets from the government" both are completely unrelated to the question at hand. –  Feb 07 '22 at 13:55
  • @MechMK1 Correct, those are the two extreme ends of a wide spectrum. And the question at hand is somewhere in between. The original scenario sounds more toward the casual end of the security spectrum, and therefore some value can be derived even without using state-of-the-art security practices. I'm not sure why this seems so hard for you to understand, and it sounds like no amount of explanation will help you to see the point I am making. Regardless, my point should be self-evident now to anyone who wants to understand. – deltamind106 Feb 08 '22 at 13:45
2

Sooner or later an attacker will get access to the binary code of your application including your embedded password and thus will know the password. It is not serious to think that, if you scramble it, an attacker will not get the password. What are you trying to do is security by obscurity.

Remember Kerckhoffs's principle 2.

It should not require secrecy, and it should not be a problem if it falls into enemy hands;

What can you do instead? Put you encryption key outside of your application, so that application can read it when it needs.

mentallurg
  • 8,536
  • 4
  • 26
  • 41
1

Text? You are storing the key as binary, not as the text hexadecimal representation of the binary bits, right?

There's security, and then there's making things slightly less convenient for an attacker. It sounds like you are assuming that they have a copy of the program and are reverse-engineering it. Whatever you do, what is to stop them from simply copying that part?

If simply trying to be a bit more difficult, there are trivial games such as:

  • Shuffle the order of the key bytes and bits

  • XOR with an incrementing, decrementing or other numeric pattern

  • Spread key de-obfuscation across multiple code areas Which should slow them down by one to a few hours.

This only works as long as the attacker has insufficient motive to figure out the puzzle - and does not come up with some other approach to building a similar device.

Technophile
  • 113
  • 5