If you create a custom sink (you'll need one for the server and one for the
client), you can change the headers and/or the actual stream content.
One simple solution is to take the serialized object info, and create a
message digest (see the RSA/DSA classes in System.Cryptography). You then
add the message digest to the headers, and read on the other side. On the
other side, perform the same digest operation, if the digest in the header
matches the one you just created, the message wasn't tampered with.
A slightly stronger mechanism, although one that is a bit more complicated
is to change the stream contents itself (instead of adding message headers).
Take the data after it's been serialized and create a message envolope. This
requires that both client and server create key pairs and share public keys
ahead of time. You can then sign the message, as well as create a symmetric
cipher key, encrypt the entire stream, encrypt the symmetric key with the
other party's public key, and send it (either as part of the stream, or in
the header). On the other side, your custom sink will decrypt the symmetric
cipher key using it's private key, decrypt the message, and validate the
digital signature.
As a slight modification to this technique, you can negotiate a symmetric
key between the two sides ahead of time instead of generating and sending a
new one each time. You can either do this by encrypting a symmetric key with
the other side's public key and sending it ahead of time (only once), or you
can have both sides derive the symmetric key using an algorithm like the DH
key exchange.
Each approach has it's pros and cons when it comes to security. In one
senario, you are sending the key only once. If an attacker can somehow grab
and crack this key, he can read all the messages. Sending a new key with
each message inside a digital envelope keeps the encryption unique for each
message, so one key cannot decipher all messages, but you are sending the
key with the actual message (and there is always a chance someone can
decipher the encrypted key itself).
Note that in all three scenarios, the major component is the message digest
(which is also part of the digital signature if you decide to do that). The
digest, if using the proper keys, will always be the same on both sides if
the message hasn't been tampered with while in transit.
-Rob Teixeira [MVP]