PKCS #7 and the Cryptographic Message Syntax Standard

Computer science, mathematics, and cryptology are closely related disciplines. Requirements arising from human life have accelerated research and development in these fields. Cryptological applications have consequently been used in cybersecurity, defence, communications, electronic signatures, electronic commerce, personal-data protection, and many other domains.

Studies in this field have shown that public-key cryptography, in which different public and private keys are used for encryption and decryption, can provide stronger security properties than many alternative approaches.

As in every area of science and engineering, standards are required to establish reliability and interoperability. The standards known collectively as PKCS were therefore published for public-key cryptography.

PKCS #7 was developed within this framework to define syntax rules for cryptographic messages. Together with the other PKCS standards, it gained broad acceptance and widespread use.

HISTORY

In 1991, the security company RSA published the first PKCS specification, elaborating the cryptographic standard that bore the same name. RSA, founded by Adi Shamir, Len Adleman, and Ron Rivest, later published PKCS #3 for the key-exchange algorithm commonly known as Diffie-Hellman. PKCS #5 proposed a password-based cryptography standard, while PKCS #6 proposed an extended standard for certificate syntax. Other standards not discussed here were subsequently withdrawn.

PKCS #7 later introduced what became one of the most widely accepted approaches to the syntax of cryptographic messages. Version 1.5 of the standard was published in 1998.

RSA continued to develop related specifications after PKCS #7. Conferences and working sessions held periodically have supported the revision and further development of the standards.

Although PKCS was introduced primarily by RSA, it has also been implemented and adapted by organisations such as Apple, Microsoft, and MIT. It is now accepted in many cryptographic applications and has become substantially more suitable for dependable implementation.

OPERATION

PKCS #7 defines a syntax for cryptographic messages together with signing, verification, and transmission processes. The digital signature used in this context provides an identity assurance for the signer. It also enables the recipient to verify that an encrypted message reached its destination without being altered during transmission.

When a message is signed, a digest is first calculated from the message content at the source. The digest is then encrypted through a private-key operation using an algorithm such as RSA or DSA. The source message and the encrypted digest representing the signature are subsequently sent to the recipient.

The encrypted digest received by the destination is recovered with the public key corresponding to the source's private key. The source and destination use the same digest algorithm. The message content may also be encrypted and decrypted. In every case, the digest supplied by the source is compared with a digest recalculated by the destination, thereby verifying the signature.

Encryption is used during signing workflows when message content must be readable only by the source and destination. The source encrypts the message content with a symmetric key. That symmetric key is itself encrypted with a public key. At the destination, the corresponding private key is used to recover the symmetric key, after which the message content is decrypted.

CRYPTOGRAPHIC MESSAGE SYNTAX (CMS)

As noted above, a generally accepted syntax is required for messages involved in encryption, signing, transmission, and verification. PKCS #7 addresses this requirement and supports the reliability of the associated processes.

CMS allows data to be treated as an encapsulated object together with the other information required by the cryptographic process. These objects, commonly described as envelopes, may be nested. Information carried alongside the message content supports decryption and stronger verification.

PKCS #7 implementations may use comparatively simple encryption algorithms and smaller envelopes where appropriate. In such cases, the structure represents basic content.

For stronger assurance, however, an enhanced content structure is generally preferred. Data is encrypted with algorithms intended to provide greater security, and the signing and verification stages are designed to offer stronger assurance.

Enhanced classes may be designed to include the properties of a base class. In this interpretation, the base-class data forms the inner content, while the additional properties of the enhanced class form the outer content. Inheritance-based architectures from object-oriented programming can simplify implementation of this structure.

CMS syntax begins with a Content Type field. It is followed, in order, by version information, optional originator information, recipient information, a message authentication code (MAC) algorithm, an optional digest algorithm, encapsulated content information, optional authenticated attributes, the resulting MAC value, and optional unauthenticated attributes.

If the encapsulated content includes a message digest, the object is treated as signed data and the content type is specified as SignedData. Data containing both encrypted content for its recipients and the related encryption-key information is treated as enveloped data, for which the content type is EnvelopedData. Data may also be both signed and enveloped.

Unlike enveloped content, data that contains only the encrypted content, without recipient and key information, is treated as encrypted data and identified with the EncryptedData content type.

If only the content-type information and digest are present, the object is treated as digested data and the content type is DigestedData.

PADDING

Cryptographic algorithms may add content-independent data to the beginning, middle, or end of a message. Padding can be used to obtain a standard data size and, in some designs, to make cryptanalysis more difficult.

Under the PKCS #7 padding scheme, the number of bytes added is also the value written into each added byte. For example, if ten padding bytes are required, each added byte has the decimal value 10, or 0x0A in hexadecimal.

Because a one-byte unsigned integer can hold at most 255, larger values require additional storage. If the content length is already an exact multiple of the block size, an additional block of padding is appended.

Because padding follows a defined standard, the recipient can determine which part of the recovered data is the original content and which part consists of padding bytes.

The padding approach defined by PKCS #7 is similar to the scheme defined by PKCS #5. PKCS #5 differs in that it is based on an eight-byte, or 64-bit, block size.

CRYPTANALYSIS AND RELATED WORK

PKCS #7 is a standard for message syntax and associated processing. The encryption algorithm itself and cryptanalysis of that algorithm are outside the scope of the standard. The message syntax and padding process defined directly by the standard can nevertheless be examined cryptanalytically.

Padding attacks, side-channel attacks, and brute-force attacks can be used in cryptanalysis, and weakly protected PKCS #7 or CMS messages may be recovered under suitable conditions.

This article examines the padding attack in detail and presents a cryptanalysis implementation developed in Python.

CRYPTANALYSIS DETAILS

As explained in the padding section, PKCS #7 specifies a standard padding process. The analysis is based on software commonly called an oracle, which reports whether padding in a message block is valid. This method is generally used when a block cipher operates in cipher-block chaining (CBC) mode. A system error or an invalid calculated result indicates that the padding is invalid and therefore that the trial value is incorrect.

Consider encrypted blocks C1, C2, and C3 and plaintext blocks P1 and P2. Different analysis scenarios are possible. If the cryptanalyst wants to recover P2 and knows that padding occurs only in the final block, the last byte of C1 can be modified during the attack. Under the relevant algorithm, all of P1 changes, whereas only the last byte of P2 changes. The oracle then determines whether padding in P2 is valid. By performing a number of iterations proportional to the block size, the final byte of P2 can be recovered.

A side-channel attack may also reveal parts of the encryption algorithm or its parameters by observing different encrypted and decrypted blocks. In a brute-force approach, all possibilities are tested, which may permit recovery of CMS data protected by weak security. Where the search space is large, parallel algorithms and GPU-accelerated implementations can shorten the time required to reach a result.

EVALUATION

PKCS #7 and its message-syntax approach have been widely accepted by software and hardware vendors. Standards used in websites, electronic-mail systems, electronic-signature software, and certificate applications make it possible to develop reliable projects that interoperate across platforms.

The use of encrypted and enveloped data types, together with full compliance with the standards, makes encrypted information more difficult to recover without authorisation. In practice, default configurations in widely used PKCS implementations often provide a high level of security.

Although PKCS #7 is used in many areas, it is particularly associated with electronic-signature systems. Systems requiring high security and reliability frequently combine biometric access methods with electronic signatures. PKCS #7 and related standards help prevent signatures from being imitated or reused.

PKCS #7 also provides a format used with SSL certificate chains on web and e-mail servers. Related files commonly use the P7B or P7C extension. Their content is represented as a data block, typically delimited by BEGIN and END markers, and does not contain a private key. These certificates share characteristics with the PEM and DER SSL formats and with the PFX format defined by PKCS #12.

The OpenSSL library can be used to develop applications involving PKCS certificates, as it can with other SSL formats. It provides extensive configuration options for message formatting, encryption, enveloping, and verification.

Taken together, the PKCS standards provide important mechanisms for data integrity, strong authentication, and confidentiality.

OTHER PKCS STANDARDS

PKCS does not prescribe a single default encryption algorithm; it describes a general message syntax. Encryption algorithms used by implementations are covered by other PKCS standards.

PKCS #1 defines the RSA cryptographic standard. The algorithm operates with a value n formed by multiplying two large prime numbers, p and q. A value e is chosen that is relatively prime to the value produced by the totient calculation based on one less than each factor.

PKCS #3 describes the key-exchange algorithm also known as Diffie-Hellman. The method is based on establishing private and shared key material over an insecure medium and subsequently using the resulting shared secret to protect data.

PKCS #5 defines password-based cryptography and padding.

PKCS #6 provides an extension to certificate syntax.

PKCS #8 defines a syntax standard for private-key information.

PKCS #9 defines standards for selected object classes and related attributes.

PKCS #10 defines a format for certificate requests.

PKCS #11 defines a standard for cryptographic token interfaces.

PKCS #12 defines a syntax standard for exchanging personal information.

PKCS #13 defines standards related to elliptic-curve cryptography.

PKCS #14 addresses pseudorandom and random-number generation.

PKCS #15 defines a standard for formatting cryptographic-token information.

PYTHON CRYPTANALYSIS IMPLEMENTATION

The padding-attack method examined in this article was implemented in Python and applied to sample data. The project was developed after examining examples available on GitHub, uses a module named OracleModule, and performs PKCS #7-compatible padding operations. The encrypted value was ultimately recovered with the method described above.

REFERENCES

Public-Key Cryptography, Wikipedia. Accessed 19 February 2021.

Aterya, M. Introduction to PKCS Standards, 2016.

Baidya, B. Public-Key Cryptography Standards, 2014. Accessed 19 February 2021.

Klima, V., and Rosa, T. Side-Channel Attacks on CBC-Encrypted Messages in PKCS #7, 2013. Czech Republic.

Padding in Cryptography, Wikipedia. Accessed 19 February 2021.

Cryptographic Message Syntax Standard, Wikipedia. Accessed 19 February 2021.

Microsoft Docs. PKCS #7 Cryptographic Message Syntax Concepts, 2018. Accessed 20 February 2021.

Padding Oracle Attack, Wikipedia. Accessed 19 February 2021.

Parker, A. Introduction to Digital Signatures and PKCS #7, 2018. Accessed 19 February 2021.

How PKCS #7 Works, SAP Help Portal. Accessed 19 February 2021.

RSA Laboratories Technical Note. PKCS #7 Cryptographic Message Syntax Standards, 1993.

Wang, Yongge. Public-Key Cryptography Standards, 2012. University of North Carolina.