Points à prendre en compte
Les considérations suivantes doivent être prises en compte pour garantir l'intégrité de Confirmation de protection Android. Si ces considérations ne peuvent pas être traitées de manière satisfaisante, la confirmation protégée ne peut pas être implémentée sur l'appareil.
Points à prendre en compte concernant le noyau Linux
La confirmation protégée est conçue pour fonctionner de manière sécurisée, même si le noyau de l'appareil est compromis. Lorsque la boîte de dialogue de confirmation de la protection est active, le noyau ne peut pas interférer avec l'intégrité du contenu de l'écran, l'intégrité de l'entrée de l'utilisateur et l'atomicité entre l'entrée et la sortie de l'utilisateur. D'un point de vue architectural, le noyau doit être empêché d'influencer la décision de l'utilisateur et de falsifier les événements utilisateur. Le kernel n'est pas considéré comme fiable pour ce cas d'utilisation, car il pourrait être sous le contrôle d'un pirate informatique ou remplacé par quelque chose de complètement différent.
Considérations concernant le micrologiciel
La confirmation protégée ne peut être implémentée sur un appareil que si tous les composants concernés disposent d'un micrologiciel approuvé. La confirmation protégée est conçue pour s'assurer que l'utilisateur a la possibilité de lire un message affiché dans l'UI sécurisée afin de prendre une décision éclairée sur la poursuite ou non d'une transaction. Le pilote du panneau d'affichage est particulièrement important, car il peut empêcher l'utilisateur d'afficher l'UI sécurisée.
Considérations concernant les entrées
Choisissez une méthode de saisie sécurisée pour vous assurer que les événements de saisie générés par cette méthode de saisie choisie ne sont pas transmis à la boîte de dialogue de confirmation protégée, sauf si l'utilisateur génère l'événement lorsque cette boîte de dialogue est active.
Matériel physique
Tout composant pouvant être contrôlé par le noyau Android, tel que le système sur puce (SoC) ou le circuit intégré de gestion de l'alimentation (PMIC), ne doit pas pouvoir piloter un fil connecté à un bouton de confirmation physique.
Remarques concernant les contrôleurs tactiles
La confirmation de protection peut utiliser des boutons logiciels à l'écran comme entrée. Chaque fois que le contrôleur tactile est piloté par le TEE, des mesures doivent être prises pour nettoyer son état.
Comportement attendu
Interruptions
Si le système interrompt la session de confirmation en raison d'un appel téléphonique entrant ou d'un événement d'alimentation, la HAL doit signaler ResponseCode::Aborted. Les applications reçoivent le rappel onCanceled() et savent que l'utilisateur n'a pas choisi d'action. Les alarmes n'ont pas besoin d'arrêter la session, mais elles doivent envoyer une notification à l'utilisateur. Les superpositions de notifications de quelque nature que ce soit ne sont pas autorisées lorsque la boîte de dialogue est active.
Saisissez le délai de grâce
Une fois la confirmation protégée lancée, la saisie doit rester inactive pendant au moins une seconde avant de répondre aux interactions de l'utilisateur. Ce délai de grâce permet à l'utilisateur de réagir à une boîte de dialogue de confirmation inattendue. Ce délai de grâce doit être appliqué par l'application de confiance.
Rotation de l'écran
Le mode portrait est le seul mode obligatoire, et la rotation de l'écran n'est pas prise en charge. La rotation de l'écran peut être utilisée de manière abusive sur un système compromis, par exemple en plaçant des boutons trompeurs ou en manipulant le corps du texte.
Échecs d'affichage du corps du texte
Il existe une limite fixe de 6 144 octets (0x1800) pour le corps du texte, y compris les données supplémentaires non affichées et les informations d'en-tête CBOR.
De plus, une limite souple doit être appliquée. Si le message affiché ne tient pas entièrement dans l'espace d'écran disponible, assurez-vous que la confirmation protégée est interrompue et que la transaction est annulée.
Si MessageSize dépasse la taille maximale autorisée, votre implémentation doit renvoyer UIErrorMessageTooLong sur promptUserConfirmation.
Il est recommandé de mettre en forme le corps du texte après avoir reçu l'appel d'API. Le corps du texte doit être affiché dans son intégralité à l'utilisateur.
Écrans secondaires
Les écrans secondaires sont acceptés sous certaines conditions. L'intégrité de la sortie et de la saisie utilisateur doit être préservée, et aucune information trompeuse ne peut être affichée par d'autres moyens. Sinon, la boîte de dialogue ne peut s'afficher que sur l'écran principal, et tous les autres écrans doivent être désactivés ou vides. Les solutions de streaming et de partage d'écran ne sont pas autorisées à afficher la boîte de dialogue ni à générer de confirmations.