MQ Message Encryption (MQME) is a solution that provides encryption for MQ message data while it resides in a queue or topic and in the MQ logs (i.e. data at rest).
By default, when an application puts a message to a protected queue, MQME will encrypted the entire message data. If the application is putting messages that contain an embedded message (i.e. MQRFH, MQRFH2, MQCIH, etc.) then MQME will encrypt the entire message data which includes the MQ embedded headers. After MQME encrypts the entire message, it changes the MD.Format field from the current value to blanks (the MD.Format value is saved).
When the receiving application issues a get on the protected check (assuming it passes authorization checks), MQME will decrypt the message and reset the MD.Format field to its original value.
For 99.9% of applications, the above scenario works without any issues.
A JMS message (aka MQRFH2) has the following layout:
{RFH2 header}{mcd folder}{jms folder}{usr folder}{message payload}
Message properties (aka named properties) are stored in the ‘usr folder’.
MQ has special features/functionality for JMS messages and there are 2 situations where the above encryption scenario will not work:
- If the protected queue has the attribute PROPCTL set to NONE
- If the receiving application uses message selectors
1. When the queue’s PROPCTL attribute is set to NONE then MQ will strip off the RFH2 header and folders of a JMS message (aka MQRFH2) when the receiving application issues an MQGET. A useful feature for applications that cannot handle JMS messages.
2. JMS application can request a particular message from a queue by using message selectors. The message selector match on a value of a message property in the usr folder.
i.e.
String selector = "category='scifi'"; consumer = session.createConsumer(destination, selector);
The MQ internal code for handling those 2 features is processed before MQME is invoked for the MQGET operation which means MQ’s internal code cannot do either of those features because the message is encrypted.
I have asked IBM about moving the point at which those 2 features are processed to be after the API Exit (MQME) is invoked for MQXF_DATA_CONV_ON_GET. IBM has said no.
The reason I asked IBM to move the point at which those 2 features are handled is because some client applications put sensitive data in the message properties (aka named properties) in the usr folder of an MQRFH2. Yes, yes, I tell them all the time that it is a bad idea but it is what it is.
I have added a new keyword to MQME called EncryptRFH2Header. Its default value is set to ‘Y’ (Yes) which means it will retain existing behavior. When the EncryptRFH2Header keyword is set to ‘N’ then MQME will only encrypt the message payload of the JMS message and not encrypt the RFH2 header or any folders.
So, here’s the catch 22: if the application is using either the queue’s PROPCTL set to NONE or message selectors then the application MUST NOT put sensitive data in the message properties (aka named properties) because the usr folder will not be encrypted.
If anyone would like to test out the latest release then send the email to support@capitalware.com
Regards,
Roger Lacroix
Capitalware Inc.
