MQ

Hi Peter,

> Is there anyway to make the MQ Client work if the stash file is located in some other location?
Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).

> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?
sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).

> Other than relying on folder permissions, what else can be done?
Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.
This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-files
This page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windows

Let me know if this helps!

Hi Rob,
Thanks for the info, I was not yet aware of this. So yes its a step in the right direction to allow this to work without a stash file. It looks like the stash file can be replaced with an encrypted password along with the key used to encrypt that password.  So we've traded a stash file that must not be compromised to the key used to encrypt/decrypt the password that must not be compromised. 

Rob wrote>> "You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key."

So the fact that the encrypt/decrypt key can live somewhere else is the improvement over the stash file that must be co located with the keystore. OK, that is a little better, a little more complicated for the bad actor. I did not understand this part: "....without knowing how to go from initial key -> encryption key."

Isn't the initial key the same as the encryption key the same as the decryption key? I guess I don't understand the details about this key yet. What kind of key? This key file(?) must be available to runmqicred at set up time and the same file must be available to your MQ app at runtime to allow access your certificate keystore?

I don't find documentation on the runmqicred command in the 9.3 Knowledge Center. I see multiple references to "the IBM MQ Password Protection System". Is there an article or presentation that describes this system?

Hi Peter,

> Is there anyway to make the MQ Client work if the stash file is located in some other location?
Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).

> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?
sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).

> Other than relying on folder permissions, what else can be done?
Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.
This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-files
This page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windows

Let me know if this helps!

Hi Rob,
Thanks for the info, I was not yet aware of this. So yes its a step in the right direction to allow this to work without a stash file. It looks like the stash file can be replaced with an encrypted password along with the key used to encrypt that password.  So we've traded a stash file that must not be compromised to the key used to encrypt/decrypt the password that must not be compromised. 

Rob wrote>> "You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key."

So the fact that the encrypt/decrypt key can live somewhere else is the improvement over the stash file that must be co located with the keystore. OK, that is a little better, a little more complicated for the bad actor. I did not understand this part: "....without knowing how to go from initial key -> encryption key."

Isn't the initial key the same as the encryption key the same as the decryption key? I guess I don't understand the details about this key yet. What kind of key? This key file(?) must be available to runmqicred at set up time and the same file must be available to your MQ app at runtime to allow access your certificate keystore?

I don't find documentation on the runmqicred command in the 9.3 Knowledge Center. I see multiple references to "the IBM MQ Password Protection System". Is there an article or presentation that describes this system?

Hi Peter,

> Is there anyway to make the MQ Client work if the stash file is located in some other location?
Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).

> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?
sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).

> Other than relying on folder permissions, what else can be done?
Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.
This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-files
This page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windows

Let me know if this helps!

Hi Rob,
Thanks for the info, I was not yet aware of this. So yes its a step in the right direction to allow this to work without a stash file. It looks like the stash file can be replaced with an encrypted password along with the key used to encrypt that password.  So we've traded a stash file that must not be compromised to the key used to encrypt/decrypt the password that must not be compromised. 

Rob wrote>> "You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key."

So the fact that the encrypt/decrypt key can live somewhere else is the improvement over the stash file that must be co located with the keystore. OK, that is a little better, a little more complicated for the bad actor. I did not understand this part: "....without knowing how to go from initial key -> encryption key."

Isn't the initial key the same as the encryption key the same as the decryption key? I guess I don't understand the details about this key yet. What kind of key? This key file(?) must be available to runmqicred at set up time and the same file must be available to your MQ app at runtime to allow access your certificate keystore?

I don't find documentation on the runmqicred command in the 9.3 Knowledge Center. I see multiple references to "the IBM MQ Password Protection System". Is there an article or presentation that describes this system?

Hi Peter,

> Is there anyway to make the MQ Client work if the stash file is located in some other location?
Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).

> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?
sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).

> Other than relying on folder permissions, what else can be done?
Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.
This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-files
This page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windows

Let me know if this helps!

Hi Rob,
Thanks for the info, I was not yet aware of this. So yes its a step in the right direction to allow this to work without a stash file. It looks like the stash file can be replaced with an encrypted password along with the key used to encrypt that password.  So we've traded a stash file that must not be compromised to the key used to encrypt/decrypt the password that must not be compromised. 

Rob wrote>> "You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key."

So the fact that the encrypt/decrypt key can live somewhere else is the improvement over the stash file that must be co located with the keystore. OK, that is a little better, a little more complicated for the bad actor. I did not understand this part: "....without knowing how to go from initial key -> encryption key."

Isn't the initial key the same as the encryption key the same as the decryption key? I guess I don't understand the details about this key yet. What kind of key? This key file(?) must be available to runmqicred at set up time and the same file must be available to your MQ app at runtime to allow access your certificate keystore?

I don't find documentation on the runmqicred command in the 9.3 Knowledge Center. I see multiple references to "the IBM MQ Password Protection System". Is there an article or presentation that describes this system?

Hi Peter,

> Is there anyway to make the MQ Client work if the stash file is located in some other location?
Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).

> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?
sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).

> Other than relying on folder permissions, what else can be done?
Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.
This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-files
This page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windows

Let me know if this helps!

Rob,

You mentioned you were going to write a blogpost on this topic. Is there any more info to share?

I'm playing around with this. Running the same password into runmqicred on the same MQ Client install gives a different encrypted result each time. This was surprising to me - I assumed same input would produce the same output each time. Using any one of those multiple encrypted outputs (again, all for the same exact input password) worked. Altering even one character in any of them caused it to fail, as expected. I assume the MQ Client install is keeping some internal list of results for every invocation of runmqicred? Where? I assume/hope securely.  In a Redistributable MQ Client install, what happens the next "upgrade" where we delete the entire folder structure of the old version and drop the new version - I'm guessing we have to go thru the runmqicred exercise again for each keystore referenced by that install? Does redoing the runmqicred need to occur anytime any type of MQ upgrade occurs, even the in place upgrades?

Hi Rob,
Thanks for the info, I was not yet aware of this. So yes its a step in the right direction to allow this to work without a stash file. It looks like the stash file can be replaced with an encrypted password along with the key used to encrypt that password.  So we've traded a stash file that must not be compromised to the key used to encrypt/decrypt the password that must not be compromised. 

Rob wrote>> "You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key."

So the fact that the encrypt/decrypt key can live somewhere else is the improvement over the stash file that must be co located with the keystore. OK, that is a little better, a little more complicated for the bad actor. I did not understand this part: "....without knowing how to go from initial key -> encryption key."

Isn't the initial key the same as the encryption key the same as the decryption key? I guess I don't understand the details about this key yet. What kind of key? This key file(?) must be available to runmqicred at set up time and the same file must be available to your MQ app at runtime to allow access your certificate keystore?

I don't find documentation on the runmqicred command in the 9.3 Knowledge Center. I see multiple references to "the IBM MQ Password Protection System". Is there an article or presentation that describes this system?

Hi Peter,

> Is there anyway to make the MQ Client work if the stash file is located in some other location?
Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).

> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?
sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).

> Other than relying on folder permissions, what else can be done?
Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.
This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-files
This page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windows

Let me know if this helps!

Rob,

You mentioned you were going to write a blogpost on this topic. Is there any more info to share?

I'm playing around with this. Running the same password into runmqicred on the same MQ Client install gives a different encrypted result each time. This was surprising to me - I assumed same input would produce the same output each time. Using any one of those multiple encrypted outputs (again, all for the same exact input password) worked. Altering even one character in any of them caused it to fail, as expected. I assume the MQ Client install is keeping some internal list of results for every invocation of runmqicred? Where? I assume/hope securely.  In a Redistributable MQ Client install, what happens the next "upgrade" where we delete the entire folder structure of the old version and drop the new version - I'm guessing we have to go thru the runmqicred exercise again for each keystore referenced by that install? Does redoing the runmqicred need to occur anytime any type of MQ upgrade occurs, even the in place upgrades?

Hi Rob,
Thanks for the info, I was not yet aware of this. So yes its a step in the right direction to allow this to work without a stash file. It looks like the stash file can be replaced with an encrypted password along with the key used to encrypt that password.  So we've traded a stash file that must not be compromised to the key used to encrypt/decrypt the password that must not be compromised. 

Rob wrote>> "You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key."

So the fact that the encrypt/decrypt key can live somewhere else is the improvement over the stash file that must be co located with the keystore. OK, that is a little better, a little more complicated for the bad actor. I did not understand this part: "....without knowing how to go from initial key -> encryption key."

Isn't the initial key the same as the encryption key the same as the decryption key? I guess I don't understand the details about this key yet. What kind of key? This key file(?) must be available to runmqicred at set up time and the same file must be available to your MQ app at runtime to allow access your certificate keystore?

I don't find documentation on the runmqicred command in the 9.3 Knowledge Center. I see multiple references to "the IBM MQ Password Protection System". Is there an article or presentation that describes this system?

Hi Peter,

> Is there anyway to make the MQ Client work if the stash file is located in some other location?
Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).

> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?
sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).

> Other than relying on folder permissions, what else can be done?
Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.
This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-files
This page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windows

Let me know if this helps!

Rob,

You mentioned you were going to write a blogpost on this topic. Is there any more info to share?

I'm playing around with this. Running the same password into runmqicred on the same MQ Client install gives a different encrypted result each time. This was surprising to me - I assumed same input would produce the same output each time. Using any one of those multiple encrypted outputs (again, all for the same exact input password) worked. Altering even one character in any of them caused it to fail, as expected. I assume the MQ Client install is keeping some internal list of results for every invocation of runmqicred? Where? I assume/hope securely.  In a Redistributable MQ Client install, what happens the next "upgrade" where we delete the entire folder structure of the old version and drop the new version - I'm guessing we have to go thru the runmqicred exercise again for each keystore referenced by that install? Does redoing the runmqicred need to occur anytime any type of MQ upgrade occurs, even the in place upgrades?

Hi Rob,
Thanks for the info, I was not yet aware of this. So yes its a step in the right direction to allow this to work without a stash file. It looks like the stash file can be replaced with an encrypted password along with the key used to encrypt that password.  So we've traded a stash file that must not be compromised to the key used to encrypt/decrypt the password that must not be compromised. 

Rob wrote>> "You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key."

So the fact that the encrypt/decrypt key can live somewhere else is the improvement over the stash file that must be co located with the keystore. OK, that is a little better, a little more complicated for the bad actor. I did not understand this part: "....without knowing how to go from initial key -> encryption key."

Isn't the initial key the same as the encryption key the same as the decryption key? I guess I don't understand the details about this key yet. What kind of key? This key file(?) must be available to runmqicred at set up time and the same file must be available to your MQ app at runtime to allow access your certificate keystore?

I don't find documentation on the runmqicred command in the 9.3 Knowledge Center. I see multiple references to "the IBM MQ Password Protection System". Is there an article or presentation that describes this system?

Hi Peter,

> Is there anyway to make the MQ Client work if the stash file is located in some other location?
Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).

> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?
sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).

> Other than relying on folder permissions, what else can be done?
Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.
This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-files
This page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windows

Let me know if this helps!