كيف تتحقّق من صحة توقيع PAdES (دليل المطوّر)

إن كنت تبني التحقق من التوقيع داخل منتج — نظام مشتريات يفحص العقود قبل الدفع، أو أرشيف يجب أن يُثبت المستندات بعد سنوات، أو خط أنابيب امتثال — فإن «يُظهر علامة صح خضراء في أكروبات» ليس اختبار قبول. التحقق من صحة PAdES خوارزمية محدَّدة بمدخلات محدَّدة وفحوص محدَّدة وحالات فشل محدَّدة. هذه هي تلك الخوارزمية، بالترتيب الذي يشغّله متحقّق مطابق، بالتفصيل على مستوى البايت الذي تحتاجه لبناء واحد أو تدقيقه.

ETSI EN 319 142-1

يعرّف ملفّات PAdES الأساسية (B-B، B-T، B-LT، B-LTA) — أي بُنى يجب أن يحتويها توقيع PDF مطابق عند كل مستوى

ETSI TC ESI

ISO 32000-2 §12.8

يحدّد قاموس توقيع PDF: ‏/ByteRange و/Contents و/SubFilter، وكيف يُضمَّن التوقيع في الملف

ISO/IEC 32000-2:2020

RFC 5652

بنية رسائل التشفير (CMS) — بنية SignedData التي تحملها PAdES في /Contents كتوقيع منفصل

IETF CMS

التوقيع يعيش في بنية الـ PDF

توقيع PAdES هو قاموس توقيع PDF مضمَّن عبر تحديث تزايدي. مُدخلان يقومان بالعمل الحقيقي. /ByteRange مصفوفة من أربعة أعداد صحيحة — [a b c d] — تحدّد بالضبط أيّ بايتات من الملف يغطّيها التوقيع: البايتات من a إلى a+b، ثم من c إلى c+d. والفجوة في المنتصف هي الثقب حيث يجلس التوقيع نفسه. و/Contents هو ذلك الثقب: كائن PKCS#7 / CMS ‏SignedData مُرمَّز ستّ عشرياً، منفصل (المحتوى الموقَّع هو بايتات ByteRange، لا مضمَّن في CMS).

ضبط الـ ByteRange بشكل صحيح هو أول موضع يفشل فيه المتحقّقون. فإن لم يغطِّ الـ ByteRange كامل الملف عدا ثقب /Contents، أمكن لمهاجم أن يُلحق محتوى بعد النطاق الموقَّع — هجوم «الحفظ التزايدي» الكلاسيكي. المتحقّق الصحيح يؤكّد أن الـ ByteRange لا يترك بايتات غير موقَّعة سوى ثقب التوقيع نفسه.

Step ١

حلّل قاموس التوقيع

حدّد موقع قاموس /Sig، واقرأ /ByteRange و/Contents. أكّد أن /SubFilter هو ETSI.CAdES.detached ‏(PAdES) — لا adbe.pkcs7.detached القديم — وأن الـ ByteRange يمتدّ على كامل الملف عدا ثقب /Contents.

Step ٢

أعد حساب الملخّص وطابِقه

احسب SHA-256 للبايتات التي يغطّيها /ByteRange. قارِنها بسمة message-digest الموقَّعة داخل CMS SignedData. عدم التطابق يعني أن البايتات المغطّاة تغيّرت منذ التوقيع.

Step ٣

تحقّق من توقيع CMS فوق السمات الموقَّعة

يغطّي توقيع RSA (أو ECDSA) الترميز DER لمجموعة السمات الموقَّعة، لا الملخّص الخام. تحقّق منه بمفتاح الموقّع العام من الشهادة المضمَّنة.

Step ٤

تحقّق من صحة شهادة التوقيع والطابع الزمني

سِر في سلسلة X.509 حتى جذر موثوق، وافحص الإلغاء (CRL/OCSP)، وتحقّق من رمز الطابع الزمني RFC 3161 في السمات غير الموقَّعة فوق قيمة التوقيع.

السمات الموقَّعة هي حيث يصبح PAdES صارماً

من المفاهيم الخاطئة الشائعة أن التوقيع يغطّي هاش المستند مباشرةً. وهو لا يفعل. في CMS، حين تكون السمات الموقَّعة حاضرةً (وPAdES تشترطها)، يُحسب التوقيع فوق ترميز DER لمجموعة SignedAttributes كاملةً. اثنتان من تلك السمات إلزاميتان وهما بالضبط ما يجب أن يفحصه المتحقّق.

السمات الموقَّعة التي يجب أن يؤكّدها متحقّق PAdES

message-digest ‏(RFC 5652)
قيمة SHA-256 لمحتوى الـ ByteRange. يُعيد المتحقّق حسابها مستقلاً ويؤكّد أنها تساوي قيمة السمة. هذا هو الرابط بين التوقيع وبايتات المستند الفعلية.
ESS signing-certificate-v2 ‏(RFC 5035)
هاش لشهادة التوقيع، مربوط داخل السمات الموقَّعة. يمنع هذا هجمات استبدال الشهادة — تبديل الشهادة مع إبقاء التوقيع. تُلزِم PAdES به؛ والمتحقّق الذي يتجاوزه يقبل شهادة مستبدَلة. ملاحظة: لا تستطيع PKCS#7 المدمجة في node-forge إصدار هذه السمة، ولهذا تبني التطبيقات المتينة بنية SignedData يدوياً.
content-type
يجب أن تكون حاضرةً ومتّسقةً (id-data). جزء من مجموعة السمات المرتَّبة بـ DER التي يلتزم بها التوقيع.
ترتيب DER لمجموعة السمات
SignedAttributes هي SET OF، ويتطلّبها DER بترتيب مفروز. فإن بناها الموقّع غير مفروزة، لن يُعيد التوقيع إنتاج نفسه. على المتحقّقين والموقّعين توحيد الترميز بشكل متطابق.

المستويات الأساسية تقرّر كم يبقى صالحاً

PAdES-B-B توقيع صالح اليوم. أمّا ما إذا كان ما زال قابلاً للتحقق بعد خمس سنوات فيعتمد على المستوى الأساسي الذي بلغه. المستويات تراكمية — كلٌّ يتضمّن ما دونه — ويضيف كلٌّ دليلاً يصمد أمام نوع مختلف من التآكل.

المستويات الأساسية لـ PAdES بموجب ETSI EN 319 142-1. على المتحقّق أن يعرف المستوى المستهدَف ليحكم ما إذا كانت البيانات المفقودة عيباً أم متوقَّعة. يُنتج سهل ساين B-T افتراضياً.

Jurisdiction	Law	Cross-border transfer rule	Intensity
PAdES-B-B	أساسي	توقيع + شهادة توقيع. لا وقت توقيع موثوق. قابل للتحقق فقط ما دامت الشهادة صالحة وما دمت تثق بساعة الموقّع.	Moderate
PAdES-B-T	طابع زمني	يضيف طابعاً زمنياً RFC 3161 فوق قيمة التوقيع من سلطة طوابع موثوقة. لحظة التوقيع قابلة للإثبات مستقلاً عن الموقّع. الأساس العملي للتوقيعات الملزِمة قانوناً.	Restricted
PAdES-B-LT	طويل الأمد	يضمّن سلسلة الشهادات كاملةً إضافةً إلى بيانات الإلغاء CRL/OCSP في قاموس DSS. يبقى التوقيع صالحاً حتى بعد أن تتوقّف سلطة التصديق المُصدِرة.	Restricted
PAdES-B-LTA	أرشيفي	يضيف طوابع زمنية للمستند تُجدَّد دورياً. يحمي من تآكل خوارزميات التشفير للحفظ بمستوى أرشيفي (١٠+ سنوات).	Strict

التحقق من الطابع الزمني

عند B-T وما فوق، يجلس رمز الطابع الزمني RFC 3161 كسمة غير موقَّعة ‏(signature-time-stamp) داخل CMS. وهو نفسه بنية CMS SignedData، موقَّعة من سلطة الطوابع، وبصمة رسالتها هي هاش قيمة التوقيع — لا المستند. على المتحقّق أن يؤكّد تطابق البصمة، وأن شهادة سلطة الطوابع تتّصل بجذر توقيت موثوق، وأن يحلّل genTime من TSTInfo لوقت التوقيع المُؤكَّد.

الطابع الزمني يغطّي قيمة التوقيع، ويُطلَب بعد التوقيع — هشّ بايتات التوقيع، أرسل تلك البصمة إلى سلطة الطوابع، ضمّن الرمز المُعاد. والمتحقّق الذي يحاول التحقق من الطابع الزمني مقابل ملخّص المستند بدل قيمة التوقيع سيرفض كل توقيع B-T صالح يراه.

— الترتيب الذي يُعثِر التطبيقات الأولى

لا تصنع واحداً من الصفر — استخدم المتحقّق المرجعي

ما لم يكن لديك سبب محدّد لتطبيق الخوارزمية بنفسك، تحقّق بـ DSS من المفوضية الأوروبية. يطبّق كل ملف ETSI، ويُنتج تقريراً منظَّماً يُسمّي الفحص الفرعي الذي فشل بالضبط، ويعمل دون اتصال لتدفقات الاكتشاف القضائي والتدقيق بالجملة.

التحقق البرمجي من صحة PAdES

EU DSS ‏(مفتوح المصدر، Java + REST)
التطبيق المرجعي لخوارزمية التحقق الكاملة من ETSI. زوّده بملف PDF ومجموعة مراسي ثقة؛ يُرجع تقريراً مفصّلاً (نجح كلياً / غير محدَّد / فشل كلياً) مع سبب كل حكم.
pyHanko ‏(بايثون)
مكتبة مفتوحة المصدر جيدة الصيانة للتوقيع والتحقق من PAdES معاً، بما في ذلك LTV والتحقق من الطابع الزمني — مفيدة لتضمين التحقق في خط أنابيب بايثون.
‏‫SahlSign /verify/[documentId]
كل مستند من سهل ساين يعرض نقطة تحقق عامة تُعيد فحص هاش السلامة وسلسلة التدقيق وطابع سلطة الطوابع من جهة الخادم — فيتحقّق الطرف المقابل دون الوثوق بواجهتنا أو تثبيت أي شيء.

كيف يبني سهل ساين توقيعات PAdES

يبني سهل ساين بنية CMS ‏SignedData يدوياً بدل الاعتماد على مساعد PKCS#7 في مكتبة، تحديداً ليتمكّن من إصدار سمة ESS signing-certificate-v2 التي تُلزِم بها PAdES، وفرز السمات الموقَّعة بـ DER، وطلب طابع RFC 3161 الزمني فوق قيمة التوقيع بموجب ETSI EN 319 122-1. والنتيجة تتحقّق بنظافة في أكروبات، وEU DSS، وأي متحقّق PAdES مطابق.

PAdES-B-T

المُخرَج الافتراضي لسهل ساين: بنية PKCS#7 SignedData منفصلة فوق /ByteRange، بـ SHA-256 + RSA، وESS signing-certificate-v2 في سمات موقَّعة مفروزة بـ DER، وطابع زمني RFC 3161 من سلطة طوابع مُدرَجة في EUTL فوق قيمة التوقيع.

src/lib/pdf-seal.ts و src/lib/tsa.ts في مصدر سهل ساين

قراءة ذات صلة

كيف تتحقّق من PDF موقَّع — التحقق نفسه، معروضاً عبر واجهة أدوبي أكروبات لغير المطوّرين.
كيف تتحقّق من توقيع رقمي — الأساسيات التشفيرية (الهاش، فحص المفتاح العام، سلسلة الثقة) تحت بنية PAdES.
هل توقيعي الإلكتروني صالح قانوناً؟ — ماذا تعني حزمة أدلة PAdES-B-T بمجرّد أن يبلغ التوقيع المحكمة.