I have a proprietary application which uses an xml config. Currently I use boost::property_tree to read the xml file.
I would like to deploy both executable and xml file on a more public system and want to avoid anyone, including that system's administrator, from reading the xml.
Ideally, I would like to maintain the clear text xml on my system so I can easily manually modify it. Then I would call some encrypt command on the file, deploy it on the more public machine and have the executable decrypt it on the fly. I'd use the same key and just hardcode it into the source of the executable.
Is this a reasonable approach? What is the easiest way to implement this? Is there a better way?
Since you're already using boost, you could always serialize it. If you use binary archives, the file will be essentially unreadable. I guess my follow-up question would be: do you also want it to be secure? Or just unreadable?
If the code runs on the client's machine, then in principle you can never prevent the data from becoming known, because it has to be on the client's machine. You can try to obfuscate, but ultimately the client will have to be able to read the data, so it has to know it.
If you were to simply embed an encryption key in your program, the client could just scan through the file and extract the key. If you work a bit harder you can make Skype, but even that has been deconstructed.
It all depends on the seriousness of your need to protect the data. If it's absolute, then you cannot do it, but if you just want to keep the casual visitor out, you could try and make it a bit harder... tell us some details if you're serious about this.
If your goal is to prevent someone from casual inspection, then that is a reasonable approach.
If you must ensure (for some weird reason) that the configuration cannot be read, it is a foolish errand, because the program can read it, so a user who is determined to do so can do it as well. Either by disassembling the program, or simply by doing a memory dump from the debugger. Having that said, a simple, lightweight encryption will be good enough, because even the toughest encryption will be broken in the same way.
You might also consider whether using an explicitly human-readable format such as xml is well-suited if you don't want people to read it.
I had a very similar case. I used a compression algorithm to store the file 'encrypted'. zlib can be used for C++. You can easily encrypt and decrypt your file, both from command-line and from code. To add some more 'security' you can xor the compressed file with a password.
This a both simple to implement and easy to use. Of course I won't use such method if my clients are hackers, or have a financial incentive to read the XML.
Related
I'm creating a program uysing c++ that relies off sensitive information contained within a folder located on my Ubuntu 14.04 desktop. I need some way to protect this information.
Essentially I have two buttons setup on my application. One to encrypt the folder and one to decrypt the folder. However, I have no experience with encryption and don't even know if you can encrypt a folder itself. Most tutorials I have found only talk about encrypting text. A friend recommended using AES encrytpion, but again, I can only find tutorials that show how to encrypt text.
Does anyone know of any way to protect these folders? They contain a large amount of images (.bmp and .png file types) concerning patient information along with a few text files. Obviously the quickest method would be best, as long as they aren't easily accessible without pressing the buttons.
Encryption is not some magic wand one can waive over some data, and encrypt it. If your application has a button that automatically "decrypts" the data, it means that anyone else can do it as well. For this button to work as you described, your application must logically know everything that's needed to decrypt the data. If so, a determined attacker can simply obtain a copy of your application, debug it, figure out how it decrypts the data, and game over.
At the very minimum, a passphrase will be required in order to decrypt the data; so that the application alone is not sufficient to effect encryption and decryption.
As far as the actual technology goes, the two primary software libraries on Linux that provide generic encryption facilities are OpenSSL and GnuTLS. Both provide comparable implementations of all standard symmetric and asymetric cipher-suites.
I believe that GnuTLS is a better API, and that's what I recommend. The design of GnuTLS's C API naturally lends itself to a light C++ OO wrapper facade. The GnuTLS library provides extensive documentation, so your first step is to read through the documentation; at which point you should have all sufficient information to implement encryption in your application.
Just a simple point.
You are going to have to make a blob, which you someway mount as a filesystem. You are also going to have to decide how to control access to that filesystem while people are using it. Also how people are going to synchronize access. Do it wrong and two people will write to the same area at the same time and create something that no one will ever decrypt!
Look at the source code for dm-crypt and TrueCrypt, but if you want to limit access beyond the permission system that your OS supports you may find yourself way in over your head.
you need build private filesystem,so every file operator must pass you application. you can encrypt the file contain to user.
I'm working on a text based adventure game in C++ and I would like to store quests in a text file,but I don't want the player to read it.
Is there an easy way to encrypt it?
Another way to "hide" content of your file to player is to encrypt the file.
You can use openssl for instance.
In this thread you can have an idea on the usage.
Velthune's OpenSSL suggestion is fine but it is arguably overkill. I would try something simple like XOR encryption instead.
Of course XOR encryption is not secure, but neither is the OpenSSL approach, since your program must store the encryption key somewhere in the executable file in order to be able to do the decryption.
There is no way to truly secure the file's contents against a determined user and still have it be accessible to a program that runs on the user's machine.
So, I'd suggest XOR encryption as a simple form of obfuscation that will deter someone from changing the file casually, yet won't make your program dependent on an external library.
I'm writing a game that will have a lot of information (configuration, some content, etc) inside of some xml documents, as well as resource files. This will make it easier for myself and others to edit the program without having to edit the actual C++ files, and without having to recompile.
However, as the program is starting to grow there is an increase of files in the same directory as the program. So I thought of putting them inside a file archive (since they are mostly text, it goes great with compression).
My question is this: Will it be easier to compress all the files and:
Set a password to it (like a password-protected ZIP), then provide the password when the program needs it
Encrypt the archive with Crypto++ or similar
Modify the file header slightly as a "makeshift" encryption, and fix the file's headers while the file is loaded
I think numbers 1 and 2 are similar, but I couldn't find any information on whether zlib could handle password-protected archives.
Also note that I don't want the files inside the archive to be "extracted" into the folder while the program is using it. It should only be in the system's memory.
I think you misunderstands the possibilities brought up by encryption.
As long as the program is executed on an untrusted host, it's impossible to guarantee anything.
At most, you can make it difficult (encryption, code obfuscation), or extremely difficult (self-modifying code, debug/hooks detection), for someone to reverse engineer the code, but you cannot prevent cracking. And with Internet, it'll be available for all as soon as it's cracked by a single individual.
The same goes, truly, for preventing an individual to tamper with the configuration. Whatever the method (CRC, Hash --> by the way encryption is not meant to prevent tampering) it is still possible to reverse engineer it given sufficient time and means (and motivation).
The only way to guarantee an untampered with configuration would be to store it somewhere YOU control (a server), sign it (Asymmetric) and have the program checks the signature. But it would not, even then, prevent someone from coming with a patch that let's your program run with a user-supplied (unsigned) configuration file...
And you know the worst of it ? People will probably prefer the cracked version because freed from the burden of all those "security" measures it'll run faster...
Note: yes it is illegal, but let's be pragmatic...
Note: regarding motivation, the more clever you are with protecting the program, the more attractive it is to hackers --> it's like a brain teaser to them!
So how do you provide a secured service ?
You need to trust the person who executes the program
You need to trust the person who stores the configuration
It can only be done if you offer a thin client and executes everything on a server you trust... and even then you'll have trouble making sure that no-one finds doors in your server that you didn't thought about.
In your shoes, I'd simply make sure to detect light tampering with the configuration (treat it as hostile and make sure to validate the data before running anything). After all file corruption is equally likely, and if a corrupted configuration file meant a ruined client's machine, there would be hell to pay :)
If I had to choose among your three options, I'd go for Crypto++, as it fits in nicely with C++ iostreams.
But: you are
serializing your data to XML
compressing it
encrypting it
all in memory, and back again. I'd really reconsider this choice. Why not use eg. SQLite to store all your data in a file-based database (SQLite doesn't require any external database process)?
Encryption can be added through various extensions (SEE or SQLCipher). It's safe, quick, and completely transparent.
You don't get compression, but then again, by using SQLite instead of XML, this won't be an issue anyway (or so I think).
Set a password to it (like a password-protected ZIP), then provide the password when the program needs it
Firstly, you can't do this unless you are going to ask a user for the password. If that encryption key is stored in the code, don't bet on a determined reverse engineer from finding it and decrypting the archive.
The one big rule is: you cannot store encryption keys in your software, because if you do, what is the point of using encryption? I can find your key.
Now, onto other points. zlib does not support encryption and as they point out, PKZip is rather broken anyway. I suspect if you were so inclined to find one, you'd probably find a zip/compression library capable of handling encryption. (ZipArchive I believe handles Zip+AES but you need to pay for that).
But I second Daniel's answer that's just displayed on my screen. Why? Encryption/compression isn't going to give you any benefit unless the user presents some form of token (password, smartcard etc) not present in your compiled binary or related files. Similarly, if you're not using up masses of disk space, why compress?
I'm looking to implement a shared configuration file that will be written (output) in python, but be read (input) in C.
The only prerequisite of this configuration file is that it can't be human readable.
Anyone have any suggestions on what file format I should use for this project?
Edit: The file can't be human readable because we don't want the user to be able to modify the configuration, also, in some cases, we don't want the user to know about certain configurations.
How secure do you need this config file to be?
There is no absolute security, you'll quickly run into DRM like issues (allow users to open a file but not allow them to open it ... I know it's insane).
Often simple obfuscation is quite effective. Dump the config to a JSON file (please don't use xml). XOR the contents and change the extension. That will stop all casual inspection of the file. Obviously don't document that this is your obfuscation procedure.
If you're worried about user modification of config files (you don't care if the configs are readable you just want prevent loading custom configs) use a cryptographic signature. Store the private key at your company and use it and the python app to generate a signed configuration. Store the public key in the c++ application and use it to verify the config is properly signed before applying the settings.
try this one http://www.picklingtools.com/
Probably easiest to use XML, then obfuscate it with a simple cypher or encryption with a fixed key.
Use a plain human readable format such as XML, and then obfuscate that to make it uneditable (i.e. encrypt the whole thing and store a hash somewhere and fail to load if its' been messed with).
Otherwise you just have to bite the bullet and write a spec for the binary format that'll be exchanged between the two programs.
I want to verify if the text log files created by my program being run at my customer's site have been tampered with. How do you suggest I go about doing this? I searched a bunch here and google but couldn't find my answer. Thanks!
Edit: After reading all the suggestions so far here are my thoughts. I want to keep it simple, and since the customer isn't that computer savy, I think it is safe to embed the salt in the binary. I'll continue to search for a simple solution using the keywords "salt checksum hash" etc and post back here once I find one.
Obligatory preamble: How much is at stake here? You must assume that tampering will be possible, but that you can make it very difficult if you spend enough time and money. So: how much is it worth to you?
That said:
Since it's your code writing the file, you can write it out encrypted. If you need it to be human readable, you can keep a second encrypted copy, or a second file containing only a hash, or write a hash value for every entry. (The hash must contain a "secret" key, of course.) If this is too risky, consider transmitting hashes or checksums or the log itself to other servers. And so forth.
This is a quite difficult thing to do, unless you can somehow protect the keypair used to sign the data. Signing the data requires a private key, and if that key is on a machine, a person can simply alter the data or create new data, and use that private key to sign the data. You can keep the private key on a "secure" machine, but then how do you guarantee that the data hadn't been tampered with before it left the original machine?
Of course, if you are protecting only data in motion, things get a lot easier.
Signing data is easy, if you can protect the private key.
Once you've worked out the higher-level theory that ensures security, take a look at GPGME to do the signing.
You may put a checksum as a prefix to each of your file lines, using an algorithm like adler-32 or something.
If you do not want to put binary code in your log files, use an encode64 method to convert the checksum to non binary data. So, you may discard only the lines that have been tampered.
It really depends on what you are trying to achieve, what is at stakes and what are the constraints.
Fundamentally: what you are asking for is just plain impossible (in isolation).
Now, it's a matter of complicating the life of the persons trying to modify the file so that it'll cost them more to modify it than what they could earn by doing the modification. Of course it means that hackers motivated by the sole goal of cracking in your measures of protection will not be deterred that much...
Assuming it should work on a standalone computer (no network), it is, as I said, impossible. Whatever the process you use, whatever the key / algorithm, this is ultimately embedded in the binary, which is exposed to the scrutiny of the would-be hacker. It's possible to deassemble it, it's possible to examine it with hex-readers, it's possible to probe it with different inputs, plug in a debugger etc... Your only option is thus to make debugging / examination a pain by breaking down the logic, using debug detection to change the paths, and if you are very good using self-modifying code. It does not mean it'll become impossible to tamper with the process, it barely means it should become difficult enough that any attacker will abandon.
If you have a network at your disposal, you can store a hash on a distant (under your control) drive, and then compare the hash. 2 difficulties here:
Storing (how to ensure it is your binary ?)
Retrieving (how to ensure you are talking to the right server ?)
And of course, in both cases, beware of the man in the middle syndroms...
One last bit of advice: if you need security, you'll need to consult a real expert, don't rely on some strange guys (like myself) talking on a forum. We're amateurs.
It's your file and your program which is allowed to modify it. When this being the case, there is one simple solution. (If you can afford to put your log file into a seperate folder)
Note:
You can have all your log files placed into a seperate folder. For eg, in my appplication, we have lot of DLLs, each having it's own log files and ofcourse application has its own.
So have a seperate process running in the background and monitors the folder for any changes notifications like
change in file size
attempt to rename the file or folder
delete the file
etc...
Based on this notification, you can certify whether the file is changed or not!
(As you and others may be guessing, even your process & dlls will change these files that can also lead to a notification. You need to synchronize this action smartly. That's it)
Window API to monitor folder in given below:
HANDLE FindFirstChangeNotification(
LPCTSTR lpPathName,
BOOL bWatchSubtree,
DWORD dwNotifyFilter
);
lpPathName:
Path to the log directory.
bWatchSubtree:
Watch subfolder or not (0 or 1)
dwNotifyFilter:
Filter conditions that satisfy a change notification wait. This parameter can be one or more of the following values.
FILE_NOTIFY_CHANGE_FILE_NAME
FILE_NOTIFY_CHANGE_DIR_NAME
FILE_NOTIFY_CHANGE_SIZE
FILE_NOTIFY_CHANGE_SECURITY
etc...
(Check MSDN)
How to make it work?
Suspect A: Our process
Suspect X: Other process or user
Inspector: The process that we created to monitor the folder.
Inpector sees a change in the folder. Queries with Suspect A whether he did any change to it.
if so,
change is taken as VALID.
if not
clear indication that change is done by *Suspect X*. So NOT VALID!
File is certified to be TAMPERED.
Other than that, below are some of the techniques that may (or may not :)) help you!
Store the time stamp whenever an application close the file along with file-size.
The next time you open the file, check for the last modified time of the time and its size. If both are same, then it means file remains not tampered.
Change the file privilege to read-only after you write logs into it. In some program or someone want to tamper it, they attempt to change the read-only property. This action changes the date/time modified for a file.
Write to your log file only encrypted data. If someone tampers it, when we decrypt the data, we may find some text not decrypted properly.
Using compress and un-compress mechanism (compress may help you to protect the file using a password)
Each way may have its own pros and cons. Strength the logic based on your need. You can even try the combination of the techniques proposed.