Easiest way to sign/certify text file in C++?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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!

1. 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.

2. 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.

3. 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.

4. 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.

Answer 5

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.