Solved

Key Protection from Reverse engineering

Posted on 2010-09-17
73
727 Views
Last Modified: 2013-12-04
Hi Guys,

I've read many questions on the anti-reverse engineering, but I don’t know if they apply to my issue.

I have a C++ AES encryptor and decryptor in the same exe. Its used to encrypt and decrypt our files. Pretty straight forward and simple. We recently parted ways with a company that did some developing for us and we know they will do everything to harm, hack, crack our software. I did implement some dynamic key encryption technique using some info on the computer like hardware profiles and date and time but I don’t know if that makes a difference at all or can someone just see the dynamic procedure we have and replicate it to decrypt the data.

My questions are:
-Is there any way to hide our AES encryption and vector keys ?
-If they decompile our code to the assembly code can the read our procedure (first encrypt with AES, then Twofish, then compress, then replace As’ with Ts’) and the keys used in the process?
- Can they modify  our exe and then just replace the original in the installation folder with their version?

If so then is there a solution to protect our code, i know that full protection can never be achieved but at least something to protect the key being used to encrypt files. Right now the key is in a char variable, would it be better if we hide every character from the key in a different place and then assemble them into a key or would someone be able to read that as well?

I'm kind of new at this Anti-reverse engineering so any guidance will be appreciated.

 Thank you,
0
Comment
Question by:xNejX
  • 15
  • 15
  • 9
  • +7
73 Comments
 
LVL 40

Expert Comment

by:evilrix
ID: 33704955
If you include a key in a binary then here is nothing you can do to prevent it being discovered. Even if you encrypt it you need to provide the key to decrypt it. The only safe thing to do is generate the keys once installed and store them locally.
0
 
LVL 40

Accepted Solution

by:
evilrix earned 150 total points
ID: 33704962
>> The only safe thing to do is generate the keys once installed and store them locally.
This should be generated using entropy such as getting the user to move the mouse around.
0
 

Author Comment

by:xNejX
ID: 33704995
@evilrix

How do you mean store locally? Like in a file or registry?
0
 
LVL 40

Expert Comment

by:evilrix
ID: 33705025
>> How do you mean store locally? Like in a file or registry?Well, it can be either. Once it's stored on the local machine you would expect to use ACLs to ensure the file is protected from inappropriate access. If the keys are in the binary and you are distributing it for installation anyone can reverse engineer it (using a disassembler). If you generate the key once it is installed from entropy and then save the key on the local file system (securely) that is about as much as you can do. If the end user fails to provide adequate protection on their machine there is little you can do to prevent access to the key.There is no such thing as perfect security - the trick is to make the game too hard for the bad guy to want to play.
0
 

Author Comment

by:xNejX
ID: 33705068
I understand but wouldn't the file location of the key or the registry location of the key be very easy to read from the disassembler?

I have no idea what entropy is :) but i will google my way through it. ;)
0
 
LVL 40

Expert Comment

by:evilrix
ID: 33705159
>> I understand but wouldn't the file location of the key or the registry location of the key be very easy to read from the disassembler?It matters not if I can see where the key is stored if I don't have access to that location does it? Put it this way. If I disassemble your program to see the key is in c:\temp there is little I can do with that as I have no access to your computer nor c:\temp on it.The only time this is an issue is if you need to share data between people but you could just use normal public/private key protection for this, whereas someone must give you their public key so you can encrypt it for use with their private key.Note the private it is exactly that and is why you cannot distribute a binary with keys embedded safely... the key is no longer private.>> I have no idea what entropy isIt's just a fancy word for randomness -- I think it is stolen from thermodynamics and is used to describe how disorganised a system is :)
0
 
LVL 32

Expert Comment

by:phoffric
ID: 33705179
Within your box, you add a small box with a small amount of ram and 5 year battery. This small box is sealed, and if seal is broken then the ram is erased.

You store half of your key in this box. Other half is stored in a local variable in memory. When you need a key, you query the small box using another key to enable communications for the main application to get the other half of the key.

Change keys as frequently as possible. In mylar tape days, keys were changed daily. Now they can be changed on each transaction.
0
 
LVL 32

Assisted Solution

by:phoffric
phoffric earned 50 total points
ID: 33705226
>> Can they modify  our exe and then just replace the original in the installation folder with their version?

Yes, they can modify your exe and try to do whatever they want. But you can prevent this. You include in your loader a CRC32 of the exe which is stored in a separate location (e.g., flash, the locked box, etc.) The loader is in flash (and it has its own CRC32 as well. If any CRC32 checks fail, you set flag in flash so that the box cannot boot ever again (without a trained specialist to reset the system). Working out the details for high security doing this type of work requires a good deal of expertise. But I hope you get some ideas to help you.
0
 
LVL 32

Expert Comment

by:phoffric
ID: 33705240
I forgot to mention that all stored keys are encrypted, requiring yet another key to be transferred over to decrypt the keys.
0
 
LVL 12

Expert Comment

by:trinitrotoluene
ID: 33705363
to add to what evilrix is saying ACLs would ensure a certain level of protection is achieved.

I know it also possible on Windows 32 bit atleast to achieve a certain level of file protection using kernel patching. it becomes a bit more tricky on 64 bit but then still I dont know whether you have the time to do this.

http://blogs.msdn.com/b/windowsvistasecurity/archive/2006/08/11/695993.aspx

Kernel patching is not recommended by Microsoft but several Anti-malware vendors use it to achieve a certain level of protection by intercepting system calls and taking adequate steps if they find it malicious. The argument is that you make the whole system unstable and unreliable

what i am trying to say is that you can implement a certain level of protection for the Installation folder of your application so that any attempts to copy, modify or read it can be controlled.

As an alternative to Kernel patching Microsoft also recommends:
http://www.microsoft.com/whdc/driver/filterdrv/default.mspx


Additionally I am sure you are digitally signing your binaries.
0
 
LVL 3

Assisted Solution

by:rgeers
rgeers earned 50 total points
ID: 33705598
The people from skype did all the tricks in the book to try and obfuscate their code and ever this has been reverse engineered. Try to google for skype reverse engineering, and you get some idea of what you are upto, not a easy task.
0
 
LVL 3

Expert Comment

by:rgeers
ID: 33705633
If you want to control the software, you need to control the hardware first. Since this is not an option on windows machines, you can only make it as hard as possible. Impossible to reverse engineer is if you can run it on a SIM, but I guess this is not an option. Is a hardware device feasable for your solution?
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33706973
Since there are already many experts participating, I wouldn't have replied, but it seems that a crucial subject is not being talked about :

>> we know they will do everything to harm, hack, crack our software.

What kind of attacks are you expecting ? What does the software do, and how does it interact with the world and other copies of the software ?

If they can get a valid copy (properly licensed etc.) of your software that they can run, then they can do anything they want with that copy. No level of security will be sufficient. Even if you add obfuscation, encryption, and all security measures you can think of : at one point or another, the decrypted code and data will be in memory, where it can be easily read.


>> first encrypt with AES, then Twofish, then compress, then replace As’ with Ts’

So, all you do with that, is make it slightly more difficult to get around. On the other hand, you also make your software a lot more complicated and a lot slower.


The kind of attacks you could (try to) do something against, are those that try to manipulate another person's copy of your software without that other person's (or your) consent. But that's a small subset of possible harmful things they could do.
So, if you could give us a bit more background information, we might be able to give you some better advice.
0
 
LVL 1

Expert Comment

by:geert_v
ID: 33708076
First of all, there is no absolute security. Depending on the skills of the hacker, there is always
a chance your code will be hacked.
I understand from your question that you want to achieve 2 things:
- store some (partial) keys in the executable in a way that is difficult to find them
- prevent that your encrypt/decrypt routines can be called from modified code

You can do a few things to make this difficult for a hacker:
- Don't store your key in a string, but calculate it. Don't use a standard for the calculation
but find something yourself. An example:
suppose the key is 1 2 3 4  (integer values)
   calculate the firs 4 fibonaci numbers 1 1 2 3
   define an array int x[4] = {0, 3, 1, 7};
   xor the fibonnaci numbers with your array, this wil result in 1 2 3 4
(it is easy to write some script that generates the required C++ code for a given key)

- Don't store the calculated key in a (global) variable for long time, reconstruct it whenever
needed.

- inline all routines that do encryption/decription or the key calculation. Make sure these
routines are not available anymore as a symbol in the executable/dll. You could even
consider putting the code in a preprocessor macro. This makes it very hard for a hacker to locate
the sensitive code and to use it from other places. (due to compiler optimization, the
encryption code may even be mixed with other code). The different instances of the inlined
code may also look different (using different registers etc)







0
 
LVL 12

Expert Comment

by:trinitrotoluene
ID: 33710044
xNeix:

Assymetric encrytption algorithms such as RSA can be more effective than symmetric algos. But brute forcing the encryption keys is also not so easy.

AES has several modes of operation and only certain modes can be brute forced by a determined hacker.
Just to dispel some of your doubts on AES I would suggest you take a look at the following post

http://xorloser.com/?p=93

The dilemma of all encryption programmers is that the any encrypted binary has still got to decrypted when it is running. I would suggest that you consider the following strategies as well

- decrypt your binary in blocks when it is running rather than decrypt all at one shot
- protect your application with several layers of encryption rather than just one
- with Windows there are ways to detect whether a binary is being disassembled, implement this in your application
- do not have a generic encryptor for all your executables. let the encryptor behaviour differ from executable to executable


Also take a look at my previous post.
0
 
LVL 40

Assisted Solution

by:evilrix
evilrix earned 150 total points
ID: 33710066
>> You can do a few things to make this difficult for a hacker:
Obfuscation is not encryption (and if you don't understand what the difference is you really shouldn't be opining in this or any encryption related question). If your application requires strong encryption (and if it's using encryption one has to assume it needs to be strong) then nothing you do to try and hide the key should be considered safe. It matters not, for example, if you inline functions... a good disassembler will still allow you to step through the code and see exactly what is being done to reconstruct the key.

>> Assymetric encrytption algorithms such as RSA can be more effective than symmetric algos
Asymmetric algorithms are weaker the symmetric so they require large keys to implement the same level of encryption. Since the asker is looking to embed the keys in the binary this really makes little difference. Once I have the key (obtained via disassembling the binary) and once I've figured out the encryption algorithm used I am in.

>> But brute forcing the encryption keys is also not so easy.
They are not "hacked" using brute force... you just step through the disassembly.

>> any encrypted binary has still got to decrypted when it is running
This is true (and, thus, data will be clear in memory) but someone has to gain physical access to the machine for this to be an issue. If the keys are in the binary all they need is the binary and a copy of the encrypted data. The latter may be easier is immediately obvious - if you are using a tool that you believe is affording protection via encryption you are likely to not be too concerned about making that data visible in the public domain.
0
 

Author Comment

by:xNejX
ID: 33711958
Wow Exprerts, thank you for all your help. I wish I could give you all 500 points or more :)

Infinity08 has requested some further info on the software. Well we expect them to try to hack our software in a way to proove that we do not offer sufficient key protection on our own without them.

The keys can't really be stored somewhere outside the persons PC (flashdrive, SIM, dongle..) because its a simple and FREE go-and-download-it application, so we can't implement anything like that.

@geert_v
That is great, but do you think that we could also calculate it in a client - server envoiroment, where the client encrypts something, sends it via network to the server and the server decrypts it. Is there a way of creating a dynamic key logic for that without it being based on time, date or anything that a user could change in windows?

Would changing the code a bit every week and forcing an update somehow be a smart way of going about it? We can change the way that it is stored and where it is stored and what type and length of encryption to use. We can also obfucate the code in a different way every time and replace classes orded in the source. We can also implement some decoy classes every time. Does that make it more difficult if that would force them to hack it every week? I know that the time to hack something depends and varies from software to software, but how long do you think that a hacker needs to crack your code?
0
 
LVL 1

Expert Comment

by:geert_v
ID: 33712024
>> That is great, but do you think that we could also calculate it in a client - server envoiroment,

I think that's difficult. I understood your question was about 'hiding' a (fixed) key in an exe for
encrypting locally stored files.

>>  Is there a way of creating a dynamic key logic for that without it being based on time, date or anything that a user could change in windows?

What you could do  (it depends on your setup whether this makes sense or not) is to use
the 'current key' to exchange a new key on a regular basis (e.g. weekly). From the moment
the new key is exchanged, both client and server use the new key, and the old key becomes
invalid.
In the case where a key is 'stolen', only one of both clients having the key can update to a new
key (since for the second client that does an attempt to renew the key, the key has become invalid.)
So at least you will notice that something irregular happened.




0
 
LVL 32

Expert Comment

by:phoffric
ID: 33712612
Do you believe that the attacker will be able to penetrate a run-time process; or just read the executable file? If they can read (and possibly write/modify) the process, then they have control over your program.

If they can only read the executable, then the client/server processes can exchange encrypted keys over the network.
0
 
LVL 12

Expert Comment

by:trinitrotoluene
ID: 33713739
"Asymmetric algorithms are weaker the symmetric so they require large keys to implement the same level of encryption. Since the asker is looking to embed the keys in the binary this really makes little difference. Once I have the key (obtained via disassembling the binary) and once I've figured out the encryption algorithm used I am in."

Aren't different keys used to encrypt and decrypt when it comes to asymmetric algos? Disassembling the code and getting the key is going to help only with symmetric algos like AES. As far as I know Symmetric encryption should not be used as protection as once the key is found the protection is lost.
0
 
LVL 40

Assisted Solution

by:evilrix
evilrix earned 150 total points
ID: 33714484
>> Aren't different keys used to encrypt and decrypt when it comes to asymmetric algos?
They are but the algos are also weaker and so far easier to crack - hence you have to use larger keys.
http://en.wikipedia.org/wiki/Key_size

>> Disassembling the code and getting the key is going to help only with symmetric algos like AES
Read the question: "I have a C++ AES encryptor and decryptor in the same exe. Its used to encrypt and decrypt our files."
If the same binary needs to encrypt and decrypt the same files in needs both keys. This doesn't help.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33715310
>> Infinity08 has requested some further info on the software. Well we expect them to try to hack our software in a way to proove that we do not offer sufficient key protection on our own without them.

Ok.

Do you want to hide the files from anyone, except your company (including hiding the files from the rightful user) ?
Or do you want to hide the files from anyone, except the rightful user ?
0
 
LVL 22

Expert Comment

by:ambience
ID: 33715466
>> crack our software
I wouldnt have replied either, but I see that a key point is still not addressed.
See, no matter what you do and how many times you apply encryptiong algo combos, a hacker would certainly not ** attack /crack** your software in a manner that those make much difference. If I were trying to crack your software, the very first thing and the ultimate thing (if it works) would be to attempt to ** hijack/intercept ** and therefore make the ** checks ** useless.
This is easily accomplished using DeTours for example or any API hooking toolkit, because all I need to know is the place where the ** function ** that checks for valid keys returns whether its ok or not. Once I know that the next thing is to redirect it by injecting a dll and intercepting the function call. Or I can just patch it with machine code that short-circuits the check or bypasses it.
It may not be as simple as it sounds, but certainly not an impossible thing, given the right kind of motivation.
Interception is probably the single reason that renders most defenses against illegimate usage useless and as far as I can think the best defense against it is code encryption (that too can be broken). IF the code is encrypted then interception will not work because you will need a valid key to decrypt the code. A big issue with decryption is that self-modifying code is prevented by Windows DEP policies. Plus, de-encryption can be reverse engineered too (as already mentioneD).
On a different note, If I can afford to buy a legitimate license, then the dynamics of cracking change altogether. All I need now is to impersonate a machine, again using API interception. I'll need to inject a dll into the app and intercept and hardcode values for the API that return system description. Just distributing the patched exe, dll and the key file will constiture a crack. If you had programmed to check whether the key is valid for a machine only, then thats the way to crack it.
Again may not be as simple as it sounds, but theoretically possible.
The bottom line is that no matter what you do can be undone, as long as everything happens on the client. If you really must prevent that then make use of web-services. Make sure significant and core portions of the functionality are provided by the server.
0
 
LVL 22

Assisted Solution

by:ambience
ambience earned 100 total points
ID: 33715473
>> crack our software
I wouldnt have replied either, but I see that a key point is still not addressed.
See, no matter what you do and how many times you apply encryptiong algo combos, a hacker would certainly not ** attack /crack** your software in a manner that those make much difference. If I were trying to crack your software, the very first thing and the ultimate thing (if it works) would be to attempt to ** hijack/intercept ** and therefore make the ** checks ** useless.
This is easily accomplished using DeTours for example or any API hooking toolkit, because all I need to know is the place where the ** function ** that checks for valid keys returns whether its ok or not. Once I know that the next thing is to redirect it by injecting a dll and intercepting the function call. Or I can just patch it with machine code that short-circuits the check or bypasses it.
It may not be as simple as it sounds, but certainly not an impossible thing, given the right kind of motivation.
Interception is probably the single reason that renders most defenses against illegimate usage useless and as far as I can think the best defense against it is code encryption (that too can be broken). IF the code is encrypted then interception will not work because you will need a valid key to decrypt the code. A big issue with decryption is that self-modifying code is prevented by Windows DEP policies. Plus, de-encryption can be reverse engineered too (as already mentioneD).
On a different note, If I can afford to buy a legitimate license, then the dynamics of cracking change altogether. All I need now is to impersonate a machine, again using API interception. I'll need to inject a dll into the app and intercept and hardcode values for the API that return system description. Just distributing the patched exe, dll and the key file will constiture a crack. If you had programmed to check whether the key is valid for a machine only, then thats the way to crack it.
Again may not be as simple as it sounds, but theoretically possible.
The bottom line is that no matter what you do can be undone, as long as everything happens on the client. If you really must prevent that then make use of web-services. Make sure significant and core portions of the functionality are provided by the server.
0
 
LVL 45

Assisted Solution

by:aikimark
aikimark earned 50 total points
ID: 33715854
* Obfuscation will slow them down. (I'm a fan of Themida by Oreans Software)

* Release new versions often

* Distribute license checking code throughout the program (create multiple targets)

* Make invoke license checking in a pseudo-random fashion (sometimes you check and sometimes you don't)

* Realize that if you use system routines, you are presenting opportunities for sniffing keys, seeing returned (plaintext) values, and authentication spoofing.
0
 

Author Comment

by:xNejX
ID: 33723285
Thank you all for your comments. It is hard to pick the best one as all of you gave me a good understanding on how things work and I was able to find further reading on your suggestions.

I distributed points:

Evilrix:          250
Infinity08:     100
ambience:    100
aikimark:      100

Again thank you for your help.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33723323
I'm not convinced that you got the best answer you could get. For one, there's still some crucial information missing. Specifically, what is it exactly that you are trying to protect, and from whom exactly ?
0
 
LVL 40

Expert Comment

by:evilrix
ID: 33723338
Hi xNejX,

There is no rush to close this question. As long as you stay active we can keep discussing this for as long as you need to make sure we resolve your issue - or at least ensure you understand the problems related to encryption.

If you wish to abort the close process please do so. I agree with Infinity08 that I don't think we have actually addressed the core issues here yet.

-Rx.
0
 
LVL 30

Assisted Solution

by:Zoppo
Zoppo earned 50 total points
ID: 33723435
Allthough there's already a lot of info here I would like to mention an additional one.

IMO a good idea to make the job for a hacker harder by using some anti-debugging techniques. Further hacking may become more difficult if some funcionality works asynchron, i.e. you could start a thread which decrypts something and, if successful, unlocks a mutex which can be used later.

ZOPPO
0
 

Author Comment

by:xNejX
ID: 33723476
@Zoppo

That is a good one, i will definitely try to implement it in our solution.


Is it worth implementing a solution to detect reverse engineering tools or will that not slow them down at all?
0
 
LVL 30

Expert Comment

by:Zoppo
ID: 33723567
> or will that not slow them down at all?

This depends on how you implement it - i.e. to avoid a slow down you could implement this by
- using a single check at startup
- check it with some seldom called but essential functions like load/save of files, login to server ...
- starting a thread which repeatedly checks this i.e. every 10 seconds

ZOPPO
 
0
 

Author Comment

by:xNejX
ID: 33723585
Ok, that seems great but aren't they abble to comment this section out with a binary hack and just disable this checking and create another instance of their own .exe?
0
 
LVL 30

Expert Comment

by:Zoppo
ID: 33723641
Yes, of course here it's the same as others mentioned above - there's no chance to avoid those calls can be removed by changing the binary, so this is not a solution to the general problem but another step to make hacking difficult ...
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33723648
Security is not about slowing an attacker down for a few hours or days.
Security is about making it unfeasible for an attacker to be able to break your security within a reasonable time frame and with reasonable resource cost (time, money, ...).

Please stop recommending obfuscation as a valid alternative for security. It's not. It just complicates your software (giving more chances for (exploitable) bugs), and gives you a false sense of security.
Obfuscation only somewhat works against attackers that are not determined.

If you are looking into securing data, I recommend ignoring all advice about obfuscation, and focusing on the advice about security and encryption. And if you want us to help you with that, we'll need some more information. See my earlier posts eg.
0
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 

Author Comment

by:xNejX
ID: 33723654
Thank you for your contribution Infinity08.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33724251
So, does that mean you don't want my help ?
0
 
LVL 22

Expert Comment

by:ambience
ID: 33724291
>> Obfuscation only somewhat works against attackers that are not determined
And that is a significant number of them. Obviously I can not compliment with survery results or an objective analysis, so that leaves it as debatable - but from experience I can tell that a wannabe hacker (and many of them) would certainly not take up a monumental task of reverse engineering. Only, the right kind of motivation can push a hacker. Real hackers dont do it for mere fun, they do it for money (perhaps) or maybe a misplaced sense of intelectual achievement. Given that the hackers are likely to be from a software company, I dont think they would have enough time/resources to do an all out attack. That however is a subjective assessment.
Nonetheless, I agree that in order to find out the best strategy the business stakes must be known in addition to other other information about they way the system should work.
I remember working on a product that got cracked and interestingly the best strategy for us was to make the reverse engineering soo difficult that a novice attacker would not pursue it long enough, but if anyone dared to crack - we sufficed to say that he/she deserved it.
I would certainly not opt out obfuscation, unless the ** cost of getting cracked ** is higher than the amount of efforts you would incur to ** try to prevent ** as much as possible.
 
0
 

Author Comment

by:xNejX
ID: 33724297
No, just an honest thank you for your advices. If you can suggest any techniques on how to protect the binary or stop memory reads, please do so.
0
 

Author Comment

by:xNejX
ID: 33724374
Obviously there is far too much input to close the thread right now, so I am re-opening it.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33724405
>> No, just an honest thank you for your advices.

You may have noticed that I asked for more information a few times - I cannot in good faith give you advice unless I know more of your specific situation. Guessing when it comes to security is very dangerous, because the stakes are too high.


@ambience :

>> Nonetheless, I agree that in order to find out the best strategy the business stakes must be known in addition to other other information about they way the system should work.

And that's the only point I'm making. I see a lot of advice that has already been given, without really knowing the exact circumstances. In order to give good advice, one needs to first understand what the problem is.
Giving advice without knowing the exact circumstances is not the way to go - especially not when dealing with a security related question.


>> I would certainly not opt out obfuscation

I'm not ruling it out. I'm saying that it should not be labelled as security, because it's not. I'm saying that it should only be used if there is no viable way to properly secure the data.

I'd also like to point out that the original question said :

>> they will do everything to harm, hack, crack our software.

That indicates a determined adversary.
0
 
LVL 45

Expert Comment

by:aikimark
ID: 33724888
Obfuscation is a means to make your code less hackable/crackable.  Since you will be distributing your code, part of the total 'security' of the licensing is the protection of the code itself.  It plays a PART in the total security.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33724988
Obfuscation of code is a means of making it slightly more difficult to figure out the algorithm.
A good encryption algorithm is an algorithm that is known to anyone that wants to know it, and that has been proven to be difficult to crack. A good encryption algorithm does not need obfuscation.

So, I tend to disagree : obfuscation is not a part of good security. It's what many people revert to when they see no way to properly secure the data (either because there is none, or more likely, because they don't know about the better options that exist).


Or, if you're still not convinced : if you rely on obfuscation to protect your data, then you need just one person to spend some time to get through the obfuscation, and your "security" is broken forever - nothing you can do against that.
If you rely on proper security, then your data will be guaranteed to be safe within certain reasonable constraints (determined by the strength of the encryption you chose eg.).

Which approach would you prefer ?
0
 
LVL 30

Expert Comment

by:Zoppo
ID: 33725126
I fully agree, obfuscation is not equivalent to security. Makeing code harder to debug isn't too.

But IMO maybe there's nothing else one can do. As soon as a hacker has the binary he can change it. That's a fact. You can encrypt it, but to be able to execute it it must be decrypted. Therefore the key for decryption has to be somehow passed with the binary (maybe coded and somehow masked in the binary). If the hacker determines the algorithm and where/how this key is stored he's able to replace the key and use his own. The same issue exists with signature. So, there's no guaranteed way to avoid a hacker can modify the binaries, thus can work around, skip or anything with security-related functionality.

The only 100% secure solution would be to remove functionality which has to be protected and let the application use it via something like a web service.

The next, less secure solution would be to use a hardware dongle - I don't exactly know, but I think every hardware dongle can be somehow simulated.

To give more detailed help I agree that more information is needed ...

ZOPPO
0
 
LVL 45

Expert Comment

by:aikimark
ID: 33725237
If you hand someone an executable that includes a decryption key and do not obfuscate your code, I assert that the application will be cracked very quickly.  That is why I capitalized 'PART' in my prior comment.

I think the goal is to limit the effectiveness of the hacker/cracker community.  For instance, if the executable for each user were unique, then that user's license file would be unique, hopefully tied to their hard drive or a dongle, and any single user crack could not be used to unlock any other user's application.

There are other actions that help, such as 'wiping'/resetting variables in a routine prior to their release.  Keep any sensitive data as short-lived as possible.  Minimize 'trust' in external/system calls.  Limit the lifespan of your application.  You may not charge for an upgrade, but you can force the crackers to start over.

At some point, you have to accept that your application will be cracked if it is popular or 'worth' cracking.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33725403
>> But IMO maybe there's nothing else one can do.

The keyword is "maybe" :) But without further information, we just don't know.

Without more background information, we have no way of knowing if the advice we give will turn out to be good or bad. In such cases, it's always my preference to wait with giving advice until I know all the facts.


>> I think the goal is to limit the effectiveness of the hacker/cracker community.

I don't know what the goal in this case is. I still don't know what it is exactly that needs to be protected, and from whom.

All I know is that it has something to do with files, and a company that used to develop for them that would do anything to prove that those files aren't protected properly. Again : this does not say what those files are, where they are, or who they need to be protected against. And those bits of information are quite important when it comes to giving advice on how to do it :)


I think I've made my point, and I'll just wait if xNejX intends to give us the information I need to be able to come up with good advice.
0
 
LVL 45

Expert Comment

by:aikimark
ID: 33725562
@Zoppo

>>...code harder to debug
I advocate a post-compilation debugger.

Barring that, add a step to the distribution kit build that will obfuscate a COPY of the source code and then do testing on the (now obfuscated) code you are about to distribute.

Adding some logging capabilities will help with debugging.  I'm a fan of Codesite by Raize.
http://www.raize.com/DevTools/CodeSite/Default.asp
0
 

Author Comment

by:xNejX
ID: 33725660
@Infinity08

We are encrypting local .dat files. They can be located anywhere on your PC. When you choose to encrypt the file the content of it gets opened and encrypted with AES 256 bit encryption. The random key that was used for the encryption gets stored in the registry (the key is encrypted when stored):

The file gets sent to our remote client along with the encrypted key (that is why we need to store it somehow because the process is automated). On the remote client side the key is decrypted, and then the result of the decryption is used as a key that decrypts the received file and categorizes it in the correct folder. (It usually creates a new folder for todays date)

So that is why the key needs to be stored somewhere. The process is often automated thus excluding the option of the user always creating a key and then using another method to notify the remote client about it.

We are trying to protect our software from our former partners who are very good at developing assembly and low level kernel type code. The concerns are:

- they will find out where the key is hidden
- they will be able to find out the key that is used for encryption of our random keys thus making the extra step for key encryption obsolete
- they will be able to release a piece of software that will decrypt and read the encrypted files thus making our software useless.

I am sorry but I am not at liberty to disclose everything about it, due to the fact that this is a public thread. I think I did provide all the information that I can -above.

Thank you
0
 
LVL 53

Assisted Solution

by:Infinity08
Infinity08 earned 50 total points
ID: 33726151
>> The random key that was used for the encryption gets stored in the registry (the key is encrypted when stored):

I would suggest not to store the key (unless the user asks to do so). By default, I would require the user to enter a password in order to access the dat file.

That way, the responsibility is in the user's hand. If he trusts his own computer (ie. is sure that no unauthorized persons can use it), he can store the key in the registry. If he doesn't trust his own computer, he can choose to require a password for every access.

The password could be anything. It could be the actual key (either typed in, or stored on a dongle, or, ...), or it could be a password that is used to decrypt an encrypted version of the key. Note that the latter weakens the whole encryption to the strength of the latter encryption of the key.

Note that you could link the password to the OS logon, or to the start of your software, so the user only needs to enter it once for each session.


>> The file gets sent to our remote client along with the encrypted key (that is why we need to store it somehow because the process is automated). On the remote client side the key is decrypted

Why do you need to send the key with the message ? That's effectively changing the strength of the security to the least strong of the two encryptions used.

This seems to be a perfect case for public key encryption. The software encrypts the file with the remote client's public key, and then sends the encrypted data to the remote client. The remote client can decrypt the file with his private key. No-one else can decrypt the data.


>> I am sorry but I am not at liberty to disclose everything about it

I certainly understand that. I just wanted a general overview of what's involved, and you provided just that :)
0
 
LVL 45

Expert Comment

by:aikimark
ID: 33726296
I concur with I08.  Asymmetric encryption is the best path.
0
 

Author Comment

by:xNejX
ID: 33726363
Ok Thanks guys, but isn’t Asymmetric encryption a lot slower than Symmetric? If it’s more secure than we will implement it regardless but I would just like to know if it will have a major affect on the software performance?
0
 
LVL 22

Expert Comment

by:ambience
ID: 33726444
>> This seems to be a perfect case for public key encryption.
Public key only serves to ensure the integrity of the message, it does not authenticate the sender. From what I understood, the intent here is to authorize/authenticate in addition to integrity. From an authorization perspective, I dont see much of difference between a key that is stored in registry and a public key - both are public! Both can be used to send content to the server.
>> On the remote client side the key is decrypted
This tells me that it's deducible from the public key (and therefore not private) and therefore less secure. So Infinity08's suggestion of public key is more secure, even though it only partially addresses the concerns.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33726491
>> Public key only serves to ensure the integrity of the message, it does not authenticate the sender.

That is true. I didn't get that from the requirements.

However, the communication is two-way, so if you use the public key of the sending party to request a confirmation (a randomly generated token that has to be sent back), then you can be sure that the sender is who he says he is.
0
 
LVL 22

Expert Comment

by:ambience
ID: 33726559
>>  if you use the public key of the sending party to request a confirmation
Only if the sending party can keep the private key safe!
0
 

Author Comment

by:xNejX
ID: 33726586
The only problem that i find with the asymmetric encryption is that every client then probably has the same public key encrypting the files. I was really trying to give a unique key to each installation just in case the private key that is used for decryption leaks or gets cracked. In that case they would only be able to read data excange from one installation but not all of them.

I dont think that there is a smart and secure way to exchange / generate the key pairs for each installation. Is it?  
0
 
LVL 22

Assisted Solution

by:ambience
ambience earned 100 total points
ID: 33726621
A webservice. Pass an installation id to an activation service (can be simple php page) and save the returned public key. This however only ensures a safe exchange, and nothing more!
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33726698
>> Only if the sending party can keep the private key safe!

Obviously. See my earlier post for ways to deal with a non-trusted system.


>> The only problem that i find with the asymmetric encryption is that every client then probably has the same public key encrypting the files. I was really trying to give a unique key to each installation just in case the private key that is used for decryption leaks or gets cracked. In that case they would only be able to read data excange from one installation but not all of them.

I think you have a basic misunderstanding of how public key encryption works :)

If the private key somehow is compromised, then you generate a new private/public key pair, and publish the new public key. All remote clients can then start using the new public key.

Furthermore : a public key does NOT allow you to decrypt the data. It only allows you to encrypt it.
For data sent to you, you use your own private key to decrypt the data. Each client will have their own private key. And again : if that key gets compromised, the client can generate a new public/private key pair, and publish the new public key.
0
 
LVL 45

Expert Comment

by:aikimark
ID: 33727634
You could encrypt a unique key (maybe a GUID) with the receiver's public key and prepend it to the AES-encrypted file.  That way, each uploaded file has a unique encryption key and you will only be using an asymmetric algorithm for a limited amount of data.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33727754
>> You could encrypt a unique key (maybe a GUID) with the receiver's public key and prepend it to the AES-encrypted file.  That way, each uploaded file has a unique encryption key and you will only be using an asymmetric algorithm for a limited amount of data.

Why ?
0
 
LVL 45

Expert Comment

by:aikimark
ID: 33728087
If the data files are large or you have to encrypt a lot of them, then you can use a relatively low-cost symmetric algorithm for the bulk of the data and the expensive asymmetric algorithm for the key.

The idea is to balance the strength of encryption with the need to thwart the bad guys that might be able to run software on the PC.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33728431
I just re-read the last few posts, and it does seem like xNejX has concerns re. performance :) Ignore my previous post heh.
0
 
LVL 45

Expert Comment

by:aikimark
ID: 33729012
If you can establish an SSL connection that the opposition can't hack, you could exchange encryption keys securely between your client application and your server.  This might not be so bad, since you are going to send the file to one of your servers.

If you only need to secure the file during transmission, you might consider secure FTP or file upload under an https umbrella.

You could combine strong encryption with compression and reduce the transmission time and network load.
0
 

Author Comment

by:xNejX
ID: 33760920
Hey evilrix,

I'm sorry, but i thought that i was supposed to go with the solution that worked for me. Sure, get it reopened and i will try to distribute the points, but when I did that in this thread already it wasn’t ok with some people...

All you guys helped me a lot so it will be tough do distribute them, but i will try my best.
0
 
LVL 40

Expert Comment

by:evilrix
ID: 33760954
>>  i thought that i was supposed to go with the solution that worked for me.

That is very true but look at what you selected... all is says is "Why ?".

The comment you thought you chose (I guess the one before) was reached after a lot of valuable thought and discussion was put into your situation. Do you really think only one comment actually assisted you here? In fact, do you think it actually addresses the original question, which was asking how to embed a key in an binary in a way that is secure. This answer addresses a follow up issue of performance of symmestric vs. asymmetric encryption. For sure, it is valuable and I have no issue if it was selected but it is an assist, it does not address the original question directly - does it?

To make this simple, I am not interested in getting points for experts I am interested in ensuring the answers selected meet the requires of the question and address is so that future readers will see not only the solution but how you got there (in other words, telling you something isn't a good solution is as valuable as suggesting something else is). Does that make sense?

So, I have requested this be reopened. Of course, only select those answers that assisted you but please take some time to choose carefully to ensure that your original question is covered. You can also include answers to follow up questions but the original question asked should be the primary factor when choosing.

Thank you in advance for taking time to do this.

0
 
LVL 45

Expert Comment

by:aikimark
ID: 33761651
The bulk of that comment's content was supplied by me in comment http:#33727634

The comment you had accepted was Infinity08 asking me for clarification of my recommendation.

If you used that, then please accept my comment.
0
 

Author Comment

by:xNejX
ID: 33786555
I want to distribute points to the experts that provided good answers.
0
 

Author Closing Comment

by:xNejX
ID: 33786589
The points were distributed per answer not per expert.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33786691
Since we weren't asked for recommendations, I didn't provide them (under the assumption that the author would get back to the question, and do the right thing).

Now it seems the author is not coming back, and this question has to be closed properly, I'd like to support evilrix in his original objection (and repeat it, since the current way is pretty much the same as what evilrix originally objected to) : accepting just one post about a follow-up issue is probably not the best way to close this question.

My recommendation would be to accept these posts (keeping in mind how the author clarified the circumstances in http:#33725660, and what turned out to be the best approach) :

http:#33704955 (evilrix) : catches the root of the issue
http:#33705159 (evilrix) : suggestion to use public key encryption for communication between the peers
http:#33712612 (phoffric) : hint towards exchanging encrypted keys
http:#33726151 (Infinity08) : assertion (given the new information) that public key encryption is the way to go, as well as an overview of how to attempt to secure keys locally
http:#33726491 (Infinity08) : explanation of how to authenticate peers with public key encryption
http:#33727634 (aikimark) : addresses the author's performance concerns
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 33786695
Ok, I see that I jumped the gun a bit :)

Thanks for closing the question yourself, xNejX.
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

This story has been written with permission from the scammed victim, a valued client of mine – identity protected by request.
Password hashing is better than message digests or encryption, and you should be using it instead of message digests or encryption.  Find out why and how in this article, which supplements the original article on PHP Client Registration, Login, Logo…
The viewer will learn how to pass data into a function in C++. This is one step further in using functions. Instead of only printing text onto the console, the function will be able to perform calculations with argumentents given by the user.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now