Rozważania
Aby zapewnić integralność potwierdzenia chronionego systemem Android, należy wziąć pod uwagę następujące kwestie. Jeśli nie można w zadowalający sposób rozwiązać tych kwestii, na urządzeniu nie można zaimplementować chronionego potwierdzenia.
Uwagi dotyczące jądra Linuksa
Chronione potwierdzenie zostało zaprojektowane tak, aby działać bezpiecznie nawet w przypadku naruszenia jądra urządzenia. Gdy okno dialogowe Chronione potwierdzenie jest aktywne, jądro nie może zakłócać integralności zawartości ekranu, integralności danych wejściowych użytkownika ani niepodzielności między danymi wejściowymi i wyjściowymi użytkownika. Architektonicznie należy przede wszystkim uniemożliwić jądru wpływanie na decyzję użytkownika i fałszowanie zdarzeń użytkownika. Jądro nie jest uważane za godne zaufania w tym przypadku użycia, ponieważ może znaleźć się pod kontrolą osoby atakującej lub zostać zastąpione czymś zupełnie innym.
Uwagi dotyczące oprogramowania sprzętowego
Chronione potwierdzenie można wdrożyć na urządzeniu tylko wtedy, gdy wszystkie zaangażowane komponenty mają zaufane oprogramowanie sprzętowe. Chronione potwierdzenie ma na celu zapewnienie użytkownikowi możliwości przeczytania komunikatu wyświetlanego w Zaufanym interfejsie użytkownika w celu podjęcia świadomej decyzji o kontynuacji transakcji. Sterownik panelu wyświetlacza jest szczególnie ważny, ponieważ może uniemożliwić użytkownikowi przeglądanie Zaufanego interfejsu użytkownika.
Uwagi wejściowe
Wybierz bezpieczną metodę wprowadzania, aby mieć pewność, że zdarzenia wejściowe generowane przez wybraną metodę wprowadzania nie zostaną przesłane do okna dialogowego Potwierdzenie chronione, chyba że użytkownik wygeneruje zdarzenie, gdy to okno dialogowe jest aktywne.
Sprzęt fizyczny
Żaden komponent, który może być kontrolowany przez jądro Androida, taki jak system na chipie (SoC) lub układ scalony zarządzania energią (PMIC), nie może sterować przewodem podłączonym do fizycznego przycisku potwierdzenia.
Uwagi dotyczące kontrolera dotykowego
W przypadku potwierdzenia chronionego można używać przycisków oprogramowania wyświetlanych na ekranie jako danych wejściowych. Za każdym razem, gdy kontroler dotykowy jest sterowany przez TEE, należy podjąć środki w celu oczyszczenia stanu kontrolera dotykowego.
Spodziewane zachowanie
Przerwy
Jeśli system przerwie sesję potwierdzającą z powodu przychodzącego połączenia telefonicznego lub zdarzenia dotyczącego zasilania, warstwa HAL musi zgłosić ResponseCode::Aborted . Aplikacje otrzymują wywołanie zwrotne onCanceled() i wiedzą, że użytkownik nie wybrał akcji. Alarmy nie muszą przerywać sesji, ale muszą powiadamiać użytkownika. Żadne nakładki powiadomień nie są dozwolone, gdy okno dialogowe jest aktywne.
Wprowadź okres karencji
Po zainicjowaniu Potwierdzenia Chronionego dane wejściowe muszą pozostać nieaktywne przez co najmniej 1 sekundę, zanim zaczną reagować na interakcję użytkownika. Ten okres karencji zapewnia użytkownikowi szansę zareagowania na nieoczekiwane okno dialogowe z potwierdzeniem. Ten okres karencji musi być egzekwowany przez zaufaną aplikację.
Obrót ekranu
Portret jest jedynym wymaganym trybem i obracanie ekranu nie jest obsługiwane. Obrót ekranu stwarza ryzyko nadużyć w zaatakowanym systemie, takich jak wprowadzające w błąd rozmieszczenie przycisków lub manipulacja tekstem głównym.
Błędy renderowania tekstu podstawowego
Istnieje sztywna granica 6144 (0x1800) bajtów dla tekstu podstawowego, w tym dodatkowych niewyświetlanych danych i informacji nagłówka CBOR. Ponadto istnieje miękka granica, którą należy egzekwować. Jeśli wyrenderowana wiadomość nie mieści się całkowicie na dostępnym miejscu ekranu, upewnij się, że potwierdzenie chronione zostanie przerwane, a transakcja zostanie anulowana. Jeśli MessageSize przekracza maksymalny dopuszczalny rozmiar, implementacja musi zwrócić UIErrorMessageTooLong w promptUserConfirmation .
Najlepszą praktyką jest formatowanie tekstu podstawowego po odebraniu wywołania API. Treść treści musi być pokazana użytkownikowi w całości.
Wyświetlacze wtórne
Wyświetlacze dodatkowe są obsługiwane pod pewnymi warunkami. Należy zachować integralność danych wyjściowych i danych wejściowych użytkownika, a żadne informacje wprowadzające w błąd nie mogą być wyświetlane w inny sposób. W przeciwnym razie okno dialogowe może być wyświetlane tylko na wyświetlaczu głównym, a wszystkie pozostałe ekrany powinny być wyłączone lub puste. Rozwiązania do przesyłania strumieniowego i udostępniania ekranu nie mogą wyświetlać okien dialogowych ani generować potwierdzeń.