الاعتبارات
يجب مراعاة النقاط التالية لضمان سلامة Android Protected Confirmation. إذا تعذّر التعامل مع هذه الاعتبارات بشكلٍ مُرضٍ، لا يمكن تنفيذ ميزة "التأكيد المحمي" على الجهاز.
اعتبارات حول نواة Linux
تم تصميم ميزة "التأكيد المحمي" للعمل بأمان حتى في حال اختراق ملف التمهيد الجهاز. عندما يكون مربّع حوار التأكيد المحمي نشطًا، لا يمكن لنظام التشغيل التأثير في سلامة محتوى الشاشة وسلامة إدخال المستخدم ووحدة المعالجة بين إدخال المستخدم وإخراجه. من الناحية المعمارية، يجب منع النواة من تعزيز قرار المستخدم ومن انتحال أحداث المستخدم في المقام الأول. لا يُعتبَر ملفّ kernel موثوقًا في حالة الاستخدام هذه، لأنّه قد يكون تحت سيطرة أحدهم المهاجمين أو قد يتم استبداله بشيء مختلف تمامًا.
اعتبارات البرامج الثابتة
لا يمكن تنفيذ ميزة "التأكيد المحمي" على جهاز إلا إذا كانت جميع المكوّنات المعنيّة تتضمّن برنامجًا ثابتًا موثوقًا به. تم تصميم ميزة "التأكيد المحمي" لضمان حصول المستخدم على فرصة لقراءة رسالة معروضة في واجهة المستخدم الموثوق بها من أجل اتخاذ قرار مدروس بشأن مواصلة المعاملة أو إيقافها. ينطبق ذلك بشكل خاص على برنامج تشغيل لوحة العرض، لأنّه قد يمنع المستخدم من الاطّلاع على واجهة المستخدم الموثوق بها.
اعتبارات متعلقة بالإدخال
اختَر طريقة إدخال آمنة لضمان عدم نقل أحداث الإدخال التي تم إنشاؤها باستخدام طريقة الإدخال هذه إلى مربّع الحوار "التأكيد المحمي" ما لم يكن المستخدم هو من ينشئ الحدث عندما يكون مربّع الحوار هذا نشطًا.
الأجهزة المادية
يجب ألا يكون أي مكوّن يمكن التحكّم فيه من خلال نواة Android، مثل نظام على الرقاقة (SoC) أو الدائرة المتكاملة لإدارة الطاقة (PMIC)، قادرًا على تشغيل سلك متصل بزر تأكيد فعلي.
اعتبارات حول وحدة التحكّم باللمس
يمكن أن يستخدم Protected Confirmation أزرار البرامج على الشاشة كمدخلات. في أي وقت يتم فيه تشغيل وحدة التحكّم باللمس من خلال TEE، يجب اتّخاذ تدابير لتنظيف حالة وحدة التحكّم باللمس.
السلوك المتوقع
المقاطعات
إذا قاطع النظام جلسة التأكيد بسبب مكالمة هاتفية واردة أو حدث طاقة، يجب أن يُبلغ HAL عن
ResponseCode::Aborted. تتلقّى التطبيقات طلب onCanceled()
الاستدعاء وتدرك أنّ المستخدم لم يختَر إجراءً. لا تحتاج المنبّهات إلى إلغاء
الجلسة، ولكن يجب إرسال إشعار إلى المستخدم. لا يُسمح بعرض أي نوع من الإشعارات المتراكبة
عندما يكون مربّع الحوار نشطًا.
فترة السماح لإدخال البيانات
بعد بدء ميزة "التأكيد المحمي"، يجب أن تظلّ البيانات التي تم إدخالها غير نشطة لمدة ثانية واحدة على الأقل قبل أن تصبح متجاوبة مع تفاعل المستخدم. تضمن هذه الفترة الزمنية للسماح بالتراجع أن يحصل المستخدم على فرصة للردّ على مربّع حوار تأكيد غير متوقّع. يجب أن يفرض التطبيق الموثوق هذه الفترة الزمنية للسماح بالوصول.
تدوير الشاشة
الوضع العمودي هو الوضع الوحيد المطلوب، ولا يمكن تدوير الشاشة. تسمح ميزة "تعامُل الشاشة" بإمكانية إساءة الاستخدام على نظام مُخترَق، مثل موضع الزر المضلِّل أو التلاعب بالنص الأساسي.
حالات تعذُّر عرض النص الأساسي
هناك حدّ
أقصى يبلغ 6144 (0x1800) بايت لنص النصّ الأساسي، بما في ذلك data
الإضافية غير المعروضة ومعلومات رأس CBOR.
بالإضافة إلى ذلك، هناك حدود غير صارمة يجب فرضها. إذا كانت الرسالة المعروضة
لا تلائم مساحة الشاشة المتوفّرة بالكامل،
تأكّد من إيقاف ميزة "التأكيد المحمي" وإلغاء المعاملة.
إذا تجاوز MessageSize الحد الأقصى المسموح به، يجب أن يعرض
عملية التنفيذ UIErrorMessageTooLong في
promptUserConfirmation.
من أفضل الممارسات تنسيق نص النصّ بعد تلقّي طلب البيانات من واجهة برمجة التطبيقات. يجب عرض نص النصّ الكامل للمستخدم.
الشاشات الثانوية
تتوفّر الشاشات الثانوية بموجب شروط معيّنة. يجب الحفاظ على سلامة النتائج ومعلومات المستخدمين، ولا يمكن عرض أي معلومات مضلّلة من خلال وسائل أخرى. بخلاف ذلك، قد يتم عرض مربّع الحوار فقط على الشاشة الأساسية ويجب إيقاف جميع الشاشات الأخرى أو جعلها فارغة. لا يُسمح لحلّات البث ومشاركة الشاشة بعرض مربّع الحوار أو توليد رسائل تأكيد.