Signature and encryption security model

At a glance

This page defines the security model for the two cryptographic surfaces the core engine exposes: document encryption with Advanced Encryption Standard 256-bit (AES-256) and document signing with Cryptographic Message Syntax (CMS)/PDF Advanced Electronic Signatures (PAdES). It explains what each mechanism protects and where the trust boundary sits.

Boundary. The strength of an encrypted document depends on the password and key custody you choose. The meaning of a signature depends on the certificate, trust anchor, timestamp authority, and verifier policy. Those controls live outside this library.

Install

composer require nextpdf/core:^3

ext-openssl is required for the signing and CMS paths.

Conceptual overview

In the core engine, Encryption uses the ISO 32000-2 §7.6 AES-256 security handler (AESV3, Revision 6). It provides confidentiality: a party without the password cannot read string and stream content. It does not provide integrity or authenticity. A ciphertext can still be truncated or replaced. A signature or a document message authentication code (MAC) detects that condition.

Permissions (print, copy, modify) are separate and easy to misread. The ISO 32000-2 permission flags are reader-cooperative. A conforming reader honors them, but they are advisory metadata, not a cryptographic access control. A non-cooperating tool can ignore them. The engine emits them faithfully; enforcement rests with the conforming reader.

For Signing, the engine embeds a CMS SignedData structure as described in ISO 32000-2 §12.8. The signed byte range is a direct object, and the digest deliberately excludes the signature Contents value, so the signature covers the document but not itself.

API surface

The encryption entry points and signing orchestrator are documented in /modules/core/security/ and /modules/core/security/signing/.

Code sample — Quick start

Encryption protects confidentiality for parties without the password:

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use NextPDF\Core\Document;

$doc = new Document();
// AES-256 (AESV3 R6). The owner/user passwords gate read access only.
// Permission flags below are advisory: a conforming reader honors them.
$doc->encrypt(
    userPassword: 'open-secret',
    ownerPassword: 'owner-secret',
);
$doc->save('confidential.pdf');

Code sample — Production

A production signing flow applies a CMS/PAdES baseline signature with a software-held key. The Core edition produces the PAdES B-B level. When you configure a timestamp authority, the Core edition produces PAdES B-T, which is B-B plus a single RFC 3161 signature-time-stamp unsigned attribute:

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use NextPDF\Core\Document;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\SignatureLevel;

$cert = CertificateInfo::fromPkcs12('signer.p12', 'pin');

$doc = new Document();
// B-B is the default. B-T adds a trusted timestamp over the signature value.
$doc->setSignature($cert, SignatureLevel::PAdES_B_B);
$doc->save('signed.pdf');

PAdES B-T is exactly B-B plus one RFC 3161 signature-time-stamp unsigned attribute carried in the CMS SignerInfo. The timestamp binds the signature value to trusted time from a timestamp authority. Validation-data dictionaries, revocation information, and archive timestamps belong to the distinct long-term levels, which ship in the paid editions.

The B-T signature-time-stamp attribute implements ETSI EN 319 122-1 §5.3 — the CMS Advanced Electronic Signatures (CAdES) basis that the EN 319 142 PAdES family imports by reference — and is produced per RFC 3161, RFC 5652, and ISO 32000-2 §12.8.

Edge cases & gotchas

• Encryption ≠ integrity. A reader that can open the document can still be given a tampered copy. A signature (or a document MAC) detects that condition.
• A signature’s presence is not its validity. That a document carries a signature dictionary says nothing about whether the certificate is trusted, unexpired, or unrevoked. Establishing validity is a verifier-side operation governed by the relying party’s policy.
• Timestamp trust is external. A B-T timestamp is only as meaningful as the trust the verifier places in the timestamp authority (TSA) that issued it. The library obtains and embeds the token.
• FIPS posture is environmental. Running on a FIPS-validated cryptographic module is a property of the operating environment and the module.

Performance

The signature path computes one byte-range digest and one CMS structure. The B-T extension adds one synchronous round-trip to the timestamp authority. Encryption is a per-string/per-stream symmetric operation. Neither dominates a typical render. The network round-trip for B-T is the variable cost, and it depends on the caller’s TSA choice.

Security notes

The trust boundaries, restated as rules:

1. Confidentiality only. AES-256 encryption protects content from parties without the password. Integrity and authenticity come from a signature or a document MAC.
2. Permissions are advisory. Permission flags are reader-cooperative; enforcement rests with the conforming reader.
3. B-B and B-T on this page. The core signing surface documented here covers PAdES B-B and its B-T timestamp extension. The long-term archival levels are a separate, paid-edition surface.
4. Legal validity is the relying party’s determination. A produced signature is a cryptographic artifact. Whether it is legally valid depends on jurisdiction, certificate policy, and the relying party.

Conformance

The engine produces output that uses the cited ISO 32000-2, RFC 3161, RFC 5652, and ETSI EN 319 122-1 constructs. FIPS 140-3 validation is a property of the cryptographic module and its operating environment. An independent validator or assessor makes any conformance or legal-validity determination.

See also

• Trust center
• Engine threat model
• Core security module reference
• Signing reference