Part 1
This is absolutely possible. This is quite apparent, but logical proof of the method needs effort.
First, let's do our assumptions. I you cannot accept some of them — I have a plan "B".
First, we need to consider three parties: Service
S, Client
C and "Middleman"
M; Middleman is able to spy on all communications between
C and
S. Apparently,
M would not be able to impersonate
C only if
C has certain "benefit" over
M. Not breaking the level of generalization, let's assume that the benefit is certain key
C receives in its deployment bases on user authentication. The full source code of client can be open, only a key is secret.
Now, let me assume you know the method of deployment of the key to all clients even over Internet (without SSL) the way
M cannot get this key even it it spies all the time. I assume that because this is a well-known method. I you're not sure it's possible, read this:
http://en.wikipedia.org/wiki/RSA[
^]. If your not convinced yet, I'll explain that on you request.
Now, I'm going to do the easiest assumptions on communication method. 1) It should be session-based non-secure protocol (HTML or TCP), 2) The session is divided in two parts: authentication followed by trusted; during authentication part client and service exchange messages used to proof authenticity of the client; after that, client is considered trusted and further work is done without any encryption. You did not require secret data communication, only authenticity of the client. If these two assumption are not OK, I can discuss plan "B" on further request.
Now, let's use same very RSA and create two keys. Further speculations are meant to maintain that the method is as strong as RSA. RSA is implemented in .NET. Let's follow the steps.
1) Generate two keys using RSA key generation function
RSA => (Ks, Kd).
The function has no "backdoor": it is not possible to calculate one key base on knowledge or another key. I'll call
Ks a "encrypting" key,
Kd — a "decrypting" key:
(unencrypted data, Ks) —> (encrypted data)
(encrypted data, Kd) —> (unencrypted data)
2) Let's deploy
Kd with
C.
At this step,
S has
Ks and
Kd,
C has only
Kd,
M has not keys or data.
3)
S starts, listen to connections,
C connects,
S accept (new) connection.
4) Authentication part of session protocol started.
S generates "Authentication Token"
Tu (unencrypted) and encrypt it into encrtypted token
Tu:
(Tu, Ks) —> Ts, and sends it to a connected client
C. New
Tu is generated randomly for every new session.
5)
C use
Ks to decrypt
Ts:
(Ts, Ku) —> Tu.
6)
C sends T
u back to
S openly,
S compares its values with the value stored before sending it to
C. That creates an evidence of
C. Trusted part of protocol starts.
7) At this point
M has both
Ts and
Tu. It cannot be used for impersonation of
C, because it would require to connect to create a new session; but for this new session Authentication Token will be new, not known to
M. Also, as there is no RSA "back door",
M cannot obtain any of the keys from data.
If there is a reason to concern about open sending of
Tu from
C to
S, this part also can have plan "B" based on additional pair of keys (one of them will be open and known to
M to make this part of communication a secret from
M.
That's it. Any concerns, further questions?
—SA