IBM Content Manager OnDemand v10.5.0.7 and GSKit support for Post-Quantum Cryptography

Introduction

If you are installing a new instance of Content Manager OnDemand, and have upgraded to the latest IBM Global Security Kit, you need to be aware of a new and currently undocumented feature that silently breaks CMOD from using encrypted ports. Other products that rely on the IBM GSKit (DB2, Tivoli Storage Manager / Spectrum Protect) may also be affected.

What is the IBM Global Security Kit ("GSKit")?

The IBM Global Security Kit is a cryptographic library used by a number of IBM products to improve security by providing cryptographic functions.

Background

Quantum Computing has the potential to disrupt IT security by making it feasible to crack the current state-of-the-art in encryption technology. Recently, cryptographic libraries have started to implement 'post quantum' computing ("PQC") methods -- that is, encryption that is resistant to the types of attacks that quantum computing enables. These changes are being made out of an abundance of caution, as there are no current encryption methods at risk of being cracked by state-of-the-art quantum computers.

Changes

If you attempt to use recent FixPacks (v8.0.55.28 or v8.0.55.31) of the IBM GSKit with Content Manager OnDemand v10.5, you MAY encounter frustrating issues relating to configuring CMOD to use SSL/TLS certificates.

These are due to the addition of PQC methods, and, unfortunately, a poor decision to enable these methods by default (without notifying end users) and making no updates to the available documentation.

What has changed?

Starting in GSKit version AFTER 8.0.55.28, any NEW key databases (.kdb) that are created are protected by PQC methods.

What's the problem?

IBM CMOD v10.5 doesn't support using these new methods for protecting key databases.

What's the error message?

There is no error message. CMOD starts up normally, without an error message or ANY indication that something is wrong.

What are the symptoms?

Attempting to connect to CMOD on the encrypted port fails silently.

That sounds frustrating.

That's not a question, but yes, it is.

How do I know I'm affected?

You configure CMOD to communicate over SSL/TLS, but it doesn't work and produces no error messages like failed logins.

Checking your operating system's diagnostic tools like netstat -tlnp shows the ssl port as open/listening.

Attempts to connect to the encrypted port with openssl s_client or ncat -ssl returns NOTHING. (No error, just no response.)

Using the arssockd -I ARCHIVE -p option when SSL_USE_CLNT_SSL=1 is set in ars.ini results in a failed connection.

Checking your KeyDB with gsk8capicmd_64 -cert -verify produces 'OK'.

If you run a server trace on arssockd, you will find a return code 407 from GSKit also known as GSK_ERROR_BAD_KEYFILE_LABEL.

Solution

When creating the key database, use the '-pqc false' option, in order to use the older method. This issue is not resolved by the latest CMOD Fixpack (v10.5.0.8) but the documentation has been updated: Setting up SSL with Windows Clients

In order to generate the key database WITHOUT Post-Quantum Cryptographic methods, add -pqc false to the GSKit -keydb -create command:

 gsk8capicmd_64 -keydb -create -db ars-ssl.kdb -genpw -stash -pqc false

In this command, this is a description of the various options:

keydb

This tells the GSKit that we're going to perform an operation on a key database.

create

We want to create a new key database.

db

Specifies the name of the key database to create.

genpw

Automatically generate a password to protect the contents of the key database.

stash

Generate a stash file containing the password, stored in an obscured way.

pqc

This option determines if Post-Quantum-Computing methods are used. We are choosing 'false' to disable PQC methods.

If you created a key database with the upgraded GSKit version, the key database for the client will need to be replaced with a 'non-pqc' key database as well. Then proceed as normal with adding Root and Intermediate Certificates, generating your certificate request, and 'receiving' your signed certificate.