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, what it does not protect, and where the trust boundary sits.

Boundary. Support for a cryptographic mechanism does not guarantee security in your deployment. 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. This page describes the mechanism; it does not certify the outcome.

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) (iso32000_2_sec7#x1.x65.p29). 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) must detect that condition; the encryption handler does not.

Permissions (print, copy, modify) are separate and easy to misread. The ISO 32000-2 permission flags are reader-cooperative (iso32000_2_sec7#x1.x71.p27). 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; it cannot enforce them.

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 (iso32000_2_sec12#x1.x121.p45), so the signature covers the document but not itself.

API surface

This page does not repeat the signature reference. The encryption entry points and signing orchestrator are described in /modules/core/security/ and /modules/core/security/signing/. This model is about meaning and boundary, not method shapes.

Code sample — Quick start

Encryption protects confidentiality for parties without the password, and nothing more:

<?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 (rfc5652#p603). The timestamp binds the signature value to trusted time from a timestamp authority (rfc3161#p208). It does not add a validation-data dictionary, a revocation-information structure, or an archive-timestamp loop. Those are distinct, separately scoped, long-term levels that are not part of the B-B/B-T surface and are out of scope for this page.

U-1. NextPDF does not assert independent ETSI EN 319 142-1 certification for PAdES B-T. EN 319 142-1 is not in the verification corpus used here. The B-T signature-time-stamp requirement is verified against ETSI EN 319 122-1 §5.3 — the CMS Advanced Electronic Signatures (CAdES) basis that the EN 319 142 PAdES family imports by reference (etsi_en_319_122_1#6.x40.p96) — together with RFC 3161, RFC 5652, and ISO 32000-2 §12.8. Support for the B-T profile is not a conformance certification or a legal-validity certification. An independent validator makes that determination.

Edge cases & gotchas

• Encryption ≠ integrity. A reader that can open the document can still be given a tampered copy. Only a signature (or a document MAC) detects that. “Tamper-proof” is not a property the encryption handler provides, and the term is not used as a product claim.
• 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, not by the signer.
• 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. It does not vouch for the TSA.
• FIPS posture is environmental. Running on a FIPS-validated cryptographic module is a property of the operating environment and the module (fips_140_3#x12), not something a PHP library can assert on its caller’s behalf.

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

Boundary statements, restated as enforceable rules for reviewers:

1. Confidentiality only. AES-256 encryption protects content from parties without the password. It does not provide integrity, authenticity, or access control (iso32000_2_sec7#x1.x65.p29).
2. Permissions are advisory. Permission flags are reader-cooperative and are not cryptographically enforced (iso32000_2_sec7#x1.x71.p27). Product wording must not claim they prevent an action.
3. B-B and B-T only on this page. The core/Pro signing surface documented here covers B-B and its B-T timestamp extension, with each B-T mention co-located with the U-1 caveat above. Long-term archival levels are a separate, paid-edition surface and are intentionally not described here. No validation-data, revocation-information, or archive-timestamp capability is asserted on this page.
4. No legal-validity claim. A produced signature is a cryptographic artifact. Whether it is legally valid depends on jurisdiction, certificate policy, and the relying party, not on this library.

Conformance

Support is not conformance. The engine produces output that uses the cited ISO 32000-2, RFC 3161, RFC 5652, and ETSI EN 319 122-1 constructs. The engine does not assert PAdES, CAdES, or eIDAS conformance. FIPS 140-3 validation is a module/environment property (fips_140_3#x12), not a library claim. 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