This blog post tries to explain in simple words the PKCS #7 and CMS Standards and its relevance for SAP Cloud Integration (CPI).
SAP Cloud Integration provides functionality to automatically add security features to our messages (so-called message-level security).
We don’t need to worry much about the formats and standards used to encrypt or sign the messages.
However, when it comes to specify the configuration options, we start wondering what they mean.
Fortunately, we find the signer and encryptor blogs in the community, which explain the settings.
However, they’re not going into detail about the standard itself.
So let me try to explain the standard with my own simple words.
Note: I've tried to explain all of those tedious security-related terms, in case anything's missing, please refer to the Security Glossary Blog.
We'll introduce into the topic along with the following sections:
How I imagine that it started:
Timmy from Texas wanted to share some secret info with his friend Taku in Tokyo.
So he encrypted a message and sent it to Taku.
Taku was unable to decrypt and read the message.
So Timmy travelled to Tokyo to enjoy some food and to explain the way how he encrypts and packages his messages.
Afterwards, Taku in Tokyo was able to decrypt and read all messages (even before breakfast).
Some time later, same situation happened with his friend Toto in Togo.
Although the food is said to be great, Timmy decided not to travel, but to invite his friends for a conference at home.
They had international food, late-night discussions and at the end, they agreed on a common way of sending secure messages.
As a consequence, everybody in the world can send secure messages and the recipients can understand the message, as long as they follow that agreement.
Does that make sense?
Really makes sense, especially the section about the international food (which didn’t make it into the specification).
What do we learn from this story?
People communicating with each other need to agree on some basic principles:
- How encryption is done, which steps in which order
- which algorithm is used
- Certificate information to ensure authentication
- Info about sender
- Fingerprint
- And finally: where is that information stored
While that story is purely fantasy, these needs were captured in reality by a company called RSA Security LLC in the 1990s.
This company designed security standards and collected them in a series of standards called PKCS, which stands for Public Key Cryptography Standards.
What is a Standard?
In my simple words: Experts from all over the world come together to “agree” on a way of doing something.
The result is a guideline and signed as agreement by the experts.
That agreement on a guideline is published as “Standard” and can be maintained by an organization, for instance IETF (Internet Engineering Task Force).
What is PKCS #7?
The seventh PKCS standard was dedicated to describe a way of securely transmitting messages over the internet.
This seventh one is called Cryptographic Message Syntax.
The latest version is 1.5 and can be found here, the RFC number is 2315.
What is RFC?
It stands for "Request for Comments" and is typically a document containing a specification.
Usually created by international volunteers and maintained by IETF, has gone through several review processes. After agreement, a number is assigned and it is published (and further maintained) via the rfc-editor, to which links point.
What dies the PKCS #7 standard say?
The specification doesn’t contain concrete commands or proposal for usage of e.g. a specific algorithm like AES.
The sender of a message can encrypt it with whatever algorithm, but the standard specifies where the information about the used algorithm is maintained. As such, the recipient can look up which algorithm he needs to use for decryption.
Like this, there’s multiple information and types of information that need to be sent along with the message.
What Information?
First of all: Do we want to encrypt the message? Or do we want to sign the message? Or both together?
As an example, if we want to send a message and sign it, we will refer to the section of the spec called “Signed-data”.
We learn that the PKCS #7 standard defines different ways of securing messages and gives them a name. These are the “types” or “content types”.
The following content types are defined in PKCS #7:
Short info:
1. The first one is just any data (text or image or whatever)
It is specified, because the other types refer to it.
2. Signed Data means that a digital signature is created on the message.
3. Enveloped Data
The message is encrypted with a symmetric key that is generated on the fly.
This key is encrypted with asymmetric key pair.
The content and the key and certificate and fingerprint, etc
there are many infos that need to be sent to the receiver.
Each info is structured and referred to via a content type.
All of it stored in an envelope, that’s the reason for the name.
4. Signed-and-enveloped data
Means that both, signing and encrypting is done in one step.
5. Digested data refer to just the hash and the content
6. Encrypted data refers to the encrypted data
How does it work?
So if we have a closer look at e.g. the SignedData, we will wonder:
How does the receiver know that the received message is structured in a SignedData-way?
How does he know which algorithm to choose for decrypting the digest?
How does he get hold of the required certificate for decrypting
How does he know that the included certificate is correct and valid?
Once decrypted, how does he get a hold of the digest and which algorithm to use?
If he wants to validate the time, when the signature was created, how does he find it?
The answer is:
Everything that is required, is contained in the data structure, which I like to call "package" (like a classic package that is sent with FedEx).
So if we send a message according to PKCS #7, it is like sending a package, containing multiple artifacts and informations.
And the PKCS#7 standard is like a paper which is attached to the package, like a table of content, such that the receiver knows where to find the corresponding info for each unpackage-step.
How to find all the info?
We can see that there are many elements defined in the spec and each element needs to uniquely be targeted.
So it is necessary to assign an ID to each element, or better: to each type (this is PKCS7-language).
This is done in form of OIDs.
What is an OID?
This is the abbreviation of “Object Identifier”.
What Object Identifier?
This is the attempt of giving everything in the world a unique identifier, which allows to describe it and exactly refer to it.
OIDs are structured in a tree hierarchy and the flattened notation is a chain of numbers separated by dots.
Example: 1.2.840.113549.1.7.1
If you encounter such an OID, you can go ahead and search for it in this repository web page.
Then enjoy the description of each tree node and see the rfc that defined the OID, resp child nodes.
So to pick one example from above:
The time of the signature is an element in a list of “Signed Attributes” and has the OID 1.2.840.113549.1.9.5, which can be found in the spec.
How does a structure look like?
Below I’ve listed an excerpt from the type structure defined by PKCS#7:
SignedData
digestAlgorithms
encapContentInfo
certificates
crls
signerInfos
digestAlgorithm
signedAttrs
signatureAlgorithm
signature
unsignedAttrs
The element “encapContentInfo” contains the actual message content, which stays encapsulated in the PKCS7-package. It contains 2 sub-elements: the content itself and the type of the content.
The element “crls” stands for a list CRLs (Certificate Revocation List) and is optional.
Below diagram tries to illustrate how a PKCS#7-based message could look like:
We can see an envelope representing the message.
The message contains the actual content, including an info about its content type.
The message also contains the certificate, as well as the info about the certificate (serial number, the owner, etc).
Furthermore, we can see that the SignerInfo is again a structured data type which contains artifacts like the digital signature as well as metadata about the signature (algorithm), etc
And so on.
Can we see a real-life example?
Sure, see below a beautiful real-life PKCS#7-structure.
Coming to the more important term.
What is CMS?
CMS stands for Cryptographic Message Syntax which is the same name as the name of the PKCS #7 standard.
In fact, it is the same, just different organization.
As we’ve learned above, PKCS #7 was defined by a company, then it was handed over to the IETF in 1999 and renamed to CMS.
Some improvements were done and the current version of the CMS standard was published as RFC5652 in 2009.
What's the difference to PKCS number 7?
Major difference to PKCS#7 v 1.5 :
The type Signed-and-enveloped data was removed and the type Authenticated-Data (MAC) was added.
What is the strange look of the specs?
The CMS spec uses ASN 1 which stands for Abstract Syntax Notation One.
It is a standard maintained by ITU (International Telecommunication Union) and describes a language for declaring data structures.
The last question would be:
How to do it in practice?
The processes of cryptographically securing messages and putting all together and dealing with binary content, etc.... all this cannot be done by humans.
Developers can use cryptography libraries like Java IAIK, Bouncy Castle or OpenSSL (c-libs).
For end users, there are tools like OpenSSL command line tools.
For Low-Code users, there’s SAP Cloud Integration, which supports 3 types:
Signed-Data
Enveloped-Data
Signed-and-Enveloped-Data
As we know, the last one was defined in PKCS #7 and omitted later in CMS.
SAP Cloud Integration allows the user to encrypt, decrypt, sign, verify messages based on CMS and PKCS #7.
The user only needs to place a shape in the graphical editor and everything will work out of the box.
However, to understand what’s happening or to understand the many possible configuration options, some blog posts are useful.
I hope.
Blow CMS structure was created by OpenSSL which has a parameter for printing the CMS structure to the console or to a file.
The example was taken from a message with digital signature and the content plus certificate are included.
For better readability, I've shortened some parts.
Basically, the PKCS #7 / CMS standard has 2 purposes:
After going through the foundation for understanding the Standards, we're prepared for using and understanding the Integration Flow Designer of SAP Cloud Integration.
And here are the corresponding blog posts:
Understanding the PKCS #7 / CMS Signer
Understanding the PKCS #7 / CMS Encryptor
SAP Help Portal
Docu for PKCS#7/CMS Encryptor
Docu for PCKS#7/CMS Signer
Docu for Message-Level Security
CMS
The CMS spec can be found here or here and even here
Wikipedia: CMS, Cryptographic Message Syntax
The spec for PKCS #7 can be found here.
S/MIME builds on top of CMS
CMS extension for CompressedData type
OID:
Wikipedia:OID, Object Identifier
Web-tool to search for OIDs
OpenSSL
Official list of unofficial binaries download page
Docu home
Docu for cms command
Understanding the PKCS #7 / CMS Signer
Understanding the PKCS #7 / CMS Encryptor
Security Glossary Blog
SAP Cloud Integration provides functionality to automatically add security features to our messages (so-called message-level security).
We don’t need to worry much about the formats and standards used to encrypt or sign the messages.
However, when it comes to specify the configuration options, we start wondering what they mean.
Fortunately, we find the signer and encryptor blogs in the community, which explain the settings.
However, they’re not going into detail about the standard itself.
So let me try to explain the standard with my own simple words.
Note: I've tried to explain all of those tedious security-related terms, in case anything's missing, please refer to the Security Glossary Blog.
Overview
We'll introduce into the topic along with the following sections:
History
How I imagine that it started:
Timmy from Texas wanted to share some secret info with his friend Taku in Tokyo.
So he encrypted a message and sent it to Taku.
Taku was unable to decrypt and read the message.
So Timmy travelled to Tokyo to enjoy some food and to explain the way how he encrypts and packages his messages.
Afterwards, Taku in Tokyo was able to decrypt and read all messages (even before breakfast).
Some time later, same situation happened with his friend Toto in Togo.
Although the food is said to be great, Timmy decided not to travel, but to invite his friends for a conference at home.
They had international food, late-night discussions and at the end, they agreed on a common way of sending secure messages.
As a consequence, everybody in the world can send secure messages and the recipients can understand the message, as long as they follow that agreement.
Does that make sense?
Really makes sense, especially the section about the international food (which didn’t make it into the specification).
What do we learn from this story?
People communicating with each other need to agree on some basic principles:
- How encryption is done, which steps in which order
- which algorithm is used
- Certificate information to ensure authentication
- Info about sender
- Fingerprint
- And finally: where is that information stored
PKCS #7
While that story is purely fantasy, these needs were captured in reality by a company called RSA Security LLC in the 1990s.
This company designed security standards and collected them in a series of standards called PKCS, which stands for Public Key Cryptography Standards.
What is a Standard?
In my simple words: Experts from all over the world come together to “agree” on a way of doing something.
The result is a guideline and signed as agreement by the experts.
That agreement on a guideline is published as “Standard” and can be maintained by an organization, for instance IETF (Internet Engineering Task Force).
What is PKCS #7?
The seventh PKCS standard was dedicated to describe a way of securely transmitting messages over the internet.
This seventh one is called Cryptographic Message Syntax.
The latest version is 1.5 and can be found here, the RFC number is 2315.
What is RFC?
It stands for "Request for Comments" and is typically a document containing a specification.
Usually created by international volunteers and maintained by IETF, has gone through several review processes. After agreement, a number is assigned and it is published (and further maintained) via the rfc-editor, to which links point.
What dies the PKCS #7 standard say?
The specification doesn’t contain concrete commands or proposal for usage of e.g. a specific algorithm like AES.
The sender of a message can encrypt it with whatever algorithm, but the standard specifies where the information about the used algorithm is maintained. As such, the recipient can look up which algorithm he needs to use for decryption.
Like this, there’s multiple information and types of information that need to be sent along with the message.
What Information?
First of all: Do we want to encrypt the message? Or do we want to sign the message? Or both together?
As an example, if we want to send a message and sign it, we will refer to the section of the spec called “Signed-data”.
We learn that the PKCS #7 standard defines different ways of securing messages and gives them a name. These are the “types” or “content types”.
The following content types are defined in PKCS #7:
- Data
- Signed Data
- Enveloped Data
- Signed-and-enveloped data
- Digested data
- Encrypted data
Short info:
1. The first one is just any data (text or image or whatever)
It is specified, because the other types refer to it.
2. Signed Data means that a digital signature is created on the message.
3. Enveloped Data
The message is encrypted with a symmetric key that is generated on the fly.
This key is encrypted with asymmetric key pair.
The content and the key and certificate and fingerprint, etc
there are many infos that need to be sent to the receiver.
Each info is structured and referred to via a content type.
All of it stored in an envelope, that’s the reason for the name.
4. Signed-and-enveloped data
Means that both, signing and encrypting is done in one step.
5. Digested data refer to just the hash and the content
6. Encrypted data refers to the encrypted data
How does it work?
So if we have a closer look at e.g. the SignedData, we will wonder:
How does the receiver know that the received message is structured in a SignedData-way?
How does he know which algorithm to choose for decrypting the digest?
How does he get hold of the required certificate for decrypting
How does he know that the included certificate is correct and valid?
Once decrypted, how does he get a hold of the digest and which algorithm to use?
If he wants to validate the time, when the signature was created, how does he find it?
The answer is:
Everything that is required, is contained in the data structure, which I like to call "package" (like a classic package that is sent with FedEx).
So if we send a message according to PKCS #7, it is like sending a package, containing multiple artifacts and informations.
And the PKCS#7 standard is like a paper which is attached to the package, like a table of content, such that the receiver knows where to find the corresponding info for each unpackage-step.
How to find all the info?
We can see that there are many elements defined in the spec and each element needs to uniquely be targeted.
So it is necessary to assign an ID to each element, or better: to each type (this is PKCS7-language).
This is done in form of OIDs.
What is an OID?
This is the abbreviation of “Object Identifier”.
What Object Identifier?
This is the attempt of giving everything in the world a unique identifier, which allows to describe it and exactly refer to it.
OIDs are structured in a tree hierarchy and the flattened notation is a chain of numbers separated by dots.
Example: 1.2.840.113549.1.7.1
If you encounter such an OID, you can go ahead and search for it in this repository web page.
Then enjoy the description of each tree node and see the rfc that defined the OID, resp child nodes.
So to pick one example from above:
The time of the signature is an element in a list of “Signed Attributes” and has the OID 1.2.840.113549.1.9.5, which can be found in the spec.
How does a structure look like?
Below I’ve listed an excerpt from the type structure defined by PKCS#7:
SignedData
digestAlgorithms
encapContentInfo
certificates
crls
signerInfos
digestAlgorithm
signedAttrs
signatureAlgorithm
signature
unsignedAttrs
The element “encapContentInfo” contains the actual message content, which stays encapsulated in the PKCS7-package. It contains 2 sub-elements: the content itself and the type of the content.
The element “crls” stands for a list CRLs (Certificate Revocation List) and is optional.
Below diagram tries to illustrate how a PKCS#7-based message could look like:
We can see an envelope representing the message.
The message contains the actual content, including an info about its content type.
The message also contains the certificate, as well as the info about the certificate (serial number, the owner, etc).
Furthermore, we can see that the SignerInfo is again a structured data type which contains artifacts like the digital signature as well as metadata about the signature (algorithm), etc
And so on.
Can we see a real-life example?
Sure, see below a beautiful real-life PKCS#7-structure.
CMS
Coming to the more important term.
What is CMS?
CMS stands for Cryptographic Message Syntax which is the same name as the name of the PKCS #7 standard.
In fact, it is the same, just different organization.
As we’ve learned above, PKCS #7 was defined by a company, then it was handed over to the IETF in 1999 and renamed to CMS.
Some improvements were done and the current version of the CMS standard was published as RFC5652 in 2009.
What's the difference to PKCS number 7?
Major difference to PKCS#7 v 1.5 :
The type Signed-and-enveloped data was removed and the type Authenticated-Data (MAC) was added.
What is the strange look of the specs?
The CMS spec uses ASN 1 which stands for Abstract Syntax Notation One.
It is a standard maintained by ITU (International Telecommunication Union) and describes a language for declaring data structures.
Tool Support
The last question would be:
How to do it in practice?
The processes of cryptographically securing messages and putting all together and dealing with binary content, etc.... all this cannot be done by humans.
Developers can use cryptography libraries like Java IAIK, Bouncy Castle or OpenSSL (c-libs).
For end users, there are tools like OpenSSL command line tools.
For Low-Code users, there’s SAP Cloud Integration, which supports 3 types:
Signed-Data
Enveloped-Data
Signed-and-Enveloped-Data
As we know, the last one was defined in PKCS #7 and omitted later in CMS.
SAP Cloud Integration allows the user to encrypt, decrypt, sign, verify messages based on CMS and PKCS #7.
The user only needs to place a shape in the graphical editor and everything will work out of the box.
However, to understand what’s happening or to understand the many possible configuration options, some blog posts are useful.
I hope.
Example Structure
Blow CMS structure was created by OpenSSL which has a parameter for printing the CMS structure to the console or to a file.
The example was taken from a message with digital signature and the content plus certificate are included.
For better readability, I've shortened some parts.
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha512 (2.16.840.1.101.3.4.2.3)
parameter: NULL
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
001e - 2d 2d 2d 2d 2d 2d 2d 0d-0a 2d 20 53 65 63 72 -------..- Secr
002d - 65 74 20 70 6c 61 69 6e-20 74 65 78 74 20 6d et plain text m
003c - 65 73 73 61 67 65 20 63-6f 6e 74 65 6e 74 20 essage content
0069 - 2d 2d 2d 2d 2d 2d 2d 2d-2d 2d ----------
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 17034094456647405626
signature:
algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11)
parameter: NULL
issuer: CN=crdemocert
validity:
notBefore: Jan 26 13:33:04 2023 GMT
notAfter: Feb 25 13:33:04 2023 GMT
subject: CN=crdemocert
key:
algor:
algorithm: rsaEncryption (1.2.840.113549.1.1.1)
parameter: NULL
public_key: (0 unused bits)
0000 - 30 82 01 0a 02 82 01 01-00 fa 59 fb 54 da 0.........Y.T.
00ee - d7 31 4a 4d f4 a9 3a 8b-44 78 af d8 c8 46 .1JM..:.Dx...F
00fc - 3c 41 50 e1 59 a1 6f 06-58 a2 a3 2f 7b 02 <AP.Y.o.X../{.
010a - 03 01 00 01 ....
extensions:
object: X509v3 Subject Key Identifier (2.5.29.14)
critical: BOOL ABSENT
value:
0000 - 04 14 3b c3 14 39 a3 0a-50 26 e5 ba c1 ..;..9..P&...
000d - af 7c af 95 a6 64 c2 d5-60 .|...d..`
object: X509v3 Authority Key Identifier (2.5.29.35)
critical: BOOL ABSENT
value:
0000 - 30 16 80 14 3b c3 14 39-a3 0a 50 26 e5 0...;..9..P&.
000d - ba c1 af 7c af 95 a6 64-c2 d5 60 ...|...d..`
object: X509v3 Basic Constraints (2.5.29.19)
critical: TRUE
value:
0000 - 30 03 01 01 ff 0....
sig_alg:
algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11)
signature: (0 unused bits)
0000 - 6e ca 78 b0 db 25 f5 a6-be bc 8d 13 2e 82 43 n.x..%........C
00e1 - 3f b5 78 fa 6d 7c 0b 76-1d 0f 86 a2 15 47 a8 ?.x.m|.v.....G.
00f0 - fa f2 44 2d e8 af ae f4-53 b1 e0 06 40 ac 2d ..D-....S...@.-
00ff - 4e N
crls:
<EMPTY>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: CN=crdemocert
serialNumber: 17034094456647405626
digestAlgorithm:
algorithm: sha512 (2.16.840.1.101.3.4.2.3)
parameter: NULL
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
value.set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
value.set:
UTCTIME:Feb 3 14:31:00 2023 GMT
object: messageDigest (1.2.840.113549.1.9.4)
value.set:
OCTET STRING:
000d - 10 11 58 97 76 77 42 a5-58 0d e6 ec ab ..X.vwB.X....
0034 - cc 32 a4 db 18 a4 4d fa-fd 95 bb 2f .2....M..../
object: undefined (1.2.840.113549.1.9.16.2.47)
value.set:
SEQUENCE:
0:d=0 hl=2 l= 78 cons: SEQUENCE
2:d=1 hl=2 l= 76 cons: SEQUENCE
4:d=2 hl=2 l= 74 cons: SEQUENCE
6:d=3 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:CBD22BAD927ECF56713EAE3393
40:d=3 hl=2 l= 38 cons: SEQUENCE
42:d=4 hl=2 l= 25 cons: SEQUENCE
44:d=5 hl=2 l= 23 cons: cont [ 4 ]
46:d=6 hl=2 l= 21 cons: SEQUENCE
48:d=7 hl=2 l= 19 cons: SET
50:d=8 hl=2 l= 17 cons: SEQUENCE
52:d=9 hl=2 l= 3 prim: OBJECT :commonName
57:d=9 hl=2 l= 10 prim: UTF8STRING :crdemocert
69:d=4 hl=2 l= 9 prim: INTEGER :EC6542A866EB503A
signatureAlgorithm:
algorithm: sha512WithRSAEncryption (1.2.840.113549.1.1.13)
parameter: NULL
signature:
0000 - e2 42 05 a8 22 d9 5e de-90 8e 09 44 73 9c 7f .B..".^....Ds..
000f - 82 7e 62 d7 79 92 ec f1-1c 8d fd 44 d8 c5 16 .~b.y......D...
002d - 26 7a f3 91 fb 70 86 33-94 9a de c6 4b 84 b7 &z...p.3....K..
00f0 - 67 ca ff b1 8c d2 ac 65-38 7d df 28 05 7e 62 g......e8}.(.~b
00ff - 2e .
unsignedAttrs:
<EMPTY>
Key Takeaways
Basically, the PKCS #7 / CMS standard has 2 purposes:
- define a fix structure
So the sender will store all required information and data in a structured way
And the receiver knows where to grab the required info from - define types
So when the sender creates artifacts (like signature, key) he knows how to classify them
And the receiver knows what kind of artifacts are contained in the package and how to read them and apply the info
Next Steps
After going through the foundation for understanding the Standards, we're prepared for using and understanding the Integration Flow Designer of SAP Cloud Integration.
And here are the corresponding blog posts:
Understanding the PKCS #7 / CMS Signer
Understanding the PKCS #7 / CMS Encryptor
Links
SAP Help Portal
Docu for PKCS#7/CMS Encryptor
Docu for PCKS#7/CMS Signer
Docu for Message-Level Security
CMS
The CMS spec can be found here or here and even here
Wikipedia: CMS, Cryptographic Message Syntax
The spec for PKCS #7 can be found here.
S/MIME builds on top of CMS
CMS extension for CompressedData type
OID:
Wikipedia:OID, Object Identifier
Web-tool to search for OIDs
OpenSSL
Official list of unofficial binaries download page
Docu home
Docu for cms command
Understanding the PKCS #7 / CMS Signer
Understanding the PKCS #7 / CMS Encryptor
Security Glossary Blog
- SAP Managed Tags:
2 Comments
