假设要在客户的计算机上部署软件应用程序(例如IIS网站(。出于许可和开具发票的目的，应用程序定期向软件公司拥有的中央服务发送某些使用统计信息(例如，被管理实体的数量(。确保传输数据完整性的最佳方法是什么(即，在客户系统上拥有管理权限的攻击者不能向中央服务发送虚假数据(？
显而易见的方法是对应用程序代码中的私钥进行硬编码以对数据进行签名，并对代码进行模糊处理。只要密钥没有被消除混淆，这将确保完整性。但是，我们能比默默无闻的安全做得更好吗？
您不能确保数据的完整性。你能做的是"；尽最大努力"；诚实正直
鉴于评论中的额外信息：
威胁模型是一个作弊的客户，他可以检查但不能修改代码，并控制到中央服务的通信信道
我们可以对此进行调查。
尽最大努力
基本威胁是重放攻击：攻击者可以使用例如Wireshark记录应用程序和中央服务之间的通信，然后重新发送。
TLS保护您免受此攻击。
但是TLS的实现通常使用本机操作系统实现(例如openssl(，如果攻击者能够控制本机操作程序实现，他们可以很容易地生成一个设置，在该设置中TLS流量可以被解密和重放
添加请求ID和时间戳可以通过让服务器拒绝接受任何不是最近24小时的内容或在过去24小时内已经看到的请求ID来缓解这种情况。
下一个威胁是攻击者发送一个修改后的版本，其中包含新的请求ID和时间戳，可能还有其他修改后的字段，这些字段使他们的欺骗行为变得有价值。你的下一道防线是混淆有效载荷。
根据兔子洞的深度，攻击者仍然可以使用ltrace/gdb/jdb/visualstudio等工具或通过研究字节码/汇编码/CIL代码对其进行逆向工程
接下来要做的是使用应用程序中嵌入的密钥对应用程序中的请求进行加密和/或签名。
但是，如果攻击者拥有机器并可以访问应用程序的文件，那么就不难找到密钥
你也许可以把钥匙拆开，分成许多无法识别的小部分，把它们藏在应用程序的不同地方，并有一些代码来重新组装钥匙。
但是，如果攻击者看到它是签名/加密的，他们会寻找密钥，当他们找不到密钥时，他们会试图从网络调用追溯到报告的创建，并查看应用程序是如何获得密钥的。
也许更好的选择是建立另一个分发密钥的服务：应用程序将请求一个密钥，并使用该密钥为中心服务加密消息。
当然，攻击者也可以调用此服务。
另一种选择是：现在有一些硬件是针对逆向工程设计的，如果没有可用的硬件，你的应用程序可能会拒绝启动——这取决于你的客户是谁。
我希望你能看到，这种最大的努力是如何让你的计费基础设施成为你的噩梦，而不是攻击者的噩梦。
通用解决方案
在这种情况下，公司通常会在服务条款中加入使用报告和反逆向工程条款，试图检测报告中的异常情况，当检测到异常情况时，进行调查并采取法律行动。
你需要在体系结构层面问自己的另一个问题是：在我发现并将客户赶出去之前，客户作弊的可能性有多大，总共要花我多少钱
即：这个问题值得解决吗？