Как аутентифицировать клиентское приложение для доверия отправленных с него сообщений

The basic question
Как я узнаю, что это мое общедоступное (клиентское) приложение отправляет мои служебные сообщения? Откуда я знаю, что это не какое-то другое приложение, которое исполняет роль моего приложения?

Some Background
В настоящее время мы регистрируем все ошибки, которые происходят на наших сайтах, через log4net и WCF в базе данных. Это хорошо работает, потому что веб-сервер (доступный из Интернета - частично доверенный) сообщает об ошибках в службу WCF, работающую на сервере приложений (недоступную из Интернета - доверенный) через доверительные отношения. Поэтому мы знаем, что все журналы ошибок реальны, и нам нужно их исследовать.

С нашими новыми сайтами мы планируем использовать SilverLight, чтобы немного оживить ситуацию. Проблема, с которой мы сталкиваемся, заключается в том, как сообщать об ошибках из приложения SilverLight, запущенного на компьютере веб-пользователя (ненадежный), на наш сервер приложений (недоступный из Интернета - доверенный).

Мы можем решить проблему недоступности сервера приложений, заставив клиента обмениваться данными через интерфейс службы на веб-сервере, так что это не беспокоит. Проблема возникает, когда мы должны быть уверены, что приложение, отправляющее сообщения, действительно является нашим приложением, а не просто имитатором.

Some Thoughts
Код будет написан наC# и бегать вSilverLight приложение, которое запускается локально на клиентском ПК, поэтому мы не можем гарантировать, что оно не будет декомпилировано и использовано для отправки поддельных сообщений в наш сервис.

Вышеуказанное означает, что мы не можем использовать обычное симметричное шифрование, потому что мы не можем хранить наш закрытый ключ в приложении (его можно декомпилировать). Точно так же мы не можем использовать асимметричное шифрование, поскольку оно может быть просто олицетворено (злоумышленник может просто подписать сообщения с сохраненным открытым ключом и отправить их - сообщения будут выглядеть реальными)

В случае этого приложения нет аутентификации пользователя, поэтому мы не можем использовать ее для обеспечения доверия.

Да, я знаю, что это довольно странно, поскольку журналы ошибок лучше защищены, чем данные, отображаемые приложением, но это так :)

Любые мысли или помощь будет принята с благодарностью!

Ответы на вопрос(3)

Ваш ответ на вопрос