One of the requirements that came up on my current project was the need to secure specific fields in a message during transit. I thought about it a while before I decided that this is something that should be made explicit in the message contract.
Here is an example from the tests:
WireEncryptedString is a type that would be encrypted on the wire, as the name suggest.
And defining the keys in the configuration is done in this way:
On the wire, it has the following format:
Following the Rhino Service Bus philosophy, it is quite a neat solution.
The actual encryption is doing using 256 bits key with Rijndael (AES). I considered other approaches, but all of them had quite a big overhead from manageability perspective.
There are some interesting implications for the implementation, that deserve some discussion. Let us assume that you send such a message to another end point.
If the endpoint…
- has the same key as us, the message will be decrypted and everything works.
- doesn’t have any security defined. At that point, the message will successfully deserialize. Any WireEncryptedString field will contain the encrypted value.
- has a different key defined. Message serialization will fail.
Trying to send a message that contains WireEncryptedString will throw, we do not allow such an action.
And now you can tell me how many holes there are in my system :-)