كيف تُبنى أنظمة الهوية الرقمية المتنقلة على أساس تشفيري قابل للحوكمة؟

لا تكمن صعوبة دمج رخصة القيادة الرقمية على الهاتف (mDL) في استدعاء واجهة برمجية للتحقق من الهوية، بل في فهم ما يحدث خلف هذه الواجهة: أين تُخزَّن بيانات الاعتماد، من يحمي مفاتيح الجهاز، كيف تُدار شهادات الثقة، وما الذي يستمر في العمل عند انقطاع الشبكة أو تعطل مزود الخدمة. ويعرض المقال المنشور على InfoQ تصوراً معمارياً لأنظمة mDL المبنية وفق معيار ISO/IEC 18013-5، موجهاً إلى المؤسسات التي تختار مزوداً أو SDK أو منصة محفظة أو خدمة تحقق.

الفصل بين إثبات الهوية وإصدار الاعتماد

يبدأ الإطار المقترح بالفصل بين مرحلتين مختلفتين في دورة حياة الهوية. ففي مرحلة إثبات الهوية، يلتقط المستخدم صور رخصته المادية وفيديو للتحقق من الحيوية، ثم تُرسل الأدلة والبيانات المستخرجة إلى نظام التحقق. وتراجع الجهة المختصة، مثل إدارة المركبات، هذه الأدلة آلياً أو يدوياً قبل إصدار قرار بالقبول أو الرفض.

بعد الموافقة تبدأ مرحلة التزويد. ينشئ الجهاز مفاتيح غير متماثلة داخل Secure Enclave أو عنصر أمني، ويرسل المفتاح العام وشهادات التصديق ومرجع عملية الإثبات إلى الجهة المصدرة. وتربط الجهة بيانات الرخصة بالمفتاح داخل Mobile Security Object موقّع، ثم تشفر حزمة الاعتماد وترسلها إلى المحفظة لتخزينها في مساحة مدعومة عتادياً.

لا يشترط أن تنفذ المؤسسة هذه الخطوات بنفسها، لكنها مطالبة بتحديد الطرف المسؤول عن كل خطوة والطرف الذي يملك قرار الثقة الناتج عنها.

ما الذي يجب فحصه خلف واجهة المزود؟

يرى المقال أن نجاح تجربة تجريبية تستدعي وظائف مثل verifyCredential() أو requestPresentation() لا يكفي لتقييم المزود. ويجب أن يشمل الفحص ستة محاور مترابطة:

• البنية التشفيرية: إنشاء المفاتيح وحمايتها، وتصديق الجهاز، والخوارزميات ودورة حياة المفاتيح.
• الثقة والبنية التحتية للمفاتيح العامة: نقاط الثقة، وشهادات Document Signer، وقوائم الثقة والإبطال.
• الخصوصية وتقليل البيانات: الإفصاح الانتقائي، والقياس عن بُعد، والاحتفاظ ببيانات العرض ومخاطر الربط بين المعاملات.
• العمل دون اتصال: المواد المخزنة مؤقتاً، وحالة الإبطال القديمة، وسلوك النظام أثناء انقطاع الشبكة.
• قابلية التشغيل البيني: الالتزام بـ ISO/IEC 18013-5 وإمكان التفاعل مع محافظ ومتحققات مستقلة.
• المرونة التشغيلية: أثر تعطل المزود، واستمرارية الاعتماد، وآليات التعافي والتعامل مع الفشل.

التشفير والشهادات ليسا تفاصيل تنفيذية

يقترح المقال استخدام Hybrid Public Key Encryption وفق RFC 9180 لحماية عمليات النقل عبر الإنترنت وتبادلات واجهات البرمجة، مع تحديد معلمات تشمل DHKEM(P-256, HKDF-SHA256)، وHKDF-SHA256، وAES-128-GCM. لكن التشفير، بحسب الإطار المطروح، لا ينبغي أن يُعامل كميزة منفصلة عن نموذج الثقة؛ إذ يجب معرفة مكان بدء التشفير وانتهائه، ومن ينشئ المفاتيح ويحميها، وكيفية تدويرها، وما المكونات الواقعة داخل حدود ثقة المزود.

كما تحتاج الاتصالات بين خوادم المحافظ ومنصات الإصدار وأنظمة التحقق إلى مصادقة متبادلة عبر TLS وبنية شهادات واضحة. ويعرض المقال أدواراً مختلفة للشهادات، من جذر الثقة المخزن في وحدة أمن عتادية وغير متصلة، إلى شهادات Document Signer قصيرة العمر، وشهادات mTLS، وشهادات تصديق مفاتيح الأجهزة. وتبقى المسألة الحاسمة هي توزيع المسؤوليات: أي بنية يديرها المزود، وأيها تحت سيطرة المؤسسة، وأي علاقات ثقة تظل بيد الجهة المصدرة.

ما الذي يتغير عملياً عند انقطاع الخدمة؟

يميز التصميم بين العمليات المتزامنة التي تحدث أثناء التحقق، مثل تبادل البيانات عبر NFC أو التحقق المباشر عبر API، والعمليات غير المتزامنة التي يمكن تنفيذها في الخلفية، مثل مراجعة إثبات الهوية، وتزويد الاعتماد، وتدوير المفاتيح ومزامنة قوائم الثقة.

هذا الفصل يسمح باستمرار عرض اعتماد موجود والتحقق منه دون اتصال عندما تسمح السياسات بذلك، بينما يمكن تأجيل مزامنة قوائم الثقة أو تحديثات الإبطال. ويقترح المقال اختبار العرض والتحقق دون شبكة، والاعتمادات المنتهية، وقوائم الإبطال القديمة، وانحراف ساعة الجهاز، واستعادة الاتصال، وسلوك النظام أثناء تعطل المزود. فالاعتماد على مزود متاح بدرجة عالية قد يظل نقطة فشل واحدة إذا تطلب كل تحقق اتصالاً بخدماته الخلفية.

الإفصاح الانتقائي ومنع الارتهان للمزود

تختلف البيانات المطلوبة باختلاف الحالة. فقد تحتاج نقطة تفتيش في مطار إلى الاسم والصورة وتاريخ الميلاد ورقم الوثيقة وسلطة الإصدار، بينما قد يكتفي متجر ببيان منطقي يثبت أن عمر المستخدم يتجاوز 21 عاماً مع صورة، من دون الاسم أو العنوان أو رقم الوثيقة. لذلك لا يكفي اختبار المزود عبر سيناريو واحد؛ إذ يجب قياسه مقابل سياسات المؤسسة وفئات المعاملات الفعلية.

وتقترح المادة إبقاء منطق الأعمال مستقلاً عن بنية المزود، بحيث تعبر التطبيقات عن سياسة مثل طلب إثبات تجاوز 21 عاماً بدلاً من نشر هياكل بيانات خاصة بالمزود في أنحاء النظام. ويمكن إخفاء تفاصيل مثل تسلسل CBOR وبناء رسائل APDU واستدعاءات مكتبات التشفير، لكن يجب أن تظل نقاط الثقة وهوية الجهة المصدرة والسمات المفصح عنها وحالة الشهادة والإبطال والاعتماد على المزود وقدرات العمل دون اتصال مرئية للمؤسسة.

قراءة certi.news

التغيير الحقيقي الذي يركز عليه المقال هو نقل تقييم mDL من اختبار وظيفة SDK إلى مراجعة نظام ثقة كامل. وتفيد هذه المقاربة فرق الأمن والهوية والمشتريات لأنها تحدد ما يمكن شراؤه وما يجب أن يبقى تحت حوكمة المؤسسة: يمكن شراء تنفيذ المحفظة وبروتوكولات NFC ومكتبات التشفير، بينما ينبغي بناء سياسات الإفصاح والتفويض والتدقيق، وحوكمة إدارة المفاتيح والشهادات والخصوصية والتوافر وقابلية التشغيل البيني.

لكن الإطار لا يحسم وحده مسائل مثل متطلبات الامتثال المحلية أو نماذج الحوكمة بين الجهات المصدرة والمتحققين. كما أن ضمان صحة التوقيع لا يضمن الخصوصية إذا احتفظت الأنظمة بسجلات زائدة أو ربطت عمليات العرض بالمستخدمين. لذلك تبقى أسئلة التتبع، والإبطال الذي يحافظ على الخصوصية، والمسؤولية عند فشل المزود، نقاطاً تحتاج إلى قرارات مؤسسية وتنظيمية قبل الانتقال إلى الإنتاج.