Considérations
Les considérations suivantes doivent être prises en compte pour garantir l’intégrité de la confirmation protégée Android. Si ces considérations ne peuvent pas être prises en compte de manière satisfaisante, la confirmation protégée ne peut pas être implémentée sur l’appareil.
Considérations sur le noyau Linux
La confirmation protégée est conçue pour fonctionner en toute sécurité même si le noyau de l'appareil est compromis. Lorsque la boîte de dialogue de confirmation protégée 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, il faut empêcher le noyau d'augmenter la décision de l'utilisateur et d'usurper les événements de l'utilisateur. Le noyau n'est pas considéré comme fiable pour ce cas d'utilisation, car il pourrait être sous le contrôle d'un attaquant ou remplacé par quelque chose de complètement différent.
Considérations sur le micrologiciel
La confirmation protégée ne peut être implémentée sur un appareil que si tous les composants impliqués disposent d'un micrologiciel fiable. La confirmation protégée est conçue pour garantir que l'utilisateur a la possibilité de lire un message affiché dans l'interface utilisateur de confiance pour prendre une décision éclairée de poursuivre ou non une transaction. Le pilote du panneau d’affichage est particulièrement important car il pourrait empêcher l’utilisateur de visualiser l’interface utilisateur approuvée.
Considérations relatives à la saisie
Choisissez une méthode de saisie sécurisée pour garantir que les événements d'entrée 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, à moins que l'utilisateur ne génère l'événement pendant que 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.
Considérations sur le contrôleur tactile
La confirmation protégée peut utiliser les boutons du logiciel à l’écran comme entrée. Chaque fois que le contrôleur tactile est piloté par le TEE, des mesures doivent être prises pour nettoyer l'état du contrôleur tactile.
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, le 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'abandonner la session, mais doivent en informer 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.
Délai de grâce de saisie
Une fois la confirmation protégée lancée, l'entrée doit rester inactive pendant au moins 1 seconde avant de devenir réactive à l'interaction de l'utilisateur. Ce délai de grâce garantit que l'utilisateur a la possibilité 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 portrait est le seul mode obligatoire et la rotation de l'écran n'est pas prise en charge. La rotation de l'écran permet un risque d'abus sur un système compromis, comme un placement trompeur de boutons ou une manipulation du corps du texte.
Échecs de rendu du corps du texte
Il existe une limite stricte de 6 144 (0x1 800) octets 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, il existe une limite souple qui doit être appliquée. Si le message affiché ne tient pas complètement dans l'espace d'écran disponible, assurez-vous que la confirmation protégée est abandonnée et que la transaction est annulée. Si MessageSize dépasse la taille maximale autorisée, votre implémentation doit renvoyer UIErrorMessageTooLong sur promptUserConfirmation .
La meilleure pratique consiste à formater le corps du texte après avoir reçu l’appel API. Le corps du texte doit être présenté à l'utilisateur dans son intégralité.
Écrans secondaires
Les affichages secondaires sont pris en charge sous certaines conditions. L'intégrité des résultats et des entrées utilisateur doit être maintenue, et aucune information trompeuse ne peut être affichée par d'autres moyens. Sinon, la boîte de dialogue ne peut être affichée 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 ou à générer des confirmations.