SAP Cloud Integration: Understanding PKCS #7/CMS Encryptor

SAP Cloud Integration (CPI) provides functionality to automatically encrypt a message with
PKCS#7 / CMS encryption.
This blog post explains the details about the configuration options.

SAP Cloud Integration offers a nice low code experience for designing processes, it really nicely makes complex transformations really nicely simple.
Also the really ugly complex cryptic world of cryptography is made easy by just placing a box on the iflow and let things go their desired cryptic flow, while we watch TV (or work with iflows).

So actually, nobody needs this blog post.
This is a known issue with all my blog posts
Don’t give up (yet)
Thanks
When it comes to configuring the PKCS7/CMS Encryptor, there are several settings that would deserve some detailed explanation.
The “General” Tab?
No comment.

Quicklinks:
Quick Guide

Content

0. Preparation
1. Introduction
2. Encryptor Configuration
2.1. Block Size
2.2. Base64 Encoding
2.3. Signature
2.4. Algorithm
2.5. Secret Key
2.6. Public Key
3. Hands-On Example
3.1. Create Key Pair
3.2. Create iFlow
3.3. Use Base64 Encoding
3.4. Optional: View Content

0. Preparation

Unfortunately, understanding the PKCS#7 / CMS Encryptor iFlow step requires understanding the PLKCS#7 and CMS standards.
I’ll try to explain the standard and everything around it with easy words (because my English is not good enough for complicated words) in a separate blog post, so please stay tuned.

Hence, I assume that you’ve read all my easy introducing words, before going ahead with explanations of the iFlow step

To follow this tutorial, access to a Cloud Integration tenant is required, as well as basic knowledge about creating iFlows.

Create a package and an empty Integration Flow, to start with below tutorial.

1. Introduction

It is so easy:
You have an iFlow and you want the message to be encrypted.

Why?
Because it contains secret information and you don’t want that a potential hidden hacker could read the content with a sniffing tool, or whatever.
So you only need to place an encryption step in the iFlow, which does the encryption for you.

What?
It encrypts only the actual content of the message, no headers or properties.

Then?
Once the iFlow is executed and the message is delivered to the receiver, it can be decrypted.

How?
This can be achieved via a separate iFlow with the “Decryptor” step, or with command line tool OpenSSL, or programmatically.

Why?
Because the encryption is done according to the “CMS” standard and as such, it can be decrypted by any tool that understands that standard.

How to configure?
As mentioned, just add the step to the iFlow, and leave the default settings.
Only need to point to an existing key-pair/certificate

What’s the meaning of the settings?
See below

What is PKCS#7 / CMS?
PKCS #7 and CMS are almost the same, because CMS is the successor, the newer version of PKCS #7

What does it mean?
In brief:
It is not just a normal encryption, it is more than that.
We’re encrypting a message and sending it out to a receiver (or multiple receivers).
To enable the receiver to decrypt it, we need to add additional information/metadata to the message (e.g. certificate)
Finally, the encrypted content and the metadata are packaged altogether.

Nobody knows how to unpackage and decrypt?
The CMS standard explains how to structure it and the iFlow-Encryptor does exactly like that.
As such, the receiver will be able to read the CMS structure and find the certificate and the encrypted content.
All nicely structured, everything he needs to decrypt.
This is possible thanks to the guideline in CMS.

Guideline?
I try to use simple words for better understanding cryptic terms,
I translate “standard” into “guideline” or “agreement”.

I still don’t know PKCS#7 / CSM…
CMS = Cryptographic Message Syntax
PKCS #7 = Public Key Cryptography Standard number 7

Why always write both PKCS#7 and slash and CMS?
CMS is the successor of PKCS#7, thus it is the current version of the guideline.
In this version, the chapter for “encrypt + sign in one step” has been dropped.
However, the CPI Encryptor still supports it:
With CPI Encryptor, we can choose to either
– encrypt a message according to CMS
or
– encrypt and sign in one step, according to PKCS #7
As such, to be on the correct side, we need to use both names.
To decide about these 2 options, we use the property sheet, where also all the other settings can be found.

I don’t understand any of the settings
Let me explain below

Will it be cryptic explanation?
No, it will be plain text

Can we start now?
Let’s get started

2. Encryptor Configuration

Below screenshot shows the property sheet for PKCS#7 / CMS Encryptor:

Let’s go through the configuration options and explain one by one.

2.1. Block Size

This setting is not to be confused with the “block size” of the encryption algorithm.
This is:
After choosing a so-called “Block Cipher” algorithm, the encryption process will work on a fix block size.
Depending on the selected algorithm, such block size can be 64 bits or 128 bits.

However, the “block size” which can be specified in this property-sheet-setting, is relevant for the Java library (iaik) which implements the CMS standard and which is responsible for performing the actual encryption.
It can be configured to read the incoming data (from message body) in chunks of different size.
This setting can help to improve performance in case of big message size or if is embedded in a streaming scenario.

Example:
Try specifying a size of e.g. 2 bytes for a big message body size, like 5 MB.
Cool – I’ll do so
The encrypted file will become much bigger and the performance much slower.
Bad advice ;-(

2.2. Base64 Encoding

This means that the message content will be encrypted and afterwards Base64-encoded.

Why should we enable this option?
If we don’t enable it, then the message body will be sent over the network as encrypted (binary) data.
This might cause problems, related to special characters that might get lost if transport protocol doesn’t handle properly.
When encoding with Base64, we’re on the safe side with respect to the possible characters in the message.
As Cloud Integration will always send messages over wire, enabling this setting would always make sense.

Really always?
Not really always.
One has to be aware that the additional encoding would require some additional computation time and might increase the size of the message body.
As such, in case of big message payload, this setting should be used after considering the potential performance impact.

I’m confused: Encoding? Encryption?
Agree, it is confusing because sometimes both terms are even used synonymously.
But in fact, the difference is:
Encryption makes the data un-understandable.
Encoding just transforms the data into different format.
Decryption requires secret password or key.
Decoding is open and can be done by everybody.
Actually, the CMS Encryptor is a good example, because it encrypts the message and in addition, it allows to encode it, to make it readable, although not understandable.

Can read but not understand?
Yes
Like your blogs?
Ehm – below tutorial gives an example

2.3. Signature

This setting means:
Hello,
Do you want to encrypt the message?
Or do you want to sign the message in addition to encryption?

But why “Enveloped Data”?
This is the correct term as used in the CMS spec.
When selecting this option, the message will be processed according to this specific guideline-chapter in CMS.

Why do we need to bother about it?
As a user of the iFlow Editor, we actually don’t need to bother about it.
We just decide that we want encryption.
However, it can be useful to use exact terminology, like “Enveloped Data”

Why?
Because at the end of an iFlow there will be a receiver.
Can be a user or a system or an application.
And this receiver needs to decrypt it, otherwise ….
…encryption would be like deletion?
Exactly.
The receiver needs to know, which spec he needs to follow.
As such, it is a useful info, to use the terminology of the underlying standard.

What about “Signed And Enveloped Data”?
Actually, this setting is not specified in the CMS standard.
It was included in the predecessor standard, in the PKCS #7 and it was dropped in the CMS.
The spec can be found here.

I don’t want to read spec…
I can try to translate:
In general, signing and encrypting the message enhances the security.
The PKCS #7 standard describes a routine of signing and encrypting in one step.
The hash value is doubly encrypted.
In brief, the procedure is as follows:
1) First, the usual way of signing:
the hash value is created
Then it is signed with private key, resulting in encrypting the hash value.
2) In addition, the result is encrypted with the symmetric key (= secret key).
That’s about the doubly encrypted hash

I’m doubly confused

Compare general scenario:
So for example, a text containing secret info, needs to be protected.
1) As such, a hash is created, to make sure that the content is not modified by hackers
The hash is signed with private key.
This ensures that hacker could not create an own hash and replace the original.
2) A hash ensures that the content is not modified, but it doesn’t actually <hide> the content.
As such, the original message content is encrypted, to make it unreadable.
This is done with the symmetric key.

What’s the difference between the 2 scenarios?

We have the choice between
– general scenario: do signing, then do encryption
– PKCS#7 scenario: doubly signing and encryption in one process

Note:
The spec itself states that it is preferable to use signing and encrypting as 2 consecutive steps.
It is more secure because of some additional attributes (wrt authenticated and signer information) added to the cms-structure.
These additional info is missing in the “Signed And Enveloped Data” description.
As such, as a normal iFlow designer, I would choose the 2 steps, “Signer” and “Encryptor” instead of the “Signed And Enveloped Data” setting of 1 “Encryptor” step.

Why do we have this setting?
This setting was requested and is kept due to PKCS7-compatibility reasons.

Can we ignore it?
As for me and my useless blogs, I do intend to ignore it

2.4. Algorithm

Now coming back to cryptographic basics…

I forgot everything…
Little recap:
For example, I would want to encrypt my blog post, such that only my followers can read it (stupid idea)
Hence I would apply a code:
E.g.
A = 1,
B = 2
etc
Then send the code to my followers

So what I’ve done:
– encryption (cannot read without code)
– symmetric key (send my code to followers, they use same code)
– use weak algorithm (can be found out easily)

As soon as I realize that my blogs are compromised and published in plaintext on hacker-websites, I need to increase my security, to use stronger algorithm:
A = 1 + 1,
B = 2 + 1

And when I need to increase security again, I use very complicated formula to create a code
E.g.
A = getEnc(A)

End of example?
Yes

What have we learned?
To improve security, we need
– strong algorithm
– complex calculation

Both can be configured in the PKCS7/CMS Encryptor properties: “algorithm” and “key size”.
A dropdown field allows us to select an algorithm.
More precise: a combination of algorithm, operation mode and padding scheme

Sounds like combination of ?? with ?? and ??
Don’t worry, this blog post explains everything
Let’s start with the algorithms (aka “ciphers”)

What choices do we have?
Currently, CPI supports these algorithms:
AES
ARCFOUR
Camellia
CAST5
DES
DESede
RC2

To make things easier, they can be grouped as follows:

Good Choice 👍	Notsogood Choice
AES, Camellia	All the others

2.4.1. Info about the Ciphers

Let’s talk a bit about every offered algorithm.
Can I skip it?
Sure, this info is only for the curious among us

AES
Advanced Encryption Standard
Published by NIST (National Institute of Standards and Technology) in 2001.
Symmetric-key algorithm.
Block cipher.
Block size: 128 bits.
Key size: 128, 192, 256 bits.
Recommended and most commonly used algorithm for symmetric encryption.

Camellia
Symmetric key algorithm,
Developed in Japan, published in 2000.
Named by Japanese flower.
Block cipher.
Block size 128 bits.
Key size 128, 192, 256 bits.
From security perspective similar like AES.

DES
Data Encryption Standard, developed by IBM. published 1975.
Symmetric-key algorithm.
Block cipher.
Block size 64 bit.
Key length 56 bit, which is too short thus too insecure.
Superseded by Triple-DES (1999), replaced by AES (2001).

TDES
TDES == Triple DES == 3DES == DESede
Aka Triple Data Encryption Algorithm (TDEA or Triple DEA)
Applies the DES algorithm three times to each data block.
By using 3 keys in TDES, the key size increases to 112 bit.
Block size 64 bit.
Deprecated since 2017.

RC2
Aka ARC2, 1987.
Designed by Ron Rives, RC = Ron’s Code or Rivest Cipher.
Symmetric key algorithm, published 2000.
Block size 64 bits.
Key size variable, 1-128 bits.
Vulnerable, not safe.

RC4
Rivest Cipher 4, aka ARC4 or ARCFOUR (Alleged RC4)
Since 1987.
Stream cipher.
Key size: 40-2048 bits.
Simple and fast, but insecure, not recommended.
Use of RC4 in TLS is even forbidden by IETF, vulnerabilities found.

CAST5
Also called CAST-128.
An algorithm based on CAST design procedure, a procedure used for constructing block ciphers.
Since 1996.
Symmetric key algorithm
Block cipher.
Block size 64 bits.
Key size 40-128 bits.
Most widely used CAST cipher, used e.g. in PGP

2.4.2. Info about Operation Mode

Short for “block cipher mode of operation”.
A block cipher does encryption for a block of bites.
As the data is always larger than this block, it is necessary to repeat.
This can be achieved in several ways, which is described by “operation mode”.
For instance, the original data is split into blocks, then the blocks encrypted, then concatenated.

There are differences between modes with regard to performance and security.

Let’s have a very brief look at some operation modes.

ECB
Electronic Code Book
Parallel encryption of blocks.
The easiest and fastest, but considered weak.
Requires padding.

CBC
Cipher Block Chaining
The first encrypted block is used as input for the next encryption.
Parallel mode not possible.
More secure,
Requires padding
The most widely used operation mode.

CFB
Cipher Feedback
No padding required

OFB
Output Feedback
Turns block cipher into stream cipher.
Hence, no padding required.

CTR
Counter mode.
Turns block cipher into stream cipher.
No padding required.

2.4.3. Info about Padding

Let’s briefly understand the meaning of “padding”, although, in the iFlow, we don’t have much choice here.

Can we s…
Yes, you can skip.

As mentioned, a block-cipher takes a block of fix size and encrypts it.
It is obvious, that the original data will be larger than the size of one block.
OK, so the original data is divided into many blocks.
But anyways, there’s always a rest in the last block.
This needs to be filled up, ideally in a smart way that makes life of hackers difficult.

Note:
If the encryption is not done in blocks, but in streaming mode, then padding is not required.

Consideration:
Before encrypting a message, some arbitrary data is added to beginning or end of the message.
This is done to avoid that a hacker could guess typical message-ending phrases, which would facilitate the hacking.

Padding-bits/bytes are added to the original data before encrypting it.
There are multiple practices for padding.
In asymmetric encryption, a padding scheme is used to prepare the message for encryption.
Examples:

OAEP
Optimal Asymmetric Encryption Padding
Often used with RSA encryption.-

PSS
Probabilistic Signature Scheme, used only for signatures

PCKS5 Padding
Done in whole bytes instead of bits.
Is applied to block sizes of 8 bytes.

PCKS7 Padding
Done in whole bytes instead of bits.
Same as PKCS5 padding, but PKCS7 padding is variable.
Difference: PKCS5 Padding can only be applied to block size of 8 bytes (which corresponds to 64 bits)
When PKCS5 is used in combination with e.g. AES, that has block size of 16 bytes (128 bits), then PKCS7 Padding will be applied under the hood.
For historic reasons, both schemes are used synonymously.

2.5. Secret Key Length

Coming to the key…

What is a key?
The “key” is the code which I use to encrypt my secret text.
In my example above, the key was very simple in the beginning.
As a consequence, a hacker can easily guess it.
Thus, choosing a very complicated key has a significant impact on the protection of the message.

And what is a secret key?
The term “Secret Key” is used in symmetric encryption, to be differentiated from the privateKey-publicKey-Keypair in the asymmetric encryption.

What does that mean?
In my example, I used a code (A=1, B=2) to encrypt my text.
Then I give the code to my followers, so they can decrypt my blogs.

How “give”?
That’s the weak point about “symmetric encryption”. It only makes sense if I can give the code in an absolute secure manner.
That’s why the “asymmetric encryption” was invented.

How does it work?
A follower publishes his public key.
I use that public key to encrypt my blog
Then the follower uses his private key to decrypt the blog.
That’s safe and practical.
Does it make sense?
I never encrypt my blogs…

Why we have symmetric key in CPI?
In OKCS#7 / CMS, a trick is described:
The symmetric algorithm is used to encrypt the content (because can be big)
Then the secret key is encrypted with public key.
As such, the secret key can be safely sent to the receiver.

Why so complicated?
The secure asymmetric encryption cannot handle big sizes of data.
The symmetric encryption can handle and is fast.
As such, a combination is a good solution.

What about the key size?
The secret key is used by the cipher to encrypt the data.
The old and insecure RC2 cipher used to use a key with length 40 bits.
The modern AES cipher supports key size up to 256 bits.
In brief: the longer the key size, the better protection we get

So why choose the key length at all?
The reason, why we wouldn’t always just take the biggest key length: the performance.
Encryption process gets significantly slower when choosing the longest key.
So in some scenarios, we might prefer higher performance, if data is not classified as strongly sensitive.

2.6. Receiver Public Key Alias

This is the only mandatory setting for the PKCS #7 / CMS Encryptor.

Why?
Remember:
In an asymmetric encryption scenario, the public key is used to encrypt – and the private key is used to decrypt.

Why asymmetric? Above is symmetric?
I recognize it is confusing.
Reason: we have a mixture of symmetric and asymmetric encryption.
The Encryptor in our iFlow does not just encrypt.
It encrypts according to the guideline which is described in the CMS document.
And the guideline states:
message -> symmetric
key -> asymmetric

Still confused
1. The “content” of a message can be big.
That’s why the content is encrypted with a symmetric algorithm (e.g. AES) and secret key (e.g. 128 bits).
The symmetric procedure is faster and can handle bigger size than the asymmetric
2. The problem is now:
In symmetric encryption scenario, the receiver of the message needs the secret key for decryption.
If we send the secret key along with the message, it would be nonsense, because unsafe.
So the trick is:
Encrypt the secret key with asymmetric encryption.
Then send the encrypted secret key together with the encrypted content.
The symmetric key is small, iso t is not a problem to encrypt it with slower asymmetric encryption.

OK
Now about the public key.

I always confuse with public <-> private
Public key is used for encryption.
Private key is used for decryption.

Maybe this mnemonic can help out:

I go to public post office to send a secret letter.
But to open a secret letter I go to my private room.

OK.
As such, in our iFlow, for encryption we need the public key.
To be more precise:
We need the public key of the receiver
After execution of iFlow, the receiver of the message will use the private key for decryption.
As such, for encryption we need the public key which corresponds to the private key of the receiver.
This public key needs to be configured in the property sheet of the encryptor.

How do I get the receiver public key?
Ask and be polite

How do I upload keys to CPI?
There are a couple of variants, let’s cover it in a separate blog post

How to configure it in the property sheet?
In the property sheet, we enter the name of the alias, which points to the certificate that contains the public key.
To find the correct name, we proceed as follows:
Open the CPI dashboard in a separate browser window
“Operate&Monitor” -> “Manage Security” -> “Keystore”
On the left column, we find our “Alias” and copy it to clipboard.
Back in the Encryptor property sheet, we press “Add”, then paste the alias name into the new field.

Why are multiple entries allowed?
The designers of CMS did foresee that there would be situations as follows:
We design an iFlow where we have multiple independent receivers with different key-pairs.
In such a case, we need to configure each public key of each receiver in the property sheet

Will it…?
Yes, every receiver-certificate (containing the public key) will be included in the CMS-based message.
When the receiver receives the message, it will be decrypted with the receiver-private-key.
The CMS-structure helps to find the right receiver-certificate for the used private key.

Is it safe to send all public keys?
As the name says, public keys are public, so it is not unsafe to include them all in the CMS-structure.

Can we try it out now?
Please proceed to the next chapter.

3. Hands-On Example

Let’s go through a very simple integration flow, to try it out, without any prerequisites, no tools no adapters required.

3.1. Create Key Pair

As promised, in this example we don’t request or create a key pair.
We let CPI generate it for us.
This is done in the Keystore of Cloud Integration.
Go to your CPI -> “Operations & Monitoring” -> “Manage Security” -> “Keystore”

Direct link:
<cpi>/itspaces/shell/monitoring/Keystore

Choose “Create” -> “Key Pair”

Enter some values of your choice, e.g. “simplecert” and press “Create”.

The alias is required later, we can take a note of it, or try to remember (or follow my description).

3.2. Create iFlow

We start with an empty Integration Flow.
We add a “Content Modifier” Step.
This is used to create some dummy message content.
From the palette, choose “Message Transformes” -> “Content Modifier”

Drop the shape in the flow, select it and open the property sheet.
Switch to “Message Body” tab and enter any dummy text of your choice

Now we add the Encryptor step:
From the palette, we choose “Security” -> “Encryptor” -> “PKCS7 Encryptor”
We drop it in the flow, after the “Content Modifier”:

Now we configure the public key for encryption:
Select the Encryptor shape and open the property sheet, “Processing” Tab.
Press “Add” next to “Receiver Public Key Alias”.
In the new line, enter the name of the alias, chosen above for the certificate.
In my example, the alias name is “simplecert”

That’s it for the iFlow design.
We’ve designed an iFlow that doesn’t make sense to be deployed, but can be run in the simulator.

Run the iFlow

To run the iFlow in simulator, we first need to define the start and end points.
We click on the connecting arrow between “Start” and “Content Modifier 1”.
From the context menu, we choose the “Simulation Start Point”:

Afterwards, we click on the arrow that connects the Encryptor with the End.
Here, we choose “Simulation End Point”
The flow looks as shown below:

We can now start the simulation by pressing “Run Simulation” button in the palette:

The simulation takes a few seconds and afterwards we can view the content of the message, as it changes from step to step.
To view the content, we have to click on the little envelope icons, which have appeared between each step, then switch to the “Body” tab in the property sheet.

After start, the message content is obviously empty.
After the “Content Modifier” step, the message body contains the dummy text which we defined above.
And after the “Encryptor” step, we see an info text saying that the message content is binary and cannot be shown:

This is disappointing
This is enough for the moment.
We’ve learned how the encryptor works

How does it work?
It changes silly text to unreadable content.
In fact, I prefer hackers to read unreadable content, rather than my original text.
Because silly?
Indeed

3.3. Use Base64 Encoding

Now we try out the base64-encoded message flow.
We select the Encryptor step and enable the checkbox for “Encode Body with Base64”.
Then run the simulation again.
When looking at the message body after encryption, we realize that this time we can see the content, it is not binary, it is base64-encoded

Looks nice.
In my eyes, the perfect format for sending messages.

3.4. Optional: View Binary Content

Wish to see how an encrypted message body looks like?
Sure, it cannot get worse…
So we need to deploy our iFlow and write the encrypted message body somewhere.
To make it easy, we use a Data Store

First, we delete the Start Event and insert a “Timer Event”

In the properties of the Timer, we make sure that “Run once” is selected.
Then we connect the “Timer” event to the “Content Modifier” step.
To write the message to a data sore, we choose “Persistence” from the palette, then “Data Store Operations”.
We click on “Write” and place the shape in the iFlow between “Encryptor” and “End”:

While the shape is selected, we go to the property sheet and enter a name of our choice for the data store, e.g. “Unreadable”:

We keep the defaults of other properties.

Finally, we have a look at the configuration of our Encryptor and disable the “Encode with Base64” checkbox.
Save.
Deploy.

After deployment, the flow is triggered automatically by the timer.
So we can go to “Operate & Monitor” -> “Manage Stores” -> “Data Stores”.
Our Store is generated and it contains a message that can be downloaded.

Download.
Unzip.
Open the body:

We can see that it is unreadable.
We can see that our certificate is included.
We can guess that there is a structure.
We assume that the structure is according to CMS standard.
We hope that some future blog post will explain a bit more about it.

Summary

In this blog post we’ve learned to understand the cryptic cryptographic options that can be configured for the PKCS#7 / CMS Encryptor.
We’ve learned to understand that we need to understand the CMS standard, to fully understand the options.

The CMS standard is a guideline for secure transfer of messages.
The guideline describes how to encrypt (etc) a message, and package all required info together in a well-defined structure.
The content (e.g. text) is encrypted with symmetric-key algorithm
The symmetric key itself is encrypted with asymmetric-key.
That’s the guideline (small part of it) and the iFlow will behave like that.

Quick Guide

Basically, a good choice:
– AES or camellia,
– Big key size
– Enable Base64 encoding
– Default block size