Verifikasi tanda tangan: verifikasi kriptografis AdES / PAdES

Sekilas

NextPDF Enterprise memverifikasi tanda tangan digital secara kriptografis. Sisi verifikasi membaca CMS Cryptographic Message Syntax (SignedData) atau token stempel waktu Request for Comments (RFC) 3161 dari PDF, menghitung ulang digest, memeriksa tanda tangan, mengikat setiap tanda tangan ke sertifikat penanda tangannya, dan memvalidasi rantai sertifikat, termasuk pemrosesan kebijakan-sertifikat, terhadap penyimpanan jangkar kepercayaan yang disediakan pemanggil. Halaman ini menjelaskan perilaku tersebut: apa yang diverifikasi, apa yang ditolak secara fail-closed, algoritme yang didukung, dan letak batas kepercayaannya.

Ini terpisah dari Validation, yang menjalankan pemeriksaan kebijakan struktural hanya-baca dan dengan sengaja tidak melakukan kriptografi apa pun. Ini juga merupakan pasangan sisi verifikasi untuk produser Tanda tangan, yang menulis struktur PDF Advanced Electronic Signatures (PAdES) B-LT / B-LTA.

Pemasangan

composer require nextpdf/enterprise:^3

Tinjauan konseptual

Verifikasi berbasis bukti dan bersifat fail-closed: pemeriksaan yang tidak dapat dibuktikan secara positif tidak menghasilkan hasil positif. Bagian-bagian di bawah ini digabungkan menjadi satu hasil yang dibawa oleh sebuah ValidationReport.

Verifikasi kriptografis CMS / token stempel waktu. Tumpukan DER panjang-pasti yang mandiri dan ketat mengurai CMS SignedData dan token stempel waktu RFC 3161. Sebuah token hanya diterima ketika token tersebut membawa tepat satu SignerInfo, atribut bertanda tangannya diurai secara ketat, sertifikat penanda tangan terselesaikan, atribut message-digest cocok dengan digest yang dihitung ulang, ikatan sertifikat-penanda-tangan wajib (ESS signing-certificate-v2) berlaku, dan tanda tangan SignerInfo terverifikasi atas atribut bertanda tangan yang ditag ulang. Aturan pencocokan digest mengikuti model verifikasi RFC 5652 §5.6 / §5.4: penerima menghitung ulang digest pesan konten, dan tanda tangan valid hanya ketika nilai tersebut sama dengan atribut bertanda tangan messageDigest. Verifikator tidak pernah mempercayai digest yang disediakan oleh produser.

Validasi sertifikat-TSA pada genTime. genTime dari stempel waktu adalah instan UTC saat token dibuat (RFC 3161 §2.4.2). Sertifikat penanda tangan TSA divalidasi pada instan tersebut, bukan pada “sekarang”: extended key usage-nya harus berupa satu id-kp-timeStamping tunggal yang kritis (RFC 3161 §2.3), dan jendela keberlakuan, rantai, asal jangkar kepercayaan, serta status pencabutannya semuanya dievaluasi terhadap genTime. Rantai yang secara struktural terbentuk dengan baik, tetapi tidak mencapai jangkar kepercayaan yang terkonfigurasi, tidak pernah dapat mendukung hasil positif.

Tanda tangan dokumen dasar PAdES terlepas. Ekstraktor konkret melakukan verifikasi dasar Advanced Electronic Signatures (AdES) / PAdES yang sebenarnya untuk tanda tangan dokumen terlepas: digest pesan dihitung ulang atas rentang byte yang ditandatangani lalu dibandingkan, tanda tangan diverifikasi, dan ikatan sertifikat-penanda-tangan bersifat wajib. Ini menggantikan fallback hanya-struktural sebelumnya. Verifikator stempel waktu dan ekstraktor tanda-tangan-dokumen berbagi satu validator penerbit-dan-serial ESS, sehingga penguraian pengikatan-sertifikat tidak dapat menyimpang.

Rantai cakupan DocTimeStamp arsip. validateArchivalTimestampChain() memvalidasi rantai token DocTimeStamp tepercaya atas rentang byte PDF sebagai bukti arsip B-LTA. Imprint setiap token diikat ke byte ByteRange aktual yang dicakupnya, rantai mengikuti urutan ETSI yang ketat, rantai TSA setiap token berjangkar kepercayaan, dan rantai harus mencakup berkas hingga penanda akhir-berkasnya. Hasil lulus penuh hanya dicapai untuk rantai yang lengkap, berjangkar kepercayaan, dan mencakup hingga EOF.

Pemrosesan kebijakan-sertifikat (RFC 5280 §6.1.4). Validasi jalur menerapkan pemrosesan kebijakan-sertifikat penuh: pohon kebijakan berstruktur simpul, pemetaan kebijakan dengan fallback anyPolicy, serta pelipatan policyConstraints / inhibitAnyPolicy, didukung oleh pembaca DER ekstensi-kebijakan yang fail-closed. Variabel status pemrosesan-jalur explicit_policy dan inhibit_anyPolicy (RFC 5280 §6.1.2) menentukan apakah pohon kebijakan-valid yang tidak kosong diperlukan; langkah penutup memotong pohon kebijakan-valid dengan user-initial-policy-set (RFC 5280 §6.1.4). Tanpa kebijakan wajib dan dengan anyPolicy diterima, pemrosesan menjadi tidak dibatasi, yaitu perilaku standar yang tidak berubah dari perilaku sebelumnya.

Algoritme yang didukung

Sisi verifikasi menerima kumpulan algoritme di bawah ini dan gagal-tertutup untuk apa pun di luar kumpulan tersebut: algoritme yang tidak didukung berarti verifikasi ditolak, bukan kelulusan diam-diam.

Keluarga	Didukung	Catatan
RSA (PKCS#1 v1.5)	rsaEncryption dengan SHA-2, dan OID sha*WithRSAEncryption	Diterima
ECDSA	kurva P-256, P-384, P-521	Diterima
RSASSA-PSS	—	Tidak didukung → fail-closed
EdDSA	—	Tidak didukung → fail-closed
Digest SHA-3	—	Tidak didukung → fail-closed
SHA-1	—	Lemah: tanda tangan dasar yang terverifikasi di bawah SHA-1 diturunkan menjadi kegagalan batasan-kripto, bukan kelulusan

Permukaan API

Anda menggunakan sisi verifikasi melalui engine publik dan kontrak Core / Pki. Kelas strategi konkret bersifat internal.

Tipe	Jenis	Peran
AdESValidationEngine	kelas	Titik masuk sisi verifikasi: validasi tanda tangan dan rantai-arsip.
AdESValidationEngine::validateArchivalTimestampChain()	metode	Memvalidasi rantai cakupan DocTimeStamp tepercaya atas rentang byte PDF.
ValidationReport	hasil	Hasil terstruktur: status keseluruhan ditambah temuan per-pemeriksaan.
PathValidatorInterface	antarmuka (NextPDF\…\Pki)	SPI validasi-jalur-sertifikasi yang digunakan engine.
PathValidationOptions	objek nilai	Kontrol pemrosesan-kebijakan: requireExplicitPolicy, inhibitAnyPolicy, inhibitPolicyMapping, maxPolicyFanout.
TrustAnchorStoreInterface	antarmuka	Kumpulan jangkar tepercaya yang disediakan pemanggil sebagai acuan evaluasi rantai.

Metode rantai-arsip memiliki signature berikut:

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

Hasil lulus penuh hanya dicapai ketika rantai DocTimeStamp telah sepenuhnya terverifikasi, berjangkar kepercayaan, dan mencakup berkas hingga penanda EOF-nya.

CertificateChainValidator::validate() menerima kumpulan kebijakan-awal (user-initial-policy-set RFC 5280). Nilai standarnya adalah anyPolicy, yang tidak dibatasi, sehingga rantai biasa tidak terpengaruh. Berikan kumpulan eksplisit, atau setel requireExplicitPolicy, untuk mewajibkan pohon kebijakan-valid yang tidak kosong.

Contoh kode — Memulai cepat

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

Contoh kode — Produksi

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

Perubahan perilaku & catatan pemutakhiran

Sisi verifikasi berpindah dari penerimaan struktural / temporal ke verifikasi kriptografis penuh. Jika Anda bergantung pada perilaku lama yang lebih longgar, tinjau perubahan ini.

• Fail-closed pada stempel waktu yang dapat dikenali namun tidak dapat diverifikasi. DocTimeStamp atau token arsip yang sebelumnya lulus atas dasar struktural dan temporal kini memerlukan verifikasi kriptografis penuh: tanda tangan, message-digest, dan ikatan sertifikat-penanda-tangan. Token yang tidak terverifikasi tidak lagi menghasilkan bukti-keberadaan yang positif; token tersebut dipetakan ke hasil yang tak tentu atau gagal.
• Tanda tangan dasar SHA-1 diturunkan, bukan diluluskan. Tanda tangan dokumen dasar yang terverifikasi namun menggunakan SHA-1 dilaporkan sebagai kegagalan batasan-kripto, bukan sebagai kelulusan penuh.
• Pemrosesan kebijakan-sertifikat RFC 5280 §6.1.4 ditegakkan. Rantai yang explicit_policy-nya mencapai nol dengan pohon kebijakan-valid yang kosong kini gagal, termasuk ketika kondisi tersebut digerakkan oleh policyConstraints requireExplicitPolicy internal-rantai. Rantai standar yang tidak dibatasi (tanpa kebijakan wajib, anyPolicy diterima) tidak terpengaruh.
• Perubahan signature konstruktor (pelanggaran BC). AdESValidationEngine::__construct() kini mengetik parameter $chainValidator-nya sebagai SPI Pki\PathValidatorInterface, dengan default malas Pki\CertificateChainValidator::withDefaults(). Sebelumnya parameter ini adalah Ltv\CertificateChainValidator yang konkret. Pemanggil yang menyuntikkan validator LTV konkret harus menyuntikkan implementasi SPI Pki sebagai gantinya. Validator Pki membungkus engine jalur struktural yang sama dan menambahkan batasan nama serta pemrosesan kebijakan; ia bersifat no-op untuk masukan standar yang konforman.

Kasus tepi & jebakan

• Algoritme tidak didukung ≠ tidak meyakinkan. RSASSA-PSS, EdDSA, dan SHA-3 ditolak secara fail-closed, bukan ditangguhkan. Jika penanda tangan Anda menggunakannya, sisi verifikasi ini tidak akan mengembalikan hasil positif.
• Kepercayaan bersifat relatif terhadap jangkar. Verifikasi selalu relatif terhadap penyimpanan jangkar kepercayaan yang Anda sediakan. Kumpulan jangkar yang kosong atau salah menghasilkan hasil tidak tepercaya, terlepas dari ketepatan kriptografisnya.
• genTime, bukan sekarang. Sertifikat TSA dinilai pada genTime token. Sertifikat TSA yang kini telah kedaluwarsa masih dapat mendukung token yang dibuat saat sertifikat itu valid; sertifikat yang belum valid pada genTime tidak dapat mendukungnya.
• Cakupan EOF. Rantai arsip harus mencakup dokumen hingga penanda EOF-nya. Stempel waktu yang hanya mencakup sebagian awal berkas tidak membuktikan cakupan seluruh dokumen.
• Belum-terbukti-dicabut bukanlah Good. Putusan Valid memerlukan status yang secara konklusif tidak dicabut. Jika OCSP maupun CRL sama-sama kembali sebagai Unknown atau Unavailable, bahkan tanda tangan yang sehat secara kriptografis, valid-rantai, dan berjangkar kepercayaan pun terurai menjadi Indeterminate. Sediakan materi Good OCSP/CRL tertanam untuk sertifikat penanda tangan agar mencapai Valid.

Kinerja

Verifikasi berjalan dalam proses atas byte PDF yang disediakan dan materi validasi tertanam; biayanya berskala mengikuti panjang rantai dan jumlah stempel waktu. Verifikasi tidak melakukan perjalanan bolak-balik jaringan. Materi pencabutan dan kepercayaan berasal dari apa yang disediakan pemanggil atau yang tertanam dalam dokumen. Verifikasi bersifat deterministik: masukan yang sama dan jangkar kepercayaan yang sama menghasilkan laporan yang sama.

Catatan keamanan

• Fail-closed adalah perilaku standar. Setiap langkah penerimaan menolak materi yang tidak dapat diverifikasi secara positif. Ini mencegah dokumen mengiklankan keabsahan yang tidak pernah ditetapkan oleh engine.
• Penambahan-setelah-stempel-waktu dipatahkan oleh cakupan EOF. Karena imprint setiap stempel waktu arsip diikat ke byte ByteRange aktual dan rantai harus mencapai EOF, konten yang ditambahkan setelah stempel waktu tidak dicakup olehnya dan tidak memperoleh bobot pembuktiannya.
• Perlakukan masukan sebagai bermusuhan. Byte PDF, CMS tertanam, dan token stempel waktu dari sumber tidak tepercaya diurai oleh pembaca DER panjang-pasti yang ketat, yang menolak pengkodean cacat atau berpanjang-tak-pasti.

Residensi data & mitigasi PII

Verifikasi berlangsung dalam proses dan lokal, tanpa I/O jaringan. Sertifikat dan tanda tangan membawa identitas subjek; terapkan sendiri kontrol retensi dan minimisasi terhadap laporan dan data sertifikat apa pun yang diekstraksi.

Telemetri aman & pembersihan log

Temuan membawa pengidentifikasi pemeriksaan dan status. Beberapa diagnostik dapat memuat kembali nama subjek sertifikat atau nomor serial; bersihkan atau redaksi bidang-bidang tersebut sebelum Anda meneruskan log ke sink bersama.

Batas cakupan

Nyatakan batas-batas ini dalam keluaran yang dihadapkan kepada pengguna agar hasil positif tidak ditafsirkan berlebihan.

• validateArchivalTimestampChain() membuktikan cakupan rentang-byte, bukan keterjangkauan xref. Ini menetapkan bahwa rantai stempel waktu tepercaya secara kriptografis mencakup rentang byte dokumen hingga EOF. Ini tidak melakukan analisis keterjangkauan-objek tingkat-xref atau startxref; hal itu memang berada di luar cakupan secara desain. Aturan cakupan-EOF, bersama dengan penjangkaran kepercayaan, mematahkan serangan penambahan-setelah-stempel-waktu, bukan menggantikan analisis graf-objek.
• Di luar cakupan secara desain. Evidence Records (RFC 4998 / RFC 6283); verifikasi token stempel waktu RSASSA-PSS, EdDSA, atau SHA-3; integrasi daftar-tepercaya (TSL) dan TSA-berkualifikasi; serta pengambilan pencabutan-TSA daring tidak disediakan oleh sisi verifikasi ini. Pencabutan dievaluasi dari materi yang sudah tersedia bagi verifikator.

Konformansi

Perilaku	Referensi	Status
Nilai tanda tangan / token stempel waktu disimpan dalam pengkodean DER di /Contents	ISO 32000-2 §12.8.1	Diurai dan diverifikasi
Kamus stempel waktu dokumen	ISO 32000-2 §12.8.5	Dibaca untuk rantai arsip
Penerima menghitung ulang digest konten; nilainya harus sama dengan atribut messageDigest	RFC 5652 §5.6 / §5.4	Ditegakkan
Sertifikat TSA membawa satu id-kp-timeStamping EKU tunggal yang kritis	RFC 3161 §2.3	Diperiksa pada genTime
genTime adalah instan pembuatan UTC	RFC 3161 §2.4.2	Digunakan sebagai instan validasi
Variabel status pemrosesan-kebijakan (explicit_policy, inhibit_anyPolicy)	RFC 5280 §6.1.2	Diproses
Penutup memotong pohon kebijakan-valid dengan user-initial-policy-set	RFC 5280 §6.1.4	Ditegakkan
Entri DSS dan stempel-waktu dokumen untuk tanda tangan jangka-panjang	ETSI EN 319 142-2 §5.5	Divalidasi sebagai bukti arsip

Semua klausa diparafrasakan. NextPDF tidak mereproduksi teks normatif; rujuk standar yang diterbitkan untuk redaksi yang berwenang. NextPDF tidak membuat klaim sertifikasi AdES / PAdES. Sisi verifikasi mengimplementasikan pemeriksaan kriptografis yang dijelaskan oleh spesifikasi yang dikutip; ini bukan layanan validasi tersertifikasi dan tidak menghasilkan atestasi pihak ketiga.

Perilaku mode-FIPS

Ketika profil FIPS Enterprise aktif, batasan tersebut berlaku pada algoritme digest dan tanda tangan yang diterima verifikator. Logika verifikasi, termasuk penghitungan ulang digest, pemeriksaan tanda tangan, pengikatan-sertifikat, dan validasi jalur, tidak berubah.

Model ancaman

Aset	Lawan	Risiko	Mitigasi
Token stempel waktu	Token yang dipalsukan atau diubah	Bukti-keberadaan yang palsu	Verifikasi kriptografis penuh; fail-closed pada apa pun yang tidak dapat diverifikasi
Sertifikat TSA	Penerbit tidak tepercaya	Kepercayaan semu yang seharusnya tidak ditegaskan verifikator	Rantai divalidasi ke jangkar yang disediakan pemanggil pada genTime; rantai tidak tepercaya tidak pernah lulus
Byte dokumen	Penambahan-setelah-stempel-waktu	Konten memperoleh bobot stempel waktu tanpa cakupan	Imprint diikat ke byte ByteRange aktual + aturan cakupan-EOF
Algoritme lemah	Penurunan ke SHA-1 / skema tidak didukung	Tanda tangan lemah dibaca sebagai valid	SHA-1 diturunkan; RSASSA-PSS / EdDSA / SHA-3 fail-closed

Gerbang edisi

Sisi verifikasi ini adalah kapabilitas Enterprise dan dikirimkan dalam paket nextpdf/enterprise. NextPDF Core mendeteksi keberadaan tanda tangan dan memproduksi tanda tangan B-B / B-T, namun tidak menyediakan sisi verifikasi kriptografis ini. Dapatkan lisensi.

Flag fitur lisensi

Sisi verifikasi digerbangi oleh edisi Enterprise (license_feature_flag: enterprise). Ini terselesaikan melalui kontrak Core dan Pki; API publik tidak berubah saat pemutakhiran edisi.

Kontrak perilaku

• Token CMS atau stempel waktu hanya diterima dengan tepat satu SignerInfo, atribut bertanda tangan yang terurai ketat, sertifikat penanda tangan yang terselesaikan, message-digest yang cocok, ikatan sertifikat-penanda-tangan yang wajib, dan tanda tangan SignerInfo yang terverifikasi.
• Sertifikat TSA divalidasi pada genTime token: satu id-kp-timeStamping EKU tunggal yang kritis, jendela keberlakuan, rantai berjangkar kepercayaan, dan pencabutan.
• Putusan Valid juga memerlukan status yang secara konklusif tidak dicabut: setidaknya satu Good yang berwenang (respons OCSP yang terverifikasi-baik, atau CRL segar yang menempatkan serial di luar daftar yang belum kedaluwarsa). Status yang sekadar belum-terbukti-dicabut, ketika OCSP dan CRL keduanya Unknown atau Unavailable, terurai menjadi Indeterminate, tidak pernah Valid (ETSI EN 319 102-1: status-pencabutan-tak-tersedia → INDETERMINATE). Karena jalur fallback-CRL hanya menyatakan kesegaran daftar dan bukan pencabutan per-serial, rantai hanya-CRL tanpa OCSP Good umumnya Indeterminate.
• validateArchivalTimestampChain() mencapai hasil lulus penuh hanya untuk rantai DocTimeStamp yang lengkap, berjangkar kepercayaan, dan mencakup hingga EOF; ini membuktikan cakupan rentang-byte, bukan keterjangkauan xref.
• Pemrosesan kebijakan-sertifikat mengikuti RFC 5280 §6.1.4; rantai standar yang tak terbatasi tidak terpengaruh.
• Algoritme yang didukung adalah RSA (PKCS#1 v1.5 dengan SHA-2) dan ECDSA (P-256/384/521); RSASSA-PSS, EdDSA, dan SHA-3 gagal-tertutup; SHA-1 diturunkan.

Status pemindaian NDA

Halaman publik ini hanya menjelaskan perilaku sisi verifikasi yang dapat diamati secara eksternal. Halaman ini menyebut engine publik, kontrak Pki / jangkar-kepercayaan, dan metode validateArchivalTimestampChain() melalui permukaan yang didukung. Internal DER, CMS, pemroses-kebijakan, dan validator-jalur konkret berada di referensi mendalam yang digerbangi di bawah perjanjian kerahasiaan (NDA).

Fallback Core

NextPDF Core mendeteksi keberadaan tanda tangan dan memproduksi tanda tangan B-B / B-T, namun tidak memverifikasi CMS atau token stempel waktu secara kriptografis, tidak memvalidasi rantai arsip, dan tidak menjalankan pemrosesan kebijakan RFC 5280 §6.1.4. Penyebaran hanya-Core tidak memiliki sisi verifikasi yang setara; lihat Keamanan / Penandatanganan (Core).

Fallback Pro

NextPDF Pro menambahkan strategi penandatanganan dan penanganan e-invoice, namun tidak menyediakan sisi verifikasi kriptografis ini; validasi rantai-arsip dan pemrosesan kebijakan-sertifikat hanya dikirimkan dalam nextpdf/enterprise.

Catatan batas Enterprise

Sisi verifikasi dijelaskan pada tingkat perilaku. Tumpukan DER ketat, pengurai CMS, pemroses kebijakan, dan internal validator-jalur berada di luar cakupan permukaan publik dan tidak direproduksi di sini.

Batas penyebaran

Verifikasi bergantung pada penyimpanan jangkar kepercayaan dan materi pencabutan apa pun yang disediakan pemanggil atau yang tertanam dalam dokumen. NextPDF Enterprise mengevaluasi materi tersebut; ia tidak mengoperasikan daftar kepercayaan, TSA, atau layanan pencabutan. Operator bertanggung jawab atas pemilihan jangkar dan kesegaran materi pencabutan tertanam.

Batas kepatuhan-hukum

Halaman ini ditandai export_control_class: legal-review-required; isinya menyangkut verifikasi kriptografis. Persetujuan hukum diperlukan sebelum flag publish disetel. Hasil verifikasi yang positif adalah pernyataan kriptografis tentang tanda tangan dan stempel waktu dokumen. Itu bukan opini hukum, bukan penentuan kualifikasi eIDAS, dan bukan sertifikasi. NextPDF tidak membuat klaim sertifikasi AdES / PAdES. Konsultasikan dengan penasihat kepatuhan dan hukum Anda sendiri untuk kewajiban regulasi Anda.

Lihat juga

• Tanda tangan: produser PAdES B-LT / B-LTA — sisi produser.
• Validation — pemeriksaan kebijakan struktural dalam proses (tanpa kriptografi).
• Arsip: DSS, VRI, kesehatan LTV — pengarsipan jangka-panjang dan kesehatan LTV.
• Keamanan / Penandatanganan (Core) — CMS, RFC 3161, validasi jalur RFC 5280, OCSP/CRL.
• Pemetaan baseline PAdES — B-B, B-T, B-LT, B-LTA lintas edisi.
• PAdES · DSS · LTV — istilah glosarium.