Secure Software License Usage Audit Log

views:

223

answers:

+3 Q:

Secure Software License Usage Audit Log

Folks,

We have an intriguing technical challenge. How to write a secure audit file that tracks usage of a software so license fees can be based on usage thereby making it more affordable to those who use it less.

Specifically, TickZoom sells a alpha generation trading platform for hedge funds which presently costs $2,000/month to license including support (will increase soon to more than double). That's fine for institutions but too expensive for individuals. Individuals often ask for a lower price in exchange for a % of the profits made using the software until they can afford to pay the fixed fees.

We like that proposal. But we need a reliable way to audit the profit actually generated on the platform and a way to prevent users from "gaming" it by deleting or overwriting the audit file thereby reporting lower earnings than actual.

This application is written in C# and this portion of the system is obfuscated at least making it difficult to decipher the code.

The other requirement is write to the file for every trade that occurs so as to allow for more in depth auditing in the event that the user feels there is some discrepancy in the total fee. That way, individual trade profits can be compared with broker statements.

It is, of course, assumed that the file will be encrypted.

But any ideas on how to make it "tamper proof"? Especially against a simple delete attempt?

My first guess is to make the software always require a preexisting audit file or it will refuse to run.

Then when we deliver the software it gets packaged with an "empty" audit file but which, in fact, has some kind of tamper-proof verification.

The next obvious technique users might try to "tamper" with the file would be for someone to simply backup that original "empty" file and later use it to overwrite the audit file later thereby fooling the system into thinking that it was a fresh start.

Perhaps that can be resolved by included some kind of "last update timestamp" and an expiration time.

Also, totally different solution ideas are welcome. We might be forced in this case to add a "phone home" ability so that trades get logged to our central server. But that seems disadvantageous and potentially adds another failure point in a mission critical application. Generally they greatly dislike "phone home" features with obvious good reasons.

Sincerely, Waynek

+1 A:

No, I don't believe there is anything you can do other than report all earnings in real-time back to your servers, but even that has issues.

-- Edit:

You're only options, as I see it, are:

Convert the system to web-based (or at least thin-client), thereby making all the transactions on the server

Clearly, this is probably pretty impractical, if you're already developed an entire locally-based system

Think up some elaborate scheme that is "hard" to break and hope people don't break it

And combine within this method, some sort of profiling that shows if the shops are earning X, and suddenly X-sigificantAmount, you can determine that they aren't even profitable any longer, thus probably cheating the system (or going out of business :) But this verges on quite an invasion of privacy, and may not be at all appropriate.

Practically, I think you'll need to weigh the risks against the possible profit, or find another angle on how to sell to these people (i.e. only let the interface/app itself manage X in total funds, if it goes over, prompt for pro version, or whatever).

Noon Silk 2010-01-25 03:33:17

That is my instinct too, of course.Reporting to servers in real time can be made to happen in a separate thread, queue in the event of temporary connection problems, but after too many trades fail to log, it will eventually have to block the software from running until the connection gets corrected.Users will begrudgingly agree to get the more affordable pricing but it will be extremely embarrassing if the "servers" failed thereby causing user apps to die and perhaps cause them financial losses.

Wayne 2010-01-25 03:42:58

On the other hand, it should be easy and cheap to setup a domain name with 5 or even more redundant Linux machines at separate data centers in the country (or the world) since we have users internationally. That way, the logging can have a long list of hosts IP addresses to log to.We can allow it to log to anyone at any time without a "stateful" connection and then have processes in the back end that collect all the logs, store them by user id, create reports, etc.so it could easily be extremely reliable.

Wayne 2010-01-25 03:45:11

Wayne: Even if you do that, the requests themselves could be forged (or just completely suppressed/faked). What I mean is that even that isn't foolproof, it's just "harder". I've elaborated a little in my recent edit.

Noon Silk 2010-01-25 03:46:29

Thanks, but web-based won't work because trading platforms like TZ need to be "low latency" so connected as closely as possible to the broker or TZ will even soon allows direct connection to exchanges. Users hate and server based option because it means their "secret sauce" strategy ideas will be submitted to our server and they fear the ideas will be stolen.

Wayne 2010-01-25 05:41:52

Wayne: I completely understand; I didn't think conversion to thin-client was practical, or even wise. Good luck with whatever you do; but I don't believe there is a foolproof system for you, in this case.

Noon Silk 2010-01-25 05:46:13

Understood about the suppressed/faked. Perhaps, using SSL with authentication of the connection will make that more challenging. But users might still figure out how to get the key out of the executable.WAIT! What if the logging server responds to every transaction (asynchronously) with an encrypted response like a SHA-1 hash of the last 100 trades plus some secret "salt". That way if the client and server hash mismatch then it knows suppression or faking occurred. It would still be possible to intercept and fake but require more effort and figuring out the "salt" from the binary, etc.

Wayne 2010-01-25 05:53:41

I think no matter what, if the client app is doing "anything" any replacement app can do the same. Further, you'll need to make it such that your app only functions when online (probably a bad move) because otherwise they can simply block your website via a firewall/hosts entry, and implement their own server that tricks your client app. All, of course, incredibly involved, but nonetheless ...

Noon Silk 2010-01-25 05:56:32

Of course, nothing will be foolproof but maybe this could create a level of difficulty to keep most people honest. Much like car door locks which never prevent the professionals but at least prevent the small timers and joy riding. The problem with a hash is that makes the servers stateful so more complex for server redundancy. I want to avoid a common single point of failure like a central database. so thanks for the chat. It might not be possible.

Wayne 2010-01-25 05:57:43

Wayne: No problem. Personally, I think I'd be thinking about a cut-down app that only supports X amount of funds to be processed through it, or some variant. However, some sort of tamper-protection (as proposed by the other poster) may be enough to tentatively keep people honest :) (Though, it does only take one dedicated 'cracker' to realise a tool to modify the logs for your entire app, and distribute around. Probably unlikely, but worth considering [arguably, same as just pirated versions of the 'pro' version]).

Noon Silk 2010-01-25 06:00:18

+1 A:

Here is a thought - whenever the user exits a session with the software, generate a hash based on the audit log. Encrypt the hash, then write it out to another file, perhaps hidden amongst your binaries, or to the registry.

When the user opens the application next, read the log file, re-generate the hash and see if it matches the recorded value. If it doesn't, shut down the application with a "Audit file tampered with" error message.

Not totally fool proof, but would be pretty solid.

Also, check out this question

CraigS 2010-01-25 05:54:54

This is quite a genious idea. Here's a couple concerns but they seem easily solvable. Q: When users send the file for auditing, how to verify it's legitimate? A: They need to send the hash file along with the audit file. Q: If the file gets hashed on closing of the program, what if the program gets killed by the user? A: That means you would have a file which doesn't match the hash file so, obviously, at next startup the program would reject it as tampered with. I'd like opinions on ideas to solve these in the next comment.

Wayne 2010-01-27 14:14:48

Solution 1. The program can hash the file along with a secret "salt" so the user cannot reproduce the hash easily--they would have to debug the obfuscated code to find the salt.Solution 2. It should be alright to recreate the hash to the file upon every time an audit log line gets added. That happens relatively infrequently--perhaps some hundreds of time per day at the outside.

Wayne 2010-01-27 14:20:28

The salt can be more complex than a simple fixed string thereby making it more of a challenge to reproduce and it can be variable and change or even with every trade. Obviously, I can't post those tricks publicly. But it would be most challenging for a cracker to handle because they wouldn't get any verification if the hash was correctly "hacked" it until they send us the file for audit reporting. Then, if they use the wrong "salt", we'll know it for sure.

Wayne 2010-01-27 14:24:32

What I love about this solution is 1. No server hassles. 2. Can leave audit file plain text for easier verification. 3. Very hard for a cracker due to the "salt" algorithm and zero verification of whether they cracked it properly until they submit it to us for auditing.

Wayne 2010-01-27 14:25:59

Thanks Wayne, glad you found my thoughts helpful. I hadn't thought about the program crashing - that *is* a problem. You could simply keep the log file in memory until they close the program, then write it out at the same time as the audit file.

CraigS 2010-01-27 20:05:52

Actually, all you would need to do would be to re-calc and write the hash every time you wrote to the audit log. I doubt that would hit performance very much.

CraigS 2010-01-27 21:32:58

Correct. I agree. It's better, at least starting out, to do it the most reliable way. It can always get optimized if needed.FYI, this isn't that reliable against cheaters by itself, but when coupled with our already existing copy protection scheme (see below) and "sanity" checks on data submitted for auditing, it will become extremely difficult to cheat. Thanks again!

Wayne 2010-02-04 15:26:02

+5 A:

The statement of your problem is:

we don't trust the client; the client could be hostile.
we want the client to send us data which we can trust.

There is no solution to this problem. You might as well say "I want to find two guys, one named Bob, one named Bill, such that Bob is a foot taller than Bill and Bill is a foot taller than Bob". You're not going to find two guys with that property.

You absolutely positively cannot trust anything that comes from a machine that you don't own that might be owned by a hostile client. My advice is do not waste your valuable time trying to solve an impossible problem; spend that time on making your server, which you do own and do trust, robust against hostile clients.

Eric Lippert 2010-01-27 22:45:33

That is totally true. However, it is also true that you "positively cannot trust anything" that you use to copy protect your software. It is definitely possible to crack any kind of software. The only question is how much effort that will take the cracker and if it's worth it.

Wayne 2010-02-04 15:06:19

So, in my head, the same principles for good copy protection apply to this challenge. One critical principle is this: The vast majority of your clients will be honest and cooperate. So you have to balance making it reasonably difficult to discourage cheaters while not making the protection mechanism such a pain that you turn away honest customers.

Wayne 2010-02-04 15:09:27

When it comes to copy protection, TickZoom, has a very nice balance that our customers love. 1. The FREE version has certain features compiled out so there's nothing for crackers to even crack except the expiration which doesn't matter much. 2. TZ never uses dongles or license keys limiting to the machine. 3. There user gets a unique, "one per user", 256 bit key which doesn't activate anything in the software. 4. Instead, the user key allows the user to download a new binary version every 3 months. 5. The binary expires in a way that will take weeks for a cracker to remove.

Wayne 2010-02-04 15:14:01

So the point of all that was just that users like the balance struck between the protection and the flexibility to honest users. --- Converting the software to a server based system for auditing usage is flat unacceptable to users. That would kill the business.-- However, adding a hash key will cause zero difficulty for honest users. And while cheating users can rather easily disable the hash function, if they fail to send reasonable numbers every 3 months then their download account gets disabled from downloading extended binaries so their ability to use the software will cease.

Wayne 2010-02-04 15:18:29

Additionally, we realized that the submitted audit files can be checked for "sanity" much like the IRS does with tax returns. They can be compared to past data, the documents the client origianlly submitted to get approved for usage, etc. And this can all, easily be automated to fire alarms if a clients reports seem falsified.Of course, customers can always pay the higher fees to cease the auditing so that makes this an "opt-in" decision for users to get far lower pricing initially.

Wayne 2010-02-04 15:21:22

ansaurus

tags:

views:

answers:

Secure Software License Usage Audit Log

related questions