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.
Related
I'm developing an engine for a 2D game in C ++ and for some days I've been looking for a way to protect the images and audio of my future game. I know there is no 100% protection and that someone would be able to open these files, but I mean the regular user who just installed the game, prevent it from modifying the sprites, change the sound, overwrite the xml files with game map data.
I downloaded some games made in Unity and noticed that a .assets extension is used, in Diablo 2 it is used .ma0, .mpq, .data, in FEZ .pak, in Super Meat Boy only a .tp file. In other words, you can not open and edit any of these files in a text editor or unzip with winrar, they offer a minimum level of protection. How is this done? Do I have to create my own binary file format or is there any program that makes it easier to work?
You can't.
That "minimum level of protection" is even more minimal than you think. You can open those files in a hex editor and hack away at them. This activity is something that has been commonplace for many decades.
You can encrypt the data, but since the key must be stored in your application and the user has a copy of your application, that can be extracted and/or changed too.
You can add a digital signature to prevent people from modifying the assets then using them ("modding") but, again, this can be altered in your application.
You can obfuscate the assets by shipping them in a proprietary format, but this is usually done purely for functional reasons because, again, someone will reverse engineer them.
Once a thing is on someone else's computer, you have lost control of that thing.
There are actually multiple questions here, iirc:
How can users be prevented from reading game assets?
How can users be prevented from manipulating game assets?
What file format can be used to store game assets?
If you're using an existing engine, it probably has some support for this, and if it is sufficient for your purposes you only need to learn how to use it.
If you need to roll your own, you need to define your requirements clearly and pick a solution which fulfills them. For asset storage, a ZIP based format is probably easiest to handle, all languages have some form of support for that. To protect integrity, you should use cryptographic algorithms: digital signatures to detect tampering, and encryption to prevent reading. These will probably slow down the opening of assets a little bit, but in most cases this should be acceptable.
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.
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?
Here's the thing:
In my Qt4.6-Project, I use a SQLite-Database. This database shouldn't be unencrypted on my harddrive. So I want, that on every start of my program, the user gets asked to enter a password to decrypt the database. Of course the database never should appear "in clear" (not encrypted) on my harddrive.
So is there any possibility to decrypt a SQLite-database "on the fly" and read and write data? What algorithm is here the best (maybe AES)?
When it's not possible (or very slow), maybe it's better to encrypt every string in the database and decrypt the string when the password was right (so that a user could open the database, but has no clue what all the entrys could mean)?
There is no built in support, that being said you do have options.
1) You can encrypt/decrypt all of your strings yourselves, but this is a lot of work, is not transparent, and won't allow you to do things like searching in the database.
2) SQLiteCrypt and SQLCipher do what you're looking for.
You can use them almost entirely transparent and typically they are said to have only about 5% overhead compared without encryption.
I would suggest using a library that does this for you, rather than building in your own encryption.
http://www.hwaci.com/sw/sqlite/see.html
or
http://sqlite-crypt.com/documentation.htm
Use your favorite search engine for some alternatives.
The best way I can think about is to use FUSE - "filesystems in user-land" - available for Linux , Mac OS X and other systems, or a different encrypted file-system. This will make SQLite see it as unencrypted while being physically encrypted on the disk. By playing with the permissions you can make sure people cannot access the unecrypted file system.
I'm not sure if SQLite has a way to over-ride the low-level read/write routines which will allow you to implement the encryption on the fly without filesystem games. At least I never needed to do that. You may wish to search for such a feature request and file one it if it's not in the SQLite issue tracker.
An additional option would be the SQLite encryption codec that comes with Botan 1.9.x (src/wrap/sqlite).
That option gives you the ability to customize the encryption type at compile time, including the cipher and mode.
Disclosure: I contributed the codec to Botan.
I have a Qt application written in C++ that uses a SSL-connection (QSslSocket) with another application for extra security. However, the application has a private key embedded in it.
With applications like Process Explorer it's really easy to fish out the private key. (Properties of file -> Strings)
Security is not very important for my application but it would be nice to make a little bit more difficult getting the private key from my application. Is there any way?
"strings" only finds blocks that are actual Ascii/UTF8/Unicode strings. If you keep your key around as a binary buffer then there is nothing that discriminates it from random binary data which strings usually ignores.
Other than that, There are much more clever programs out there such as IDA and OllyDebug which enable the user to fully disassemble or even decompile your program and get a hold of the key no matter what you try.
You may need of solutions to your problem from a different angle.
I agree with Shoosh's answer in that no matter what you do a person with the right tools and knowledge will be able to break your code and figure out your private key.
What you need to do is either externalize the data or mitigate the risks if your private keys are found.
The best way to externalize any private data is to encrypt it with a user supplied password that must be entered by the user to be used. Unfortunately this is not really reasonable for most applications.
To mitigate the risks I normally try to ensure that only the one 'install' is compromised if the security is broken.
For example, randomly generate the private key data on install.
For client/server applications you could follow the https model and use public/private key communication to exchange a randomly generated encryption key.
If each client install has there own public/private key set, then the server can tell what clients are connecting and also if there is a problem they can outlaw clients.
Hope that helps.
Crypt it with some simple symmetric algorithm. For example define arrays cryptedData and cryptedDataKey so that n-th byte of your private key can be get by cryptedData[cryptedDataKey[n]]. It will save you from someone who looks to your binary executable with text editor but won't help against more or less experienced person.
Also if you have persistent connections with QSslSocket a runtime it's most likely that private key is stored in memory as is. So only modifying QT library is a way to mangle key presentation in memory.
Another common technique is to put the secret data into a binary resource such as an icon image.