Uprawnienia operatora UICC

W Androidzie 5.1 wprowadzono mechanizm przyznawania specjalnych uprawnień interfejsom API, które są przydatne właścicielom aplikacji na karty UICC. Platforma Android wczytuje certyfikaty zapisane na karcie UICC i przyznaje aplikacjom podpisanym tymi certyfikatami uprawnienia do wywoływania kilku specjalnych interfejsów API.

Android 7.0 rozszerzył tę funkcję o obsługę innych źródeł pamięci masowej na potrzeby reguł uprawnień operatora UICC, co znacząco zwiększyło liczbę operatorów, którzy mogą korzystać z interfejsów API. Informacje o interfejsie API znajdziesz w klasie CarrierConfigManager, a instrukcje – w artykule Konfiguracja operatora.

Operatorzy mają pełną kontrolę nad kartą UICC, więc ten mechanizm zapewnia bezpieczny i elastyczny sposób zarządzania aplikacjami od operatora sieci komórkowej (MNO) hostowanymi na ogólnych kanałach dystrybucji aplikacji (takich jak Google Play), przy zachowaniu specjalnych uprawnień na urządzeniach i bez konieczności podpisywania aplikacji certyfikatem platformy na urządzeniu lub instalowania ich jako aplikacji systemowych.

Zasady dotyczące kart UICC

Miejsce na dane w UICC jest zgodne ze specyfikacją GlobalPlatform Secure Element Access Control. Identyfikator aplikacji (AID) na karcie to A00000015141434C00, a standardowe polecenie GET DATA służy do pobierania reguł zapisanych na karcie. Te reguły możesz aktualizować za pomocą bezprzewodowych (OTA) aktualizacji kart.

Hierarchia danych

Reguły UICC używają tej hierarchii danych (2-literowa kombinacja liter i liczb w nawiasach to tag obiektu). Każda reguła jest REF-AR-DO (E2) i składa się z koniunkcji REF-DO i AR-DO:

  • REF-DO (E1) zawiera: DeviceAppID-REF-DO lub konkatenację DeviceAppID-REF-DO i PKG-REF-DO.
    • DeviceAppID-REF-DO (C1) przechowuje podpis SHA-1 (20 bajtów) lub SHA-256 (32 bajty) certyfikatu.
    • PKG-REF-DO (CA) to pełny ciąg znaków nazwy pakietu zdefiniowany w pliku manifestu, zakodowany w standardzie ASCII, o maksymalnej długości 127 bajtów.
  • Rozszerzenie AR-DO (E3) obejmuje 84 osobne uprawnienia, czyli PERM-AR-DO (DB).

Jeśli PKG-REF-DO nie jest obecny, dostęp jest przyznawany każdej aplikacji podpisanej przez certyfikat. W przeciwnym razie nazwa certyfikatu i nazwa pakietu muszą być takie same.

Przykład reguły

Nazwa aplikacji to com.google.android.apps.myapp, a certyfikat SHA-1 w formacie szesnastkowym:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

Reguła w UICC w ciągu szesnastkowym:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

Obsługa pliku reguły dostępu

Android 7.0 obsługuje odczytywanie reguł uprawnień operatora z pliku reguł dostępu (ARF).

Platforma Android najpierw próbuje wybrać identyfikator AID aplikacji reguły dostępu (ARA) A00000015141434C00. Jeśli nie znajdzie AID na karcie UICC, użyje AID karty ARF, wybierając AID PKCS15.A000000063504B43532D3135 Następnie Android odczytuje plik z regułami kontroli dostępu (ACRF) w miejscu 0x4300 i szuka wpisów z identyfikatorem AID FFFFFFFFFFFF. Wpisy z różnymi identyfikatorami AID są ignorowane, więc reguły dotyczące innych zastosowań mogą współistnieć.

Przykład treści ACRF w formacie szesnastkowym:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

Przykładowa treść pliku warunków kontroli dostępu (ACCF):

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

W tym przykładzie 0x4310 to adres ACCF, który zawiera hasz certyfikatu 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Aplikacje podpisane tym certyfikatem mają przypisane uprawnienia operatora.

Włączone interfejsy API

Android obsługuje te interfejsy API:

TelephonyManager

Połączenie zwrotne

TelephonyCallback ma interfejsy z metodą wywołania, aby powiadomić aplikację wywołującą o zmianie zarejestrowanych stanów:

Menedżer subskrypcji

SmsManager

Menedżer konfiguracji operatora

Instrukcje znajdziesz w artykule Konfiguracja operatora.

Menedżer zgłaszania błędów

Metoda uruchamiania raportu o błędzie dotyczącym łączności, który jest specjalistyczną wersją raportu o błędzie zawierającą tylko informacje do debugowania problemów z łącznością: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

Sposób przełączenia się na daną subskrypcję (włączenie): switchToSubscription

Usługa MessagingService

Usługa, która odbiera połączenia z systemu, gdy wysyłane lub odbierane są nowe SMS-y i MMS-y. Aby rozszerzyć tę klasę, zadeklaruj usługę w pliku manifestu z uprawnieniami android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE i uwzględnij filtr intencji z działaniem #SERVICE_INTERFACE. Metody obejmują:

CarrierService

Usługa, która udostępnia systemowi funkcje związane z operatorem. Aby rozszerzyć tę klasę, zadeklaruj usługę w pliku manifestu aplikacji z uprawnieniami android.Manifest.permission#BIND_CARRIER_SERVICES i uwzględnij filtr intencji z działaniem CARRIER_SERVICE_INTERFACE. Jeśli usługa ma długotrwałe powiązanie, ustaw wartość android.service.carrier.LONG_LIVED_BINDING na true w metadanych usługi.

Platforma wiąże CarrierService ze specjalnymi flagami, aby umożliwić proces usługi operatora w ramach specjalnego bufora aplikacji. Dzięki temu aplikacja operatora nie będzie podlegać ograniczeniu działania aplikacji, gdy nie jest używana, i będzie miała większe szanse na pozostanie aktywna, gdy na urządzeniu jest mało pamięci. Jeśli jednak aplikacja usługi operatora ulegnie awarii z jakiegokolwiek powodu, utraci wszystkie wymienione wyżej uprawnienia do czasu jej ponownego uruchomienia i ponownego nawiązania powiązania. Dlatego ważne jest, aby aplikacja Usługi operatora działała stabilnie.

Metody w CarrierService:

dostawca usług telefonicznych,

interfejsów API dostawcy treści umożliwiających modyfikowanie (wstawianie, usuwanie, aktualizowanie i zapytanie) w bazie danych telefonicznych. Pola wartości są zdefiniowane w  Telephony.Carriers. Więcej informacji znajdziesz w  opisie klasy Telephony.

WifiNetworkSuggestion

Podczas tworzenia obiektu WifiNetworkSuggestion użyj tych metod, aby ustawić identyfikator subskrypcji lub grupę subskrypcji:

Platforma Android

Na podstawie wykrytego UICC platforma tworzy wewnętrzne obiekty UICC, które obejmują reguły uprawnień operatora jako część UICC. UiccCarrierPrivilegeRules.java wczytuje reguły, analizuje je na karcie UICC i przechowuje w pamięci podręcznej. Gdy potrzebna jest weryfikacja uprawnień, UiccCarrierPrivilegeRules porównuje certyfikat wywołującego z zasadami. Jeśli usuniesz UICC, reguły zostaną zniszczone razem z obiektem UICC.

Weryfikacja

Aby zweryfikować implementację za pomocą pakietu Compatibility Test Suite (CTS) za pomocą CtsCarrierApiTestCases.apk, musisz mieć deweloper UICC z prawidłowymi regułami UICC lub obsługą ARF. Poproś wybranego dostawcę kart SIM o przygotowanie karty UICC dla deweloperów z odpowiednim plikiem ARF, jak opisano w tej sekcji, i wykorzystaj tę kartę do przeprowadzenia testów. Testy CTS UICC nie wymagają aktywnej usługi komórkowej.

Przygotowanie UICC

Na Androidzie 11 i starszych CtsCarrierApiTestCases.apk jest przypisany przez aosp-testkey, z wartością skrótu 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81.

Od Androida 12 obiekt CtsCarrierApiTestCases.apk jest podpisany przez cts-uicc-2021-testkey (wartość skrótu CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0).

Aby przeprowadzać testy interfejsu API operatora CTS w Androidzie 12, urządzenie musi używać karty SIM z uprawnieniami CTS operatora spełniającymi wymagania określone w najnowszej wersji specyfikacji profilu testowego GSMA TS.48 firmy zewnętrznej.

Tej samej karty SIM można też używać na urządzeniach w wersjach starszych niż Android 12.

Modyfikowanie profilu SIM CTS

  1. Dodaj: uprawnienia operatora CTS w masterze aplikacji zasad dostępu (ARA-M) lub w pliku ARF. Oba podpisy muszą być zakodowane w regułach dotyczących przywilejów operatora:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. Utwórz: pliki podstawowe ADF USIM (EF), których nie ma w TS.48, a które są potrzebne do CTS:
    1. EF_MBDN (6FC7), rozmiar rekordu: 28, numer rekordu: 4 
      • Treści
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
        2. Rec2-n: FF...FF
    2. EF_EXT6 (6FC8), rozmiar rekordu:13, numer rekordu: 1
      • Treść: 00FF…FF
        1. EF_MBI (6FC9), rozmiar rekordu: 4, numer rekordu: 1
      • Treść: Rec1: 01010101
        1. EF_MWIS (6FCA), rozmiar rekordu: 5, numer rekordu: 1
      • Treść: 0000000000
  3. Zmień: tabela usług USIM: włącz usługi 47 i 48.
    1. EF_UST (6F38)
      • Treść: 9EFFBF1DFFFE0083410310010400406E01
  4. Modyfikuj: pliki DF-5GS i DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Treść: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Treść: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS – EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Treść: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Treść: A0020000FF…FF
  5. Modyfikacja: użyj ciągu nazwy operatora Android CTS w odpowiednich plikach EF zawierających to oznaczenie:
    1. EF_SPN (USIM/6F46)
      • Treść: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Treść: Rec1 430B83413759FE4E934143EA14FF..FF

Dopasuj do struktury profilu testowego

Pobierz i dopasuj najnowszą wersję tych ogólnych struktur profili testowych. Te profile nie będą miały spersonalizowanej reguły CTS Carrier Privilege ani innych modyfikacji wymienionych powyżej.

Przeprowadzanie testów

Dla wygody CTS obsługuje token urządzenia, który ogranicza uruchamianie testów tylko na urządzeniach skonfigurowanych za pomocą tego samego tokena. Testy CTS interfejsu Carrier API obsługują token urządzenia sim-card-with-certs. Na przykład token urządzenia ogranicza testy interfejsu API operatora tylko do urządzeniaabcd1234:

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

Jeśli przeprowadzasz test bez użycia tokena urządzenia, test przebiega na wszystkich urządzeniach.

Najczęstsze pytania

Jak można aktualizować certyfikaty w UICC?

Odpowiedź: użyj istniejącego mechanizmu aktualizacji OTA karty.

Czy UICC może współistnieć z innymi regułami?

O: W UICC mogą występować inne reguły zabezpieczeń w ramach tego samego identyfikatora AID, ponieważ platforma je odfiltrowuje automatycznie.

Co się stanie, gdy usuniesz kartę UICC z aplikacji, która korzysta z certyfikatów na niej zapisanych?

O: Aplikacja traci swoje uprawnienia, ponieważ reguły powiązane z UICC są niszczone podczas usuwania UICC.

Czy istnieje limit liczby certyfikatów na karcie UICC?

Odpowiedź: platforma nie ogranicza liczby certyfikatów, ale ponieważ weryfikacja jest liniowa, zbyt duża liczba reguł może spowodować opóźnienie weryfikacji.

Czy istnieje ograniczenie liczby interfejsów API, które możemy obsługiwać za pomocą tej metody?

Odp.: nie, ale ograniczamy zakres do interfejsów API związanych z operatorem.

Czy korzystanie z tej metody jest zabronione w przypadku niektórych interfejsów API? Jeśli tak, to jak je egzekwujesz? (czyli czy masz testy, które sprawdzają, które interfejsy API są obsługiwane przy użyciu tej metody?)

Odp.: zapoznaj się z sekcją Zgodność z zachowaniem API w Dokumentacji dotyczącej zgodności Androida (CDD). Mamy kilka testów CTS, które mają na celu sprawdzenie, czy model uprawnień interfejsów API się nie zmienił.

Jak to działa w przypadku korzystania z wielu kart SIM?

O: Używana jest domyślna karta SIM określona przez użytkownika.

Czy ta technologia w jakikolwiek sposób wchodzi w interakcję z innymi technologiami dostępu z wykorzystaniem Bezpiecznego dostępu, na przykład SEEK, lub z nimi się pokrywa?

O: Na przykład SEEK używa tego samego identyfikatora co w UICC. Reguły współistnieją i są filtrowane przez SEEK lub UiccCarrierPrivileges.

Kiedy należy sprawdzić uprawnienia operatora?

Odp.: po transmisji stanu załadowania karty SIM.

Czy OEM może wyłączyć część interfejsów operatora?

O: Nie. Naszym zdaniem obecne interfejsy API mają minimalny zestaw i w przyszłości planujemy użyć maski bitowej, aby jeszcze bardziej precyzować kontrolę.

Czy operator setOperatorBrandOverride zastępuje wszystkie inne formy operatora nazwy? Na przykład SE13, SPN UICC lub NITZ oparty na sieci.

Tak, zastąpienie marki operatora ma najwyższy priorytet. Gdy jest ustawiona, zastępuje WSZYSTKIE inne formy ciągów znaków nazwy operatora.

Do czego służy wywołanie metody injectSmsPdu?

Odp.: ta metoda ułatwia tworzenie kopii zapasowej SMS-ów i ich przywracanie w chmurze. Wywołanie injectSmsPdu umożliwia funkcję przywracania.

Czy podczas filtrowania SMS-ów wywołanie onFilterSms korzysta z filtrowania portów SMS UDH? Czy aplikacje operatora mają dostęp do WSZYSTKICH przychodzących SMS-ów?

Odp.: operatorzy mają dostęp do wszystkich danych SMS.

Rozszerzenie DeviceAppID-REF-DO do obsługi 32 bajtów wydaje się być niezgodne z obecną specyfikacją GP (która zezwala tylko na 0 lub 20 bajtów). Dlaczego wprowadzasz tę zmianę? Czy SHA-1 nie wystarcza, aby uniknąć kolizji? Czy ta zmiana została już zaproponowana do GP, ponieważ może nie być zgodna wstecznie z dotychczasowymi plikami ARA-M/ARF?

O: Aby zapewnić przyszłe bezpieczeństwo, to rozszerzenie wprowadza SHA-256 dla DeviceAppID-REF-DO oraz SHA-1, który obecnie jest jedyną opcją w standardzie GP SEAC. Zdecydowanie zalecamy użycie algorytmu SHA-256.

Jeśli DeviceAppID to 0 (puste), czy reguła ma być stosowana do wszystkich aplikacji na urządzeniu, które nie są objęte żadną konkretną regułą?

Odp.: interfejsy API operatora wymagają wypełnienia pola DeviceAppID-REF-DO. Pusty plik jest przeznaczony do celów testowych i nie jest zalecany do wdrożeń operacyjnych.

Zgodnie z Twoimi specyfikacjami PKG-REF-DO użyte samo w sobie, bez DeviceAppID-REF-DO, nie powinno być akceptowane. W specyfikacji (tabela 6–4) jest ona jednak nadal opisywana jako rozszerzenie definicji REF-DO. Czy to celowe? Jak działa kod, gdy w polu REF-DO używany jest tylko kod PKG-REF-DO?

Odp.: w najnowszej wersji została usunięta opcja PKG-REF-DO jako pojedyncza wartość w elemencie REF-DO. Wartość PKG-REF-DO powinna występować tylko w połączeniu z wartością DeviceAppID-REF-DO.

Zakładamy, że możemy przyznać dostęp do wszystkich uprawnień operatora lub uzyskać bardziej szczegółową kontrolę. Jeśli tak, to co określa mapowanie między maską bitową a rzeczywistymi uprawnieniami? Jedno uprawnienie na zajęcia? Jedno uprawnienie na metodę? Czy 64 osobne uprawnienia wystarczą na dłuższą metę?

O: Ta nazwa jest zarezerwowana na przyszłość. Czekamy na sugestie.

Czy możesz dokładniej określić, co oznacza DeviceAppID w przypadku Androida? Jest to wartość skrótu SHA-1 (20 bajtów) certyfikatu wydawcy użytego do podpisania danej aplikacji. Czy nazwa nie powinna odzwierciedlać tego celu? (Ta nazwa może być myląca dla wielu czytelników, ponieważ reguła dotyczy wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).

Odpowiedź: DeviceAppID przechowywanie certyfikatów jest obsługiwane przez istniejące specyfikacje. Staraliśmy się zminimalizować zmiany w specyfikacji, aby obniżyć barierę wdrażania. Szczegółowe informacje znajdziesz w artykule Reguły UICC.