Überlegungen
Die folgenden Überlegungen müssen berücksichtigt werden, um die Integrität der geschützten Android-Bestätigung sicherzustellen. Wenn diese Überlegungen nicht zufriedenstellend berücksichtigt werden können, kann die geschützte Bestätigung nicht auf dem Gerät implementiert werden.
Überlegungen zum Linux-Kernel
Die geschützte Bestätigung ist so konzipiert, dass sie auch dann sicher funktioniert, wenn der Kernel des Geräts kompromittiert ist. Während das Dialogfeld „Geschützte Bestätigung“ aktiv ist, kann der Kernel die Integrität des Bildschirminhalts, die Integrität der Benutzereingaben und die Atomizität zwischen Benutzereingabe und -ausgabe nicht beeinträchtigen. Architektonisch muss verhindert werden, dass der Kernel die Entscheidung des Benutzers beeinflusst und Benutzerereignisse von vornherein fälscht. 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.
Überlegungen zur Firmware
Die geschützte Bestätigung kann nur dann auf einem Gerät implementiert werden, wenn alle beteiligten Komponenten über vertrauenswürdige Firmware verfügen. Die geschützte Bestätigung soll sicherstellen, dass der Benutzer die Möglichkeit hat, eine in der Trusted UI angezeigte Nachricht zu lesen, um eine fundierte Entscheidung zu treffen, ob er mit einer Transaktion fortfahren möchte oder nicht. Der Anzeigefeldtreiber ist besonders wichtig, da er den Benutzer daran hindern könnte, die vertrauenswürdige Benutzeroberfläche anzuzeigen.
Überlegungen zur Eingabe
Wählen Sie eine sichere Eingabemethode, um sicherzustellen, dass von dieser ausgewählten Eingabemethode generierte Eingabeereignisse nicht an das Dialogfeld „Geschützte Bestätigung“ übermittelt werden, es sei denn, der Benutzer generiert das Ereignis, während dieses Dialogfeld aktiv ist.
Physische Hardware
Jede Komponente, die vom Android-Kernel gesteuert werden kann, wie etwa das System-on-Chip (SoC) oder der Power Management Integrated Circuit (PMIC), darf nicht in der Lage sein, ein Kabel anzusteuern, das mit einer physischen Bestätigungstaste verbunden ist.
Überlegungen zum Touch-Controller
Bei der geschützten Bestätigung können Softwaretasten auf dem Bildschirm als Eingabe verwendet werden. Immer wenn der Touch-Controller vom TEE gesteuert wird, müssen Maßnahmen ergriffen werden, um den Zustand des Touch-Controllers zu bereinigen.
Erwartetes Verhalten
Unterbrechungen
Wenn das System die Bestätigungssitzung aufgrund eines eingehenden Telefonanrufs oder eines Stromereignisses unterbricht, muss der HAL ResponseCode::Aborted melden. Apps erhalten den onCanceled() -Rückruf und wissen, dass der Benutzer keine Aktion ausgewählt hat. Alarme müssen die Sitzung nicht abbrechen, sondern den Benutzer benachrichtigen. Benachrichtigungsüberlagerungen jeglicher Art sind nicht zulässig, solange das Dialogfeld aktiv ist.
Eingabefrist
Nachdem die geschützte Bestätigung initiiert wurde, muss die Eingabe mindestens 1 Sekunde lang inaktiv bleiben, bevor sie auf Benutzerinteraktion reagiert. Dieser Kulanzzeitraum stellt sicher, dass der Benutzer die Möglichkeit hat, auf einen unerwarteten Bestätigungsdialog zu reagieren. Diese Kulanzfrist muss von der vertrauenswürdigen App durchgesetzt werden.
Bildschirm Rotation
Das Hochformat ist der einzige vorgeschriebene Modus und die Bildschirmdrehung wird nicht unterstützt. Durch die Bildschirmrotation besteht die Möglichkeit eines Missbrauchs auf einem kompromittierten System, beispielsweise durch irreführende Schaltflächenplatzierung oder Manipulation des Textkörpers.
Fehler bei der Darstellung des Textkörpers
Es gibt eine feste Grenze von 6144 (0x1800) Bytes für den Textkörper, einschließlich zusätzlicher nicht angezeigter Daten und CBOR-Header-Informationen. Darüber hinaus gibt es eine weiche Grenze, die durchgesetzt werden muss. Wenn die gerenderte Nachricht nicht vollständig in den verfügbaren Bildschirmbereich passt, stellen Sie sicher, dass die geschützte Bestätigung abbricht und die Transaktion abgebrochen wird. Wenn MessageSize die maximal zulässige Größe überschreitet, muss Ihre Implementierung UIErrorMessageTooLong bei promptUserConfirmation zurückgeben.
Die beste Vorgehensweise besteht darin, den Textkörper nach Erhalt des API-Aufrufs zu formatieren. Der Fließtext muss dem Nutzer vollständig angezeigt werden.
Sekundäre Displays
Sekundäranzeigen werden unter bestimmten Bedingungen unterstützt. Die Integrität der Ausgabe und Benutzereingabe muss gewahrt bleiben und es dürfen keine irreführenden Informationen auf andere Weise angezeigt werden. Andernfalls wird der Dialog möglicherweise nur auf dem primären Display angezeigt und alle anderen Displays sollten deaktiviert oder leer sein. Streaming- und Screen-Sharing-Lösungen dürfen den Dialog nicht anzeigen oder Bestätigungen generieren.