تسجيل دخول بالبصمة لا يمكن تزييفه باعتراض الاستدعاء
تثق تطبيقات Android كثيرة باستدعاء نجاح المصادقة البيومترية الذي تستطيع أدوات الاعتراض تفعيله. تعرّف كيف يسدّ ربط البصمة بمفتاح عبر CryptoObject هذه الثغرة.
تسجيل الدخول بالبصمة من أكثر الميزات التي يحبها المستخدمون في التطبيقات المصرفية: نظرة أو لمسة بدلًا من رمز PIN. وهو أيضًا من أسهل الميزات التي يمكن تنفيذها بطريقة تبدو آمنة وهي ليست كذلك.
في تدقيق أمني لتطبيق Android تابع لبنك تجزئة، كانت المصادقة البيومترية من المجالات التي عزّزنا حمايتها. في هذا المقال نشرح نقطة الضعف الشائعة، وكيف يسدّها ربط المصادقة البيومترية بـCryptoObject، وما الذي لا يزال خارج نطاق هذا الحل.
نقطة الضعف الشائعة: الثقة بالاستدعاء
تُبلغ BiometricPrompt في Android عن نتيجة التحقق عبر استدعاء (callback). وأبسط تنفيذ يبدو منطقيًا على هذا النحو:
-
عرض نافذة المصادقة البيومترية.
-
انتظار onAuthenticationSucceeded.
-
فتح الجلسة.
المشكلة في الخطوة 3. فعلى جهاز مخترق، تستطيع أداة اعتراض مثل Frida استدعاء دالة النجاح مباشرةً. ولا يملك التطبيق أي وسيلة للتمييز بين تطابق بيومتري حقيقي واستدعاء مزيّف للدالة.
📌 فكرة أساسية:
الاستدعاء يقول «شيءٌ ما أبلغ عن النجاح». أما المفتاح التشفيري الذي لا يستطيع فتحه إلا النظام فيقول «جرى تحقق بيومتري حقيقي».
الحل: ربط المصادقة البيومترية بمفتاح
بدلًا من الثقة بالاستدعاء، يربط التطبيق تسجيل الدخول بعملية تشفيرية:
-
إنشاء مفتاح في Android Keystore يشترط مصادقة المستخدم قبل كل استخدام.
-
تغليف Cipher أو Signature يستخدم هذا المفتاح داخل CryptoObject وتمريره إلى BiometricPrompt.
-
بعد تطابق بيومتري حقيقي فقط يفتح النظام المفتاح لتلك العملية.
-
استخدام أداة التشفير بعد فتحها لفك تشفير سرّ الجلسة أو توقيع تحدٍّ (challenge) من الخادم. ولا يستمر تسجيل الدخول إلا إذا نجحت هذه العملية.
إذا زيّف المهاجم الاستدعاء، فإن أداة التشفير لم تُفتح أصلًا. فيفشل فك التشفير أو التوقيع، ويفشل معه تسجيل الدخول.
قرارات تصميمية مهمة
1. فك تشفير شيء حقيقي أو توقيعه
يجب أن يحمي CryptoObject شيئًا يعتمد عليه تسجيل الدخول فعلًا، مثل سرّ الجلسة أو توقيع يتحقق منه الخادم. أما استدعاء أداة التشفير على بيانات وهمية وتجاهل النتيجة فيعيد نقطة الضعف كما كانت.
2. تحديد ما يحدث عند تغيّر البيانات البيومترية
يمكن ضبط المفاتيح بحيث تصبح غير صالحة عند تسجيل بصمة إصبع أو وجه جديد. وهذا يوقف من يضيف بياناته البيومترية إلى هاتف غير مقفل. لكنه يعني أيضًا أن التطبيق يحتاج إلى مسار واضح لإعادة تفعيل المصادقة البيومترية عبر رمز PIN أو كلمة المرور.
3. الإبقاء على بديل احتياطي
المصادقة البيومترية تفشل أحيانًا: أصابع مبللة، وكمامات، وهواتف جديدة. والرجوع إلى رمز PIN أو كلمة المرور جزء من التصميم، ويجب أن يكون محميًا بالقدر نفسه الذي يُحمى به المسار البيومتري.
4. الجمع بينه وبين آليات حماية أخرى
الربط بـCryptoObject يسدّ ثغرة واحدة. أما كشف الروت والاعتراض، والتحقق من الجلسة على الخادم، وتحديد معدل المحاولات، فتسدّ ثغرات أخرى.
المصادقة البيومترية بالاستدعاء فقط مقابل المربوطة بـCryptoObject
| الجانب | الاستدعاء فقط | مربوطة بـCryptoObject |
| ما الذي يثبت النجاح | استدعاء دالة | مفتاح يفتحه النظام |
| استدعاء مزيّف بأداة اعتراض | ينجح تسجيل الدخول | يفشل تسجيل الدخول |
| جهد التنفيذ | منخفض | متوسط |
| التغيير في تجربة المستخدم | — | لا شيء بالنسبة إلى المستخدم |
كيف تساعدك Mobian
في Mobian، كانت المصادقة البيومترية المربوطة بـCryptoObject إحدى آليات الحماية ضمن خطة معالجة من 124 مهمة لتطبيق Android تابع لبنك تجزئة، إلى جانب الحماية من التراكب (overlay)، وكشف الاعتراض والمحاكيات، وفحوص منع إعادة التغليف (repackaging). وجرى التحقق من كل آلية حماية عبر حزمة اختبارات أمنية مستقلة لضمان الجودة، لا من قِبل المطوّر الذي بناها فقط.
الخلاصة
تسجيل الدخول بالبصمة الذي يثق بالاستدعاء لا يتجاوز في قوته قوة الجهاز الذي يعمل عليه. أما ربط تسجيل الدخول بمفتاح في Keystore لا يفتحه النظام إلا بعد تطابق حقيقي، فيعني أن الاستدعاء المزيّف لا يمنح المهاجم شيئًا. تبقى تجربة المستخدم كما هي، ولا يظهر الفرق إلا حين يحاول أحدهم الغش.
الأسئلة الشائعة
ما المشكلة في الاكتفاء بالتحقق من استدعاء نجاح المصادقة البيومترية؟
إذا فتح التطبيق الجلسة بمجرد استدعاء onAuthenticationSucceeded، فإن المهاجم الذي يملك أداة اعتراض (hooking) مثل Frida على جهاز مخترق يستطيع استدعاء هذه الدالة مباشرةً. فيرى التطبيق نجاحًا دون أن يجري التحقق من أي بصمة إصبع أو وجه على الإطلاق.
ما هو CryptoObject في المصادقة البيومترية على Android؟
يغلّف CryptoObject عملية تشفيرية، مثل Cipher أو Signature، تستخدم مفتاحًا من Android Keystore. وحين يُنشأ هذا المفتاح بحيث يشترط مصادقة المستخدم، لا تعمل العملية إلا بعد تحقق بيومتري حقيقي يجريه النظام. أما الاستدعاء المزيّف فلا يمنح المهاجم إلا أداة تشفير (cipher) لا يمكن استخدامها.
هل تحمي المصادقة البيومترية المربوطة بـCryptoObject من كل الهجمات؟
لا. فهي تسدّ ثغرة الاستدعاء المزيّف، لكن ينبغي دمجها مع آليات حماية أخرى، مثل كشف الروت (root) والاعتراض، والتحقق من الجلسة على الخادم، والرجوع إلى رمز PIN أو كلمة المرور. لا توجد آلية حماية واحدة تجعل التطبيق آمنًا بمفردها.
ماذا يحدث حين يسجّل المستخدم بصمة إصبع جديدة؟
يمكن ضبط المفاتيح بحيث تصبح غير صالحة عند تسجيل بيانات بيومترية جديدة. وهذا يمنع من يضيف بصمته إلى هاتف غير مقفل من استخدامها لتسجيل الدخول، لكن التطبيق يحتاج حينها إلى مسار واضح لإعادة التفعيل، يكون عادةً عبر رمز PIN أو كلمة المرور.
ما فئة OWASP التي يعالجها هذا الحل؟
أساسًا M3: Insecure Authentication/Authorization في OWASP Mobile Top 10 (2024). كما يدعم ربط المفتاح بالمصادقة البيومترية الممارسات الجيدة في M10، أي Insufficient Cryptography.