With the recent announcement of MQ 9.0 there is now a third policy option to provide protection to MQ messages, this is known as a Confidentiality policy (encryption only). Confidentiality policies are uniquely different to Integrity and Privacy policies in the following regards;
- The sender of a message still must know the intended recipient, but the recipient does not need to know the sender
- It is possible to enable use of the same encryption key for multiple messages that are destined for the same recipient
Without going into too much detail, I'll try and generalize in a paragraph the relative costs and merits of the two main cryptographic technologies involved in protecting a message; symmetric key is fast and cheap and asymmetric key is slow and expensive. Symmetric key cryptography is where both the sender and receiver of data already know/use the same key to encode/decode data - but the problem is how to share the key. Asymmetric key is where the key is split into a private/public pairing, the private key is kept secret by its owner whilst the public key is shared and used by anyone who wants to exchange data with the keys owner. Opposite keys must be used to encode/decode and so asymmetric key is often used to solve the problem of sharing a symmetric key. If you know a little of how SSL/TLS works then you'll know that the initial handshake is where the CPU intensive asymmetric key operations are used and a session key agreed (symmetric key) and then from that point the session key is used. AMS uses both asymmetric and symmetric key operations on a per message basis, exactly how much of each type depends on the policy type.
"Alice and Bob"
With a Confidentiality policy, the recipient does not need to know the sender of the message - this means that Bob does not need to have a copy of Alices certificate.
By removing the digital signature and opting for encryption only, you can immediately halve the number of asymmetric key operations that involved in transferring the message from Alice to Bob.
Furthermore, if you have more than one message that you need to transfer to the same recipient and you are are willing to use the same symmetric key for subsequent message transfer then you can eliminate the asymmetric key operations on the 2nd and subsequent messages, the cost for transferring these messages is just symmetric key based which is comparatively fast and cheap.
The graph here provides a simple comparison of how quickly a queue could be loaded with 5000 x 2KB messages using different policy types. The bars indicate the elapsed time for the put and get operations.
The flip side of reusing the same symmetric key over multiple messages encrypted with a Confidentiality policy is that more messages could be decrypted if the key were to become compromised. With Privacy or Confidentiality policies without key reuse, every message has its own symmetric key and so a compromised key does not help decrypt another message. To put this threat into some perspective, current estimates it would take a brute force attack against a 128-bit AES key by a cluster of supercomputers billions of years to complete.
setmqspl -m QMGR -p QUEUE -e AES128 -r 'CN=Bob, O=IBM, C=GB'
Key reuse can be added to provide further cost reductions when putting multiple messages to the same recipient, it is configurable from no reuse (0), 1-9999999 or unlimited ('*' via setmqspl). This example shows a definition of a policy that uses AES-256 encryption and allows 20 further messages to reuse the same symmetric key;
setmqspl -m QMGR -p QUEUE -e AES256 -r 'CN=Bob, O=IBM, C=GB' -c 20
Mark Taylor has put together a video showing the new Confidentiality policies in action which can be found here.
Confidentiality policies are complementary options to Privacy and Integrity policies, it is a case of the "right tool for the job". If digital signatures and the assurances that they provide are required then AMS Privacy policies are probably still going to be a good starting point for most. If strong encryption is required for moving large numbers of messages between applications without impacting messaging throughput then take a look at what Confidentiality policies can offer.
Keep those messages secure !