Historia pytania
Autoryzacja biometryczna przeszła od nowinki do głównego mechanizmu bezpieczeństwa po wydaniu TouchID w iPhone 5s w 2013 roku. Ręczne QA ewoluowało od prostego weryfikowania odblokowania do złożonej walidacji modułów zabezpieczeń sprzętowych, ponieważ aplikacje finansowe i zdrowotne wymagały zgodności z HIPAA i PCI-DSS na platformach mobilnych. To pytanie powstało w szczególności, aby zająć się fragmentacją między implementacjami iOS Secure Enclave a Android Keystore, szczególnie po wprowadzeniu w Android 10 interfejsów API BiometricPrompt z różnymi zachowaniami w zakresie unieważniania kluczy w porównaniu do kontroli dostępu do kluczy iOS.
Problem
Hardware’owe czujniki biometryczne wykazują nieokreślone tryby awarii, w tym throttling termiczny, zakłócenia wilgotności i zakłócenia elektromagnetyczne, które są unikalne dla czujników ultradźwiękowych w porównaniu do optycznych. Warstwy abstrakcji React Native często nieprawidłowo obsługują asynchroniczne wywołania między mostem JavaScript a natywnymi modułami podczas szybkiego w tle, powodując unieważnienie LAContext lub niezgodności CryptoObject. Testowanie wymaga symulacji awarii sprzętu czujników, unieważnień uprawnień oraz zmian rejestracji na poziomie OS bez wywoływania trwałych zablokowań biometrycznych, które zablokowałyby urządzenia testowe na godziny lub wymagałyby resetu fabrycznego.
Rozwiązanie
Wdrażaj matrycę testową przejść stanów obejmującą sukces biometryczny, czasowe niepowodzenie z powtórzeniem, eskalację trwałego zablokowania i bezproblemowe przejście do wprowadzenia PIN. Weryfikuj poziomy dostępności klucza kryptograficznego (WhenUnlockedThisDeviceOnly w porównaniu do AfterFirstUnlock) w odniesieniu do zmian stanu biometrycznego przy użyciu fizycznych urządzeń reprezentujących krytyczne segmenty sprzętowe. Używaj specyficznych dla platformy narzędzi do wstrzykiwania wyników biometrycznych w trybie imitacji, jednocześnie weryfikując rzeczywiste operacje związane z kluczami sprzętowymi na Secure Enclave i Keystore, aby upewnić się, że wynik autoryzacji kryptograficznie dowodzi posiadania ważnych danych biometrycznych, a nie tylko odbioru wywołania zwrotnego w postaci boolean.
Startup fintechowy opracował aplikację React Native, pozwalającą na wysokowartościowe przelewy, autoryzowane za pomocą FaceID, TouchID lub czujników linii papilarnych Android. Podczas testów beta pojawiły się krytyczne awarie: urządzenia Samsung Galaxy S21 wykrzaczały się z IllegalStateException, gdy użytkownicy szybko anulowali i ponownie próbowali wywołać monity biometryczne, a jednostki iPhone 12 zamrażały się, gdy aplikacja była w tle podczas wyświetlania monitów FaceID, a urządzenia Google Pixel pokazywały nieskończone kręgi ładowania, gdy użytkownicy usunęli wszystkie odciski palców z ustawień systemowych, a aplikacja była zminimalizowana.
Rozwiązanie 1: Ręczne testowanie na czystych fizycznych urządzeniach
Podejście to polegało wyłącznie na testowaniu każdego przepływu użytkowników na fizycznym sprzęcie pokrywającym dwadzieścia najlepszych urządzeń pod względem udziału w rynku. Metodologia obejmowała ręczne rejestrowanie i usuwanie biometrii, symulację zanieczyszczonych czujników za pomocą barier fizycznych oraz celowe uruchamianie zablokowań poprzez wielokrotne nieudane próby. Plusy obejmowały rejestrowanie problemów z czasem w rzeczywistym świecie, dostosowania UX specyficzne dla producentów, takie jak Samsung Pass, oraz rzeczywiste zachowanie modułów zabezpieczeń sprzętowych. Minusy obejmowały prohibicyjne koszty utrzymywania aktualnego laboratorium urządzeń, niemożność reprodukcji warunków wyścigu w sposób deterministyczny oraz ryzyko trwałego zablokowania urządzeń testowych podczas negatywnych przypadków testowych, co sprawiało, że stawały się one nieużyteczne przez godziny.
Rozwiązanie 2: Testowanie oparte na emulacji z fałszywymi danymi biometrycznymi
Strategia ta wykorzystała Android Emulator z fałszywymi czujnikami linii papilarnych oraz iOS Simulator z symulacją rejestracji biometrycznej XCUITest, aby zautomatyzować szybkie cykle stanów. Podejście to pozwoliło testować zmiany uprawnień i zdarzenia tła poprzez zautomatyzowaną skryptową. Plusy obejmowały efektywność kosztową, możliwość natychmiastowego resetowania stanów biometrycznych i szybkie cykle regresji. Minusy obejmowały całkowity brak walidacji modułu zabezpieczeń sprzętowych (zachowania Secure Enclave i Keystore znacznie różnią się na emulatorach), niemożność wychwycenia specyficznych dla czujnika problemów z czasem, takich jak opóźnienia rozpoznawania ultradźwiękowego w porównaniu do optycznego, oraz fałszywie pozytywne wyniki dotyczące obsługi CryptoObject, ponieważ emulatory nie egzekwują powiązania kryptograficznego.
Rozwiązanie 3: Hybrydowe instrumentowanie z ukierunkowaną walidacją fizyczną
Metodologia ta łączyła testy end-to-end Detox na symulatorach do weryfikacji logiki biznesowej z ukierunkowanym ręcznym testowaniem na krytycznych segmentach sprzętowych reprezentujących iOS FaceID, iOS TouchID, standardowy Android (Pixel) oraz mocno dostosowany Android (Samsung, Xiaomi). Debugowanie modułów natywnych wykorzystywało narzędzia instrumentacyjne Android Studio i Xcode do wstrzykiwania konkretnych kodów błędów do wywołań BiometricPrompt i LAContext. Plusy obejmowały wszechstronne pokrycie zarówno przepływów logiki, jak i dziwactw sprzętowych bez potrzeby posiadania ogromnej farmy urządzeń, możliwość symulowania przypadków brzegowych poprzez imitację, przy jednoczesnym weryfikowaniu operacji kryptograficznych na rzeczywistym sprzęcie. Minusy obejmowały złożone wymagania konfiguracyjne łączące kod mostu React Native z narzędziami debugującymi zewnętrznie oraz wyższe początkowe koszty infrastruktury dla usług farmy urządzeń.
Zespół wybrał Rozwiązanie 3, ponieważ awaria Samsung wymagała debugowania natywnych stanów cyklu życia Fragment, które niemożliwe było do powtórzenia na emulatorach, podczas gdy problem z tłem iPhone wymagał rzeczywistych interakcji z czasem Secure Enclave. Zaimplementowali integrację z Firebase Test Lab dla zautomatyzowanych testów dymnych na dwudziestu konfiguracjach urządzeń, uzupełnionych codziennymi sesjami ręcznymi na sześciu krytycznych urządzeniach fizycznych. Deweloperzy naprawili awarię Samsung, zapewniając, że fragmenty BiometricPrompt całkowicie wznowiły po wywołaniu, rozwiązali zamrożenie iPhone poprzez odświeżenie LAContext w słuchaczach AppState, a problemy Pixel poprzez dodanie kontroli ważności kluczy keystore w onResume.
Wynik osiągnięty: zero awarii związanych z biometrią we wszystkich dwunastu kolejnych wydaniach, utrzymanie wskaźnika sukcesu autoryzacji 99,9% w analizach produkcyjnych oraz redukcja czasu testowania regresji o sześćdziesiąt procent dzięki strategicznej automatyzacji, przy jednoczesnym zachowaniu pokrycia walidacji specyficznych dla sprzętu.
Jak zachowanie unieważniania kluczy iOS Secure Enclave różni się od Android Keystore w przypadku rejestracji nowych danych biometrycznych i dlaczego ta różnica zasadniczo zmienia przypadki testowe do ręcznego testowania autoryzacji zapasowej?
W iOS klucze utworzone przy pomocy kSecAccessControlBiometryCurrentSet (lub nowoczesna flaga biometryCurrentSet) stają się natychmiastowo trwale unieważnione po dodaniu jakiegokolwiek nowego odcisku palca lub twarzy, wymagając wyraźnej ponownej autoryzacji użytkownika w celu przywrócenia dostępu. Natomiast w Android klucze związane przy pomocy setUserAuthenticationRequired(true) bez flagi setInvalidatedByBiometricEnrollment(true) (dostępnej API 30+) pozostają ważne nawet po rejestracji nowej biometrii, chyba że zostaną skonfigurowane inaczej. Dla ręcznego testowania oznacza to, że przypadki testowe iOS muszą weryfikować łagodne przejście do zapasowego wprowadzenia PIN z potencjalnymi procedurami ponownego szyfrowania danych, gdy klucze zostaną unieważnione, podczas gdy testowanie Android musi potwierdzić ciągłość dostępu lub intencjonalne unieważnienie w zależności od wymagań bezpieczeństwa. Kandydaci często pomijają, że iOS egzekwuje natychmiastowe unieważnienie kryptograficzne na poziomie sprzętowym, podczas gdy Android domyślnie przyjmuje ciągłość, co prowadzi do niewystarczającego pokrycia testów dla scenariusza "dodany nowy odcisk palca przez współmałżonka", który powinien wywołać ostrzeżenia zabezpieczeń w iOS, ale niekoniecznie w Android.
Jaką konkretną lukę musi weryfikować ręczne testowanie w odniesieniu do braku CryptoObject w wywołaniach Android BiometricPrompt i jak to wpływa na aplikacje React Native inaczej niż aplikacje natywne Android?
BiometricPrompt Android może zwrócić AuthenticationResult bez CryptoObject, jeśli wywołująca aplikacja nie dostarczy go podczas tworzenia wywołania, co oznacza, że system zweryfikował biometrię, ale nie wykonał operacji kryptograficznej. W aplikacjach React Native wykorzystujących moduły mostowe, takie jak react-native-biometrics, warstwa JavaScript zazwyczaj otrzymuje prosty boolean sukcesu, co potencjalnie maskuje, że moduł natywny nigdy nie zainicjował CryptoObject, co sprawia, że aplikacja jest podatna na ataki podłączające przy użyciu Frida lub Xposed, które wstrzykują fałszywe wywołania w zwrotne sukcesu. Ręczni testerzy muszą to zweryfikować, sprawdzając Logcat pod kątem obecności CryptoObject lub próbując za pomocą objection podłączyć wywołanie zwrotne i wstrzyknąć wyniki sukcesu; jeśli aplikacja kontynuuje działanie bez rzeczywistego odszyfrowania klucza, implementacja biometryczna jest kosmetyczna, a nie kryptograficzna. Kandydaci często zakładają, że zakończenie monitu oznacza udaną autoryzację, nie zdając sobie sprawy, że asynchroniczny most React Native pozwala na warunki wyścigu, w których obietnica JavaScript rozwiązuje się po zakończeniu UI, zanim zakończą się natywne weryfikacje kryptograficzne.
Jak ręczni testerzy powinni weryfikować zachowanie aplikacji podczas trybu lockdownu w iOS i trwałego zablokowania biometrycznego w Android oraz jakie są konkretne ryzyka dla trwałości danych Keystore i Keychain podczas tych stanów?
iOS wchodzi w tryb lockdownu po pięciu nieudanych próbach FaceID lub natychmiastowym aktywowaniu za pomocą sekwencji przycisku zasilania, zmuszając do wprowadzenia PIN i wyłączając biometrię w całym systemie, podczas gdy Android wdraża stopniowe czasy oczekiwania kończące się trwałym zablokowaniem, wymagającym PIN. Ręczni testerzy muszą celowo popełnić pięć do dziesięciu kolejnych błędów autoryzacji biometrycznej, a następnie zweryfikować, czy aplikacja wykrywa LAErrorBiometryLockout (iOS) lub BiometricStatus.LOCKOUT_PERMANENT (Android) i bezproblemowo przechodzi do zapasowego wprowadzenia PIN bez uszkodzenia danych. Krytyczne ryzyka obejmują klucze Keystore skonfigurowane z setUserAuthenticationValidityDurationSeconds, które stają się tymczasowo niedostępne podczas zablokowania (co potencjalnie może prowadzić do utraty danych, jeśli aplikacja próbuje odszyfrować zapisane poświadczenia) oraz elementy Keychain iOS z dostępnością biometryAny, które pozostają dostępne za pomocą zapasowego PIN, podczas gdy elementy biometryCurrentSet stają się trwale osierocone. Kandydaci często pomijają testowanie scenariusza "powrót do aplikacji po zablokowaniu", w którym aplikacje w tle wznawiają działanie i podejmują operacje kryptograficzne, które nieudanie kończą się cicho lub powodują awarie, ponieważ nie sprawdzają ponownie dostępności biometrii w cyklu życia onResume, co prowadzi do nieobsługiwanych wyjątków przy dostępie do danych chronionych przez Secure Enclave.