问题描述
基本问题
我怎么知道发送我的服务消息的是我的可公开访问的(客户端)应用程序?我怎么知道不是其他某个应用程序在冒充我的应用程序?
The basic question
How do I know that it is my publicly accessible (client) application that is sending my service messages? How do I know that it is just not some other application that is impersonating my application?
一些背景
目前，我们通过 log4net 和 WCF 将我们网站上发生的所有错误记录到数据库中.这很有效，因为 Web 服务器(可从 Web 访问 - 部分受信任)通过受信任关系向在应用程序服务器(无法从 Web 访问 - 受信任)上运行的 WCF 服务报告错误.因此，我们知道所有错误日志都是真实的，我们需要对其进行调查.
Some Background
Currently we log all errors that occur on our websites via log4net and WCF to a database. This works well because the web server (accessible from the web - Partly Trusted) reports there errors to the WCF service running on the application server (inaccessible from the web - Trusted) via a trusted relationship. We therefore know that all error logs are real and we need to investigate them.
在我们的新站点中，我们计划利用 SilverLight 使事情变得活跃一点.我们面临的问题是如何将错误从 Web 消费者 PC(不受信任)上运行的 SilverLight 应用程序报告回我们的应用程序服务器(无法从 Web 访问 - 受信任).
With our new sites we plan to make use of SilverLight to liven things up a little. The problem we are faced with is how to report errors back from the SilverLight application running on the web consumer's PC (Untrusted) to our application server (inaccessible from the web - Trusted).
我们可以通过让客户端通过Web服务器上的服务门面进行通信来解决应用服务器无法访问的问题，这样就不用担心了.当我们需要确保发送消息的应用程序确实是我们的应用程序而不仅仅是一个模仿者时，就会出现问题.
We can solve the inaccessibility problem of the application server by making the client communicate via a service facade on the web server, so that is no worry. The problem occurs when we need to be sure that the application sending the messages really is our application and not just an impersonator.
一些想法
代码将使用 C# 编写并在客户端 PC 本地运行的 SilverLight 应用程序中运行，因此我们不能保证它不会被反编译并用于向我们的服务发送虚假消息.
Some Thoughts
The code will be written in C# and be running in a SilverLight application that runs locally on the client PC, so we cannot be guaranteed that it will not be decompiled and used to send fake messages to our service.
以上意味着我们不能使用传统的对称加密，因为我们不能在应用程序中存储我们的私钥(它可以被反编译).同样，我们也不能使用非对称加密，因为它可以被模拟(攻击者可以使用存储的公钥签署消息并发送它们 - 消息看起来是真实的)
The above means that we cannot make use of conventional symmetric encryption because we can't store our private key in the application (it can be decompiled). Similarly we can't use asymmetric encryption since it could just be impersonated (the attacker could just sign messages with the stored public key and send them - the messages would look real)
在此应用程序的情况下，没有用户身份验证，因此我们无法使用它来为我们提供信任.
In the case of this application there is no user authentication, so we cannot use that to provide us with trust.
是的，我知道这很奇怪，因为错误日志比应用程序显示的数据得到了更好的保护，但情况确实如此:)
Yes, I know this is rather bizzare with the error logs being better protected than the data the application displays, but it is the case :)
任何想法或帮助将不胜感激！
Any thoughts or help would be greatly appreciated!
推荐答案
不可能.
您可以对用户进行身份验证，但不能对应用程序进行身份验证.
You can authenticate users, but not the application.
假设您决定对应用程序进行数字签名.然后，您的客户端应用程序会在运行时根据此签名检查其自己的可执行二进制文件来读取此签名.没有什么可以阻止对手简单地从您的应用程序中删除此检查.
Let's say you decide to digitally sign the application. This signature is then read at runtime by your client application checking its own executable binaries against this signature. There is nothing that prevents the adversary from simply removing this check from your application.
即使您几乎不可能对您的应用程序进行逆向工程，对手总是可以查看通信渠道并编写一个从您的客户端到您的服务器看起来无法区分的冒名顶替者.
Even if you make it close to impossible to reverse engineer your application, the adversary could always look at the communication channel and write an imposter that looks indistinguishable from your client to your server.
您唯一能做的就是根据用户身份验证服务器上的操作.
The only thing you can do is validate the actions on the server against a user identity.
这篇关于如何验证客户端应用程序对其发送的消息的信任的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！