I was considering the various options that i have when i want to protect a generic chunk of data to apply this principles to the distribution of a generic application.
Encryption doesn't make sense, it's like giving something unusable for the user or i have to give both the encrypted file and the key do decrypt it which make even less sense.
Generating entropy does not make sense because this process will only re-arrange the data in other way without breaking the business logic of the application.
Wrapping my application in an executable that requires a password to the user, my real application and my wrapper are double-linked and if my wrapper does not gives a green light my application will not run.
Web based distribution like the popular "Steam" service with a customized compilation for every user based on some login/ID verification.
What are the other options? I know that this will not end up with a definitive solution but at least i want to avoid the user to just redistribute my application with a simple copy and paste and i want to have at least a small edge over the software distribution system.
The usual way of doing this is to encrypt the data using some piece of information that is already on the user's system as the key; the data is then keyed to that system. For instance, on Mac OS X you can get the system serial serial number with a library call. Sun systems have a gethostid() library call that makes this trivial. An alternative that works on dumb systems cough Winders cough is to use the MAC address of an ethernet interface, or something like that.
It can be tricky, you typically have to write a little program that will grovel around in the system and generate a key, and then have the customer email this key to you, or at least OK the program to email the key to you. You can then encrypt the protected data using the key information you got back, and have the customer download it. It is possible to add this entire transaction to your application installer, if the size of the data blob is reasonable.
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 want to create portable c++ application for myself [CLI] which will store my secret project information.
But i am not sure, how can i store information in my program, as whatever i will update in program when i am using it will be stored in buffer and when i will close it, it will get deleted and same informations will not be available at any place.
I want to store information persistently, what is the best way to do it. [Considering my application will be portable, i.e, i can carry it in my pen drive in any place and i can fetch my information from program].
Option i found was Datbase , but i have certain problem with database :-
1). sqlite => If any one gets my sqlite.db file, he will know all my secret project.
2). mysql/sql or any other database => They are not portable, it needs to be installed in system too and i need to import , export everytime in system wherever i will have to use it.
How such application stores information in crypted format, so that no one can read it easily.
Any help will be great.
Thanks
If you want your data to remain secret then you must encrypt it.
How you persist the data (sqlite, text file, etc.) makes no difference whatsoever.
See also:
encrypt- decrypt with AES using C/C++
This is not REALLY an answer, but it's far too long "discussion about your subject" to fit as a comment, and I'd rather break the rules by writing one "non-answer answer" (especially now that you have already accepted another answer) than write 6 comments.
First of all, if it's written in C++, it won't be truly portable in the sense that you can carry it around and plug it in anywhere you like and just access the ifnormation, because different systems will have different OS and processor architecture. Fine if you restrict being able to "plug in" on Windows and Linux with x86 - you only need to build two copies of your code. But covering more architectures - e.g. being able to plug into a iPad or a MacBook will require two more builds of the software. Soon you'll be looking at quite a lot of code to carry around (never mind that you need the relevant C++ compiler and development environment to built the original copy). Yes, C++ is a portable language, but it doesn't mean that the executable file will "work on anything" directly - it will need to be compiled for that architecture.
One solution here may of course be to use something other than C++ - for example Java, that only needs a Java VM on the target system - it's often available on a customer system already, so less of an issue. But that won't work on for example an ipad.
Another solution is to have your own webserver at home, and just connect to your server from your customer's site. That way, none of the information (except the parts you actually show the customer) ever leaves your house. Make it secure by studying internet/web-site security, and using good passwords [and of course, you could even set it up so that it's only available at certain times when you need it, and not available 24/7]. Of course, if the information is really top-secret (nuclear weapons, criminal activities, etc), you may not want to do that for fear of someone accessing it when you don't want it to be accessed. But it's also less likely to "drop out of your pocket" if it's well protected with logins and passwords.
Encrypting data is not very hard - just download the relevant library, and go from there - crypt++ is one of those libraries.
If you store it in a database, you will need either a database that encrypts on itself, or a very good way to avoid "leaking" the clear-text information (e.g. storing files on /tmp on a linux machine), or worse, you need to decrypt the whole database before you can access it - which means that something could, at least in theory, "slurp" your entire database.
Depending on how secret your projects are, you may also need to consider that entering for example a password will be readable by the computer you are using - unless you bring your own computer as well [and in that case, there are some really good "encrypt my entire disk" software out there that is pretty much ready to use].
Also, if someone says "Can I plug in my memory stick on your computer and run some of my from it", I'm not sure I'd let that person do that.
In other words, your TECHNICAL challenges to write the code itself may not be the hardest nut to crack in your project - although interesting and challenging.
I'm working on a wxWidgets GUI application that allows the user to upload files to an FTP server and a pair of username/password is required to access the FTP server.
As far as I know, STL strings or even char* strings are visible to end user even the program is compiled already, using hex editors or maybe string extractors like Sysinternals String Utility.
So, is there a safe/secure way to store sensitive informations inside a C++ application?
PS. I cannot use .NET for this application.
This is actually independent of the programming language used.
FTP is a protocol that transfers its password in plain text. No amount of obfuscation will change that, and an attacker can easily intercept the password as it is transmitted.
And no amount of obfuscation, no matter the protocol used, will change the fact that your application has to be able to decode that password. Any attacker with access to the application binary can reverse-engineer that decoding, yielding the password.
Once you start looking at secure protocols (like SFTP), you also get the infrastructure for secure authentication (e.g. public/private key) when looking at automated access.
Even then you are placing the responsibility of not making that key file accessable to anyone else on the file system, which - depending on the operating system and overall setup - might not be enough.
But since we're talking about an interactive application, the simplest way is to not make the authentication automatic at all, but to query the user for username and password. After all, he should know, shouldn't he?
Edit: Extending on the excellent comment by Kate Gregory, in case that users share a common "technical" (or anonymous) account accessing your server, files uploaded by your app should not be visible on the server before some kind of filtering was done by you. The common way to do this is having an "upload" directory where files can be uploaded to, but not be downloaded from. If you do not take these precautions, people will use your FTP server as turntable for all kind of illegal file sharing, and you will be the one held legally responsible for that.
I'm not sure if that is possible at all, and if, than not easy. If the password is embedded and your program can read it, everybody with enough knowledge should be able to do.
You can improve security against lowlevel attempts (like hexeditor etc.) by encrypting or obfuscating (eg two passwords which generate the real password by XOR at runtime and only at the moment you need it).
But this is no protection against serious attacks by experienced people, which might decompile you program or debug it (well, there are ways to detect that, but it's like cold-war - mutual arms race of debugging-techniques against runtime-detection of these).
edit: If one knows an good way with an acceptable amount of work to protect the data (in c++ and without gigantic and/or expensive frameworks), please correct me. I would be interested in that information.
While it's true that you cannot defend against someone who decompiles your code and figures out what you're doing, you can obscure the password a little bit so that it isn't in plain text inside the code. You don't need to do a true encryption, just anything where you know the secret. For example, reverse it, rot13 it, or interleave two literal strings such as "pswr" and "asod". Or use individual character variables (that are not initialized all together in the same place) and use numbers to set them (ascii) rather than having 'a' in your code.
In your place, I would feel that snooping the traffic to the FTP server is less work than decompiling your app and reading what the code does with the literal strings. You only need to defeat the person who opens the hex and sees the strings that are easily recognized as an ID and password. A littel obscuring will go a long way in that case.
As the others said, storing a password is never really save but if you insist you can use cryptlib for encryption and decryption.
Just a raw idea for you to consider.
Calculate the md5 or SHA-2 of your password and store it in the executable.
Then do the same for input username/password and compare with stored value.
Simple and straightforward.
http://en.wikipedia.org/wiki/MD5
http://en.wikipedia.org/wiki/SHA-2
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 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.