بدأت Google Pay وMastercard في طرح المدفوعات المدعومة بالبصمة الحيوية (biometric) في الهند باستخدام طريقة التحقق من حامل البطاقة عبر جهاز المستهلك (CDCVM). يؤكد المتسوقون عملية الشراء عبر مسح بصمة الإصبع أو الوجه، وتظل البيانات الحيوية محصورة داخل الهاتف.
لماذا تكتسب تقنية CDCVM أهمية الآن
تنقل تقنية CDCVM عملية التحقق من "هويتك" إلى الجهاز نفسه. لا يغادر الهاتف سوى رمز دفع (token) صالح للاستخدام لمرة واحدة وموقع تشفيرياً، مما يضمن عدم انتقال البيانات الحيوية عبر الإنترنت أبداً.
كيف تعمل هذه العملية تقنياً
- استخراج الميزات (Feature extraction) – يقوم المستشعر (قارئ بصمة الإصبع أو الكاميرا) بتغذية البيانات الخام إلى "المستودع الآمن" (Secure Enclave) أو "بيئة التنفيذ الموثوقة" (TEE). تقوم هذه المناطق المعزولة بمعالجة المدخلات دون تعريضها لنظام التشغيل.
- المقارنة المحلية – يخزن الجهاز نموذجاً مشفراً للبيانات الحيوية للمستخدم. يقوم المستودع الآمن (Secure Enclave) بمقارنة اللقطة الحية بهذا النموذج، دون إرسال الصورة الخام أو متجه الميزات (feature vector) إلى أي مكان آخر.
- التصديق على الأجهزة (Hardware attestation) – عند نجاح المطابقة، يقوم المستودع بتوقيع المعاملة باستخدام مفتاح خاص لا يغادر الأجهزة أبداً. يثبت هذا التصديق أنه تم استخدام بصمة حيوية تم التحقق منها، دون الكشف عن البصمة نفسها.
- إنشاء الرمز (Token generation) – يتم دمج التصديق الموقع مع خدمة الرموز (token-service) لإنتاج رمز صالح للاستخدام لمرة واحدة. ينتقل الرمز، وليس البيانات الحيوية، إلى التاجر ثم إلى البنك المصدر لإتمام التسوية.
لا يرى التاجر والبنك سوى الرمز الموقع. وتظل جميع البيانات الحيوية في الذاكرة المحمية للجهاز.
عثرات يجب على المطورين تجنبها
- إرسال متجهات البيانات الحيوية (biometric vectors) – يؤدي نقل بيانات بصمة الإصبع أو الوجه الخام إلى تعريض البيانات للخطر بشكل دائم. فبصمة الإصبع لا يمكن تغييرها في حال اختراق قاعدة البيانات.
- هجمات إعادة التشغيل (Replay attacks) – يمكن التقاط التمثيلات الرقمية للبيانات الحيوية وإعادة إرسالها لانتحال صفة المستشعر إذا انتقلت عبر الشبكة.
- التعقيدات التنظيمية – تتعامل العديد من الولايات القضائية مع البيانات الحيوية كمعلومات شخصية حساسة للغاية، وتفرض قواعد صارمة بشأن التخزين والموافقة والإخطار بالاختراقات.
تعامل مع البيانات الحيوية كمفتاح محلي يفتح العمليات التشفيرية؛ ولا ترسلها أبداً كحمولة بيانات (payload).
قائمة مراجعة للتنفيذ العملي
- استخدم واجهات برمجة التطبيقات (APIs) الحيوية التي توفرها المنصة والتي تبقي عملية الالتقاط والمعالجة داخل بيئة التنفيذ الموثوقة (TEE) للجهاز.
- خزّن نموذج البيانات الحيوية مشفراً باستخدام مفتاح يديره المستودع الآمن (Secure Enclave)؛ ولا تقم أبداً بكتابته في نظام الملفات.
- اطلب التصديق على الأجهزة (hardware attestation) بعد نجاح عملية المطابقة.
- تكامل مع خدمة الترميز (tokenization service) التي تستقبل التصديق وتصدر رمزاً صالحاً للاستخدام لمرة واحدة. قم بتضمين التصديق الموقع في طلب الرمز، ولكن لا تضمن أي بيانات حيوية.
- تحقق من صحة الرمز من جانب الخادم باستخدام المفتاح العام للجهة المصدرة. ارفض أي رمز يفتقر إلى توقيع تصديق صالح.
- اختبر الحالات الاستثنائية (edge cases) مثل فشل المستشعر، والرفض الخاطئ، وتبديل الأجهزة. يجب أن تعود العملية إلى استخدام رمز PIN أو كلمة مرور دون الكشف عن البيانات الحيوية.
الخلاصة
عندما يظل التحقق الحيوي داخل الأجهزة الآمنة للهاتف ويقوم فقط بتوقيع رمز صالح للاستخدام لمرة واحدة، يحافظ المستخدمون على خصوصية بصمات أصابعهم أو بيانات وجوههم، ويقلل التجار من التعرض للمعلومات الشخصية الحساسة. بالنسبة للمطورين، القاعدة بسيطة: اجعل البيانات الحيوية تفتح المفتاح التشفيري، ولا تسمح لها أبداً بمغادرة الجهاز.