This presentation was originally presented at IBM TechCon 2020. In it we go through the various options in IBM MQ to protect both connections and message data using encryption focussing on the TLS and AMS features.
In this presentation we will be talking about protecting valuable message data when it is in your MQ infrastructure. We will look at where and how you can protect message data during its lifetime and the benefits/disadvantages of each.
We will look at both MQ and third-party technologies as MQ provides flexible options for how you can protect your data.
In the introduction section we will cover a few key topics and concepts for protecting data
In data at rest section we will discuss options for protecting data at rest
Once message data is created there are two main places that it can reside. At rest on your systems disk or memory and in transit while flowing between two destinations. There are different risks associated with leaving message data unprotected in each of these places.
For example leaving the message data unprotected at rest poses the risk that if an attacker gains access to your system either physically or virtually they could steal your message data or change it. For certain types of message data, policies or regulation may require the message data to be protected at rest. For example: PCI, HIPAA, etc
Leaving message data in transit unprotected could result in man in the middle attacks where the traffic is intercepted to either steal the data or modify it in transit..
Generally protecting data is costly and so protecting all data that flows through your network on lives on disks can create an unacceptable performance degradation.
As such sometimes it is ideal to protect only a subset of data in your network. But what data do you need to protect?
Some data has to be protected due to regulations around it, for example credit card data, health care data, other personal data
Some data you may want to protect because it’s leak or edit may cause damage to your company, for example if your company is working on a secret project to gain an edge in a market, having that information leaked so competitors can move into that area before you could cause issues.
Of course when protecting data there is a number of different ways we can protect data.
When protecting data at rest or in transit there are two forms of protection we can apply.
Integrity protection can provide 2 main protections:
Ensuring that the message data was not changed since it was created.
Ensuring that the message data has arrived from the expected person.
It is generally quicker than encryption and useful if the data is not secret and so could be viewed but absolutely cannot be changed or come from an invalid source.
Encryption protection ensures that only intended recipients can read the contents of the message data
Both require a pre-exchange of information in order to provide the protection. Commonly referred to as the keys.
Even though encryption is a broad topic we can subdivide it one more time to the two major forms of encryption that are used.
Symmetric Key
Single secret key
Relatively fast
Poses key distribution challenges when faced with large numbers of senders/receivers
The key has to be known by the sender and receiver
Asymmetric Keys
Private & Public key pairing
Message encrypted with one key can only be decrypted by the other one
Slower than symmetric key cryptography
Asymmetric Keys can be used to solve the key distribution challenges associated with symmetric keys
In some places to provide encryption protection BOTH are used together.
Integrity protection is commonly provide using asymmetric encryption.
A one way hash function will be used to create a hash of the plaintext being sent, this hash is then signed with the private key of the sender.
The plaintext and signed hash are sent to the recipient who decrypts the signed hash, rehashes the plaintext they got and compares the two.
If the hashes match then it came from the owner of the public key (the sender) and was not altered in transit.
In this section we will be focusing on what options there are for protecting data that is at rest on your system.
One option is to encrypt the entire disk. This will ensure that messages sat on a queue or disk are protected in the event that the disk is stolen.
As long as the disk encryption software is invisible to applications then it may work with IBM MQ. For example, Data Set encryption on Z is invisible to applications and encrypts/decrypts data depending on a system policy.
If the method of disk encryption requires the software to provide a key or interact with an API in order to gain access to data then it will not work with IBM MQ.
A benefit to disk encryption is that any message data on the physical disk could not be read if the disk was physically stolen. However disk encryption does not prevent data being stolen if an attacker gains access to the system and does not prevent administrators or other users from accessing the data as long as they are on the system when they do it.
It also adds a performance impact because every disk call requires a encrypt or decrypt operation before the data is provided to application, this includes configuration reading, logging and all messages regardless of content.
Data Set encryption is a feature of z/OS where encryption is provided on specific data sets invisibly to applications. When an application asks to read/write from a protected dataset the data set encryption policy will intercept the read/write in order to add or remove encryption protection as defined in the policy.
Support for this has been added in 9.1.4 for active logs and page sets as well as BSDS CSQINP and Archive logs.
Another option is to protect just the message data. This has benefits over disk encryption as it means that costly encrypt and decrypt operations are not performed on every IO write. Additionally if message data is protected on disk then even if an attacker gains access to the system they will not be able to read the message data unless they have the key.
This system also works because it will be invisible to MQ. We do not parse message data so if the data is encrypted or plain text will not matter. However it also offloads the responsibility to the application to perform the encrypt/decrypt and so requires applications changes or integrations of a third party application into your applications in order to work. As well as integrating libraries you also have to exchange secret data ahead of time (e.g. the symmetric keys used to encrypt the data).
By also pushing the encryption/decryption to the applications you also need to ensure that applications system will have the capacity to perform the cryptographic operations.
But what if you can’t make a change to your application? Or you don’t want another third party app/library? Or you can’t put encryption operations on your client applications? MQ has a solution…
IBM MQ Advanced Message Security (or AMS) is MQ’s answer to message data protection.
It provides all the benefits as discussed in the previous slides with some improvements in the areas identified as disadvantages.
Unfortunately it does not come without it’s own disadvantages, namely that it still requires an exchange of secret information (this time certificates) and an advanced license. Additionally although it does not require changes to the applications it does require additionally MQ objects to be defined on AMS Queue Managers.
The basis for configuring AMS on queue managers is to define a policy object for each queue that will handle messages that need to be protected. The Policy object needs to be defined on the first and last queue that the message will be in your MQ system.
Each policy object details the minimum level of protection that should be placed on a queue object, for example if the first policy says the messages are to be protected with AES128 then the last policy must allow AES128. If it is set to AES256 it will cause an error.
Policies support two different types of protection. Encryption and Integrity. For encryption protection you must also supply who the intended recipients are. For Integrity protection you must supply who is allowed to have signed the message.
The default protection in AMS is that client applications will handle the protection/deprotection of message data.
However if you do not want the client applications to perform AMS operations you can opt to move the protection to the Queue Manager.
A downside to this is that in the first jump from App to Queue Manager the message data will not be protected. As such other protection should be applied for the message while it is in transit.
Added in 9.1.3 for z/OS queue managers the capability to add or remove AMS protection on a queue manager to queue manager boundary was added. This is useful for times when there is a difference in requirement on a organisational boundary.
Distributed queue managers do not have this functionality but there is a statement of direction saying we will add it in the future.
The control for this is on channel objects the SSLPROT property can be configured to remove or apply AMS protection as necessary.
To implement AMS in client applications no changes to the application is required.
Instead activation an application for AMS is performed by supplying a environment variable pointing to a configuration file. This file contains details of the key store and certificate to use for AMS.
When an IBM MQ application sees that a queue has a policy defined on it, it will look for the key store configuration file automatically in order to perform AMS operations.
AMS protection works by combining Asymmetric encryption and symmetric encryption.
First we will generate a symmetric key and encrypt the message data with that key. We also add a PDMQ header to the message so we know this message contains protected data.
The protected message data is added to a PKCS#7 envelope and attached to the message.
We also protect the symmetric key we used to encrypt the message with the public keys of all intended recipients. These protected keys are then also attached to the PKCS#7 envelope.
The whole message is then sent to the queue.
When an application wants to get the message it will use it’s private key to retrieve the symmetric key and then use the symmetric key to retrieve the message data.
By default the same set of operations as discussed before are performed on every message.
This means in the case that 6 messages are sent we have to perform 18 cryptographic operations to protect the messages and a further 12 to decrypt the messages. This can be costly for performance but there is a way we can improve the performance using key reuse.
By setting key reuse to a number greater than 1 we will reuse the same symmetric key. For the first message the process is the same but then we remember the symmetric key for the next 4 messages.
With a remembered symmetric key we can cut the number of cryptographic operations as we can reuse the symmetric key to quickly encrypt/decrypt message data.
For the same 6 messages the number of cryptographic operations drop from 30 to 18.
If you set key reuse to large numbers then you get a better performance improvement at the loss of security. With message data being protected by the same key if that key is cracked then an attacker could use that key to read the messages.
In this section we will talk about what options there are for protecting data in transit
If you have protected your message data and it is protected throughout it’s lifetime then as it traverses through your network it will retain that protection.
This will meet your protection in transit but may cause some issues around detecting when a message was tampered with. For example, if a message does get tampered with during it’s traversal from Client A to B then you will only pick that up at Client B. If it had to go through 100 nodes to get there then which one tampered with it?
Additionally, protected message data will not protect the whole message? Message headers or properties could still be tampered with or a message could be rerouted by a man in the middle attack.
The more common approach for protecting data in transit is to use TLS.
IBM MQ has supported TLS for a number of versions and continues to add new features and improvements to our TLS enhancement even to this day.
With TLS you can secure your data both to ensure that it is not edited in transit and that prying eyes cannot view it. If data is edited in transit then MQ will detect this and reject the tampered data. This is a benefit over just using protected data as you will be able to see exactly which hop is open to data tampering.
Additionally MQ supports using TLS as an authentication method so you can ensure that clients connecting to you are valid clients and additionally that your clients are connecting to expected servers (not a man in the middle).
The downside to TLS is that it does require certificate management and the exchanging of certificates to work. This is a common pitfall for customers as it is not a single action. Certificates expire and when they do it can cause outages, renewing certificates also requires downtime in order for queue managers or applications to use the new certificates.
IBM MQ supports TLS 1.2 and TLS 1.3 CipherSpec by default, older CipherSpecs can be enabled but are disabled by default due to being weak.
Each queue manager and client must have a key store that contains certificates. What certificates need to go in depends on what purpose the queue manager or client is performing. If a queue manager is acting as a server it must have both the certificate and private key for that certificate available to it. If it is a client application or queue manager acting as a client then it must trust the queue manager it is connecting to by containing the certificate of the queue manager in it’s trust store.
On Distributed IBM MQ uses the CMS format key store which combines both trust store and key store. On Z and IBM I we use the platform key store (RACF).
Once the certificates have been exchanged to enable TLS communication a channel object must be edited to supply a CipherSpec in the SSLCIPH value of the channel. If you are using a specific CipherSpec this same one must be set on the other channel. Now when the channels start they will use TLS communications.
Setting a specific CipherSpec was the standard way of enabling TLS on IBM MQ up until 9.1.2. However this is not the industry standard of how TLS communications should work. The normal way of operating is that the TLS client and TLS server communicate a list of CipherSpecs they support and then the TLS handshake process choses one from the list that both support and is the highest priority.
In 9.1.2 and 9.1.4 we added Alias CipherSpecs which begin to operate IBM MQ in the industry standard. By setting an Alias CipherSpec like ANY_TLS12_OR_HIGHER you tell the channel to use any CipherSpec that is in TLS 1.2 or above.
If you need granular control over which CipherSpec needs to be used you can still set the client side to use a specific CipherSpec and leave the server side as a broader alias CipherSpec. However you should not do this the other way as it likely will not work.
A benefit of using a alias CipherSpec on your server channels is that if the client decides to move up to a different CipherSpec for whatever reason then the only change that needs to be made is on the client side. You no longer have to co-ordinate with the server to make the change there as well.
In this case we moved from TLS 1.2 to a specific TLS 1.3 CipherSpec.
Of course if you don’t want Granular control then you can set Clients to a matching Alias CipherSpec and then let MQ figure it out.
As stated before though, don’t set the Client to an Alias CipherSpec and the server to a specific CipherSpec. This will not work as any users of .NET will tell you.
By configuring the clients to connect with their own certificate you can have the server authenticate that it trusts the client trying to connect.
With IBM MQ as well you can enforce that clients connecting must supply a valid, trusted certificate using the SSLCAUTH setting.
Additionally you can further filter to make sure that the certificate received either on the client side or server side matches a particular Distinguished name to ensure you have connected to where you expect. On the Server side you can also use Channel Authentication rules to filter further on the issuer.
Finally, while the default for Distributed MQ is to store certificates and private keys in a file on the system disk you can also configure IBM MQ to securely store these private keys in PKCS#11 devices instead.
If you don’t want to configure IBM MQ Queue Managers to be available on the outside network or only want particular routes to be secured then using a secure gateway or MQIPT may be a solution as well.
You can configure MQIPT or secure gateway to be invisible to MQ and automatically convert communications into TLS secured communications.
Additionally if you want to secure your firewall so that only HTTPS traffic can enter then you can use MQIPT to convert MQ traffic into HTTP or HTTPS traffic and then later convert it back invisibly to MQ.
SOAP is also supported
Finally as of 9.1.5 MQIPT supports PKCS#11 as a place you can store your certificates and private keys. However this is a MQ Advanced feature and requires a license as such.
No Notes
In conclusion deciding on whether you need to protect your message at rest and in transit or just one of those is up to you. We looked at each in turn and the advantages and disadvantages of each solution.
