تستند العديد من حلول التحقق عن بُعد في إصدار حكمها النهائي إلى دلائل غير مباشرة: بيئة المتصفح، والبصمة الشبكية، وبيانات القياس عن بُعد للكاميرا، وإحصائيات الصورة. هذه البيانات مفيدة لتقييم المخاطر، لكنها تصبح أساسًا ضعيفًا للحماية إذا اعتبرها النظام تأكيدًا مستقلًا على الأصالة. مع تطور الذكاء الاصطناعي التوليدي وهجمات تزوير تدفق الوسائط، أصبح التمييز بين الوثيقة التي تبدو حقيقية والوثيقة المؤكدة أمراً جوهرياً. ويتم تناول هذا التهديد بشكل منفصل من قبل NIST و ENISA.[1][2]
ما الذي يجب أن تؤكده عملية التحقق في الواقع
تُقسّم العملية الموثوقة العملية إلى ثلاث مسائل مستقلة:
- أصالة الوثيقة: هل يتطابق الوسيط المقدم أو الشهادة الرقمية مع الوثيقة الصادرة عن مصدر معتمد؟
- صحة المعلومات: هل يتم تأكيد البيانات التفصيلية، وحقيقة الإصدار، والحالة الحالية للوثيقة (عندما تكون متاحة) من قبل مصدر موثوق؟
- ملكية حامل الوثيقة: هل هناك أسباب كافية للاعتقاد بأن الشخص الذي يخضع للتحقق هو بالضبط الشخص الذي صدرت له الوثيقة؟
إن تطابق الحقول أو عدم وجود علامات على تعديل الصورة لا يغطي سوى جزء من السؤال الأول. ويفرق معيار NIST SP 800-63A-4 بشكل صريح بين تحديد الهوية، والتحقق من صحة الشهادات، وتأكيد ارتباط مقدم الوثيقة بالهوية المعلنة.[1]
ثمانية نقاط ضعف في الأساليب الشائعة
1. الاعتماد على JavaScript وبيئة المتصفح
تستنتج بعض الأنظمة نوع الجهاز و«طبيعية» الجلسة بناءً على User-Agent, navigator.platform، واللغة، والمنطقة الزمنية، والإدخال باللمس، ومعلمات الشاشة، وبصمات Canvas/WebGL، وغيرها من بيانات JavaScript.
المشكلة تكمن في مصدر الثقة. فبيئة المتصفح تخضع لسيطرة الطرف الذي يبادر بالطلب. ولذلك، لا يمكن اعتبار ادعاءاتها معادلة للحقائق المؤكدة على مستوى الجهاز. تعد فحوصات JavaScript مناسبة للبحث عن التناقضات وزيادة تقييم المخاطر، ولكن لا ينبغي أن تقرر بمفردها ما إذا كان الجهاز حقيقيًا وما إذا كان التعريف مقبولًا أم لا. تطالب OWASP بشكل منفصل بإعادة التحقق من الشروط المهمة على الخادم.[3]

2. القوائم الثابتة للبروكسيات/شبكات VPN والبصمة الشبكية الفريدة p0f
توفر سمعة عناوين IP وقوائم مراكز البيانات وشبكات VPN والبروكسيات وأدوات إخفاء الهوية المعروفة إشارات مفيدة، لكنها لا تثبت مصدر المستند. لا تغطي القوائم الثابتة جميع مسارات حركة المرور المحتملة، كما أن استخدام البروكسي أو عدم استخدامه في حد ذاته لا يحدد نزاهة المستخدم.
p0f يقوم بتحليل السمات السلبية لمكدس TCP/IP. وهذا ليس آلية للتحقق من صحة الجهاز المادي. عند العمل عبر بروكسي تطبيقي، قد يشير البصمة الشبكية إلى عقدة وسيطة، وليس إلى العميل الأصلي. كما يوصي مطورو p0f بتفسير النتيجة على أنها إشارة مساعدة.[4] لا يمكن للتحقق باستخدام عنوان IP أو p0f وحدهما أن يثبت بشكل موثوق أن هاتفًا محمولًا معينًا هو الذي يقف وراء الطلب.

3. تسجيل معلمات الكاميرا وبيانات القياس عن بُعد عبر N إطارًا
أثناء التصوير، يمكن للخدمة جمع اسم الكاميرا (label), deviceId, groupId، والدقة، ومعدل الإطارات، واتجاه الكاميرا، والعلامات الزمنية، وتسلسل الصور. كما يتم حساب السطوع (luminance)، والضبابية (blur)، والحدة، والتباين، والتغيرات في التعريض الضوئي، والانعكاسات، والحركة، والتناسق بين الإطارات، وفقدان الإطارات. تعتمد إتاحة المعلمات المحددة على المتصفح والجهاز والأذونات.[5][6]
تصف هذه القياسات عن بُعد التدفق المستلم، لكنها في حد ذاتها لا تثبت مصدره المادي. إذا كان المهاجم يتحكم في الوسائط الواردة، فيمكنه محاولة محاكاة الديناميكيات المتوقعة للمؤشرات. يؤدي التقاط عدة إطارات، وتحليل الإضاءة، وطلبات الحركة إلى تعقيد الهجوم، لكنها لا تحل محل التحقق من أصل الإشارة والحماية من الحقن الرقمي.[2]

4. التحليل الثابت للصورة: خريطة الحرارة، والضوضاء، والعيوب
تقوم الخوارزميات بتحليل خرائط الانحرافات (heat maps)، وتحليل مستوى الخطأ، وبقايا الضوضاء، وعلامات PRNU، وتكمية JPEG، ومعاملات DCT، وحدود الإدراجات، والتغيرات المحلية في الحدة، وعدم تجانس الإضاءة، وهندسة الرموز، والتطابق مع نموذج المستند.
تكشف هذه الأساليب عن الانحرافات الإحصائية، وليس عن حقيقة إصدار الوثيقة من قبل الدولة. تعتمد النتيجة على الترميز، وإعادة التصوير، وجودة المستشعر، وتوزيع البيانات التدريبية. ولا يُثبت غياب العيوب الملحوظة أصالة الوثيقة، كما أن اكتشاف أي شذوذ لا يعني دائمًا أنها مزورة. ويطالب المعهد الوطني للمعايير والتقنية (NIST) باختبار هذه الخوارزميات على عينات أصلية وعينات مزيفة، مع مراعاة حالات الإنذار الكاذب وحالات الإغفال.[2]
5. التوافق الشكلي بين منطقة القراءة الآلية (MRZ) والرمز الشريطي والبيانات المطبوعة
مقارنة المنطقة المرئية (VIZ) بالمنطقة القابلة للقراءة آليًا (MRZ)، والتحقق من أرقام المراجعة والتواريخ وهيكل الرموز ثنائية الأبعاد أمور ضرورية. لكن رقم المراجعة الصحيح يؤكد اتساق البيانات، وليس أن جهة حكومية قد أصدرت في أي وقت من الأوقات وثيقة تحتوي على هذه البيانات.
والخطأ العكسي أكثر خطورة: حيث يلاحظ النظام تباينًا بين منطقة القراءة الآلية (MRZ) والوجه الأمامي للوثيقة، لكنه لا يمنع إصدار قرار إيجابي. في NIST SP 800-63A-4، تم تضمين مقارنة منطقة القراءة الآلية (MRZ) أو الرمز الشريطي بالبيانات المطبوعة بشكل صريح ضمن متطلبات الفحص البصري الآلي.[2]
6. الرموز «الديناميكية» التي تفتقر إلى الحماية من إعادة الاستخدام
nonce، ومعرّف العملية والتحدي الذي يُستخدم لمرة واحدة لا تكون مفيدة إلا عندما يتحقق الخادم من صلاحيتها، وارتباطها بالجلسة ومرحلة العملية، وكذلك من حقيقة استخدامها سابقًا. لا تُعد السلسلة التي يتم إنشاؤها عشوائيًا حمايةً إذا كان من الممكن تقديمها مرارًا وتكرارًا لعمليات تحقق مختلفة.
يجب أن يتم ضمان الحماية من إعادة الاستخدام من خلال منطق الخادم، وعند الاقتضاء، من خلال ربط النتيجة تشفيرياً بعملية محددة. تعتبر OWASP إعادة استخدام الرموز وتخطي مراحل العملية من المخاطر المتعلقة بمنطق الأعمال في واجهة برمجة التطبيقات (API).[7]
7. «Liveness» والتعرف على الوجه كبديل للتحقق من الوثائق
تحقق وجود الشخص (liveness / PAD) ومقارنة الوجه بالصورة يحلان مهامًا مهمة، لكنها محدودة. حتى المقارنة البيومترية الناجحة لا تثبت حقيقة إصدار الوثيقة أو أن الشخص الذي يظهر وجهه على الوثيقة هو نفسه الشخص الذي يدعي أنه هو. علاوة على ذلك، فإن اختبار PAD ومقاومة السلسلة بأكملها للتزوير الرقمي هما نوعان مختلفان من التقييم. تتناول المواصفة ISO/IEC 30107-3:2023 اختبارات PAD، لكنها لا تتناول تقييم أمان النظام بأكمله للتعريف عن بُعد.[8]
8. النماذج ذاتية التعلم التي تفتقر إلى الحماية من تسميم البيانات
يظهر خطر خاص عندما يستخدم النظام تلقائيًا نتائج التحميلات التي يقوم بها المستخدمون أو ردود الفعل التي لم يتم التحقق منها بشكل كافٍ لتعديل أوزان النموذج. وبدون تصنيف موثوق به، وعزل الأمثلة الجديدة، ومراقبة الإصدارات، والتحقق المستقل، يتمكن المهاجم من التأثير على القرارات المستقبلية.
يُعرف هذا النوع من التهديدات باسم data poisoning ويتم تناوله بالتفصيل من قبل NIST في تصنيف هجمات أنظمة التعلم الآلي.[9]
لماذا تفاقمت المشكلة في عصر الذكاء الاصطناعي التوليدي
الحماية التي تعتمد فقط على التسلسل المتوقع للملاحظات معرضة للتكرار: إذا تلقى الخادم تدفقًا تم تشكيله مسبقًا، فلن يتمكن تلقائيًا من اعتبار القياسات blur, luminanceوالحركة والتأخيرات كأدلة مستقلة على التصوير الفعلي. يمكن تكرار عمليات التحقق المحددة من جانب العميل بدقة عالية في عدد من السيناريوهات، شريطة وجود رقابة كافية على البيانات المدخلة.
هذا لا يعني أن أي خوارزمية يمكن التحايل عليها بشكل مؤكد أو أن جميع آليات التحقق من الحيوية عديمة الفائدة. تصبح الحماية أقوى عند إجراء عمليات التحقق غير المتوقعة، والتحقق من صحة المستشعر، وربط الجلسة بالخادم، ومصادر البيانات المستقلة، والتحقق التشفيري. ومع ذلك، لا يُعد أي من هذه العوامل بمفرده دليلاً كافياً على الهوية الحقيقية. تُصنف وكالة ENISA الهجمات التي تعتمد على «الحقن الرقمي» و«الوسائط المزيفة» على أنها تهديدات خطيرة للتعريف عن بُعد.[10]
ما اكتشفناه خلال عمليات الفحص التي أُجريت بموافقة العملاء
في إطار الأبحاث التي تم الاتفاق عليها مع مالكي الأنظمة، سجل فريقنا فئات الأخطاء التالية:
- الثقة في User-Agent. كانت بعض التطبيقات تقبل الادعاء بوجود متصفح جوال دون إجراء فحص مستقل كافٍ لخصائص الاتصال والجهاز.
- إعادة استخدام المعلمات الأمنية. كانت المعلمات المُصنَّفة على أنها «ديناميكية» تُقبل من قبل الخادم مرارًا وتكرارًا دون مراقبة مناسبة لدورة حياتها.
- تسميم عملية التعلم الحي. في أحد الأنظمة المكتوبة يدويًّا، أثرت المستندات المزيفة التي تم تحميلها على حلقة التعلم، وبدأت سمات هذه العينات تحظى بالأفضلية على المعايير المرجعية التي تم تسجيلها سابقًا.
- تجاهل التناقضات. في إحدى عمليات التنفيذ، لم يمنع التناقض بين بيانات المنطقة القابلة للقراءة آليًّا والجزء المرئي من المستند اتخاذ قرار إيجابي.
تم إخطار الأطراف المسؤولة والشركات المصنعة بالعيوب التي تم الكشف عنها. الحالات المذكورة هي نتائج عمليات التدقيق الخاصة بنا، وليست عينة إحصائية عامة للسوق: لا يتم الكشف هنا عن أسماء الأنظمة وحجم العينة والمواد المستخدمة في التجربة. وهي توضح أخطاء تصميم محددة ولا تعني أن جميع الموردين يعانون من نفس نقاط الضعف.
الحد الفاصل الرئيسي للثقة هو مصدر الإصدار، وليس الصورة
قد يبدو المستند مثاليًّا ومتسقًا داخليًّا، لكنه قد يحتوي على بيانات هوية لشخص غير موجود أو لم يتم تأكيده من قبل مصدر مُخوَّل. لذلك، لا يمكن استبدال الحكم القائل «لم يتم الكشف عن علامات التلاعب» بالحكم القائل «تم تحديد الهوية».
في حالة توفر الوصول القانوني والتقني، يجب أن تقارن عملية التحقق السمات الرئيسية وحالة الوثيقة بالسجل الحكومي أو مصدر الإصدار أو أي مصدر موثوق آخر أو مصدر يمكن التحقق من مصداقيته. بالنسبة لجوازات السفر الإلكترونية، توجد طريقة تشفيرية منفصلة: التحقق من التوقيع الرقمي لبيانات الشريحة وسلسلة الثقة DSC → CSCA، كما وصفتها منظمة الطيران المدني الدولي (ICAO). وهي تؤكد منشأ وسلامة البيانات الموقعة، لكنها في حد ذاتها لا تحل محل التحقق من الحالة الحالية للوثيقة وعلاقتها بحاملها.[1][11]
في حالة عدم توفر مصدر موثوق، فإن النتيجة الصحيحة هي «لم يتم تأكيد صحة الإصدار أو الحالة الحالية»، وليس «الوثيقة أصلية» بشكل قاطع. ولا يُثبت عدم وجود رد من السجل في هذه الحالة التزوير: يجب أن يميز النظام بين التحقق السلبي وعدم القدرة على التحقق.
| المستوى | ما الذي يوضحه | ما الذي لا يثبته |
|---|---|---|
| بيئة المتصفح والشبكة | وجود علامات خطر في الاتصال والجلسة | صحة الجهاز أو المستند أو الهوية |
| الكاميرا، والتحقق من الحيوية، وتحليل الوسائط | توافق التدفق المرصود وعلامات التزوير | حقيقة إصدار الوثيقة من قبل الدولة |
| التعرف الضوئي على الحروف (OCR)، المنطقة القابلة للقراءة آليًا (MRZ)، الرموز والقوالب | تنسيق البيانات وتناسقها الداخلي | وجود السجل لدى الجهة المصدرة |
| التوقيع الرقمي وسلسلة الثقة | أصل وسلامة البيانات الموقعة عند التحقق الصحيح من صحتها | الحالة الحالية ومشروعية الاستخدام من قبل حامل الوثيقة |
| المصدر الموثوق والتحقق من هوية حامل السند | تأكيد السمات المتاحة والحالة والارتباط بالهوية | الخلو التام من الاحتيال في أي سيناريو لاحق |
نهجنا: التحقق من أسس الثقة الحقيقية، وليس فقط من العلامات غير المباشرة
نحن لا نقيم النظام بناءً على عدد أجهزة الاستشعار والتوقيعات والخوارزميات الواردة في العرض التقديمي، بل بناءً على الادعاء المحدد الذي يمكن لكل عملية تحقق إثباته وكيف تتصرف عند تعرضها لهجوم موجه. نقوم ببناء نموذج حماية للعميل بناءً على الوثائق، والسلطات القضائية، وسيناريو الاستخدام، ومستوى المخاطرة المسموح به.
- مستويات رقابة مستقلة. تُؤخذ المؤشرات المتعلقة بالمتصفح والشبكة والمؤشرات المرئية في الاعتبار كإشارات إضافية على وجود مخاطر، وليس كدليل قائم بذاته.
- عملية تحقق محمية. التحكم في المراحل من جانب الخادم، والطابع الأحادي الاستخدام، وربط التحدي (challenge)، وكشف التكرارات، والحماية من التبديل الرقمي لتيار البيانات.
- التحقق من منشأ المستند. التحقق من الشهادات التشفيرية المقبولة والتكامل مع المصادر الرسمية أو غيرها من المصادر الموثوقة حيثما كان ذلك ممكنًا من الناحيتين القانونية والتقنية.
- حماية حلقة التدريب. التخزين المنفصل لبيانات المستخدمين والتمييز المرجعي، والتحديث الخاضع للرقابة للنماذج، والتحقق من انحراف الجودة، وإمكانية الرجوع إلى الإصدار السابق.
- الاستقرار القابل للقياس. تقييم الافتراضات الخاطئة والانحرافات (بما في ذلك
DFAR/DFRRفي تحليل المستندات)، واختبارات استبدال التدفق، والتكرارات، والحقول المتناقضة، وأنواع جديدة من الصور الاصطناعية.
بالنسبة لنا، لا تعني الفحص القوي «حماية بنسبة 100٪»، بل إجراءً قابلاً للتكرار مع مصادر ثقة واضحة، ومقاييس قابلة للتحقق، وفصل واضح بين حالات «تم التأكيد» و«غير مؤكد» و«تم اكتشاف تناقض».
هل تحتاج إلى حماية من المستندات المزورة بما يتناسب مع مهمتك؟
لا يوجد مرشح شامل موثوق به بنفس الدرجة لجميع المستندات وقنوات التحقق. إذا كان هدفك هو الحد من إساءة استخدام المستندات المزورة، أو التحقق من متانة عملية «اعرف عميلك» (KYC) الحالية، أو بناء حل خاص لولاية قضائية معينة ونموذج تهديدات محدد، فاتصل بنا.
سنساعدكم في تحديد النقاط التي يعتمد فيها النظام على إشارات مزيفة، وتحديد مصادر الثقة الضرورية، وتصميم عملية تحقق يمكن تأكيد متانتها من خلال الاختبارات الفنية، وليس من خلال الوعود التسويقية.
المصادر التقنية
تؤكد هذه المصادر الخصائص التقنية العامة ونماذج التهديدات والمعايير. وقد تم وصف النتائج الخاصة بتدقيقاتنا بشكل منفصل أعلاه.
- NIST SP 800-63A-4 — نظرة عامة على إثبات الهوية. الفصل بين تحديد الهوية والتحقق من الشهادات والتحقق من هوية حاملها؛ المصادر الموثوقة والمعتمدة.
- NIST SP 800-63A-4 — متطلبات إثبات الهوية. التحليل البصري، منطقة القراءة الآلية (MRZ)، استبدال تدفق الوسائط، الهجمات باستخدام الذكاء الاصطناعي التوليدي، ومتطلبات الاختبار.
- OWASP — ورقة مرجعية للتحقق من صحة المدخلات. عدم الثقة في التحقق من جانب العميل والتحقق الإلزامي من جانب الخادم.
- p0f — وثائق المشروع. الغرض من «بصمة TCP/IP» السلبية وقيود هذه الطريقة.
- MDN — MediaDevices.enumerateDevices(). قائمة أجهزة الوسائط وقيود الوصول إلى بياناتها الوصفية.
- MDN — MediaStreamTrack.getSettings(). المعلمات المتاحة لدفق الوسائط.
- OWASP — REST Security Cheat Sheet. حماية حالة واجهة برمجة التطبيقات (API) وتسلسل الخطوات والرموز من إعادة الاستخدام.
- ISO/IEC 30107-3:2023. طرق الاختبار وإعداد التقارير للكشف البيومتري عن هجمات التزوير (PAD).
- NIST AI 100-2e2025 — التعلم الآلي العدائي. تصنيف الهجمات، بما في ذلك تسميم البيانات والنماذج.
- ENISA — التحقق من الهوية عن بُعد: الممارسات الجيدة (2024). تهديدات تحديد الهوية عن بُعد، بما في ذلك هجمات التزوير والحقن الرقمي.
- ICAO — أساسيات جواز السفر الإلكتروني. التوقيعات الرقمية لجوازات السفر الإلكترونية وسلسلة الثقة DSC/CSCA.