ลายเซ็นดิจิทัลพิสูจน์ผู้ลงนามได้อย่างไร

Spec: RFC 5652Spec: RFC 5280, §6Spec: RFC 3161, §1

ภาพรวมโดยย่อ

ลายเซ็นดิจิทัลทำสามสิ่ง และควรแยกแยะมันออกจากกันตั้งแต่ต้น มันพิสูจน์ว่าไบต์ไม่ถูกเปลี่ยนแปลง มันพิสูจน์ว่า ใคร เป็นผู้ลงนาม และ — ด้วยความช่วยเหลือเล็กน้อย — มันพิสูจน์ว่า เมื่อใด หน้านี้สร้างแนวคิดนั้นขึ้นจากศูนย์ เพื่อให้การเข้ารหัสเลิกเป็นกล่องดำ

ทำไมเรื่องนี้จึงสำคัญ

“ลงนามแล้ว” เป็นคำที่ผู้คนเอาการตัดสินใจไปแขวนไว้ ทั้งสัญญา ใบแจ้งหนี้ บันทึกการออกซอฟต์แวร์ที่จะมีคนนำไปรัน หากคุณรู้เพียงว่าเครื่องมือพิมพ์เครื่องหมายถูกสีเขียวออกมา คุณก็ไม่ได้รู้จริงว่าอะไรถูกพิสูจน์ คุณอาจมีหลักฐานว่าไบต์ครบถ้วน แต่ไม่รู้เลยว่าคีย์ของใครเป็นผู้ลงนาม คุณอาจมีผู้ลงนามตัวจริง แต่ใบรับรองหมดอายุไปหลายปีแล้ว การเข้าใจชิ้นส่วนต่างๆ คือสิ่งที่ทำให้คุณบอกได้อย่างแม่นยำว่า ลายเซ็นที่ถูกต้องหมายความว่าอะไร — และที่มีประโยชน์พอกันคือ มันไม่ได้หมายความว่าอะไร

ฉบับย่อ

ลองนึกถึงซองที่ปรากฏร่องรอยเมื่อถูกแกะ พร้อมตราประทับส่วนตัวกดลงบนฝาซอง

ตราประทับ เป็นเอกลักษณ์ของคนคนเดียวและแทบเป็นไปไม่ได้ที่จะปลอม ใครก็จดจำ มันได้ แต่มีเพียงเจ้าของเท่านั้นที่สร้างมันได้ นั่นคือ คู่คีย์ ได้แก่ คีย์ส่วนตัวที่คุณถือไว้คนเดียว และคีย์สาธารณะที่ทุกคนเห็นได้
คุณไม่ได้กดตราประทับลงทั้งเอกสาร คุณกดมันลงบนบทสรุปย่อๆ ที่ปลอมไม่ได้ของ เอกสาร — นั่นคือ แฮช เปลี่ยนเอกสารเพียงหนึ่งไบต์ บทสรุปก็เปลี่ยนไปอย่าง สิ้นเชิง ตราประทับจึงไม่พอดีอีกต่อไป
การลงนาม คือการสร้างลายเซ็นเหนือเอกสารด้วยคีย์ ส่วนตัว ของคุณ — เหนือ แฮชสำหรับ RSA และ ECDSA หรือเหนือเนื้อหาเองสำหรับ EdDSA ซึ่งแฮชเองภายใน การตรวจสอบยืนยัน คือการรันการตรวจของอัลกอริทึมด้วยคีย์ สาธารณะ ของคุณ ลายเซ็น และเนื้อหาเดียวกัน (ในรูปแฮชหรือโดยตรง) — มันคืนค่าว่าถูกต้องหรือไม่ ถูกต้อง คณิตศาสตร์ ไม่ใช่ความเชื่อ คือสิ่งที่เชื่อมโยงทั้งสองเข้าด้วยกัน
ใบรับรอง คือส่วนที่บอกว่า ตราประทับนี้เป็นของใคร หากไม่มีมัน คุณก็พิสูจน์ ได้ว่าคีย์หนึ่งลงนามไบต์ แต่ไม่ได้พิสูจน์ว่าคีย์นั้นเป็นของใครคนใดคนหนึ่งโดย เฉพาะ
การประทับเวลา คือส่วนที่บอกว่า เมื่อใด นาฬิกาของผู้ลงนามเองเป็นเพียงคำ กล่าวอ้าง เวลาที่เชื่อถือได้มาจากหน่วยงานภายนอก

NextPDF จัดการเรื่องนี้อย่างไร

เริ่มจากแฮช เพราะทุกอย่างที่เหลือยืนอยู่บนมัน ฟังก์ชันแฮชเชิงการเข้ารหัสอ่านข้อมูลปริมาณเท่าใดก็ได้และผลิตลายนิ้วมือสั้นที่มีความยาวคงที่ — สำหรับลายเซ็น PDF โดยทั่วไปคือค่า 256 บิต มีสองคุณสมบัติที่ทำให้มันมีประโยชน์ คือ อินพุตเดียวกันให้ลายนิ้วมือเดียวกันเสมอ และเป็นไปไม่ได้ในทางปฏิบัติที่จะหาอินพุตอื่นที่ให้ลายนิ้วมือเดียวกัน ดังนั้นแฮชจึงเป็นตัวแทนที่ซื่อตรงของเอกสาร หากแฮชสองค่าตรงกัน ไบต์ก็ตรงกัน

ตอนนี้มาที่คู่คีย์ คีย์ส่วนตัวและคีย์สาธารณะเชื่อมโยงกันทางคณิตศาสตร์ แต่คุณหาตัวหนึ่งจากอีกตัวหนึ่งไม่ได้ในเวลาที่เป็นไปได้ในทางปฏิบัติ มีเพียงคีย์ส่วนตัวที่ผลิตลายเซ็นที่ถูกต้องได้ และมีเพียงคีย์สาธารณะที่จับคู่กันที่ตรวจมันได้ การลงนามใช้ความไม่สมมาตรนั้น ผู้ลงนามใช้การดำเนินการด้วยคีย์ส่วนตัวกับอินพุตที่อัลกอริทึมที่เลือกกำหนดไว้ — แฮชของเนื้อหาสำหรับ RSA และ ECDSA หรือเนื้อหาโดยตรงสำหรับ EdDSA ซึ่งแฮชภายในเอง ผลลัพธ์คือ ค่าลายเซ็น เพราะมีเพียงผู้ถือคีย์ส่วนตัวที่ผลิตมันได้ และเพราะมันผูกกับเนื้อหา นี้ มันจึงพิสูจน์สองสิ่งในคราวเดียว — ผู้ถือคีย์ลงนาม และไบต์ไม่ได้ขยับนับตั้งแต่นั้น

การตรวจสอบยืนยันสะท้อนตรรกะนั้น ตัวตรวจสอบยืนยันสร้างอินพุตเดียวกันขึ้นใหม่ — แฮชเอกสารสำหรับ RSA และ ECDSA หรือนำเนื้อหาโดยตรงสำหรับ EdDSA — แล้วรันการดำเนินการ verify ของอัลกอริทึมลายเซ็นบนคีย์สาธารณะ ค่าลายเซ็น และอินพุตนั้น การดำเนินการคืนค่าว่าถูกต้องหรือไม่ถูกต้อง — และเป็นรูปแบบเดียวกันไม่ว่าอัลกอริทึมจะเป็น RSA, ECDSA หรือ EdDSA แม้ว่าจะมีเพียง RSA ที่นึกภาพได้ว่าเป็นการ “กู้คืน” แฮชอย่างแท้จริง ถูกต้องหมายถึงครบถ้วนและเป็นของแท้ ไม่ถูกต้องหมายถึงมีบางอย่างเปลี่ยนไป หรือใช้คีย์ผิด และคำตอบที่ซื่อตรงคือ ไม่ถูกต้อง

Prepare the inputRSA and ECDSA hash the document to a short, fixed-length fingerprint; EdDSA signs the content directly and hashes it internally. Either way, any change to the bytes changes what is signed.
Sign with the private keyThe signer applies a private-key operation to that input — the hash for RSA and ECDSA, the content for EdDSA. The output is the signature value; only the private-key holder could have produced it.
Reconstruct the inputThe verifier independently rebuilds the same input from the content — a recomputed hash for RSA and ECDSA, the content itself for EdDSA. This is what the verify operation checks against.
Verify with the public keyThe verifier runs the algorithm's verify operation on the public key, the signature value, and that input. The same shape works for RSA, ECDSA, and EdDSA.
Accept or rejectThe verify operation returns valid or invalid. Valid means the bytes are intact and the private-key holder signed them. Otherwise the result is invalid — no guessing.

How a digital signature is produced and then checked, from first principles. The signer produces a signature over the content with their private key — over a hash for RSA and ECDSA, or over the content directly for EdDSA; the verifier reconstructs the same input, then runs the algorithm's verify operation on the public key, the signature, and that input. A valid result proves the bytes are intact and that the private-key holder signed them.

ใน PDF จริง NextPDF ไม่ได้กดตราประทับลงบนหน้าที่มองเห็น — มันกดลงบนช่วงไบต์ที่ประกาศไว้ และห่อลายเซ็นเป็นออบเจกต์ CMS แบบแยกส่วน (Spec: RFC 5652) ที่วางไว้ภายในไฟล์ (Spec: ISO 32000-2, §12.8) มีการปรับแต่งหนึ่งอย่างที่สำคัญ ผู้ลงนามไม่ได้ลงนามแฮชของเนื้อหาดิบโดยตรง มันลงนามชุดเล็กๆ ของ signed attributes ที่ รวม แฮชของเนื้อหาไว้ด้วย ดังนั้นเวลา ชนิดเนื้อหา และตัวระบุใบรับรองของผู้ลงนามจึงถูกผนึกไว้ด้วยกันทั้งหมด ส่วนไบต์เหล่านั้นอยู่ที่ไหน และทำไมช่วงไบต์จึงมีรูปทรงเช่นนั้น เป็นหัวข้อของลายเซ็นวางตัวอยู่ใน PDF อย่างไร

มาถึงตรงนี้ คณิตศาสตร์พิสูจน์ว่า คีย์หนึ่ง ลงนาม ไบต์เหล่านี้ มันไม่ได้บอกอะไรเกี่ยวกับคีย์ ของใคร ช่องว่างนั้นคือสิ่งที่ใบรับรองเติมเต็มพอดี ใบรับรองเองคือคำกล่าวที่ลงนามแล้ว — จากผู้ออกใบรับรอง — ว่าคีย์สาธารณะนี้เป็นของผู้ถือชื่อนี้ การเชื่อถือมันหมายถึงการตามลูกโซ่จากใบรับรองของผู้ลงนามขึ้นไปจนถึงหน่วยงานที่คุณตัดสินใจจะเชื่อถือ พร้อมตรวจความถูกต้องของทุกข้อต่อตลอดทาง (Spec: RFC 5280, §6) หากไม่มีลูกโซ่นั้น “ลงนามแล้ว” ก็ไม่มีชื่อ เมื่อมีมัน “ลงนามแล้ว” ก็มีชื่อ

ชิ้นส่วนสุดท้ายคือ เมื่อใด ลายเซ็นฝังเวลาที่ผู้ลงนามอ้างเองได้ แต่นาฬิกาที่คุณควบคุมไม่ได้คือคำกล่าวอ้าง ไม่ใช่หลักฐาน การประทับเวลาจาก Time-Stamp Authority ผูกแฮชของลายเซ็นเข้ากับช่วงเวลาหนึ่ง ซึ่งรับรองโดยฝ่ายที่ไม่มีส่วนได้เสียในเอกสาร (Spec: RFC 3161, §1) นั่นคือสิ่งที่ทำให้ลายเซ็นยังมีความหมายหลังจากใบรับรองของผู้ลงนามหมดอายุ คุณแสดงได้ว่าลายเซ็นมีอยู่ในขณะที่ใบรับรองยังถูกต้อง การจัดการในเชิงลึกอยู่ในการประทับเวลาและเวลาที่เชื่อถือได้

ตัวอย่างการใช้งานจริง

รูปร่างด้านล่างคือการดำเนินการเชิงแนวคิด เขียนไว้อย่างตรงไปตรงมา ประเด็นไม่ใช่การเรียก API — แต่คือการเห็นว่า การลงนาม และ การตรวจสอบยืนยัน เป็นภาพสะท้อนซึ่งกันและกัน และไบต์ที่ถูกแก้ไขทำให้การจับคู่พังโดยโครงสร้าง

<?php

declare(strict_types=1);

// SIGN — the holder of the private key seals the content.
// RSA and ECDSA sign a hash; EdDSA signs the content directly (hashing inside).
$signingInput = sign_input($content);            // a digest for RSA/ECDSA, the content for EdDSA
$signatureValue = private_key_transform(         // only the key holder can do this
    privateKey: $signerPrivateKey,
    input: $signingInput,
);

// VERIFY — anyone with the public key runs the algorithm's check.
$recomputedInput = sign_input($content);          // verifier rebuilds the same input
$intactAndAuthentic = signature_verify(           // RSA, ECDSA, EdDSA — same shape
    publicKey: $signerPublicKey,                  // taken from the certificate
    signatureValue: $signatureValue,
    input: $recomputedInput,                       // the freshly reconstructed input
);
// true  -> bytes unchanged AND signed by the private-key holder
// false -> a byte changed, or the wrong key — the honest answer is "invalid"

// The certificate answers a SEPARATE question: whose public key is this?
// The timestamp answers ANOTHER: when did this signature exist?
// "intact + authentic" alone proves neither identity nor time.

การปลอมแปลงการเปลี่ยนแปลงที่ยังตรวจผ่านเป็นเรื่องที่เป็นไปไม่ได้ในเชิงการคำนวณ แฮชนำพาเนื้อหาอย่างซื่อตรง ดังนั้นการแก้ไขเนื้อหาจึงแก้ไขแฮช และการดำเนินการ verify ปฏิเสธมัน — เว้นเสียแต่จะหา hash collision ได้ ซึ่งฟังก์ชันที่เลือกถูกออกแบบให้ทำสิ่งนั้นได้ยากในทางปฏิบัติ

ความเข้าใจผิดที่พบบ่อย

ความผิดพลาดที่พบบ่อยคือการอ่าน “ลายเซ็นที่ถูกต้อง” เป็น “เอกสารที่น่าเชื่อถือ” ทั้งสองไม่ใช่ประโยคเดียวกัน การเข้ารหัสพิสูจน์ว่า ไบต์ครบถ้วน และ ผู้ถือคีย์ส่วนตัวลงนามมัน — ไม่มีอะไรมากกว่านั้น เอกสารที่ลงนามด้วยคีย์ที่คุณไม่เคยได้ยินมาก่อน รับรองโดยไม่มีหน่วยงานใดที่คุณรู้จัก สามารถ “ถูกต้อง” อย่างไร้ที่ติและไร้ค่าได้ ตัวตนมาจากใบรับรองและลูกโซ่ของมัน เวลามาจากการประทับเวลาที่เชื่อถือได้ เครื่องหมายถูกสีเขียวที่ยุบทั้งหมดนี้รวมเป็นค่าบูลีนเดียวอย่างเงียบๆ ได้ตัดสินแทนคุณไปแล้วว่าคำถามใดสำคัญ การรู้ชิ้นส่วนต่างๆ คือสิ่งที่ทำให้คุณถามที่เหลือได้

เหตุผลที่ต้องแยกแนวคิดเหล่านี้ออกจากกันไม่ใช่ความเจ้าระเบียบ — แต่เพื่อให้คำว่า “ลงนามแล้ว” ยังคงซื่อตรง ความครบถ้วน ตัวตน และเวลา เป็นการพิสูจน์ที่ต่างกันสาม อย่าง ซึ่งสร้างขึ้นด้วยกลไกที่ต่างกันสามอย่าง (แฮชบวกคู่คีย์ ลูกโซ่ใบรับรอง และ หน่วยงานประทับเวลา) เครื่องมือที่รายงานมันเป็นธงเดียวอ่านง่ายกว่า และอ่านผิดได้ ง่ายกว่ามาก NextPDF แยกมันออกจากกัน ทั้งในเอาต์พุตและในการทดสอบ เพื่อให้ผลที่ บอกว่า “ถูกต้อง” สามารถแกะออกมาเป็นสิ่งที่ถูกพิสูจน์จริงได้อย่างแม่นยำ

ขีดจำกัดและขอบเขต

หน้านี้อธิบาย แนวคิด ของลายเซ็นดิจิทัล ไม่ใช่กระบวนการตรวจสอบความถูกต้องฉบับเต็ม คณิตศาสตร์ในที่นี้พิสูจน์ความครบถ้วนและความเป็นของแท้ มันไม่ได้ บอกคุณด้วยตัวมันเองว่าใบรับรองที่ใช้ลงนามถูกออกให้กับใครที่คุณคิดหรือไม่ มันถูกต้องในเวลาที่ลงนามหรือไม่ หรือมันถูกเพิกถอนในภายหลังหรือไม่ — เหล่านั้นเป็นคำถามเรื่องลูกโซ่ใบรับรองและการเพิกถอน และการตรวจสอบความถูกต้องที่ถูกต้องจะรันทั้งหมด ชุดการตรวจที่ครบถ้วนอยู่ในการตรวจสอบความถูกต้องของลายเซ็นอย่างเหมาะสม

NextPDF สร้างโครงสร้างลายเซ็นและดำเนินการตรวจเชิงการเข้ารหัส มันไม่ได้เลือก trust anchor ของคุณ ไม่ได้รับรองผู้ออกใบรับรองใด หรือตัดสินผลทางกฎหมายของลายเซ็น — สิ่งเหล่านั้นขึ้นอยู่กับการดีพลอยของคุณ ใบรับรอง และเขตอำนาจศาล เอนจินพิสูจน์กลไก ส่วนการตัดสินใจเรื่องความเชื่อถือที่อยู่เหนือมันเป็นของคุณ

สิ่งที่เอนจินมาพร้อม จำแนกตามระดับ ต่อยอดออกไปจากรากฐานนี้

Digital signature: integrity, identity, and trusted time — edition availability
Edition	Availability
Core	PAdES B-B: the hash-and-sign mechanism described here, packaged as a detached CMS SignedData object, plus certificate-path validation against a trust anchor you supply.
Pro	Adds PAdES B-T — a verified RFC 3161 trusted timestamp on the signature value, so the “when” is attested rather than self-claimed.
Enterprise	Adds the long-term profiles (B-LT, B-LTA): embedded validation material and document timestamps that keep the identity and time proofs answerable for years.

เอกสารที่เกี่ยวข้อง

ลายเซ็นวางตัวอยู่ใน PDF อย่างไร — ค่าลายเซ็นและช่วงไบต์ของมันอยู่ที่ไหนจริงๆ ในไฟล์
การตรวจสอบความถูกต้องของลายเซ็นอย่างเหมาะสม — ชุดการตรวจฉบับเต็มที่ตัวตรวจสอบยืนยันต้องรัน เกินกว่าคณิตศาสตร์ในหน้านี้
การประทับเวลาและเวลาที่เชื่อถือได้ — การประทับเวลา RFC 3161 พิสูจน์อะไร และทำไมนาฬิกาของผู้ลงนามเองจึงไม่ใช่สิ่งนั้น
โปรไฟล์เบสไลน์ของ PAdES — โปรไฟล์ใด ที่ซ้อนตัวตน เวลา และวัสดุระยะยาวลงบนรากฐานนี้

อภิธานศัพท์

Hash (digest) — ลายนิ้วมือสั้นที่มีความยาวคงที่ของข้อมูลจากฟังก์ชันแฮช เชิงการเข้ารหัส การเปลี่ยนแปลงข้อมูลใดๆ เปลี่ยนมันอย่างสิ้นเชิง
Key pair — คีย์ส่วนตัว (ถือไว้โดยผู้ลงนามเท่านั้น) และ คีย์สาธารณะ (แบ่งปันได้อย่างเสรี) ที่เชื่อมโยงกัน มีเพียงคีย์ส่วนตัวที่ลงนามได้ และมีเพียง คีย์สาธารณะที่จับคู่กันที่ตรวจสอบยืนยันได้
Signing — การใช้การดำเนินการด้วยคีย์ส่วนตัวกับอินพุตที่อัลกอริทึมกำหนด ได้แก่ แฮชของเนื้อหาสำหรับ RSA และ ECDSA หรือเนื้อหาโดยตรงสำหรับ EdDSA (ซึ่ง แฮชภายในเอง) ใน PDF เนื้อหานั้นคือ signed attributes ซึ่งรวมแฮชของเอกสารไว้ ผลลัพธ์คือค่าลายเซ็น
Verifying — การสร้างอินพุตเดียวกันขึ้นใหม่ (แฮชที่คำนวณซ้ำ หรือเนื้อหา โดยตรงสำหรับ EdDSA) แล้วรันการดำเนินการ verify ของอัลกอริทึมบนคีย์สาธารณะ ค่าลายเซ็น และอินพุตนั้น เพื่อให้ได้คำตอบว่าถูกต้องหรือไม่ถูกต้อง
Signature value — ไบต์ที่การดำเนินการด้วยคีย์ส่วนตัวผลิตขึ้น สิ่งที่ตัว ตรวจสอบยืนยันตรวจเทียบกับอินพุตของอัลกอริทึมที่สร้างขึ้นใหม่สดๆ (digest สำหรับ RSA และ ECDSA เนื้อหาเองสำหรับ EdDSA)
Certificate — คำกล่าวที่ลงนามแล้วซึ่งผูกคีย์สาธารณะเข้ากับตัวตนที่มีชื่อ เชื่อถือได้โดยการตามลูกโซ่ไปยังหน่วยงานที่คุณยอมรับ (RFC 5280 §6)
Trust anchor — ผู้ออกใบรับรองที่คุณตัดสินใจจะเชื่อถือ รากของลูกโซ่ ใบรับรองที่ยอมรับได้
Timestamp (RFC 3161) — โทเคนที่ลงนามแล้วจาก Time-Stamp Authority ซึ่งผูกแฮชเข้ากับค่าเวลา ให้หลักฐานที่เชื่อถือได้ว่า เมื่อใด
CMS SignedData — โครงสร้าง Cryptographic Message Syntax (RFC 5652) ที่นำพาค่าลายเซ็นและใบรับรองของผู้ลงนาม
PAdES — PDF Advanced Electronic Signatures ตระกูลโปรไฟล์ของ ETSI สำหรับ การลงนาม PDF มีอธิบายในเชิงลึกในหน้าเกี่ยวกับการลงนาม