I have a WinForms application which reads data from a sensitive file and performs calculations using that data. In order to keep the sensitive information from people's PCs, we decided to move the calculations to a web service, where the file will hide in a protected folder and only is accessible by the web service program itself.
Due to some complications it looks like it may not be possible to secure the server space in the required timeframe, so what we are now looking to do is use encryption to protect the file so that it can be safely distributed to people's PCs.
My question is this. Is is possible to encrypt a file (once, so a pre-encrypted file will be attached to the project) and then decrypt the file for use by the application without revealing
The sensitive information inside the file
The Encryption key used to decrypt the file
I know it is possible to generate source code from a .exe file so I would be looking for a solution that bears this in mind. I am new to this kind of app development so please excuse me if this is a stupid question and that what I am trying to do is not actually possible.
Cheers
No, it is not possible, you can only make it hard to do those two things. You can not make it impossible. All you can do is just make it hard enough it is not worth the effort to try, and that takes money to do (via specialized obfuscation software and paying experts in the field to look at your code and make it more secure)
Related
I'm developing an application in c# which uses an .xml file to obtain information that is used inside the logic of the app. When a new version of the app is launched, a setup is created (using Inno Setup Compiler) and after successfully installing the setup, the .xml is placed inside the setup files of the app. This .xml file contains about 200 objects with 4 properties each of sensitive data.
I got asked to launch a customer version of the app, and a requirement for this version is to remove the access or manipulation of this .xml file, since it contains sensitive data that the customer should not be able to see or manipulate.
My senior engineer told me to simply implement the information inside a list in the source code, so that the use of the .xml file is removed and the customer can't manipulate this info once installed the app, as it would be hidden inside the source code, but this seems really inefficient for me and i would need to change a lot of logic about the use of the .xml file inside the app for this to work.
Is there a way to create a setup of the app and hiding this file in the setup files so it cant be manipulated by the customer?
If there isn't, what approach could you suggest me to do? Or do i have no options but to do this the hard way?
If you want to make it harder for the end user to modify the information, while still keeping a separate configuration file that won't require code change of the application itself, you can sign the file and have the application verify the signature.
A simplest way is to to calculate a hash of a file and "secret" value. Of course it is hardly tamperproof. But in the end, there's no tamperproof way to prevent a user from manipulating data on his/hers own computer. It's only about how hard you want to make it.
A better way would be to use a proper certificate for the signature. The application will know only the public key and will use it to verify a signature created with a private key, which will never leave the development team.
From a theoretical standpoint, if your program can get hold of the data, then a user with full control of the computer on which the program is running can also get hold of the data if they try hard enough. That means you can make it difficult for them, but you can't make it impossible. So if that's what you're trying to achieve, you need to be quite clear about the limitations of the approach.
How difficult should you make it? Well, if it's purely a commercial risk, you should make it hard enough that the cost of getting the data is greater than the benefit. If the risk can't be measured in that way, for example if there are legal requirements for you to protect the data, then that isn't going to be good enough.
For some situations, it's probably enough to encrypt the XML file, and bury the decryption key deep within the logic of a compiled program written in a language that doesn't allow easy decompilation. That's likely to be better than simply burying the XML data within the compiled program, which is what your senior engineer is suggesting. But her suggestion may be OK too. It really shouldn't be too difficult to change the program logic from reading an external file to reading a string constant within the program.
I am doing a larger application which at some point would serialize/deserialize XML files. The problem is, that I need to make some of those XML files encrypted.
Basically, the encrypted one would be made by my professor for his students. It would be like a black-box, so my professor prepares a class in my application, serializes it and additionally, my app would encrypt the whole XML. Then student loads the XML to the application, but they don't know what's in it. I thought about a simple encryption, AES, whatever. I would store the key to encryption/decryption as bytes in my code.
But then it came to me, that every student could go for something like dotPeek, or something like this, disassembly my executable and then get the key and be able to decrypt every encrypted XML file. Now that is not something I can allow.
I was searching through the internet for possible solutions to my problem, but I couldn't quite find an answer.
Can you guys think of any way of doing that kind of thing? The app would be written in C# and would be running on Windows 7/10 if that matters.
If it is a multi-user application, then you need to ensure the ownership of the file by individual user authentication & authorization.
Server should be able to validate client incoming request and serve the authorized file accordingly.
Maintain different encryption keys for each user; this is to decrypt the file. Note that, having global-admin-enc-key is vulnerable in attack vector.
To prevent the code from re-engineered, you can obscure the code by obfuscation. It confuses the code for human. This thread also claims to have a protector.
How to prevent decompilation of any C# application
I'm trying to release a software I wrote to multiple Computers in several different locations. The Program itself is a Windows Forms Application. To install it I added a setup project which also works perfectly fine. All files get copied to the right folders and the choices the user can make during the installation work without a flaw. But:
The only problem is that the config file, which contains sensible data like for example the SQL connection string, gets also copied / installed on the target computer.
Is there a way to store this data unreadable for the user in the application?
I thought about just writing it in a class since the application gets obfuscated but I'm not sure if this is secure enough and if this really is a way to go...
Any help appreciated!
You might cryptographically secure the sensitive file with a private key embedded in code itself with an obfuscation scheme. This is better then embedding all sensitive config data in code since you would not need rebuild-test-release your application when only your config changes.
Theoretically, If an application running in user mode can -anyhow- access the plain sensitive data, so can the user(de-obfuscation, memory dump etc). Since all information needed to generate or decipher the sensitive data is present offline (code, disk, memory), one -with enough skills- can determine the decryption scheme by examining the code (even the machine code)
Think of an application as a user with rapid calculation and massive memory skills so it can de-obfuscate your code on the fly and do the needed calculations to decrypt the "safe" data
It's impossible that the config file/data is only readable for the program but not for the user, because you can decompile the program and search for the conection String, but you can make it to the user as hard as possible.
You can also write a php script or something else that checks the request and can block requests from specific ips if the script notice that the user spam requests or send rubbish data.
Perhaps it is enough to you also, that you create a new database user which limited write and read permissions has, so that the user didn't have the opportunity to do bad things with the Connection String.
My situation is as follows:
I have to deploy a series of .NET desktop applications consisting of a file with encrypted data and an executable that will access that data and decrypt some parts of it in runtime.
What I need to achieve is that each data container should only be decryptable by that specific .exe it is provided with.
The first idea was to encrypt the data using, say, the hash value of the .exe file as a symmetric key and during decryption calculate the hash value of the .exe file in runtime and decrypt the parts of the data container with it.
However, the problem with that approach is that the user can easily look into the .NET assembly with ILSpy or any other decompiler and discover the whole encryption algorithm which will enable the user to decrypt all the data containers in my series of applications.
Another solution that comes to my mind is to make a small C native library (that is less easy to decomplile) that will perform some manipulations with the .exe assembly information and generate a key for decryption based on it (let's consider the user lazy enough so that he will not try to intercept the key from the memory).
But ideally I wouldn't like to resort to any languages other than C# because porting the application to other platforms with Mono will require additional effort (P/Invokes and so).
So my question is: is there a way I can encrypt the data so that only a certain application would be able to decrypt it?
Of course I understand that in case of a local application it is impossible to keep the data absolutely secure but I need to make the 'hacking' at least not worth the effort. Are there any reasonable solutions or I will have to stick to one of my ideas I described above?
Thank you in advance!
The simple answer is no.
To encrypt and decrypt data, you need an algorithm and, optionally, a secret or key. If a computer can execute the algorithm, someone else can learn what it is. Ignoring decompilation and disassembly, a user could just look at the instructions executed by the CPU and piece together the algorithm.
This leaves the secret. Unfortunately, if the computer or program can access or derive a secret, so can someone with root or administrator rights on that computer for the same reasons above.
However, maybe you are just thinking about the problem the wrong way. If you want the program to access data that no one else can, consider making that data available from a server that users must authenticate to access. Use SSL so data is protected in transit and encrypt the data locally using a key that only the local user and local administrators can access. It is not perfect but it is about the best you are going to get in the general case.
If you need more protection than that, you may want to consider hardware dongles but this gets expensive and complex quite quickly.
The question about storing connection string in safest way.
My current approach (Don't laugh)
1. Wrote RSAEncryption program and passed connection string to generate cypher.
2. Stored Cypher and private key in Resource file
3. Runtime retrieved encryption file again.
My concern of using config file
- I am creating library so projects who will use my dll will need to copy my config file which I dont want
Please tell me best practice to store connection string inside the dll.
Regards,
Omkar
There is a built in mechanism in .NET to encrypt sections of config. The beauty is you can use DPAPI and have the machine itself create the key, so nobody knows what it is except Windows. The best thing is you get this pretty much for free (small learning curve) and the learning curve is easily handled with a quick Google search on encrypting configuration files. May not fit all scenarios, but it is more likely to be secure than a quickly envisioned alternative.
The only issue here is if this is shrinkwrap ware (ie, you are selling software), but there are ways to handle that by having the install require network and adding the bits they can't know while you encrypt only go into memory during install. :-)