PGP (Pretty Good Privacy) is a robust encryption protocol used to secure digital communication by encoding messages in a way that only intended recipients with the corresponding decryption key can read. Additionally, PGP allows users to sign messages cryptographically, verifying the sender’s identity and ensuring the message’s integrity hasn’t been compromised in transit.

In SAP Integration Suite (IS) oe of the most common and looked up to technique is PGP Encryption/Decryption and Signing/Verifying. I will try to keep this blog concise in information and detailed in understanding.

Lets get the terminologies out

Simplest way to understand PGP terminologies is understanding 3 things:
a) Keypair
b) Encryption
c) Signing
on top of these we extend three more terms/phrases:
a) Primary Key
b) Sub Key
c) Keyring

Keypair: As name suggest is a pair of keys. One is public key which you can handover to external parties who will be communicating with you or sending data. Other is private key which you (or your application) keep to yourself.

Encryption: Encryption is just a process to jumble and tranform a readble message/file into an generally unrecognizable format. It done through a program which is a group of functions, which takes a message as input and then generates a jumbled output.

Signing: Signing in context of privacy is basically a set of code block attached to original message (which may or may not have to be encrypted) which is recognizable to only certain set of parties.

To string the three terms together:
“A keypair consists of a Public and Private key. Private key is kept secret, while public key is shared. Encryption is a way to protect a content by making it unreadable to unauthorized parties. Signing is process of adding authenticity to a message or document by attaching your signature to it.”

Technical Process of Encryption and Signing

You need three things for encryption - a key, an algorithm and the message. In business processes you need always a public key when you want to encrypt a message. Sender uses other party’s public key to encrypt a message. This public key will be given to you by other party as they will be holding the corresponding private key which will be used to decrypt the message you send.

To Sign a message as well you need the same three things. However the way you achieve is this is a bit different when doing for real business scenarios.

In real business scenarios:

You always encrypt a message using a public key.
You always sign a message using a private key.

That brings us to the other three terms we referred earlier:
1. Primary Key or Master Key- This is the key which generated immediately when you generate a new key pair. This primary key is used to certify other keys. A master key can certify, encrypt or sign a message. At mimimal it has certifying authority to authenticate other keys.
2. Sub key - A subkey is derived from a primary key for specific purpose(s). You can generate a sub key specifically for encryption and another one for signing for added security.
3. Key ring - Just as your building watchman holds a metal ring which contains many keys hooked on it, similarly a key ring is a group of keys both public and private. You can have one keyring for a set of users and another one for different set of users.

Below diagram shows the relationship between each of the term we have discussed so far:

Figure01: Relationship between Key ring, primary key, key pair, and sub keys

Understanding the process exchange

Below is how the complete flow works:

Figure02: PGP Process of Encryption & Signging and Verifying & Decryption

A few things to note here:
1) Overall we see two sets of keypairs in above diagram, one pair for sender and one pair for receiver.
2) In real world scenario a receiver will share different public keys to different senders while using different verifying keys (public) to idetify a sender.
3) Also, the sender will keep one (or many) private key to sign all the documents and will use different differnt public keys to encrypt them per reciever.
4) So you can have a combination of any number of private keys and any number of public keys on your side depending on how you want to deal with various customers. This is what results in creation of keyrings.
5) Technically one or both of Encryption and Signing processes can be optional. Howerver in Integration Suite, only Signing process is optional.

Integration Suite Configuration

In integration suite you use encryptor pattern to deal with PGP encryptions.

Figure03: Integration pattern object for Encryption

So you have various fields to play with and you check out below link to understand what each one does. Here, we look at two key fields when sending data, Encryption and Signing.

For Encryption and Signing:

Figure04: Encryption available Setting part 1

if you selected the option "that your"including against signature, then there would one more field available for configuration as shown below:

Figure05: Encryption available Setting part 2

For Decryption process in Integration Suite, you have only one option whether you want to receive “only” signed documents or “unsigned” documents too. Based on you selection you have to provide the additional details about the key against which you will verify the document, as shown below:

Figure06: Decryption available Setting

Note: if you are wondering why we dont have to provide any reference to decryption key, the reason for that is: there is a reference to the “User ID” in encrypted message based on the public key used for encryption. The same “User ID” is looked up in receiver’s keyring to fetch the corresponding private key (mapped to same User ID) to decrypt the message. Hence, no reference is required.

Generating keys:

Tools used:

1) Kleopatra
2) gpgFrontEnd

In gpgFrontEnd, you can generate keys by refering official documentation here.

For our testing I have generated two sets of key pair:
Set 1: DemoPartyA : Public (to be shared with PartyB for verifying signature) and Secret for signing.
Set 2: DemoPartyB : Public (to be shared with PartyA for encryption) and secret for decryption.

Lets say, DemoPartyA is “Sender” and DemoPartyB is the “receiver” of secure document exchange. Now if go back to Figure02 and you will understand below steps in sequence:

  1. DemoPartyB “public key” will be used by DemoPartyA for encrypting the payload.
  2. DemoPartyA “private key” will be used by DemoPartyA for Signing the document.
  3. DemoPartyA “public key” will be used by DemoPartyB for verifying the signature on the document.
  4. DemoPartyB “private key” will be used by DemoPartyB for decryption of the document.

Based on above four observation this will be our configuration in Integration suite:

In Encryptor:
1. Encryptor User ID from Key ring: DemoPartyB (Looks for public key of DemoPartyB)
2. Signer User ID from Key ring: DemoPartyB (Looks for private key of DemoPartyA)

If we pass the payload from this encryptor step to a decryptor then:

In Decryptor:
1. Signer User ID from Key ring: DemoPartyA (Looks for public key of DemoPartyA)

Note:
This is where Subkeys are important (though optional for explanation’s sake here) You can create a separate subkey for Signing and Encryption and share corresponding public keys with 3rd party, keeping you original master key pair safe and secure. This also give you flexibility as your secure exchange partner number grows. You can keep generating subkeys for each of them.

Set Up in Integration Suite

Import the Keypairs for both parties in your integration suite by navigating to Monitor -> PGP Keys ->

We will use two iFlows:

01. Encryption Flow: This takes in a payload through an HTTPS service and used encryptor for PGP encryption and responds with encrypted and signed message.

Configuration for encryptor

02. Decryption Flow: This iFlow takes in an encrypted payload through the HTTPS service and uses a “decryptor” to verify signature and then perform the decryption. In the end it returns the decypted payload to the caller.

Configuration for decryptor

End to End Testing

Sending a readable payload to HTTP(S) endpoint of iFlow#1 for encryption and signing and it return a PGP Encrypted and Signed Message.

We have encrypted the text “hello world” using the Encryptor where we have encrypted payload using Public key of party B and Signed with private key of party A.

Now if we want to verify and decrypt this payload, we will use second iFlow:

Playround with Key rings - Ideas

Hopefully, now you understand the most of the PGP related topic, if you didnt already. However, do not stop here. Belwo are a few play around scenarios you can test.

  1. As you can import public and private keys separate in PGP Key store in Integration Suite. Try importing only public key and not private key for party A. Leave the iFlow configuration as it is.
  2. Try importing only private key for party B. See which error you get.
  3. If you happen to understand the concept of key ring and subkeys, then you can have more public private key with same user ID, give that a try through some GPG tool. Else that will be a blog for future.

With that I look forward to your comments and feedback. See you in next blog.

Note: This blog is part of OSC (One shot configuration) series. The aim is to arm with knowledge so that you can configure the channels in “one shot”.