IBM Sterling B2B Integrator and IBM Sterling File Gateway Developers

Native PGP Support for B2B Integration 6.1

By Maheshwari Raj posted 9 days ago

  

Introduction


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.

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.

From B2Bi 6.1 onwards, we have introduced support for Native PGP where these cryptographic operations are performed within B2Bi. The PGP keys are also stored within the database of B2Bi.

This blog explores the capabilities of Native PGP and the steps to migrate from External PGP to Native PGP.


Benefits of using Native PGP vs External PGP

To better understand the benefits, here are some key features of the new Native PGP support in comparison with the existing approach in B2Bi that uses External PGP solutions from other vendors:

 

Configuration Type  

Earlier Version of B2Bi 6.1 

Native PGP Support in B2Bi 6.1

Key Management  

Creation of keys are external to B2Bi. Created keys are stored in public or secret keyrings  in file system.  

Keys can now be created, and stored in B2Bi Database

PGP Server  

Uses external servers from other vendors (like GPG, Symantec, etc) to perform PGP operations i.e., encryption, decryption, compression, signing and verification.  

Uses Native PGP Implementation using Bouncy Castle library to perform PGP operations i.e., encryption, decryption, compression, signing and verification.  

PGP Server Manager Profile  

PGP Server Profile must be configured by supplying the GPG paths and key rings location on file system.
Also, we need to fetch the key ID and passphrase and add the secret key map.

PGP Server Profile must be configured by selecting the Native PGP type, for Secret key map we can select a key from the drop-down list. Reduces manual effort and errors while configuring the PGP Server profile

CLA2 Adapter Configuration  

Configuration of  CLA2 adapter with host, port and working directory.  

Since all the cryptographic operations are performed within B2Bi, there is no need for a CLA2 adapter and any script implementations. This change is expected to provide better performance for cryptographic operations.

Trading Partners Configurations in SFG  

Creation of Community, Trading Partners, Routing Channel Templates and Routing Channels.  
Key ID can be 8 digit or more

Same as existing. For Consumer Trading Partners, Key ID should be supplied as last 16 digits of its fingerprint 

File Processing

Outside B2Bi, remotely

Since file processing is done within B2Bi / SFG (Sterling File Gateway), it is easier to implement - there is no need of scripting to communicate with external PGP solutions

 


What’s new in Native PGP

  • PGP Key Management with B2Bi – Customers can now create keys natively/ check in external keys in B2Bi for cryptographic operations.
  • Documents are processed within B2Bi – Customers can get away with the dependency on CLA2 adapter for processing the file.
  • Support for external PGP Keys with B2Bi – Customers can check in the external vendors PGP keys into B2Bi and use it for Native PGP processing.
  • Rest APIs for Key Management – Customers can also use the REST API’s to perform CRUD, check in of keys and extract the key data.
  • Import/Export for all PGP keys – UI & Cmd Line
  • Dedicated PGP logging – In B2Bi 6.1, we have set a dedicated logging for PGP runtime flows & key management for both Native PGP and External PGP.
  • Cipher Algorithm support at system level – Customer can now set the hashing and encryption algorithms at system level.
  • Compression algorithm support at system level – Customer can choose the compression algorithm from ZIP, ZLIB and BZIP2.

 
Brief introduction to Native PGP capabilities
Native PGP capabilities

  • Perform the following cryptographic operations on files:
    • Encryption
    • Encryption and Signing
    • Signing
    • Decryption
    • Decryption and Verification
    • Verification
  • Can set different hashing and encryption algorithms at system level.
  • Support key types RSA and DSA 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 and External keys

 

Steps to migrate from GnuPG to Native PGP
Migrate the keys individually from GPG key rings to B2Bi Database

Pre-requisites:

All inflight PGP file processing should be completed before starting the migration process.


Migration process

Step 1: Export Secret Keys from GPG & Import into B2Bi

  • Export secret keys from GnuPG using the following command:
    “gpg –output <key Name>.asc | pgp | gpg --export-secret-key <KeyID / email ID>”
  • Import into B2Bi using PGP Secret Key Check in option (follow the screen shots below)

1.jpg

Click on GO! against “Check-in a new PGP Secret key”

2.png


Select the key file to be checked in, supply a key name and the key password

PGP3.png


Click on Next to get the confirmation Page and Finish


Step 2: Export public keys from GPG & Import into B2Bi

  • Export recipient’s public keys from GnuPG using command “gpg –output <key Name>.asc | pgp | gpg --export-key <KeyID / email ID>”
  • Import into B2Bi using PGP Public Key Check in option

 

4.jpg


Click on GO! against “Check-in a new PGP public key”

PGP5.png


Select the key file to be checked in and input a Key Name

6.jpg

Click on Next to get the confirmation Page and Finish.


Step 3: Update the PGP Server Manager Profile

Edit the existing PGP Server Manager profile

7.jpg

Convert it to a Native profile by selecting the “Native PGP” option and click Next

8.jpg

Edit the secret maps to select the keys from Database

9.jpg

Select the Secret Key. All keys that have been migrated from GPG and checked in as Secret key will get listed.              

Click on Save


10.jpg

Click Next and Finish on the Confirm Page

This process allows migration to native implementation:

  • Without having to change any SFG (Sterling Filegateway) configurations. All scripts and config data can be kept AS IS.
  • Without having to change any custom BPs in B2Bi that are used for cryptographic operations. Any CLA2 entries in the BP will be ignored for Native PGP transactions.

REST API’s for Key Management

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

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

11.jpg


Secret Key APIs

  • Create, Check-in, Get, Update, Delete
  • Get APIs:
    • Get All
    • Get with KEYID
    • Get with ObjectID

(Secret Key GET API with KEYID and ObjectID gets the actual Secret Key data)


12.jpg

Public Key APIs

  • Check-in, Get, Delete
  • GET APIs:
    • Get All
    • Get with KEYID
    • Get with ObjectID

(Public Key GET API with KEYID and ObjectID gets the actual Public Key data)

 

Pre migration, Post migration validation, impact to workload during migration

Pre migration, if the files have been processed using GPG, the encrypted or signed files look like the following: 




Post migration
, the Natively processed files will look like the following:


Security

 


Performance of GnuPG versus Native PGP in B2Bi



The graph above depicts the performance of GnuPG versus Native PGP.

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

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.


Conclusion

There are many advantages of using Native PGP in B2Bi as mentioned in this blog such as

  • Maintaining the PGP Keys within B2Bi Database
  • Leveraging Key management using B2Bi UI & REST APIs
  • Doing away with the dependency on 3rd party PGP vendors and CLA2 adapters – in turn better performance for cryptographic operations
  • Lower maintenance overhead as there is no dependency on external PGP software deployed in additional VM/hardware

 


#Featured-area-1
#Featured-area-3
#Featured-area-3-home
0 comments
69 views

Permalink