Secure messaging tips.

Hi,

Messaging is inheritantly somehow 'broadcast' oriented in some way. Thats one of the strengths of messaging.
This strength can also be a weakness if one does not design ones subject hierachy properly, by as you give as example, letting sensitive messages slip through to clients who shouldnt get those messages.

Firstly it would be a good idea to let nodes obtain an encryption key by first making an SSL secured pipe via the normal TCPIP transports to a central 'key server' who would generate new keys every 24 hours or what would be convienient. The key would then be used to encrypt all messaging traffic between all the nodes.
This way, breaking the encryption wouldnt be a trivial task as the key would be frequently updated and not stored on disk on each node.

Further one must think about exactly _where_ is the WIB placed? If you place it within the companys own premisis, perhaps putting all central nodes on the same LAN segment to ensure that interserver communication never goes out of this highly secure zone, then essentially no security risc would exist for these nodes and they can transfer all the sensitive info between them as they like.

If you have nodes placed outside secure zones which needs to receive sensitive information, you would want to establish a local WIB for each of them typically by estabilishing a hub/spoke setup and on the hub, ensure only to send messages to nodes who are approved to receive them. Default kbmMW's hub relays incoming messages based on what clients subscribe for automatically, but you can choose not to do that, by setting AutoRelay:=false and instead put your own relay rules within the OnMessage event of the hub. You would put code similar to this in the event:

procedure... OnMessage(Sender:TObject; const TransportStream:TkbmMWCustomMessageTransportStream; const
Args:TkbmMWArrayVariant; UserStream:TMemoryStream);
var
  tsclone:TkbmMWCustomTransportStream;
  info:TkbmMWCustomMessagingServerTransportInfo;
begin
  if (kbmMWSubjectPart(TransportStream.Subject,3)='SECURE')
     and (TransportStream.UserName='...') then // Or some other arbitraire rules.
  begin
     info:=TkbmMWCustomMessagingServerTransportInfo.Create;
     info.Subject:=TransportStream.Subject;
     info.AutoFreeInfo:=true;

     tsclone:=ATransportStream.CreateCopy(TransportStream,info);
     OutboundMessageQueue.AddMessage(tsclone); 
  end;
end;

Using hub/spoke messaging utilize something called a multiple endpoints deliverance, while broadcast/multicast type messaging utilize something called single endpoint deliverance.

Multiple endpoint deliverance allows for compressing, encrypting and signing messages for each spoke independantly as one of its merits. Single endpoint deliverance use the same compression, encryption and signing for all receipients. What that means in normal english, is that you can implement point to point security between the hub and spokes independantly for each spoke.

To implement encryption, you will however need to implement your own encryption component, as described in one of the whitepapers.

One of the arguments you get to the Encrypt and Decrypt methods (which you override) are a TObject Caller argument. The Caller argument can directly be cast to a TkbmMWCustomTransportStream and can be tested for if its a TkbmMWCustomRequestTransportStream, TkbmMWCustomResponseTransprotStream or TkbmMWCustomMessageTransportStream. Then cast it appropriately and you will have access to the username/password etc provided by clients. This way you can make the encryption/decryption act differently for each spoke.

Theres lots of posibilities to get secure messaging going.

--

best regards
Kim Madsen
kbm@components4developers.com
www.components4developers.com

The best components for the best developers
kbmMW - kbmMemTable - kbmWABD - kbmX10