Server needs to trust *client* code without a certificate

Question

Here's a sticky security question
I want my server to trust that a client has performed the operation it says it has on some data held by the client (the client performs the operation to reduce server load). The server can supply code to perform the operation to the client, via a serialized object or RMI.
However, I don't want every client to have to register with the server (eg if each client had its own certificate this would be necessary)
Presumably something must happen as the client performs the operation to show that the correct (server generated) code was used.
If the object whic h knows how to perform the operation is sent using RMI with a public sign method and the server lends its own private key for the signing, in a private field of this object, can a malicious client discern the private key of the server simply by deserializing the object ? Encryption of the serialized object doesn't seem to help as a normal client needs to decrypt, so the malicious one can too.
What about if a private/public key pair is generated at the server and given to the client for signing? again the malicious client could sign using the key then perform a completely different operation.
What should actually be signed at the client end - the object sent which performs the operation ? the server needs to know that this signature proves that the code it sent was used.
would be interested in any ideas (this is for a university project)
thanks to all
John

Answer 1

Hi John,
First, secure your coms : SSLv2 for example (1), so the further discussions between the "server" and the "client" will be sure (for a moment ;-).
Next, supply the "server code" from the server (only via the secured channel) to the "client" (2).
This code must be in two parts : "crypted data" and a "decryption module".
The "decryption module" must contains a "server's public key certificate" to use to decrypt the "crypted data" (3) that contains the "real code" and a "serial ID generated by the server".
Then the "decryption module" must start the newly decrypted "real code", to do the "server operation" on the "client data".
At the end, the "real code" sends back the "client result" and the "serial ID" encrypted with the "server's public key" (4).
(1) SSL v2 creates a secure channel betwwen a server and a client (typically a browser), but at the intiative of the server and with no active part of the client, except to accept the chosen algorithm (I simplify here but it's schematically the point).
(2) So with this channel (at the initiative of the identified server) the "client" is sure that the "modules" came from the "server".
(3) This encryption has been made with the "server's private key", so only its "public key" can undo it : so the "client" and the "decryption module" are sure that the "real code" has not been alterated.
(4) Same thing, but opposite side : only the "server's private key" can undo an encryption with its "public key" : the "client" is sure that only the "server" will be able to do something with its "result".
With this proposition, the "server" is sure that the "client" has done its "server code" on some data and has given back a "result". But it has no guarantees on the identification of the "client", only that it is the same from the beginning.
By the way, never "lend" a private key to another one, it is lethal to your security, since PKI is only a matter of trust on the public/private keys pair and its link with an identity (that's why Certificate Authorities are made).
Pleased if I have been of some help, Wild.