Enhancing Digital Signature Security with Secure-by-Default Verification plus MDP

When stakeholders perform critical business transactions, they want to trust their signed documents' authenticity and integrity. A sort of "electronic" fingerprint, or coded message, a digital signature provides a way to create that trust. And organizations will often digitally sign PDFs, the accepted standard for various legally binding documents, from contracts to tax filings.

However, as a vendor of a commercial PDF SDK, we hear from many customers facing frustration with their digital document signing solution. Few PDF libraries provide both professional signing and signature verification. And whether due to a misunderstanding or poor vendor documentation, some customers then use more than one library or forgo proper verification, exposing vulnerabilities with any number of adverse consequences, such as hacking, theft, and litigation.

Customers require a signature verification solution they can trust. One that returns an accurate result and that reports accurately in cases where it cannot. Today, that is why we are announcing new professional signature verification features, available to explore yourself via the web-based Validation demo.

We provide a secure-by-default signature verification solution, plus support for robust Modification Detection and Prevention (MDP) verification.

Together, these empower developers to design document signing workflows and rich interactive experiences, including real-time collaboration and form-filling, while ensuring user confidence in their signatures and digitally signed content.

In this article, we discuss how digital signatures work and how you can secure your PDFs with the latest dig sig best practices and Apryse technology.

Learn more about the history of digital signatures. Read the blog post.

A digital signature is a unique encrypted message, embedded in a document with other verification data, to establish two things:

When signing contracts and other legal & financial documents, digital signatures may also enforce non-repudiation: i.e., make it so the signer cannot later say they did not sign.

A professional digital signing workflow will require a supporting Public Key Infrastructure (PKI), referring to the set of roles, processes, and technologies used to ensure trust between stakeholders.

PKI is used to generate the public/private key pair when signing documents and verifying signatures. To protect the integrity of the signature, PKI requires secure management and saving of these encryption keys, and often involves the services of a Certificate Authority (CA) vendor, such as IdenTrust, DigiCert, Notarius, or GlobalSign, to provide third-party authentication and widespread acceptability of the signature.

Adobe, for example, has its list of trusted CAs which will work with Acrobat 9+. But some organizations may wish to “self-sign” certificates to save on certificate costs when communicating internally or for testing purposes, using a library such as OpenSSL.

Generally speaking, self-signing is considered less-secure than relying on a CA. Either a self-signed authority or a CA can act as the trust anchor or "root" certificate authority for PKI's trust chain, used to authenticate Intermediate Authorities (ICAs) lower down on the trust hierarchy. In turn, these ICAs are responsible for issuing the end-user certificates (i.e., digital IDs) to entities that wish to sign documents.

The electronic equivalent of a driver's license or passport, a digital ID can be issued to a person, a team, or an entire organization.

A digital signature can be broken into the following components. Each will need to be extracted and evaluated during verification.

1. The Digital Certificate: Most digital signatures are certificate-based to ensure the authenticity of the signer. An embedded certificate inherits specific information from the unique Digital ID issued by the CA. This information includes the public key used to decrypt the digest and other verification data. And it may include optional end-user identifiers, such as an IP address, biometric data, etc.

2. The Encrypted Digest: An application will also create and embed what's known as the encrypted document digest. It will later verify the document's integrity by providing a static snapshot of its contents at the signing time. A digest is a unique and fixed-length string of alphanumeric characters generated by feeding the document file's binary through a one-way hash function algorithm. Once calculated, the digest is encrypted (i.e., "signed") using the signer's secret private key and then embedded.

3. The Timestamp: Next, the solution may embed one or more timestamps into the document as part of Long-Term Validation (LTV) or the signature itself (to establish the time of signing securely for later verification).

4. LTV Information: Lastly, as part of enabling Long-Term Validation, the signer or verifier can add any required verification information (e.g., missing certificates or revocation data about those certificates).

To verify a digital signature, a solution will need to do the following:

Assuming proper configuration, a solution like the Apryse SDK should handle this whole process automatically, so you would not need to do it manually.

The story doesn’t entirely end here; a valid signature, by itself, will not provide trust, and many solutions leave gaps in their PKI authentication processes.

A systems designer needs to ensure that certificates can be verified in real-time, upon viewing, and with up-to-date revocation information to guarantee security. Organizations will often wish to embed this revocation information in their signatures via an OCSP URL. This allows an application to check the current revocation status of a single certificate. Developers may also use a CRL responder URL, an older, less-efficient authentication method that retrieves a blacklist of revoked certificates.

One thing to note is that both these methods eventually expire, with OCSP passing faster than CRL. And with no external authority to call out to, a solution must fall back on revocation data embedded within the file.

Even if it's present, this information can become obsolete quickly, opening vulnerabilities if the application is not configured right. A Man-in-the-Middle attack can succeed where the Digital ID was stolen and used to sign the file, but the CA didn't know about it when revocation was last retrieved and embedded. This revocation information, when present, also becomes obsolete quickly. And the compromised file will then never fail verification (because it will always have the same erroneous revocation data).

One of the cool things about PDF for digital signing is that the format supports opening a window in the encrypted envelope via incremental save. By saving changes to the file's end, outside the byte-range used to calculate the encrypted digest, the application can let users make limited changes without invalidating previous signatures.

This ability is incredibly useful for many back-and-forth approval workflows. Users can form-fill, communicate via their annotations, comments, and replies to comments, and certify changes with additional approval signatures.

But being able to append changes creates an additional challenge: document actions must be carefully controlled after signing. Otherwise, someone could hide or change important content with annotations over the top, slip in new pages, etc.⁠—and have any of those changes pass verification.

That's why PDF supports embedding permissions called Modification Detection and Prevention (MDP) to lock down and control changes post-signing.

MDP includes two mechanisms:

DocMDP specifies global permissions on what can be changed associated with the original Certification Signature. The “P” value within the DocMDP transform is an enumerated flag, with three settings:

FieldMDP specifies granular permissions for form filling. It can be associated with a Certification Signature or an Approval Signature, and supplied with a list of locked form fields, a list of unlocked form fields, or switched to “all” to lock all form fields.

During verification, a professional solution should be able to read the MDP permissions within the file and then invalidate signatures where embedded permissions are violated.

But most vendors don’t bother with MDP verification and leave it up to the customer to figure out. Other vendors support MDP verification but take a permissive approach that is easier to implement but introduces uncertainty. For example, they will restrict specific actions that are dicey, such as adding pages, while ignoring other actions deemed irrelevant, such as changing file metadata or embedding rich-media annotations, including video.

Few solutions have features that would let customers inspect the MDP permissions to enable more granular MDP verification.

The Apryse SDK adopts a “strong” security approach to verifying digital signatures, as we do across the rest of our SDKs. For all signature verification sub-features, customers must choose between two operating modes:

Within these two modes, developers still have complete freedom to calibrate each step of their verification process to support maximum security or compatibility.

For example, you can toggle on/off any part of the verification process (digest, MDP, trust) and access detailed security options after setting the general security level.

The entire solution is also built with attention to detail and provides solid reporting. Each part of verification has its sub-code that tells you exactly what’s going on, so you can dig deeper and quickly diagnose an issue.

For example, you can get information on your entire certificate chain, revocation checks, and more. (We support embedded revocation checking, including support for checking LTV data, so your documents stay valid longer.)

The solution also checks the time used for trust verification, necessary for security. And it’ll tell you all the disallowed changes made since the document was signed, exactly where they are, and what they are⁠—making robust MDP verification much more straightforward.

Those building for electronic archiving workflows will also appreciate the Apryse SDK’s comprehensive PDF/A conversion. (Given that PDF/A conversion will make profound alterations to the document file, invalidating most existing signed signatures, it is advised to (re)apply signatures after conversion.)

Apryse signature verification currently works with adbe.pkcs7.detached and DocTimeStamp (ETSI.RFC3161) signatures, representing the majority (~2/3rds) of signatures we’ve encountered during testing. As Apryse signature verification is still under active development, you can expect support for even more signature formats, features, and capabilities soon.

Try the validation demo and for next steps, check out the related documentation and code samples:

Cross-platform (Core) Documentation

If you have any questions, feedback, or special requirements, don’t hesitate to reach out on Discord. Our developers would be happy to chat with you about your options.