Uprawnienia operatora dotyczące kart UICC

W Androidzie 5.1 wprowadzono mechanizm przyznawania specjalnych uprawnień interfejsom API istotnym dla właścicieli aplikacji na uniwersalną kartę SIM (UICC). Platforma Android wczytuje certyfikaty przechowywane na karcie UICC i przyznaje uprawnienia aplikacjom podpisanym tymi certyfikatami do wykonywania połączeń z kilkoma specjalnymi interfejsami API.

Android 7.0 rozszerzył tę funkcję, aby obsługiwała inne źródła pamięci dla reguł uprawnień operatora UICC, co znacznie zwiększyło liczbę operatorów, którzy mogą korzystać z interfejsów API. Dokumentację interfejsu API znajdziesz w sekcji CarrierConfigManager, a instrukcje – w sekcji Konfiguracja operatora.

Operatorzy mają pełną kontrolę nad kartą UICC, więc ten mechanizm zapewnia bezpieczny i elastyczny sposób zarządzania aplikacjami operatora sieci komórkowej hostowanymi w 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 poszczególne urządzenia ani preinstalowania ich jako aplikacji systemowych.

Zasady dotyczące karty UICC

Pamięć na karcie UICC jest zgodna ze specyfikacją GlobalPlatform dotyczącą kontroli dostępu do bezpiecznego elementu. Identyfikator aplikacji (AID) na karcie to A00000015141434C00, a do pobierania reguł przechowywanych na karcie używane jest polecenie standardowe GET DATA. Możesz aktualizować te reguły za pomocą aktualizacji bezprzewodowych (OTA) karty.

Hierarchia danych

Reguły UICC korzystają z tej hierarchii danych (dwuznakowa kombinacja liter i cyfr w nawiasach to tag obiektu): Każda reguła to REF-AR-DO (E2) i składa się z połączenia REF-DO i AR-DO:

  • REF-DO (E1) zawiera DeviceAppID-REF-DO lub połączenie 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łna nazwa pakietu zdefiniowana w pliku manifestu, zakodowana w ASCII, o maksymalnej długości 127 bajtów.
  • AR-DO (E3) jest rozszerzone o PERM-AR-DO (DB), czyli 8-bajtową maskę bitową reprezentującą 64 osobne uprawnienia.

Jeśli nie ma PKG-REF-DO, dostęp uzyskuje każda aplikacja podpisana certyfikatem. W przeciwnym razie muszą się zgadzać zarówno certyfikat, jak i nazwa pakietu.

Przykład reguły

Nazwa aplikacji to com.google.android.apps.myapp, a certyfikat SHA-1 w postaci ciągu szesnastkowego to:

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

Reguła dotycząca UICC w ciągu szesnastkowym to:

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

Obsługa plików reguł dostępu

Android 7.0 wprowadza obsługę odczytywania reguł uprawnień operatora z pliku reguł dostępu (ARF).

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

Przykładowa treść ACRF w postaci ciągu szesnastkowego:

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

Przykładowa zawartość 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 przykładzie powyżej 0x4310 to adres ACCF, który zawiera hash 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ą przyznane uprawnienia operatora.

Włączone interfejsy API

Android obsługuje te interfejsy API:

TelephonyManager

TelephonyCallback

TelephonyCallback ma interfejsy z metodą wywołania zwrotnego, która powiadamia aplikację wywołującą o zmianach zarejestrowanych stanów:

SubscriptionManager

SmsManager

CarrierConfigManager

Instrukcje znajdziesz w artykule Konfiguracja operatora.

Kompilacja

Sposób uzyskania numeru seryjnego sprzętu, jeśli jest dostępny: getSerial

BugreportManager

Metoda rozpoczynania zgłaszania błędów z łącznością, czyli specjalnej wersji raportu o błędzie, która zawiera tylko informacje do debugowania problemów związanych z łącznością: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

Metoda przejścia na daną subskrypcję (włączenia jej): switchToSubscription

CarrierMessagingService

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 dodaj filtr intencji z działaniem #SERVICE_INTERFACE. Możesz wykorzystać następujące metody:

CarrierService

Usługa, która udostępnia systemowi funkcje specyficzne dla operatora. 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, w metadanych usługi ustaw wartość android.service.carrier.LONG_LIVED_BINDING na true.

Platforma wiąże CarrierService ze specjalnymi flagami, aby umożliwić uruchomienie usługi operatora w specjalnym zasobniku gotowości aplikacji. Dzięki temu aplikacja usługi operatora jest zwolniona z  ograniczenia dotyczącego braku aktywności aplikacji i ma większe szanse na pozostanie aktywną, gdy na urządzeniu jest mało pamięci. Jeśli jednak aplikacja usługi przewoźnika ulegnie awarii z jakiegokolwiek powodu, utraci wszystkie powyższe uprawnienia do czasu ponownego uruchomienia i przywrócenia powiązania. Dlatego ważne jest, aby aplikacja usługi operatora była stabilna.

Metody w CarrierService obejmują:

  • Aby zastąpić i skonfigurować ustawienia specyficzne dla operatora: onLoadConfig
  • Aby poinformować system o planowanej zmianie sieci operatora przez aplikację operatora: notifyCarrierNetworkChange

Dostawca usług telefonicznych

Interfejsy API dostawcy treści umożliwiające modyfikacje (wstawianie, usuwanie, aktualizowanie, wysyłanie zapytań) bazy danych telefonicznych. Pola wartości są zdefiniowane w  Telephony.Carriers. Więcej informacji znajdziesz w  Telephony klasie referencyjnej.

WifiNetworkSuggestion

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

Platforma Android

Wykryta karta UICC powoduje utworzenie przez platformę wewnętrznych obiektów UICC, które zawierają reguły uprawnień operatora. UiccCarrierPrivilegeRules.java wczytuje reguły, analizuje je z karty UICC i zapisuje w pamięci podręcznej. Gdy wymagane jest sprawdzenie uprawnień, UiccCarrierPrivilegeRules porównuje certyfikat wywołującego z własnymi regułami. Jeśli karta UICC zostanie usunięta, reguły zostaną zniszczone wraz z obiektem UICC.

Weryfikacja

Aby zweryfikować wdrożenie za pomocą Compatibility Test Suite (CTS) przy użyciu CtsCarrierApiTestCases.apk, musisz mieć kartę UICC dewelopera z prawidłowymi regułami UICC lub obsługą ARF. Poproś wybranego dostawcę kart SIM o przygotowanie karty UICC dla deweloperów z odpowiednim ARF zgodnie z opisem w tej sekcji i użyj tej karty UICC do przeprowadzenia testów. Karta UICC nie wymaga aktywnej usługi komórkowej, aby przejść testy CTS.

Przygotowywanie karty UICC

W przypadku Androida 11 lub starszego CtsCarrierApiTestCases.apk jest podpisany przez aosp-testkey, a wartość skrótu to 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81.

Od Androida 12 CtsCarrierApiTestCases.apk jest podpisywany 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 uruchomić testy interfejsu API operatora CTS w Androidzie 12, urządzenie musi używać karty SIM z uprawnieniami operatora CTS spełniającymi wymagania określone w najnowszej wersji specyfikacji GSMA TS.48 Test Profile z ustalonym ADM1, klucz = 55555555 / 0x3535353535353535.

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

Modyfikowanie profilu SIM CTS

  1. Dodaj: uprawnienia operatora CTS w aplikacji głównej reguły dostępu (ARA-M) lub ARF. Oba podpisy muszą być zakodowane w regułach uprawnień 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: podstawowe pliki USIM ADF (EF) nieobecne w TS.48, a potrzebne w 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. Modyfikacja: tabela usług USIM: włącz usługi nr 47 i 48.
    1. EF_UST (6F38)
      • Treści: 9EFFBF1DFFFE0083410310010400406E01
  4. Modyfikacja: pliki DF-5GS i DF-SAIP.
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Treści: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Treści: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Treści: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Treści: A0020000FF…FF
  5. Zmodyfikuj: użyj ciągu znaków z nazwą przewoźnika Android CTS w odpowiednich plikach EF zawierających to oznaczenie:
    1. EF_SPN (USIM/6F46)
      • Treści: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Treści: Rec1 430B83413759FE4E934143EA14FF..FF

Dopasuj strukturę profilu testowego

Pobierz i dopasuj najnowszą wersję tych ogólnych struktur profilu testowego: Te profile nie będą miały spersonalizowanej reguły uprawnień operatora CTS ani innych modyfikacji wymienionych powyżej.

Przeprowadzanie testów

Dla wygody CTS obsługuje token urządzenia, który ogranicza testy do uruchamiania tylko na urządzeniach skonfigurowanych z tym samym tokenem. Testy CTS interfejsu Carrier API obsługują token urządzenia sim-card-with-certs. Na przykład ten token urządzenia ogranicza testy interfejsu API operatora do uruchamiania tylko na urządzeniu abcd1234:

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

Jeśli test jest przeprowadzany bez użycia tokena urządzenia, jest on uruchamiany na wszystkich urządzeniach.

Najczęstsze pytania

Jak można zaktualizować certyfikaty na karcie UICC?

A: Użyj dotychczasowego mechanizmu aktualizacji OTA karty.

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

O: Możesz mieć inne reguły bezpieczeństwa na karcie UICC w ramach tego samego identyfikatora AID. Platforma automatycznie je odfiltruje.

Co się stanie, gdy usunę kartę UICC w przypadku aplikacji, która korzysta z zawartych na niej certyfikatów?

O: Aplikacja traci uprawnienia, ponieważ reguły powiązane z kartą UICC są usuwane po jej wyjęciu.

Czy istnieje ograniczenie liczby certyfikatów na karcie UICC?

O: Platforma nie ogranicza liczby certyfikatów, ale ponieważ sprawdzanie jest liniowe, zbyt duża liczba reguł może powodować opóźnienia.

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

O: Nie, ale ograniczamy zakres do interfejsów API związanych z operatorami.

Czy są jakieś interfejsy API, w przypadku których nie można używać tej metody? Jeśli tak, w jaki sposób je egzekwujesz? (czyli czy masz testy, które sprawdzają, które interfejsy API są obsługiwane przez tę metodę?)

O: Zapoznaj się z sekcją Zgodność behawioralna interfejsu API w dokumencie definicji zgodności (CDD) Androida. Mamy kilka testów CTS, które sprawdzają, czy model uprawnień interfejsów API nie został zmieniony.

Jak to działa w przypadku funkcji obsługi 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 do SE lub pokrywa się z nimi, np. z SEEK?

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

Kiedy warto sprawdzić uprawnienia operatora?

O: Po wczytaniu stanu karty SIM.

Czy producenci OEM mogą wyłączyć część interfejsów API operatora?

O: Nie. Uważamy, że obecne interfejsy API stanowią minimalny zestaw, a w przyszłości planujemy używać maski bitowej do bardziej precyzyjnego sterowania.

Czy symbol setOperatorBrandOverride zastępuje WSZYSTKIE inne formy ciągów znaków z nazwą operatora? Na przykład SE13, UICC SPN lub NITZ oparty na sieci?

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

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

O: Ta metoda ułatwia tworzenie kopii zapasowych SMS-ów i ich przywracanie w chmurze. Wywołanie injectSmsPdu włącza funkcję przywracania.

Czy w przypadku filtrowania SMS-ów wywołanie onFilterSms jest oparte na filtrowaniu portu UDH SMS-a? Czy aplikacje operatora mają dostęp do WSZYSTKICH przychodzących SMS-ów?

O: Przewoźnicy mają dostęp do wszystkich danych SMS.

Rozszerzenie DeviceAppID-REF-DO do obsługi 32 bajtów wydaje się niezgodne z obecną specyfikacją GP (która dopuszcza tylko 0 lub 20 bajtów), więc dlaczego wprowadzacie tę zmianę? Czy SHA-1 nie wystarczy, aby uniknąć kolizji? Czy ta zmiana została już zaproponowana zespołowi GP, ponieważ może być niezgodna wstecznie z obecnymi standardami ARA-M/ARF?

O: Aby zapewnić bezpieczeństwo w przyszłości, to rozszerzenie wprowadza SHA-256 dla DeviceAppID-REF-DO oprócz SHA-1, który jest obecnie jedyną opcją w standardzie GP SEAC. Zalecamy używanie SHA-256.

Jeśli wartość DeviceAppID wynosi 0 (pusta), czy reguła jest stosowana do wszystkich aplikacji na urządzeniu, które nie są objęte konkretną regułą?

O: Interfejsy API operatora wymagają wypełnienia pola DeviceAppID-REF-DO. Puste pole jest przeznaczone do testowania i nie jest zalecane w przypadku wdrożeń operacyjnych.

Zgodnie ze specyfikacją PKG-REF-DO użyte samodzielnie, bez DeviceAppID-REF-DO, nie powinno być akceptowane. W specyfikacji w tabeli 6-4 jest on jednak nadal opisany jako rozszerzenie definicji REF-DO. Czy to jest celowe? Jak kod zachowuje się, gdy w REF-DO używana jest tylko wartość PKG-REF-DO?

O: W najnowszej wersji usunięto opcję, która umożliwiała używanie PKG-REF-DO jako pojedynczej wartości 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ń związanych z operatorem lub mieć większą kontrolę nad tym procesem. Jeśli tak, co definiuje 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 funkcja jest zarezerwowana na przyszłość. Chętnie poznamy Twoje sugestie.

Czy możesz dokładniej wyjaśnić, czym jest DeviceAppID w przypadku Androida? Jest to wartość skrótu SHA-1 (20 bajtów) certyfikatu wydawcy użytego do podpisania danej aplikacji, więc czy nazwa nie powinna odzwierciedlać tego celu? (Nazwa może być myląca dla wielu czytelników, ponieważ reguła będzie wtedy dotyczyć wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).

O: DeviceAppID przechowywanie certyfikatów jest obsługiwane przez obecną specyfikację. Staraliśmy się zminimalizować zmiany w specyfikacji, aby ułatwić jej wdrożenie. Więcej informacji znajdziesz w sekcji Reguły dotyczące karty UICC.