What's missing in PDF 2.0?

PDF 2.0 (ISO 32000-2): What's missing?

Security-related Clarifications for PDF are sorely needed

Many developers and users have a wish-list of features they’d like to see in future versions of PDF. Many of these wishes have been included in PDF 2.0 in a collaborative international process. On this page we won’t go into graphical, interactive or technical additions to PDF, but focus on topics related to security.

PDF 2.0 declares a number of outdated cryptographic algorithms as deprecated, which is a good thing. Unfortunately, there are still a number of security-related shortcomings in PDF 2.0 which may have the following consequences:

  • PDF documents may not be fully compatible among applications because PDF 2.0 leaves some technical details unspecified. Some of the items below have already been implemented in Acrobat (e.g. digital signatures with certain elliptic curves). While this is a good move in general, already now it leads to a situation where the latest and greatest PDF 2.0 standard does not cover certain PDF documents which have been created in recent years.
  • PDF security may exhibit cryptographic weaknesses since it doesn’t leverage advances in science and technology. Note that we are not talking about the latest crypto hypes here, but rather cryptographic progress from the last 10-15 years which brought established and well-understood security improvements.

Of course there is a fundamental conflict between keeping the PDF format well-defined and specific on the one hand, while keeping security mechanisms up to date on the other hand. However, PDF 2.0 security is missing many important improvements from a long period of time. Also, a simple mechanism could be introduced which identifies the security requirements of a document. As a result, the current Acrobat messages

invalid format
or
Internal cryptographic library error
could be replaced by the more user-friendly
Document uses an encryption method which is not supported in this product.

Designing cryptographic applications, formats and protocols in a modular manner to facilitate security enhancements is state of the art. Although static file formats have different requirements than on-line protocols, let’s mention that negotiating common cryptographic algorithms between client and server is an important aspect of the TLS protocol.

To be fair, the ISO committee for PDF 2.0 considered some of the issues discussed below, but for timing or other reasons no corresponding stipulations made it into the PDF 2.0 standard.

Digital Signatures

For a long time RSA (RFC 5652) has been the dominant public key algorithm; key lengths go up to 8192 bits.

RSA Key Length

Depending on the document life cycle different RSA key lengths may be required. Security guidelines are regularly updated to recommend longer RSA keys to provide sufficient security margins. However, PDF 2.0 does not specify which key lengths are actually supported. (More precisely: only two contradicting old notes regarding PDF 1.5 remain in the text: one claiming that PDF 1.5 supports up to 2048-bit keys, and another note mentioning keys up to 4096-bit length).

While the maximum supported key length in Acrobat has been increased over the years (algorithm and key length summary), Acrobat DC is still inconsistent: while the Windows version supports 8192 bit keys, Acrobat for OS X cannot process keys of this length.

Encoding Method for RSA Signatures

RSA signatures require an encoding method (Encoding Method for Signatures with Appendix, EMSA). The default encoding method according to PKCS#1 v1.5 is supported in all Acrobat versions. However, it is being phased out in modern security guidelines. A more secure alternative encoding method called Probabilistic Signature Scheme (PSS) has been standardized in PKCS#1 v2.2 and RFC 3447 in 2003.

EMSA-PSS is state of the art for RSA signatures and recommended or required in many security guidelines, for example:

  • RFC 3447 and its successor RFC 8017 recommend to replace PKCS #1 v1.5 with EMSA-PSS for new applications »in the interest of increased robustness«.
  • The algorithm catalog published by the German Bundesnetzagentur in its 2017 draft allows the old PKCS#1 v1.5 scheme only until the end of 2017, but recommends EMSA-PSS for longer-term applications.
  • ETSI TS 119 312 defines the cryptographic suites on which the PAdES standards are based. It still supports the PKCS#1 v1.5 method, but recommends EMSA-PSS. For this reason European vendors of signature software already started the move to EMSA-PSS.

Unfortunately, EMSA-PSS is not included in PDF 2.0. Acrobat XI and DC support validation of PSS signatures starting with the November 2017 release. Acrobat DC Continuous track introduced support for creating signatures with EMSA-PSS. Since this feature doesn't yet have any API it must be enabled in the registry (see instructions).

PDFlib PLOP DS supports EMSA-PSS with the option rsaencoding=pss.

Elliptic Curve (ECDSA) Signatures

While PDF 1.7 per ISO 32000-1 supports RSA and DSA signatures, PDF 2.0 adds support for ECDSA signatures based on Elliptic Curve cryptography according to RFC 5480 (initial publication as FIPS 186-2 in 2000). An ECDSA signature is based on a specific type of elliptic curve, and many such curves are available for implementers. However, PDF 2.0 doesn’t specify which curves are supposed to be supported in PDF software. Given the vagueness of ISO 32000-2 it isn’t clear whether PDF documents with a certain ECDSA signature conform to the standard. Modern applications of Elliptic Curve cryptography are often based on one of the following curves:

  • The most common curves are called P-256, P-384 and P-521. These curves are supported in Acrobat XI and above (algorithm summary).
  • The NIST publication FIPS 186-2 contains twelve additional curves recommended by NIST. These are supported in Acrobat XI and above, but only when Acrobat directly accesses the certificate/digital id; they are not supported via the Windows certificate store or OS X key chain.
  • Brainpool curves are specified in RFC 5639 (initial publication 2005). They are used in many applications including the German national identity card. Brainpool curves are not supported in Acrobat DC and below.

In the list above we didn’t take into account modern curves which cannot be used with the ECDSA signature scheme, but would require a different signature algorithm. Most notably, Curve25519 per RFC 7748 (initial publication 2006) may be a suitable successor for the 15 NIST curves.

The choice of elliptic curves for digital signatures isn’t just an academic exercise. In fact, for several years there has been a discrepancy between signature algorithms required by various security guidelines and the algorithms available in Acrobat. Only a subset of signatures created according to EU regulations can be validated with Acrobat.

PDFlib PLOP DS supports EC-based signatures with NIST and Brainpool curves. Since Brainpool signatures are not Acrobat compatible they require the option conformance=extended.

Password Security

Password-based PDF encryption started out with the RC4 encryption algorithm in the 1990s and gradually progressed to AES-256 (overview of encryption algorithms for PDF password security). PDF 2.0 deprecates most of the algorithms, keeping only the Acrobat X flavor of AES-256 encryption (called AESV3 in PDF). Focusing on a well-established strong encryption method certainly is a good thing.

However, not all modes of operation for symmetric block ciphers such as AES are born equal. PDF mandates the use of AES in Cipher Block Chaining mode (CBC), invented in 1976. CBC requires a random initialization vector at the start of each encrypted stream and padding at the end. CBC keeps the protected content confidential, but does not protect from accidental or deliberate modification of the encrypted data. While modifications can be detected with an additional signature, there are authenticating encryption modes which provide both confidentiality and integrity in a combined operation. This is called authenticated encryption.

A widely used authenticated encryption mode is called Galois Counter Mode (GCM). It has been published as NIST 800-38D in 2007 and also been standardized in ISO 19772:2009. GCM is being used in many cryptographic protocols including IPSec, TLS, and IEEE 802 WiFi security.

Including GCM would be a welcome addition to PDF security. Since AES encryption is also a building block for certificate security, the same suggestion applies there.

Update 2020-02: The Encryption Adhoc group within the ISO committee is working on a proposal to include GCM as an extension to ISO 32000-2.

Certificate Security

Longer Seed Value

Certificate Security is composed of multiple encryption steps with asymmetric and symmetric algorithms; see here for an overview. In the first step a random Content Encryption Key (CEK) is generated based on a 20-byte random seed value. However, this 160-bit value is shorter than the key length of AES-256. According to the »weakest link« paradigm full 256-bit security can no longer be achieved given the short 160-bit seed value. A seed value of 256-bit should be used instead.

Certificate Security (Key Exchange) based on RSA

Certificate security, also called public key security has been available since PDF 1.4. For a long time RSA (RFC 5652) has been the dominant public key algorithm; supported key lengths gradually approached 8192 bits (overview of public key algorithms for PDF certificate security).

Certificate security involves a building block called key exchange which creates a random key and encrypts it with RSA. RSA encryption requires a padding method which prepares data for the RSA algorithm. The traditional padding method has been found susceptible to the so-called Bleichenbacher attack (original paper from 1998), also called Million Message Attack (MMA). This method has successfully been used in practical attacks against the SSL protocol. While the threat scenarios for Web servers and PDF documents are different, known security flaws such as the Bleichenbacher attack should be fixed nevertheless.

An improved padding method called Optimal Asymmetric Encryption Padding (OAEP) according to PKCS#1 version 2.1 in RFC 3447 from 2003) thwarts the Bleichenbacher attack.

Unfortunately PDF 2.0 does not clarify whether RSA-OAEP is supported since it references RFC 5652 where RSA-OAEP is optional.

PDFlib PLOP supports RSA-OAEP with the option rsapadding=oaep. Since the output is not Acrobat compatible this requires the option conformance=extended.

The comment regarding key lengths for RSA signatures above also applies to certificate security: the key lengths available in PDF should be specified explicitly.

Certificate Security (Key Exchange) based on Elliptic Curves

An RSA alternative called ECDH (Elliptic Curve Diffie-Hellman) offers security and performance advantages over RSA. ECDH is supported since Acrobat XI (algorithm summary). However, Adobe’s implementation does not conform to any published standard and is therefore not compatible with third-party implementations (in specific cases there is even an incompatibility between Acrobat XI and DC). This leaves us in the unfortunate situation that Acrobat XI/DC uses ECDH outside of any standard, which makes encrypted files incompatible to third-party implementations.

ISO 32000-2 references RFC 5652 which describes the CMS (Cryptographic Message Syntax) container holding the encrypted key information, but it does not clarify which of the CMS options are available in PDF 2.0. Since ISO 32000-2 does not refer to RFC 5753 which specifies the use of ECDH within CMS, we must assume that the important use case of certificate security based on Elliptic Curves is not supported in PDF 2.0.

Let’s assume for a moment that PDF might support Elliptic Curve encryption according to RFC 5753. In this case it would have to be clarified which optional features of RFC 5753 are meant to be available in PDF. For example, several key agreement algorithms for ECDH are listed in RFC 5753, based on different hash functions for the key derivation function (KDF). A specific combination called dhSinglePass-stdDH-sha256kdf-scheme must be supported by all implementations, while others such as dhSinglePass-stdDH-sha512kdf-scheme are optional in RFC 5753. As it happens, the latter is not available in the Microsoft Crypto API, which means that documents encrypted with this method cannot be decrypted if the credentials are located in the Windows certificate store. While dhSinglePass-stdDH-sha512kdf-scheme is available in the newer Windows interface called CNG (Cryptography Next Generation) interoperability requires that the PDF standard clarifies support of crypto features which are optional in RFC 5753 and others.

PDFlib PLOP supports EC-based certificate security with NIST and Brainpool curves. Since documents encrypted with Brainpool curves are not Acrobat compatible they require the option conformance=extended.

Summary of Suggestions

The table below summarizes the suggested clarifications for PDF discussed on this page.

topic Acrobat DC PDF 2.0 (ISO 32000-2) suggested PDF extension
digital signatures
encoding method for RSA signatures PKCS#1 v1.5 encoding; Acrobat XI/DC on Windows (since January 2017) also EMSA-PSS encoding method not explicitly mentioned support EMSA-PSS
key length for RSA signatures up to 8192 bit on Windows; lower limit on OS X unspecified specify supported RSA key lengths
Elliptic Curve signatures ECDSA with NIST-15 curves supported ECDSA supported, but curves not specified specify supported curves for ECDSA
password security
AES encryption for password security only CBC mode only CBC mode support Galois Counter Mode (GCM)
certificate security
key length for RSA certificate security up to 8192 bit on Windows; lower limit on OS X unspecified specify supported RSA key lengths
padding for RSA certificate security only PKCS#1 v1.5 padding only PKCS#1 v1.5 padding support RSA-OAEP
certificate security based on Elliptic Curves (ECDH) proprietary and incompatible use of ECDH; fixed in Acrobat DC 17.012.20093 Continuous track and Acrobat DC Classic 15.6.30352 (August 2017 updates) ECDH support not explicitly specified support ECDH and specify supported curves