<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2826169&amp;fmt=gif">
Start  trial

    Start trial

      Fujitsu Enterprise Postgres on IBM LinuxONE delivers maximum data security for your organization, and CryptoCards are big part of the reason why. But what are CryptoCards, and how do I protect my organization's data with them?

      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.

      Fujitsu Enterprise Postgres
      Transparent Data Encryption
      without CryptoCard
      A server is required to store the keys
      Fujitsu Enterprise Postgres
      Transparent Data Encryption
      with CryptoCard
      Keys are stored in hardware

      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.

      Fujitsu Enterprise Postgres, openCryptoki and OpenSSL
      Diagram showing usage of openCryptoki and OpenSSL
      The server process using openCryptoki and OpenSSL

      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
      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_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
      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
      Sessions: 0/18446744073709551614
      R/W Sessions: 18446744073709551615/18446744073709551614
      PIN Length: 4-8
      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.

      Subscribe to be notified of future blog posts
      If you would like to be notified of our future PostgreSQL-related blog posts, fill the form here.
      We also have a series of technical articles for PostgreSQL enthusiasts of all stripes, with tips and how-to's.
      To start exploring, click the button below.


      Explore PostgreSQL Insider >

      Topics: Database security, Fujitsu Enterprise Postgres, How-to, Encryption, IBM LinuxONE

      Receive our blog

      Search by topic

      see all >

      Read our latest blogs

      Read our most recent articles regarding all aspects of PostgreSQL and Fujitsu Enterprise Postgres.

      Receive our blog

      Fill the form to receive notifications of future posts

      Search by topic

      see all >