安全软件许可证使用审核日志

发布于 2024-08-18 15:28:06 字数 868 浏览 11 评论 0原文

各位,

我们面临着一项有趣的技术挑战。如何编写一个安全的审计文件来跟踪软件的使用情况,以便许可证费用可以基于使用情况,从而使那些使用较少的人更负担得起。

具体来说,TickZoom 为对冲基金销售阿尔法生成交易平台,目前该平台的许可费用为 2,000 美元/月,包括支持(很快将增加到两倍以上)。这对机构来说很好,但对个人来说太昂贵了。个人通常会要求较低的价格,以换取使用该软件所赚取的一定比例的利润,直到他们有能力支付固定费用为止。

我们喜欢这个提议。但我们需要一种可靠的方法来审计平台上实际产生的利润,并防止用户通过删除或覆盖审计文件来“欺骗”平台,从而报告低于实际的收入。

该应用程序是用 C# 编写的,系统的这一部分被混淆了,至少使得代码难以破译。

另一个要求是将发生的每笔交易写入文件,以便在用户认为总费用存在一些差异的情况下进行更深入的审核。这样,个人交易利润就可以与经纪商报表进行比较。

当然,假设该文件将被加密。

但关于如何使其“防篡改”有什么想法吗?尤其是针对简单的删除尝试?

我的第一个猜测是让软件始终需要预先存在的审核文件,否则它将拒绝运行。

然后,当我们交付软件时,它会与“空”审核文件打包在一起,但实际上具有某种防篡改验证。

用户可能尝试“篡改”文件的下一个明显技术是某人简单地备份原始“空”文件,然后用它来覆盖审核文件,从而欺骗系统认为这是一个新的开始。

也许可以通过包含某种“上次更新时间戳”和过期时间来解决这个问题。

此外,欢迎完全不同的解决方案想法。在这种情况下,我们可能被迫添加“电话主页”功能,以便将交易记录到我们的中央服务器。但这似乎是不利的,并且可能会在关键任务应用程序中增加另一个故障点。一般来说,他们非常不喜欢“电话之家”功能,这是有明显充分理由的。

真挚地, 韦内克

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

要走就滚别墨迹 2024-08-25 15:28:06

您的问题陈述是:

  • 我们不信任客户;客户可能会怀有敌意。
  • 我们希望客户向我们发送我们可以信任的数据。

这个问题没有解决办法。你也可以说“我想找两个人,一个叫鲍勃,一个叫比尔,这样鲍勃比比尔高一英尺,比尔比鲍勃高一英尺”。你不会找到两个拥有该财产的人。

您绝对不能信任来自不属于您的机器、可能属于敌对客户的任何东西。我的建议是不要浪费你宝贵的时间去解决一个不可能的问题;花时间让您拥有并信任的服务器能够抵御敌对客户端。

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.

荒芜了季节 2024-08-25 15:28:06

不,我不认为除了将所有收入实时报告回服务器之外您还能做任何事情,但即使这样也有问题。

-- 编辑:

在我看来,您唯一的选择是:

  • 将系统转换为基于网络的系统(或至少是瘦客户端),从而使所有事务都在服务器上进行

显然,这可能是相当不切实际的,如果你已经开发了一个完整的基于本地的系统

  • 想出一些“难以”破坏的复杂方案并希望人们不要破坏它

并在这种方法中结合某种分析来显示商店是否赚取X,突然X-sigificantAmount,你可以确定他们甚至不再盈利,因此可能欺骗系统(或倒闭:)但这接近于侵犯隐私,并且可能根本不合适。

实际上,我认为你需要权衡风险与可能的利润,或者找到另一个角度如何向这些人销售(即只让界面/应用程序本身管理X的总资金,如果超过,提示专业版或其他版本)。

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

又怨 2024-08-25 15:28:06

这里有一个想法 - 每当用户退出软件会话时,就根据审核日志生成哈希值。加密哈希值,然后将其写入另一个文件(可能隐藏在二进制文件中)或注册表中。

当用户接下来打开应用程序时,读取日志文件,重新生成哈希并查看它是否与记录的值匹配。如果没有,请关闭应用程序并显示“审核文件被篡改”错误消息。

虽然不是完全万无一失,但相当可靠。

另外,看看这个问题

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文