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]
"Paul Fi" <na*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
1.communication between the client and server has to go thru client and
server channel sinks before its turned to object method invokations
those channel sinks carry messages thru and other header informations
now how can u secure those header information like the requestheaders
from being modified during its way to the server say by a third party
that acts illegaly to those information?
2.what are the header information that gets added to our header
collection from the formatter sinks from client and server sides?
3.what type of objects that get stored inside our streams ?
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
