MQ

This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

I asked the team during the recent "IBM MQ: Ask Us Anything" event, what their favourite little feature of IBM MQ was. Matt Sunley's answer was about the Key Reuse capability in AMS Confidentiality policy. So let's learn a little about that little gem of a feature today.

IBM MQ Advanced has a feature called Advanced Message Security (AMS) which provides digital signing and encryption of messages from application to application. This is distinct and different from channel based features using TLS which only applies those security features while the message moves over the channel. These security features are configured by means of message protection policies, of which there are, as of IBM MQ V9.0.0, three different types.

• Integrity
  This causes the messages to be digitally signed, allowing detection of tampering of the message data.
• Privacy
  This causes the messages to be encrypted with the selected encryption algorithm, and digitally signed.
• Confidentiality (added in IBM MQ V9.0.0)
  This causes the messages to be encrypted with the selected encryption algorithm, but not to be digitally signed.

Another way to look at these different types of policies is from the perspective of the two message protection features that AMS offers you, digital signatures and message data encryption.

The Confidentiality policy type is designed to remove some of the expense seen when using the Privacy policy to allow for more affordable message protection when all the features were not required.

Message protection with AMS uses both symmetric and asymmetric key operations. Symmetric key operations are significantly cheaper than asymmetric ones.

When a message is digitally signed, which happens for both the Integrity and Privacy policies, the hash of the message is encrypted with an asymmetric key operation to produce the digital signature. When a digitally signed message is read, that signature is decoded with another asymmetric key operation. These are expensive operations that have to happen for each and every message.

When a message is encrypted, the cheaper symmetric key encryption is used for the bulk data encryption, but in order to safely deliver that symmetric key to each recipient, it is encrypted in a little package itself, and added to the message, once for each recipient. In order to decrypt the message, the recipient must first decode that package with another asymmetric key operation, another expensive pair of operations.

The Confidentiality policy type does not have a digital signature, and in addition, allows the symmetric key being used for encryption to be re-used for a number of messages, so that a reduction in the asymmetric key operations can be achieved by reusing the previously generated package, and by the recipient detecting that the same key has been used and not having to decrypt the package when it already has the key needed.

As the MQ administrator setting up message protection policies, you have control over the amount of key reuse that should happen, as shown in the example policy definitions below.

Example policy using setmqspl control command

setmqspl -m MQG1 -p CONF.Q -e AES128 -r "CN=Morag Hughson,O=MQGem" -c 9

Example policy using MQSC command

SET POLICY(CONF.Q) ENCALG(AES128) RECIP('CN=Morag Hughson,O=MQGem') KEYREUSE(9)

These two examples do the same thing, they state that "Morag Hughson" is the only recipient that the message will be encrypted for and that the key can be reused nine times, that is ten messages can be sent using the same key. There is no authorised signer provided, nor a signing algorithm, so this policy does not digitally sign the messages. Encryption but no signature is what makes it a Confidentiality policy.

Based on the above policy setting key reuse to 9, the encrypted symmetric key can then be reused by subsequent messages that are intended for the same recipients. An application that is getting encrypted messages can apply the same optimization, in that the application can detect when a symmetric key has not changed and avoid the expense of retrieving the symmetric key.

In this example 90% of the asymmetric key operations can be avoided by both the putting and getting applications by reusing the same key.

A performance report about this specific feature was published by the IBM Hursley Performance Team. You can view it here.

To finish, let's listen to a snippet of the Ask Us Anything webinar, where Matt Sunley describes this feature in his own words.

You can watch the full replay of the "Ask Us Anything" webinar here.