Native PGP Support for Sterling B2B Integrator

8 min readMar 17, 2022

What is PGP?

Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, files, etc.

PGP is a hybrid cryptosystem. When a user encrypts plaintext with PGP, PGP first compresses the plaintext. Data compression saves modem transmission time and disk space and, more importantly, strengthens cryptographic security.

PGP then creates a session key, which is a one-time-only secret key. This key is a random number generated from the random movements of your mouse and the keystrokes you type or use PGP tools like Symantec, GnuPG, WinGPG, etc. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient’s public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient.

Decryption works in the reverse. The recipient’s copy of PGP uses his or her private key to recover the temporary session key, which PGP then uses to decrypt the conventionally-encrypted ciphertext.

How did Sterling Integrator leverage PGP before 6.1?

In IBM Sterling B2B Integrator (B2Bi), the cryptographic operations are achieved by sending the files/data with the help of a command line adapter to an External PGP software that is typically hosted on a different server for processing, and then back to B2Bi. As we are focusing more on Native PGP support, so please refer to the details here for setting a command-line adapter to interact with any PGP server like Symantec, GnuPG, etc.

From Sterling B2B Integrator (B2Bi) 6.1 onwards, we have introduced support for Native PGP where these cryptographic operations are performed within B2Bi. We, from the core engineering team, used an open-source library The Bouncy Castle Crypto Package For Java to develop this solution.

This blog explores the capabilities of Native PGP and the steps to migrate from External PGP to Native PGP, and why should end users start using it more.

Native PGP vs External PGP

Main differences between External PGP using CLA2 adapter and Native PGP

Why should you choose Native PGP?

Easy Key Management for cryptographic operations: Customers can now create keys natively/check-in external keys in B2Bi, or import keys from secondary B2Bi instances.
Rich User Experience: The easy to use User Interface will now help end-users to easily manage the keys from one place in the B2Bi dashboard
No interdependency with the external components: Users can get away with the dependency on the CLA2 adapter for processing the file.
Support for external PGP Keys with B2Bi: Users can check in the external vendor’s PGP keys into B2Bi and use it for Native PGP processing.
REST APIs for Key Management: Customers can also use the REST APIs to perform CRUD operations, check-in of keys, and extract the key data (check-out).
Import/Export for all PGP keys: Sterling B2B Integrator dashboard & command-line utility can be used.
Dedicated PGP logging: In B2Bi from 6.1, we will have dedicated logging (debug, error (default), info)for PGP runtime cryptographic flows & key management for Native PGP.
Cipher Algorithm support at the system level: Users can now set the hashing and encryption algorithms at the system level. A list of supported algorithms can be referred from here
Compression algorithm support at the system level: Customer can choose the compression algorithm from ZIP, LIB, and BZIP2 (best performing and default), as well compression levels (BEST_COMPRESSION, BEST_SPEED, and UNCOMPRESSED from 6.1.1)
Security: Files remain within B2Bi, as the cryptographic operations are performed natively. Keys are now stored in the database in an encrypted format.
Compliance with industry security standards: Native PGP supports both NIST 800–131a and FIPS mode
PGP Migration Utility: A new migration utility has been introduced from B2Bi v6.1.1 onwards, which aims to update the Trading Partner accounts to modify 8-bit external key IDs to 16-bit Native PGP public key IDs, as Native PGP supports 16-bit key IDs for all cryptographic operations. Details can be referred from here
Performance: The engineering team performed some load testing, and the results were very positive, Native PGP outperformed PGP operations using the CLA2 adapter, in terms of throughput and CPU usage.

Native PGP capabilities

Ability to perform the following cryptographic operations on files:
- Encryption
- Encryption and Signing
- Signing
- Decryption
- Decryption and Verification
- Verification
Ability to set different hashing and encryption algorithms at the system level. Refer here for sets of supported algorithms.
Support key types RSA, DSA, and ElGamal (Post 6.1.1)with key strengths 1024, 2048, 3072, and 4096(only for RSA).
Support creation of native keys and check-in of keys from external vendors
Support read, update, delete and check out of Native (keys created using B2Bi out of the box Native PGP)and External (keys from external trusted partners) keys

Key management from the B2Bi dashboard

Please note that the user can search for any string pattern for the search functionality, and the query will return the corresponding matches.

Please note for the Public Key, users can check-in keys from external partners, the search will only display results for partner key types (not for natively created or checked-in secret keys)

Migration of keys from an external PGP server to B2Bi

Pre-requisites:

All inflight PGP file processing should be completed before starting the migration process, and Sterling Integrator should be UP & running

Generating a GPG key, refer to this page

2. Export Secret Keys from GPG & Import into B2Bi:

Import into B2Bi using the PGP Secret Key Check-in option (follow the screenshots below):

Click on Next to get the confirmation Page and Finish

3. Export Public Keys from GPG & Import into B2Bi:

4. Edit the existing PGP Server Manager profile, convert it to a Native profile by selecting the “Native PGP” option and clicking Next

Edit the secret maps to select the keys from the database, or add a new secret key-map as shown below

Click Next and Finish on the Confirm Page

This process allows migration to the native implementation

SFG(Sterling File gateway) trading partner’s having an 8 bit public key ID should be replaced with a 16-bit key ID. All other scripts and config data can be kept AS-IS.
Custom BPs in B2Bi that are used for cryptographic operations having an 8 bit key ID needs to be replaced with a 16-bit key ID. Any CLA2 entries in the BP will be ignored for Native PGP transactions.

Users are requested to follow the steps mentioned in the IBM knowledge center for creating business processes required for cryptographic flows (PGPPackageService & PGPUnpackageService)using the PGP keys, the document doesn’t detail those steps of creating a business process.

Using the REST APIs for Key Management

Customers can use the Swagger API documentation for PGP Key Management. These APIs are developed on Spring-boot, with Swagger UI (User Interface). Here are the services to create, read, update, and delete PGP Keys from B2Bi:

Default URL: http://<IP or Hostname>:<Liberty_port>/sfgapis/swagger-ui.html

Please note both the secret and public keys API are being deprecated, please refer to the IBM Knowledge Center documentation

Performance of GPG versus Native PGP in B2Bi

1.5KB File concurrent file transfer for inbound scenarios (Decryption) and outbound scenarios (Encryption) with Compression type **ZLIB**

1.5KB File concurrent file transfer for inbound scenarios (Decryption) and outbound scenarios (Encryption) with Compression type **NONE**

1.5KB File concurrent file transfer for inbound scenarios (Decryption) and outbound scenarios (Encryption) with Compression type **ZIP**

The graph above depicts the performance of GPG versus Native PGP for a smaller file size of 1.5kb.

Native PGP shows a reduction in CPU usage and an increase in the throughput for file processing.

Similar tests were carried out for larger file sizes (>1GB), and every time we noted a consistent increase in throughput for Native PGP compared to external PGP.

Note: Above results are from internal performance tests in a lab environment, the results may vary with the hardware/network configuration and on the cryptographic flow tested.

Conclusions

There are more than one reasons, end-users should slowly start migrating from external PGP servers (via B2Bi CLA2 adapters) to Native PGP, and the entire blog speaks on the same. In a nutshell:

Earlier all the keys were maintained in the user’s file system, and there were chances of getting misplaced, with Native PGP all the keys will be maintained within the B2Bi database in a secured encrypted format.
Key management now has become easy, using B2Bi dashboard & REST APIs.
Lower maintenance overhead as there is no dependency on external PGP software deployed in additional VM/hardware.
No hassles of setting up of Authentication+SSL as the entire cryptographic file operations takes place within the secured B2Bi environment.
Better performance compared to external PGP irrespective of file sizes.

References

If you found this blog helpful please give a clap and share with a larger community,

Cheers & Happy Reading!