How to authenticate client application for trust of messages sent from it

Question

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?

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.

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

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.

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!

Snowfield

Answer 1

Impossible.

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.

Gabriellagabrielle

This is almost the point that I have reached, but this seems like a common software problem. I am hoping to get some more ideas that may send me down the right (or better) path. – Snowfield

It is a very bad idea to say "impossible" when it comes to technology. Generally, someone has already done it at the time someone else is saying "impossible"... – Cornice

I don't see this as an issue of technology. It's an issue of incomplete information. The server gets instructions from an untrusted source. This source can only be trusted if information is supplied from a trusted channel. – Gabriellagabrielle

That's the point of the technology argument. New uses of existing technology, or new technologies can be used to create the trusted channel. – Cornice

Answer 2

Presumably, your server is creating the web page that the Silverlight application sits in. You could create a short-lived temporary "key" that only that web page contains. When the Silverlight app starts up, it reads this key and uses it. Because the server itself has a constantly changing, very short list of allowed keys, you can be more sure that only your app is accessing your services.

Cornice

How does the server know the which client's are safe to give keys to? – Gabriellagabrielle

He's already determined that by creating a Silverlight application which is embedded in a web page being hosted by a web server. Whatever browsers can access the page are the valid clients. – Cornice

I like this idea John, but testing it out it looks like the parameters that are passed to the SilverLight application are passed in plain text. What would prevent someone from preventing the load of the SilverLight application and then using the once off short lived key could gain access to the services? – Snowfield

You can't reach a 100% secure system (which is a general security issue anyway). However, you can make it harder to crack at the important points. If you decide that the probability of someone loading the page and reading your key to then call things with a different app is high enough, then you spend money to avoid that issue. Assuming you need to, you can take the alternate approach of automatically updating the SilverLight app itself every X minutes or hours. That way, the hackers wouldn't have enough time to crack the app before the new app with new codes is in place. – Cornice

Answer 3

The best advice for you in this matter is to hire a security expert to help you. This is not a unique or unusual problem -- consider any game (like WoW for example) that is attempting to determine if it is speaking to a true client or a fraudulent client. Even with a massive amount of effort (look up Blizzard Warden, I'm not going to link it here), they still have issues. The problem boils down to exactly how much time and effort your attacker is going to invest in thwarting your attempts to make thing hard on him. Just be sure to validate everything on the server-side. :)

Muck