تنفيذ التأكيد المحمي

اعتبارات

يجب معالجة الاعتبارات التالية لضمان سلامة التأكيد المحمي لنظام Android. إذا لم يكن من الممكن معالجة هذه الاعتبارات بشكل مرض، فلا يمكن تنفيذ التأكيد المحمي على الجهاز.

اعتبارات نواة لينكس

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

اعتبارات البرامج الثابتة

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

اعتبارات الإدخال

اختر طريقة إدخال آمنة للتأكد من أن أحداث الإدخال التي تم إنشاؤها بواسطة طريقة الإدخال المختارة هذه لا يتم نقلها إلى مربع حوار التأكيد المحمي إلا إذا قام المستخدم بإنشاء الحدث عندما يكون مربع الحوار هذا نشطًا.

الأجهزة المادية

يجب ألا يكون أي مكون يمكن التحكم فيه بواسطة نواة Android، مثل النظام الموجود على الشريحة (SoC) أو الدائرة المتكاملة لإدارة الطاقة (PMIC)، قادرًا على تشغيل سلك متصل بزر تأكيد فعلي.

اعتبارات تحكم اللمس

يمكن للتأكيد المحمي استخدام أزرار البرامج التي تظهر على الشاشة كمدخل. في أي وقت يتم فيه تشغيل وحدة التحكم باللمس بواسطة TEE، يجب اتخاذ التدابير اللازمة لتطهير حالة وحدة التحكم باللمس.

سلوك متوقع

انقطاعات

إذا قام النظام بمقاطعة جلسة التأكيد بسبب مكالمة هاتفية واردة أو حدث طاقة، فيجب على HAL الإبلاغ عن ResponseCode::Aborted . تحصل التطبيقات على رد الاتصال onCanceled() وتعرف أن المستخدم لم يختر إجراءً ما. لا تحتاج الإنذارات إلى إلغاء الجلسة ولكنها تحتاج إلى إخطار المستخدم. لا يُسمح بتراكبات الإشعارات من أي نوع عندما يكون مربع الحوار نشطًا.

فترة سماح الإدخال

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

دوران الشاشة

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

فشل عرض النص الأساسي

يوجد حد صارم يبلغ 6144 (0x1800) بايت للنص الأساسي بما في ذلك البيانات الإضافية غير المعروضة ومعلومات رأس CBOR. بالإضافة إلى ذلك، هناك حدود ناعمة يجب فرضها. إذا لم تتناسب الرسالة المقدمة تمامًا مع مساحة الشاشة المتاحة، فتأكد من إحباط التأكيد المحمي وإلغاء المعاملة. إذا تجاوز MessageSize الحد الأقصى المسموح به، فيجب أن يُرجع التنفيذ الخاص بك UIErrorMessageTooLong على promptUserConfirmation .

أفضل الممارسات هي تنسيق النص الأساسي بعد تلقي استدعاء API. يجب أن يظهر النص الأساسي للمستخدم بالكامل.

شاشات العرض الثانوية

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