CryptoCards — what are they, and how do they fit in with Fujitsu Enterprise Postgres?
In a nutshell, IBM CryptoCards are Hardware Security Modules (HSM) used to manage digital keys and that take data security to the next level. They are PCIe cards included in the IBM System Z family to provide functionalities such as key management, encryption/decryption, and random number generation.
They support a massive list of symmetric and asymmetric cryptography algorithms, and most impressively, they are validated by NIST at FIPS 140-2 Level 4 - the highest level of certification achievable for commercial cryptographic devices.
Firmware supported by IBM CryptoCard that ignite interest of security teams are EP11 (IBM Enterprise PKCS #11) and CCA (IBM Common Cryptographic Architecture). EP11 is a recent addition to IBM HSMs, and provides the de-facto industry standard PKCS #11 API, used by a wide range of applications created by different organizations. The CCA API has been around for several decades, and is well-suited for applications handling finance industry payments.
For LinuxONE™, there are enterprise-grade software/libraries/tools to support user space applications – libcsculcca, libica, openCryptoki to name a few.
Fujitsu's partnership with IBM leverages the advantage of IBM CryptoCard by integrating it with Fujitsu Enterprise Postgres. Fujitsu Enterprise Postgres on IBM LinuxONE™ supports Transparent Data Encryption, which seamlessly secures your data without requiring application changes. And with integration with IBM CryptoCard, the solution pushes data security to the highest level.
Transparent Data Encryption
without CryptoCard
Transparent Data Encryption
with CryptoCard
The illustrations above show how the keys are managed in Fujitsu Enterprise Postgres - without CryptoCard, users can secure data-at-rest using keys stored on a remote mounted volume, while with CryptoCard available, they can store the keys on a HSM. In layman terms: security is enhanced with HSMs, as the keys are stored on a separate hardware, not exposed in the operating system - that is, even to those applications which need data encryption/decryption.
Behind the scenes
In the background, Fujitsu Enterprise Postgres uses openCryptoki (in other words, industry-standard PKCS #11 interface) to store master keys on the HSM. It allows Fujitsu Enterprise Postgres to make use of CCA and EP11 firmware in CryptoCard transparently.
The PKCS #11 interface makes Fujitsu Enterprise Postgres able to handle new firmware in CryptoCard or even new key management systems.
As shown in the illustration above, the server process uses openCryptoki having relevant tokens per firmware in CryptoCard. It also makes use of OpenSSL to gain advantages of acceleration in data encryption/encryption.
Data encryption key is protected by a master encryption key, which in turn is protected by a secure key. The secure key is itself protected by a key stored in a HSM. Use of AES256 encryption algorithm, with added security of HSM-managed keys, makes it next to impossible for any malicious person to hack the data at rest. Even further, the HSM keys are never accessible directly in the operating system.
Let’s get our hands dirty
Our System Administrator made the following setup and shared the system with us:
- RHEL7-based VM on LinuxONE (z15)
- One CryptoCard (CEX7S) with CCA firmware
- Configured openCryptoki slot5 with CCA token and default user PIN set to ‘pass@123’
- Loaded keys in the HSM and configured default domain for the system
You can change user PIN at any time, even when that database is running, without any impact on running transactions.
To check the CryptoCard configuration, use the lszcrypt command:
[fepuser@zlfu0002]$ lszcrypt
CARD.DOMAIN TYPE MODE STATUS REQUEST_CNT
-----------------------------------------------------
00 CEX6C CCA-Coproc online 674
00.0000 CEX6C CCA-Coproc online 348
00.0001 CEX6C CCA-Coproc online 326
The result above shows that there is one card installed and two HSMs configured for use by this node. The notation of CARD.DOMAIN (first column) is to be read as CARD representing the physical card, and DOMAIN as the domain mapped to one of the HSMs on the card. There can be 85 domains in latest CryptoCard series.
[fepuser@zlfu0002]$ lszcrypt -b
ap_domain=0x0
ap_max_domain_id=0x54
ap_interrupts are disabled
config_time=30 (seconds)
poll_thread is disabled
poll_timeout=1500000 (nanoseconds)
The important parameter to see above is the domain 0x0, which signifies the default domain. It is important to know this information since this is the HSM on which the key allocated to us should be stored.
And checking the configuration of openCryptoki in opencryptoki.conf is also easy. To check token information in slot 5:
[fepuser@zlfu0002]$ grep –A 5 "slot 5" /etc/opencryptoki/opencryptoki.conf
slot 5
{
tokname=fujitsu
stdll = libpkcs11_cca.so
}
To confirm that the token is appropriately initialized, use pkcsconf:
[fepuser@zlfu0002]$ pkcsconf –t –c 5
Token #5 Info:
Label: fujitsu_enterprise
Manufacturer: IBM Corp.
Model: IBM CCA Token
Serial Number: 123
Flags: 0x880445 (RNG|LOGIN_REQUIRED|USER_PIN_INTIALIZED|CLOCK_ON_TOKEN|TOKEN_INITIALIZED)
Sessions: 0/18446744073709551614
R/W Sessions: 18446744073709551615/18446744073709551614
PIN Length: 4-8
Public Memory: 0xFFFFFFFFFFFFFFFF/0xFFFFFFFFFFFFFFFF
Private Memory: 0xFFFFFFFFFFFFFFFF/0xFFFFFFFFFFFFFFFF
Hardware Version: 1.0
Firmware Version: 1.0
Time: 2020072404181300
That’s pretty much we need to know to kick-start setting up Fujitsu Enterprise Postgres to use the CryptoCard-based secure keys.
Let’s proceed with setting up of a server instance.
First, create a default database using initdb command:
[fepuser@zlfu0002]$ initdb –D /home/pankaj/my_secure_pgDB
Then set up postgresql.conf to make use of CryptoCard, and start the server:
export PGDATA = "/home/pankaj/my_secure_pgDB"
[fepuser@zlfu0002]$ echo "keystore_location='/home/pankaj/mek_keystore'" >> ${PGDATA}/postgresql.conf
[fepuser@zlfu0002]$ echo "shared_preload_libraries='tde_z'" >> ${PGDATA}/postgresql.conf
[fepuser@zlfu0002]$ echo "tde_z.SLOT_ID=5" >> ${PGDATA}/postgresql.conf
[fepuser@zlfu0002]$ echo "tde_z.USER_PIN='pass@123'" >> ${PGDATA}/postgresql.conf
[fepuser@zlfu0002]$ pg_ctl start –l logfile
In the configuration above, keystore_location points to the directory where metadata of secure keys is stored. However, by default there is no key generated. In order to start using Transparent Data Encryption with CryptoCard, generate a master key and open it.
[fepuser@zlfu0002]$ psql –d postgres –c "SELECT pgx_set_masterkey('pass@123');"
[fepuser@zlfu0002]$ psql –d postgres –c "SELECT pgx_open_keystore('pass@123');"
While the pgx_set_masterkey function needs to be invoked only once, pgx_open_keystore needs to be invoked every time the database is started. To auto-open the keystore, we can either set tde_z.USER_PIN in postgresql.conf or pass the "-u userPin" option to pg_ctl.
And the final step is to create a tablespace whose data (that is, data in any table created in this tablespace) will be secured using the AES256 algorithm while using CryptoCard:
psql> CREATE TABLESPACE secure_tablespace
psql> LOCATION '/home/pankaj/secure_tablespace_folder'
psql> WITH (tablespace_encryption_algorithm='AES256');
psql> CREATE TABLE secure_tbl ( id serial, sensitive_data text )
psql> TABLESPACE secure_tablespace;
After this point, any data in the table secure_tbl is secured. All disk files corresponding to the table above will be encrypted.
Note last but not least that developers and administrators will appreciate equally that there is absolutely no changes required in SQL commands - they will work as is, and Fujitsu Enterprise Postgres at the backend along with CryptoCard will ensure that the data is secure on disk.
Wrapping up
This is all that is required in the context of setup. Because Fujitsu Enterprise Postgres understands the complexities of the production environment – ranging from backup needs, standby setup, multiple CryptoCards as well as multiple domains, they are all supported as well.
What's next?
Watch this space for our next blog touching on each of these topics in detail. For information until then, contact us at enterprisepostgresforibm@fujitsu.com.
To start exploring, click the button below.
