Securing a Queuing Service in WSO2 EI or WSO2 ESB

Messages processed in a Queuing service (AMQ, SQS, RabbitMQ etc.) are generally in plain text. As general requirement securing the Queuing service through user credentials is enough. Thereby a selected few users have the access to AMQ. However, AMQ is generally handled/maintained by people who sometimes are not cleared to see the content of data (in case of sensitive data such as personal, financial or medical). The data however can be encrypted before it is placed in a Queuing Service for further processing. This blog describes a way on how to secure a queuing service in WSO2 EI or WSO2 ESB.

Encryption Strategy

There are a lot of encryption mechanism available amongst which are AES and RSA. These being used in this example.

AES
Advance Encryption Standards or AES algorithm is used to encrypt the entire payload. You can generate a random AES key to encrypt the payload and use the same key to decrypt the payload once it has been read from the Queuing Service for further processing.

RSA
Rivest–Shamir–Adleman or RSA is a public key encryption algorithm. The idea behind it is that a sender can encrypt data using the public key of the receiver and data can only be decrypted by the private key of the receiver. This is a good solution if the data is meant to be seen by only one other entity.

Drawbacks of each Algorithm

AES
This is a perfect solution to handle large amount of data. But the secret key {SK} which is generated every time to encrypt/decrypt needs to be transferred to the recipient entity.  Sending a key in plain-text compromises the security.

RSA
RSA can only encrypt a small amount of data. So any day to day payload can only be handled by RSA if it is spilt into smaller bits. This adds to the complexity and is harder to implement

A Combination of RSA and AES

As AES can encrypt large amounts of data we can use AES to encrypt the sensitive payload.

RSA only encrypts a small amount of data so we use that to encrypt the shared secret which allows the recipient to decrypt the AES-encrypted payload. We use the RSA public key of the recipient entity to encrypt the secret of AES. This ensures that the recipient is the only one who can decrypt the secret. Once both the payload as well as the secret key is encrypted it can be sent to recipient.

The recipient needs to decrypt the SK using its private key first, then decrypt the payload using the decrypted SK.

Implementation In WSO2 Enterprise Integrator or WSO2 ESB

In this blog I am securing JSON payload, an xml payload implementation would be very similar. The JSON structure which I have agreed with the recipient is below

_{Figure 1}

Figure-1 contains the sensitive payload that needs to be encrypted.

_{Figure 2}

Figure-2 The sensitive payload is encrypted and placed in tag ENCRYPTED where

_{Figure 3}

Figure-3 The entire content in Figure-2 is Base64 encoded and placed in payload tag of the final json. This json can now be sent into the Queuing Service as means of communication to the recipient party.

Implementation

The entire approach is done using custom mediator for which I have written a small java implementation. In the implementation keystore for the specific tenant is used. Therefore it will also work in a muti-tenant setup.

1. Initialize KeyPair

2. Get Keystore

3. Encrypt Text

4. Decrypt Text

5. Mediate logic for ESB Proxies

I hope this blog will help you to setup such an integration scenario. Please let me know if you have any questions.