RE: Encryption Key Question

[Simon Zuckerbraun <szucker () sst-pr-1 com>]

> Essentially its not about the user, its about the software. I want to
> ensure that only my software can talk to my webservice and vice
> versa. I don't care about the user, or who is using it, but the
> application. So, the thought is to have a unique method of sending
> and recieving data...namely encryption.

Ah. Ok.

Here is my take on this: There is a client machine, which is under the
control of potentially untrustworthy people. The client machine
communicates with the web service. We wish to ensure that all the
communications from the client machine to the webserver are actually
produced by the "authorized" client app, and not by some other software
introduced by the operators of the client machine.

Sadly, it is physically impossible to ensure such a thing. If you don't
have administrative control over client machine "A", the software
running on "A" could be absolutely anything.

For example: Let's say that the proper client app is intended to compose
a valid request message "V", then encrypt V using function f to yield
f(V), and send f(V) to the web service. Well, an evil piece of software
running on the client could just as easily compose a malicious request
"M", encrypt it to get f(M), and submit f(M) to the web service. In such
a situation, cryptography buys us nothing.

One might think, "This won't happen, because the malicious software
won't know how to produce the encrypted value f(M)", but the reality is
quite the opposite. The malicious software generally can obtain f(M)
effortlessly by taking M and passing it to the encryption routine found
in the legitimate software. Bottom line is, since the encryption process
is taking place entirely on the client machine, the client is in the
ideal position to observe the encryption process and learn every last
detail. Nothing can prevent this from happening.

The golden rule for implementing security checks in a client-server
environment (by which, I mean trusted servers with untrusted clients*)
is as follows: The only checks that make any difference are the
server-side checks. Every piece of data the server receives from a
client must be regarded as possibly malicious. There is never any
assurance that the client has produced the request in the expected
fashion. There is no way around this. It's a hard fact of life and every
client-server system needs to be designed to take this into account.

Simon


* It might be theoretically possible to have some assurance of client
integrity if one were to introduce a trusted component into each client.
An example of a trusted client component would be a smart card that is
distributed to each client.