Wissenswertes
Die folgenden Punkte müssen berücksichtigt werden, um die Integrität der Bestätigung durch den geschützten Android-Zugriff zu gewährleisten. Wenn diese Punkte nicht zufriedenstellend geklärt werden können, kann die geschützte Bestätigung auf dem Gerät nicht implementiert werden.
Hinweise zum Linux-Kernel
Der geschützte Bestätigungsmechanismus funktioniert auch dann sicher, wenn der Kernel des Geräts manipuliert wurde. Solange das Dialogfeld „Geschützte Bestätigung“ aktiv ist, kann der Kernel die Integrität des Bildschirminhalts, die Integrität der Nutzereingabe und die Atomarität zwischen Nutzereingabe und ‑ausgabe nicht beeinträchtigen. Architektonisch muss verhindert werden, dass der Kernel die Entscheidung des Nutzers beeinflusst und Nutzerereignisse manipuliert. Der Kernel gilt für diesen Anwendungsfall nicht als vertrauenswürdig, da er unter der Kontrolle eines Angreifers stehen oder durch etwas völlig anderes ersetzt werden könnte.
Hinweise zur Firmware
Die geschützte Bestätigung kann auf einem Gerät nur implementiert werden, wenn alle beteiligten Komponenten vertrauenswürdige Firmware haben. Die geschützte Bestätigung soll dafür sorgen, dass der Nutzer die Möglichkeit hat, eine in der vertrauenswürdigen Benutzeroberfläche angezeigte Nachricht zu lesen, um eine fundierte Entscheidung darüber zu treffen, ob er mit einer Transaktion fortfahren möchte oder nicht. Der Treiber für das Displaypanel ist besonders wichtig, da er verhindern kann, dass der Nutzer die vertrauenswürdige Benutzeroberfläche sehen kann.
Hinweise zur Eingabe
Wählen Sie eine sichere Eingabemethode aus, damit Eingabeereignisse, die mit dieser Methode generiert werden, nur dann an das Dialogfeld „Geschützte Bestätigung“ gesendet werden, wenn der Nutzer das Ereignis generiert, während dieses Dialogfeld aktiv ist.
Physische Hardware
Keine Komponente, die vom Android-Kernel gesteuert werden kann, z. B. das System-on-Chip (SoC) oder der integrierte Schaltkreis für die Energieverwaltung (Power Management Integrated Circuit, PMIC), darf einen Draht steuern, der mit einer physischen Bestätigungsschaltfläche verbunden ist.
Hinweise zum Touch-Controller
Für die geschützte Bestätigung können Softwareschaltflächen auf dem Bildschirm als Eingabe verwendet werden. Jedes Mal, wenn der Touch-Controller von der TEE gesteuert wird, müssen Maßnahmen ergriffen werden, um den Status des Touch-Controllers zu säubern.
Erwartetes Verhalten
Unterbrechungen
Wenn das System die Bestätigungssitzung aufgrund eines eingehenden Anrufs oder eines Stromereignisses unterbricht, muss die HAL ResponseCode::Aborted melden. Apps erhalten den onCanceled()-Callback und wissen, dass der Nutzer keine Aktion ausgewählt hat. Wecker müssen die Sitzung nicht beenden, aber den Nutzer benachrichtigen. Benachrichtigungs-Overlays jeglicher Art sind nicht zulässig, während das Dialogfeld aktiv ist.
Kulanzzeitraum für die Eingabe
Nachdem die geschützte Bestätigung gestartet wurde, muss die Eingabe mindestens eine Sekunde lang inaktiv bleiben, bevor sie auf Nutzerinteraktionen reagiert. Diese Kulanzzeit gibt dem Nutzer die Möglichkeit, auf ein unerwartetes Bestätigungsdialogfeld zu reagieren. Diese Kulanzzeitraum muss von der vertrauenswürdigen App erzwungen werden.
Bildschirmdrehung
Der Hochformatmodus ist der einzige zulässige Modus und die Bildschirmdrehung wird nicht unterstützt. Die Bildschirmdrehung kann bei einem manipulierten System zu Missbrauch führen, z. B. durch irreführende Platzierung von Schaltflächen oder Manipulation des Fließtexts.
Fehler beim Rendern des Textkörpers
Für den Textkörper gilt eine feste Grenze von 6.144 Byte (0x1800), einschließlich zusätzlicher nicht angezeigter Daten und CBOR-Headerinformationen.
Außerdem muss eine weiche Grenze durchgesetzt werden. Wenn die dargestellte Nachricht nicht vollständig in den verfügbaren Bildschirmbereich passt, muss die geschützte Bestätigung abgebrochen und die Transaktion storniert werden.
Wenn MessageSize die maximal zulässige Größe überschreitet, muss Ihre Implementierung UIErrorMessageTooLong für promptUserConfirmation zurückgeben.
Es wird empfohlen, den Textkörper nach Erhalt des API-Aufrufs zu formatieren. Der Textkörper muss dem Nutzer vollständig angezeigt werden.
Sekundäre Displays
Sekundäre Displays werden unter bestimmten Bedingungen unterstützt. Die Integrität der Ausgabe und der Nutzereingaben muss gewahrt bleiben und es dürfen keine irreführenden Informationen auf andere Weise angezeigt werden. Andernfalls wird das Dialogfeld möglicherweise nur auf dem primären Display angezeigt und alle anderen Displays sollten deaktiviert oder leer sein. Streaming- und Bildschirmfreigabelösungen dürfen das Dialogfeld nicht anzeigen oder Bestätigungen generieren.