SAP Cloud Integration (CPI) offers easy to use iFlow steps to secure messages with encryption or signing. But how to decrypt a message outside of CPI?
For your convenience, this blog post helps to make OpenSSL work together with CPI.
With other words it shows which commands to use in OpenSSL to process messages encrypted in CPI, etc
Example:
We encrypt a message in CPI, then send it to an SFTP receiver.
So what to do with such a unreadable file, in order to make it readable?
Solution:
Follow this blog post to decrypt it with OpenSSL
Note that there are no explanations here, as everything was explained in previous blog posts.
This blog posts rather serves as reference for OpenSSL commands, prepared for CPI.
Following scenarios are covered:
CMS Encryption
encrypt in CPI with PKCS #7 / CMS Encryptor and decrypt with OpenSSL
encrypt locally with OpenSSL and decrypt in CPI with PKCS #7 / CMS Decryptor
CMS Digital Signature
sign in CPI with PKCS #7 / CMS Signer and verify with OpenSSL
sign with OpenSSL and verify in CPI with PKCS #7 / CMS Verifyer
Normal Digital Signature
sign in CPI with Simple Signer and verify with OpenSSL
Prerequisites
Preparation
Key Pair
CMS Encryption
Encrypt in CPI and decrypt with OpenSSL
Encrypt with OpenSSL and decrypt in CPI
CMS Digital Signature
Sign in CPi and verify with OpenSSL
Sign with OpenSSL and verify with CPI
Normal Digital Signature
Sign in CPi and verify with OpenSSL
View CMS Structure
To understand what’s happening and to prepare Integration Flows, please refer to my previous blog posts:
Understanding the PKCS #7 / CMS standard
Understanding the PKCS #7 / CMS Encryptor
Understanding the PKCS #7 / CMS Signer
Understanding the Simple Signer
And refer to this glossary if any piece of info is missing.
To follow this tutorial, we need OpenSSL and access to a CPI tenant.
Install OpenSSL
OpenSSL is the most commonly used tool (and library) for security-related operations, dealing with certificates, keys, converting, etc etc
Basically, it consists of libraries (for “c”) and a command line tool.
If you have GIT installed, you can just open the git bash which contains openssl.
Otherwise, follow these instructions to install OpenSSL under Windows:
Download openssl starting from here.
Afterwards it might be required to add the openssl.exe to the PATH.
If you get this error:
Unable to load config info from /usr/local/ssl/openssl.cnf
You need to set an environment variable.
e.g. on command line:
set OPENSSL_CONF=c:/tools/openssl/openssl.cfg
Note:
For windows, the config-file extension .cnf has to be adjusted to .cfg
A template .cnf file can be found in GIT installation folder.
Create iFlow
For the CPI part of the tutorial, we create very simple iFlows, with the goal to avoid specific prerequisites like SFTP server.
As such. our iFlows take some hard-coded input in a Content Modifier, perform the cryptographic operations and write the result into a data store.
Detailed description can be found here.
For the cryptographic operations, we need a key pair, including certificate.
As we need it in both environments (CPI and locally), we generate it with OpenSSL and upload it to the CPI Keystore (instead of generating it in CPI).
1. Create key pair and certificate
Below req command creates a key pair and a self-signed certificate in one step.
Note:
When copy- and pasting the command under windows, it might be required to clean the formatted quotation marks.
Info:
The req command is typically used for CSRs (certificate signing requests) according to PKCS #10, but it supports parameters for generating certificates as well.
-x509 this flag is responsible for generating a certificate.
-newkey generates a private key with algorithm “RSA”. We don’t specify the key size here, we can rely on the default, which is 2048.
-nodes not encrypt the private key.
-out the name of the generated certificate. The file extension can be chosen as of our taste.
-subj here we can pass the attributes of the certificate, like CN (common name) in our example. Other attributes may be specified here, but we leave them, to make it more simple.
Optional: view content of certificate
Below x509 command prints the content of the certificate:
The x509 command is used for certificate operations.
Above command prints the content of the specified file.
We can see e.g. the “Common Name” that we’ve specified above.
2. Extract public key
For the normal "verify" command (not cms), we need the public key, which can be extracted from the private key with pkey command:
or using rsa command:
Info:
-pubout is used to write the public key
-outform PEM optional to specify format like DER
As we have a certificate, we can even extract the public key from cert with x509 command:
Info:
-pubkey is used to write the public key
-noout is used to suppress the certificate in the output
The result is the same for all 3 variants.
3. Create p12/pfx file
We need a container to upload both private key and certificate to CPI keystore.
The reason is:
As we're using both Encryptor and Signer, we also need both, private key and certificate (which includes the public key)
For the Encryptor, it would be enough to upload the certificate via “Add->Certificate” only.
To create a container, we use the pkcs12 command of OpenSSL.
The pkcs#12 standard defines a binary format to store certificates (etc), protected with password and thus suitable for import/export.
Info:
The pkcs12 command uses 2 input parameters to specify the certificate and private key that should be stored in the .p12 result file.
-export is used to generate a .p12 file (instead of operating on an existing one).
-passout allows us to specify a password, as the PKCS #12 standard supports password to protect the stored private key.
-out we specify the result file with the usual .p12 file extension. Another frequent file extension would be .pfx.
Note:
If desired, we can assign an alias by adding the -name option.
This would be displayed in tools that support it, e.g. CPI Keystore
Optional: view content of p12 file
We can use below command to view the certificate and private key stored in the .p12 file.
Below command includes the private key and writes the required password in the console (can be passed as file as well)
Info:
-info prints the contained encoded certificate and private key.
-nodes to view the private key unencrypted.
4. Upload to CPI Keystore
In your CPI dashboard, go to "Monitoring" -> "Keystore" and choose "Add"->"Keystore".
Browse for the .p12 file and enter the password, as provided in the command: "abcd".
CPI displays a warning, because it couldn’t find a trusted CA in the certificate chain.
As we’ve self-signed our certificate during test phase, this is ok for us.
Remember the Alias name ("myownstore") for later use.
When talking about "encryption", we have to understand that the CPI Encryptor processes messages based on the CMS standard. Such a message can only be decrypted with a tool that supports CMS.
Reason:
The CMS standard describes a "hybrid" approach: the content is encrypted with symmetric key, generated on the fly, and the key is afterwards encrypted with asymmetric key.
As such, tools or libraries for "normal" encryption cannot be used in conjunction with CPI.
To be more precise: only the CMS-type “EnvelopedData” is supported by both CPI and OpenSSL.
Note:
Other encryption option in CPI, the PGP Encryptor, is currently not in scope of this blog post.
We create an iFlow with the following elements:
After deploy and successful execution of the iFlow, we download the encrypted message from the Datastore.
We extract the “body” file of the zip into the same folder that contains our certificate and private key.
To decrypt, we use the cms command of OpenSSL, which implements the CMS standard.
(same standard as used by CPI).
The cms command requires the private key to decrypt a content that was encrypted with the corresponding public key.
The result is written to the file specified via -out
Info:
The -inform DER parameter is required, because we’re decrypting a binary file, not base64 encoded.
Alternatively, the PEM and SMIME formats for input are supported.
Result:
We can see the plaintext content of the message in the decrypted.txt file.
Note about the formats:
There are 3 options to use with the cms -decrypt command and that can be passed via -inform parameter.
The format must match the format of the given encrypted input file.
These are the 3 formats supported by OpenSSL:
1. SMIME
The default format for en/decryption with openssl cms command is SMIME (no -inform param required).
This format contains a MIME-header like this:
The content can be encrypted or base64-encoded.
If we want to decrypt a CPI-message with a tool that supports only SMIME format, we could manually add this header, as a workaround.
Note: blank line is required after header
Note: if payload is binary, make sure to use header without transfer-encoding set to base64
2. PEM
This format can be set with -inform PEM during decryption.
Prerequisite:
In CPI iFlow, the base64 flag must be enabled for the Encryptor.
Decrypting binary format with -inform PEM doesn’t work, according to the PEM spec.
However, if your decryption tool supports only PEM, there's again a simple workaround:
Manually add BEGIN and END at beginning and end, like this:
3. DER
If we use the parameter -inform DER to decrypt a message received from CPI, then no workaround is required, as shown above.
Prerequisite:
In CPI iFlow, the base64 flag must not be enabled for he Encryptor.
In this chapter we encrypt a text file locally with OpenSSL on command line.
Then we decrypt it in CPI with the PKCS #7 / CMS Decryptor.
First of all, we create a text file with name orig.txt and arbitrary plaintext content.
Then we encrypt it with the cms command and -encrypt operation option:
Info:
The command takes an input file with the original plaintext content.
It writes the CMS-based encrypted message to the output file.
The operation is done according to the CMS type EnvelopedData.
-aes256 the algorithm to use for (symmetric) encryption.
-outform this param is used to specify one of the 3 formats. We choose DER, which is used in CPI.
cert.pem the certificate with public key to be used for (asymmetric) encryption.
Note:
The result is a binary file that could be understood by the CPI decryptor.
This file could be copied to an SFTP server used as sender in CPI.
However, our iFlow is as simple as possible, to enable users who don’t have an SFTP server.
So we manually copy and paste our encrypted file into the iFlow.
There's just a little problem with this approach: we cannot copy binary content into the iFlow.
The solution for this problem: base64 encoding.
Although there are workarounds like using different output format, we’re happy to add this step for our learning.
The enc command of OpenSSL is simple, it takes a binary input file and writes the base64-encoded result to the -out file:
Info:
-base64 specifies the encoding for the enc command.
Result:
The encrypted file is now base64 encoded and can be easily processed further.
Design Integration Flow
We create an iFlow with the following elements:
After deploy, we download the decrypted message from Datastore and view our plaintext content in the “body”.
When talking about "digital signature", we have to understand that the CPI Signer processes messages based on the CMS standard. Such a message can only be verified with a tool that supports CMS.
To be more precise: only the CMS-type SignedData is supported by CPI PKCS #7 / CMS Signer (and Verifier).
Note:
Other signing options in CPI are currently not in scope of this blog post.
In this chapter we’re creating the CMS-based Signature in an iFlow in CPI, then we verify it locally with OpenSSL.
We create an iFlow with the following elements:
After deploy and successful execution of the iFlow, we download the message from Datastore.
We extract the “body” file of the zip into the same folder that contains our certificate and private key.
To verify, we use the cms command of OpenSSL, which implements the CMS standard.
Info:
-inform this option is required because CPI writes binary file (not the default SMIME format).
-noverify this option is required, because we’re using a self-signed certificate.
Note:
The command doesn’t require certificate, because we configured the Signer in CPI to include it in the message.
Result:
Success message is printed to the console.
The output file specified above contains the original plaintext message content.
It has been verified by OpenSSL, so we can rely on the fact that the content is correct and has not been altered by any hacker.
In this chapter we create a digital signature of a text file with OpenSSL.
Then we verify it in CPI with PKCS #7 / CMS Verifier.
First of all, we create a text file with name orig.txt and arbitrary plaintext content.
Then we sign it with the cms command and -sign operation option:
Info:
The command creates a CMS-based digital signature using the given private key.
It adds the certificate to the CMS-package.
-outform DER the generated signature file needs to be in DER form, to be understood by CPI.
Result:
This creates an external digital signature, without the content.
With other words, we’re operating on a so-called “Detached Mode”
Note:
Again, we need to base64-encode the generated binary file, such that we can copy it into the content modifier in the iFlow.
Design Integration Flow
We create an iFlow with Verifier and configure it for “Detached Mode”.
Means, the Verifier expects that
- the actual content of the message is in the body.
- the CMS-package with the “external Signature” is contained in the special exchange property with name SapCmsSignedData
In our case, we try to simulate a real scenario with our simple iFlow.
We copy the base64-encoded CMS-package into the Message Body of a Content Modifier.
So afterwards, we have to move it to the special Exchange Property, in a second Content Modifier.
The original content from orig.txt is copied into the Message Body of the second Content Modifier.
So we create an iFlow as follows:
After deploy, we download the verified message from Datastore and view our plaintext content in the “body”.
Simple Signer is used in iFlows to create a digital signature of the message content.
The signature is base64-encoded and stored in a message header.
It is explained in detail in this blog post.
We use the keypair created in above section, for verification, we need the public key (unlike cms command).
In this chapter we’re creating a “normal” digital signature with the Simple Signer in CPI, then we verify it locally with OpenSSL.
We create an iFlow with the following elements:
After deploy and successful execution of the iFlow, we download the message from Datastore.
We extract the body file of the zip into the same folder that contains our public key.
We also extract the headers.prop file into the same folder.
We open the file and find the header “SAPSimpleSignatureValue” and the value which is the base64-encoded signature.
We delete all content from this file and leave only the signature.
If the signature contains escape characters (\), we remove them as well:
So at the end, the headers.prop file looks like this:
Note:
On my machine (win), it is necessary to add a CR at the end of the string (just press Enter), otherwise the openssl command doesn’t work.
After preparing the 2 downloaded files, we can go ahead and verify the signature with OpenSSL
Decode
First of all, we need to decode the signature using the enc command:
Verify
To verify, we use the dgst command of OpenSSL.
We need to specify the same hashing algorithm that was used for signing in CPI: SHA512
Also, we need to use the public key that corresponds to “myownstore”
Result:
Success message is printed to the console.
Some of the OpenSSL cms commands support viewing the structure of the generated CMS package.
This is interesting to understand the CMS standard and mechanism.
So let's view it.
As an example, we encrypt a file with OpenSSL.
Then we decrypt it with OpenSSL.
Then we print the CMS-structure while decrypting.
First step: encrypt our existing orig file:
Second step: optionally run the normal decrypt command, just to remember:
Third step: Add the 2 required options to view the structure of the encrypted input file:
In this blog post we’ve learned that the CMS-based iFlow steps can seamlessly work in conjunction with open-source tools like OpenSSL.
We’ve learned which configuration settings are required on both sides, CPI and OpenSSL, to make them work together.
We’ve also learned how to use the “detached mode” of the CMS-based signing (datatype “SignedData”).
Blogs on the cryptographic support of CPI:
Understanding the PKCS #7 / CMS standard
Understanding the PKCS #7 / CMS Encryptor
Understanding the PKCS #7 / CMS Signer
Understanding the Simple Signer
And the Security Glossary Blog.
OpenSSL
Official list of unofficial binaries download page
Docu home
Manual: https://www.openssl.org/docs/manmaster/man1/
cms: https://www.openssl.org/docs/manmaster/man1/openssl-cms.html
req: https://www.openssl.org/docs/manmaster/man1/openssl-req.html
pkcs12: https://www.openssl.org/docs/manmaster/man1/openssl-pkcs12.html
x509: https://www.openssl.org/docs/manmaster/man1/openssl-x509.html
pkey: https://www.openssl.org/docs/manmaster/man1/openssl-pkey.html
rsa: https://www.openssl.org/docs/manmaster/man1/openssl-rsa.html
decode: https://www.openssl.org/docs/manmaster/man1/openssl-enc.html
digest: https://www.openssl.org/docs/manmaster/man1/openssl-dgst.html
SAP Help Portal
Docu for PKCS#7/CMS Encryptor
Docu for PCKS#7/CMS Signer
Docu for Simple Signer
Docu for Message-Level Security
For your convenience, this blog post helps to make OpenSSL work together with CPI.
With other words it shows which commands to use in OpenSSL to process messages encrypted in CPI, etc
Example:
We encrypt a message in CPI, then send it to an SFTP receiver.
So what to do with such a unreadable file, in order to make it readable?
Solution:
Follow this blog post to decrypt it with OpenSSL
Note that there are no explanations here, as everything was explained in previous blog posts.
This blog posts rather serves as reference for OpenSSL commands, prepared for CPI.
Following scenarios are covered:
CMS Encryption
encrypt in CPI with PKCS #7 / CMS Encryptor and decrypt with OpenSSL
encrypt locally with OpenSSL and decrypt in CPI with PKCS #7 / CMS Decryptor
CMS Digital Signature
sign in CPI with PKCS #7 / CMS Signer and verify with OpenSSL
sign with OpenSSL and verify in CPI with PKCS #7 / CMS Verifyer
Normal Digital Signature
sign in CPI with Simple Signer and verify with OpenSSL
Content
Prerequisites
Preparation
Key Pair
CMS Encryption
Encrypt in CPI and decrypt with OpenSSL
Encrypt with OpenSSL and decrypt in CPI
CMS Digital Signature
Sign in CPi and verify with OpenSSL
Sign with OpenSSL and verify with CPI
Normal Digital Signature
Sign in CPi and verify with OpenSSL
View CMS Structure
Prerequisites
To understand what’s happening and to prepare Integration Flows, please refer to my previous blog posts:
Understanding the PKCS #7 / CMS standard
Understanding the PKCS #7 / CMS Encryptor
Understanding the PKCS #7 / CMS Signer
Understanding the Simple Signer
And refer to this glossary if any piece of info is missing.
Preparation
To follow this tutorial, we need OpenSSL and access to a CPI tenant.
Install OpenSSL
OpenSSL is the most commonly used tool (and library) for security-related operations, dealing with certificates, keys, converting, etc etc
Basically, it consists of libraries (for “c”) and a command line tool.
If you have GIT installed, you can just open the git bash which contains openssl.
Otherwise, follow these instructions to install OpenSSL under Windows:
Download openssl starting from here.
Afterwards it might be required to add the openssl.exe to the PATH.
If you get this error:
Unable to load config info from /usr/local/ssl/openssl.cnf
You need to set an environment variable.
e.g. on command line:
set OPENSSL_CONF=c:/tools/openssl/openssl.cfg
Note:
For windows, the config-file extension .cnf has to be adjusted to .cfg
A template .cnf file can be found in GIT installation folder.
Create iFlow
For the CPI part of the tutorial, we create very simple iFlows, with the goal to avoid specific prerequisites like SFTP server.
As such. our iFlows take some hard-coded input in a Content Modifier, perform the cryptographic operations and write the result into a data store.
Detailed description can be found here.
Key Pair
For the cryptographic operations, we need a key pair, including certificate.
As we need it in both environments (CPI and locally), we generate it with OpenSSL and upload it to the CPI Keystore (instead of generating it in CPI).
1. Create key pair and certificate
Below req command creates a key pair and a self-signed certificate in one step.
openssl req -x509 -newkey rsa -nodes -keyout privkey.pem -out cert.pem -subj "/CN=myowncert"Note:
When copy- and pasting the command under windows, it might be required to clean the formatted quotation marks.
Info:
The req command is typically used for CSRs (certificate signing requests) according to PKCS #10, but it supports parameters for generating certificates as well.
-x509 this flag is responsible for generating a certificate.
-newkey generates a private key with algorithm “RSA”. We don’t specify the key size here, we can rely on the default, which is 2048.
-nodes not encrypt the private key.
-out the name of the generated certificate. The file extension can be chosen as of our taste.
-subj here we can pass the attributes of the certificate, like CN (common name) in our example. Other attributes may be specified here, but we leave them, to make it more simple.
Optional: view content of certificate
Below x509 command prints the content of the certificate:
openssl x509 -text -in cert.pemThe x509 command is used for certificate operations.
Above command prints the content of the specified file.
We can see e.g. the “Common Name” that we’ve specified above.
2. Extract public key
For the normal "verify" command (not cms), we need the public key, which can be extracted from the private key with pkey command:
openssl pkey -pubout -in privkey.pem -out pubkey.pemor using rsa command:
openssl rsa -pubout -in privkey.pem -out pubkey.pemInfo:
-pubout is used to write the public key
-outform PEM optional to specify format like DER
As we have a certificate, we can even extract the public key from cert with x509 command:
openssl x509 -pubkey -noout -in cert.pem > pubkey.pemInfo:
-pubkey is used to write the public key
-noout is used to suppress the certificate in the output
The result is the same for all 3 variants.
3. Create p12/pfx file
We need a container to upload both private key and certificate to CPI keystore.
The reason is:
As we're using both Encryptor and Signer, we also need both, private key and certificate (which includes the public key)
For the Encryptor, it would be enough to upload the certificate via “Add->Certificate” only.
To create a container, we use the pkcs12 command of OpenSSL.
The pkcs#12 standard defines a binary format to store certificates (etc), protected with password and thus suitable for import/export.
openssl pkcs12 -export -out myownstore.p12 -inkey privkey.pem -in cert.pem -passout pass:abcdInfo:
The pkcs12 command uses 2 input parameters to specify the certificate and private key that should be stored in the .p12 result file.
-export is used to generate a .p12 file (instead of operating on an existing one).
-passout allows us to specify a password, as the PKCS #12 standard supports password to protect the stored private key.
-out we specify the result file with the usual .p12 file extension. Another frequent file extension would be .pfx.
Note:
If desired, we can assign an alias by adding the -name option.
This would be displayed in tools that support it, e.g. CPI Keystore
Optional: view content of p12 file
We can use below command to view the certificate and private key stored in the .p12 file.
Below command includes the private key and writes the required password in the console (can be passed as file as well)
openssl pkcs12 -in myownstore.p12 -info -nodes -passin pass:abcdInfo:
-info prints the contained encoded certificate and private key.
-nodes to view the private key unencrypted.
4. Upload to CPI Keystore
In your CPI dashboard, go to "Monitoring" -> "Keystore" and choose "Add"->"Keystore".
Browse for the .p12 file and enter the password, as provided in the command: "abcd".
CPI displays a warning, because it couldn’t find a trusted CA in the certificate chain.
As we’ve self-signed our certificate during test phase, this is ok for us.
Remember the Alias name ("myownstore") for later use.
Encryption based on PKCS #7 / CMS
When talking about "encryption", we have to understand that the CPI Encryptor processes messages based on the CMS standard. Such a message can only be decrypted with a tool that supports CMS.
Reason:
The CMS standard describes a "hybrid" approach: the content is encrypted with symmetric key, generated on the fly, and the key is afterwards encrypted with asymmetric key.
As such, tools or libraries for "normal" encryption cannot be used in conjunction with CPI.
To be more precise: only the CMS-type “EnvelopedData” is supported by both CPI and OpenSSL.
Note:
Other encryption option in CPI, the PGP Encryptor, is currently not in scope of this blog post.
Encrypt in CPI and decrypt with OpenSSL
We create an iFlow with the following elements:
- Start Timer set to "Run Once".
- Content Modifier with some arbitrary text in the Message Body.
- PKCS #7 / CNS Encryptor with “myownstore” as Public Key Alias and default settings (“Enveloped Data Only”, no “Base64”).
- Datastore Write Operation with an arbitrary name.
After deploy and successful execution of the iFlow, we download the encrypted message from the Datastore.
We extract the “body” file of the zip into the same folder that contains our certificate and private key.
To decrypt, we use the cms command of OpenSSL, which implements the CMS standard.
(same standard as used by CPI).
The cms command requires the private key to decrypt a content that was encrypted with the corresponding public key.
The result is written to the file specified via -out
openssl cms -decrypt -in body -out decrypted.txt -inkey privkey.pem -inform DERInfo:
The -inform DER parameter is required, because we’re decrypting a binary file, not base64 encoded.
Alternatively, the PEM and SMIME formats for input are supported.
Result:
We can see the plaintext content of the message in the decrypted.txt file.
Note about the formats:
There are 3 options to use with the cms -decrypt command and that can be passed via -inform parameter.
The format must match the format of the given encrypted input file.
These are the 3 formats supported by OpenSSL:
1. SMIME
The default format for en/decryption with openssl cms command is SMIME (no -inform param required).
This format contains a MIME-header like this:
MIME-Version: 1.0
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m"
Content-Transfer-Encoding: base64The content can be encrypted or base64-encoded.
If we want to decrypt a CPI-message with a tool that supports only SMIME format, we could manually add this header, as a workaround.
Note: blank line is required after header
Note: if payload is binary, make sure to use header without transfer-encoding set to base64
2. PEM
This format can be set with -inform PEM during decryption.
Prerequisite:
In CPI iFlow, the base64 flag must be enabled for the Encryptor.
Decrypting binary format with -inform PEM doesn’t work, according to the PEM spec.
However, if your decryption tool supports only PEM, there's again a simple workaround:
Manually add BEGIN and END at beginning and end, like this:
-----BEGIN CMS-----
MIAGCSqGSIb3DQEHA6CAMIIBkQIBADGCATwwggE4AgEAMCAwE . . .
-----END CMS-----3. DER
If we use the parameter -inform DER to decrypt a message received from CPI, then no workaround is required, as shown above.
Prerequisite:
In CPI iFlow, the base64 flag must not be enabled for he Encryptor.
Encrypt with OpenSSL and decrypt in CPI
In this chapter we encrypt a text file locally with OpenSSL on command line.
Then we decrypt it in CPI with the PKCS #7 / CMS Decryptor.
First of all, we create a text file with name orig.txt and arbitrary plaintext content.
Then we encrypt it with the cms command and -encrypt operation option:
openssl cms -encrypt -aes256 -outform DER -in orig.txt -out encry.enc cert.pemInfo:
The command takes an input file with the original plaintext content.
It writes the CMS-based encrypted message to the output file.
The operation is done according to the CMS type EnvelopedData.
-aes256 the algorithm to use for (symmetric) encryption.
-outform this param is used to specify one of the 3 formats. We choose DER, which is used in CPI.
cert.pem the certificate with public key to be used for (asymmetric) encryption.
Note:
The result is a binary file that could be understood by the CPI decryptor.
This file could be copied to an SFTP server used as sender in CPI.
However, our iFlow is as simple as possible, to enable users who don’t have an SFTP server.
So we manually copy and paste our encrypted file into the iFlow.
There's just a little problem with this approach: we cannot copy binary content into the iFlow.
The solution for this problem: base64 encoding.
Although there are workarounds like using different output format, we’re happy to add this step for our learning.
The enc command of OpenSSL is simple, it takes a binary input file and writes the base64-encoded result to the -out file:
openssl enc -base64 -in encry.enc -out encry.b64Info:
-base64 specifies the encoding for the enc command.
Result:
The encrypted file is now base64 encoded and can be easily processed further.
Design Integration Flow
We create an iFlow with the following elements:
- Start Timer set to "Run Once".
- Content Modifier: we copy the content of encry.b64 into in the Message Body.
- PKCS #7 / CNS Decryptor with “Enveloped Data Only” and with "Base64" enabled.
- Datastore Write Operation with an arbitrary name.
After deploy, we download the decrypted message from Datastore and view our plaintext content in the “body”.
Digital Signature based on PKCS #7 / CMS
When talking about "digital signature", we have to understand that the CPI Signer processes messages based on the CMS standard. Such a message can only be verified with a tool that supports CMS.
To be more precise: only the CMS-type SignedData is supported by CPI PKCS #7 / CMS Signer (and Verifier).
Note:
Other signing options in CPI are currently not in scope of this blog post.
Sign in CPi and verify with OpenSSL
In this chapter we’re creating the CMS-based Signature in an iFlow in CPI, then we verify it locally with OpenSSL.
We create an iFlow with the following elements:
- Start Timer set to "Run Once".
- Content Modifier with some arbitrary text in the Message Body.
- PKCS #7 / CNS Signer with “myownstore” as Private Key Alias and default settings, “include…” is enabled, “Base64” not enabled.
- Datastore Write Operation with an arbitrary name.
After deploy and successful execution of the iFlow, we download the message from Datastore.
We extract the “body” file of the zip into the same folder that contains our certificate and private key.
To verify, we use the cms command of OpenSSL, which implements the CMS standard.
openssl cms -verify -noverify -inform DER -in body -out verifiedInfo:
-inform this option is required because CPI writes binary file (not the default SMIME format).
-noverify this option is required, because we’re using a self-signed certificate.
Note:
The command doesn’t require certificate, because we configured the Signer in CPI to include it in the message.
Result:
Success message is printed to the console.
The output file specified above contains the original plaintext message content.
It has been verified by OpenSSL, so we can rely on the fact that the content is correct and has not been altered by any hacker.
Sign with OpenSSL and verify with CPI
In this chapter we create a digital signature of a text file with OpenSSL.
Then we verify it in CPI with PKCS #7 / CMS Verifier.
First of all, we create a text file with name orig.txt and arbitrary plaintext content.
Then we sign it with the cms command and -sign operation option:
openssl cms -sign -outform DER -signer cert.pem -inkey privkey.pem -in orig.txt -out signature.encInfo:
The command creates a CMS-based digital signature using the given private key.
It adds the certificate to the CMS-package.
-outform DER the generated signature file needs to be in DER form, to be understood by CPI.
Result:
This creates an external digital signature, without the content.
With other words, we’re operating on a so-called “Detached Mode”
Note:
Again, we need to base64-encode the generated binary file, such that we can copy it into the content modifier in the iFlow.
openssl enc -base64 -in signature.enc -out signature.b64Design Integration Flow
We create an iFlow with Verifier and configure it for “Detached Mode”.
Means, the Verifier expects that
- the actual content of the message is in the body.
- the CMS-package with the “external Signature” is contained in the special exchange property with name SapCmsSignedData
In our case, we try to simulate a real scenario with our simple iFlow.
We copy the base64-encoded CMS-package into the Message Body of a Content Modifier.
So afterwards, we have to move it to the special Exchange Property, in a second Content Modifier.
The original content from orig.txt is copied into the Message Body of the second Content Modifier.
So we create an iFlow as follows:
- Start Timer set to "Run Once".
- 1st Content Modifier:
We copy the content of signature.b64 into in the Message Body. - 2nd Content Modifier:
We create an Exchange Property with following info:
Name: “SapCmsSignedData”
Source Type: “Expression”
Value: “${in.body}”
This has the effect of moving the previous Message Body (the signature) into it.
Finally, we manually copy the content of orig.txt into in the Message Body. - PKCS #7 / CNS Verifier with Public key as “myownstore” and “Header is Base64” enabled.
Make sure that “Body is Base64” is NOT enabled. - Datastore Write Operation with an arbitrary name.
After deploy, we download the verified message from Datastore and view our plaintext content in the “body”.
Digital Signature with Simple Signer
Simple Signer is used in iFlows to create a digital signature of the message content.
The signature is base64-encoded and stored in a message header.
It is explained in detail in this blog post.
We use the keypair created in above section, for verification, we need the public key (unlike cms command).
Sign in CPi and verify with OpenSSL
In this chapter we’re creating a “normal” digital signature with the Simple Signer in CPI, then we verify it locally with OpenSSL.
We create an iFlow with the following elements:
- Start Timer set to "Run Once".
- Content Modifier with some arbitrary text in the Message Body.
- Simple Signer
with “myownstore” as Private Key Alias and default settings (SHA512/RSA). - Datastore Write Operation
with an arbitrary name and “Include Message Headers” enabled (don’t miss this)
After deploy and successful execution of the iFlow, we download the message from Datastore.
We extract the body file of the zip into the same folder that contains our public key.
We also extract the headers.prop file into the same folder.
We open the file and find the header “SAPSimpleSignatureValue” and the value which is the base64-encoded signature.
We delete all content from this file and leave only the signature.
If the signature contains escape characters (\), we remove them as well:
So at the end, the headers.prop file looks like this:
Note:
On my machine (win), it is necessary to add a CR at the end of the string (just press Enter), otherwise the openssl command doesn’t work.
After preparing the 2 downloaded files, we can go ahead and verify the signature with OpenSSL
Decode
First of all, we need to decode the signature using the enc command:
openssl enc -base64 -d -in headers.prop -out signature.encVerify
To verify, we use the dgst command of OpenSSL.
We need to specify the same hashing algorithm that was used for signing in CPI: SHA512
Also, we need to use the public key that corresponds to “myownstore”
openssl dgst -verify pubkey.pem -sha512 -signature signature.enc bodyResult:
Success message is printed to the console.
View CMS Structure
Some of the OpenSSL cms commands support viewing the structure of the generated CMS package.
This is interesting to understand the CMS standard and mechanism.
So let's view it.
As an example, we encrypt a file with OpenSSL.
Then we decrypt it with OpenSSL.
Then we print the CMS-structure while decrypting.
First step: encrypt our existing orig file:
openssl cms -encrypt -aes256 -outform DER -in orig.txt -out encry.enc cert.pemSecond step: optionally run the normal decrypt command, just to remember:
openssl cms -decrypt -in encry.enc -out decrypted.txt -inkey privkey.pem -inform DERThird step: Add the 2 required options to view the structure of the encrypted input file:
openssl cms -decrypt -in encry.enc -out cmsStructure.txt -inkey privkey.pem -inform DER -cmsout -printSummary
In this blog post we’ve learned that the CMS-based iFlow steps can seamlessly work in conjunction with open-source tools like OpenSSL.
We’ve learned which configuration settings are required on both sides, CPI and OpenSSL, to make them work together.
We’ve also learned how to use the “detached mode” of the CMS-based signing (datatype “SignedData”).
Links
Blogs on the cryptographic support of CPI:
Understanding the PKCS #7 / CMS standard
Understanding the PKCS #7 / CMS Encryptor
Understanding the PKCS #7 / CMS Signer
Understanding the Simple Signer
And the Security Glossary Blog.
OpenSSL
Official list of unofficial binaries download page
Docu home
Manual: https://www.openssl.org/docs/manmaster/man1/
cms: https://www.openssl.org/docs/manmaster/man1/openssl-cms.html
req: https://www.openssl.org/docs/manmaster/man1/openssl-req.html
pkcs12: https://www.openssl.org/docs/manmaster/man1/openssl-pkcs12.html
x509: https://www.openssl.org/docs/manmaster/man1/openssl-x509.html
pkey: https://www.openssl.org/docs/manmaster/man1/openssl-pkey.html
rsa: https://www.openssl.org/docs/manmaster/man1/openssl-rsa.html
decode: https://www.openssl.org/docs/manmaster/man1/openssl-enc.html
digest: https://www.openssl.org/docs/manmaster/man1/openssl-dgst.html
SAP Help Portal
Docu for PKCS#7/CMS Encryptor
Docu for PCKS#7/CMS Signer
Docu for Simple Signer
Docu for Message-Level Security
- SAP Managed Tags:
