How can I make sure someone is not sending fake data?

Question

I've been reading Stack Overflow for quite some time, but this is my first posted question.

I have this tracking program written in C# which collects information about local computer usage and sends them to a server. The data is XML-formatted, sent once per ~10 minutes.

My problem: no matter how I encrypt the XML data (be it symmetric or asymmetric), someone could always decompile my C# tracking program, figure out the key/certificate/encryption conventions I use and write another program that sends fake reports to the server.

The tracking program works under the assumption that the user running it may be interested in sending fake reports.

Questions: 1) how can I make sure (as sure as possible) that the data is send from the real tracker instead of a clone/faker ? 2) how can I obfuscate the code badly enough that recovering keys/certificates/encryption conventions becomes hell/next to impossible ?

I want to spend little or preferably no money on the solution (so 500$ obfuscators are out of the question. I'm a university student and I'm cheap :)

Thanks in advance.

Answer 1

In theory, an application simply cannot secure itself when running in an untrusted environment. So, the answer to the first question is, "You can never be sure that data are sent by the real tracker."

In practice, obfuscation will thwart attackers up to a point. The point is determined by the quality of the obfuscation and the motivation of the attacker. So, the answer to the second question depends on who the attacker is, how capable they are, and what resources they might apply to this problem. Obfuscation that is "hell/next-to-impossible" for an unmotivated layman to to unravel might be trivial for an expert, or someone who can hire an expert.

Here is a list of some C# obfuscators.

Answer 2

As Raph Koster once put it, writing about the battle against hackers in client-server online games,

Never trust the client. Never put anything on the client. The client is in the hands of the enemy. Never ever ever forget this.

Unfortunately, for pretty much any real-world application that requires that the processing power of the client is used, something has to be put on the client, and therefore because available to a malicious attacker. The question that has to be asked - as with any security measure - is how much time and money are you prepared to spend mitigating this risk?

Some people like to point out to people asking about obfuscation or client-side licensing mechanisms, "oh there's no point, it will be broken eventually". But this is to miss the point: that the purpose of such measures is to push that 'eventually' further into the future, to the point that for an insufficiently-determined attacker, it will be 'never'.

For example: if your app sent its data by plaintext email, that would defeat approximately zero attackers. Sending it in rot13 email would defeat maybe 5% of attackers. Sending it encrypted using the username as a key would defeat more. Obfuscating the sending code with a free obfuscator would defeat more. Obfuscating with a commercial-grade obfuscator would defeat more. Requiring each client to have a hardware dongle would defeat 'all but the most determined' attackers, as people like to say - but this would probably be an intolerable cost.

From "I'm a university student" I'm guessing this isn't the most sensitive project ever. Use a free obfuscator and cnrypt the sent data using some user-specific information as the key. That'll probably do.

Answer 3

Will the client user have administrator rights over the machine? It sounds like the kind of app that would be installed by an admin, but used by non-admin users. If so, maybe you could store your key or hash protected from normal users, and run the app in the context of the administrator user. I'm not really familiar with the key store, but I'd expect all versions of Windows (at least XP+) would have this functionality available. If not the key store, then maybe a file located in an encrypted directory belonging to the admin user.

If your target user has local admin rights, then I really don't see how you can stop them.