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 CarrierConfigManager, a instrukcje – w 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 urządzenie ani preinstalowania ich jako aplikacji systemowych.

Zasady dotyczące karty UICC

Pamięć na karcie UICC jest zgodna ze specyfikacją kontroli dostępu do elementu zabezpieczającego GlobalPlatform. 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 rozszerzony 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 jest następująca:

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ą 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.

BugreportManager

Metoda rozpoczynania zgłaszania błędów z łącznością, czyli specjalnej wersji raportu o błędzie, która zawiera tylko informacje potrzebne 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 aplikacji w trybie gotowości. Dzięki temu aplikacja usługi operatora jest zwolniona z  ograniczenia bezczynnoś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ą:

Dostawca usług telefonicznych

Interfejsy API dostawców treści umożliwiające modyfikacje (wstawianie, usuwanie, aktualizowanie, wyszukiwanie) bazy danych telefonii. 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 Androida,

Wykryta karta UICC jest przetwarzana przez platformę w wewnętrzne obiekty UICC, które zawierają reguły uprawnień operatora. UiccCarrierPrivilegeRules.java wczytuje reguły, analizuje je z karty UICC i przechowuje w pamięci podręcznej. Gdy wymagane jest sprawdzenie uprawnień, usługa 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ą pakietu testów zgodności (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 i starszych wersji 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 na 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.

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ą operatora 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: W przypadku tych profili reguła CTS Carrier Privilege nie będzie spersonalizowana ani nie będą w nich wprowadzane inne modyfikacje wymienione powyżej.

Przeprowadzanie testów

Aby ułatwić testowanie, CTS obsługuje token urządzenia, który ogranicza uruchamianie testów 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ć tą metodą?

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 pozwalają sprawdzić, które interfejsy API są obsługiwane przez tę metodę?)

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

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 w jakikolwiek sposób wchodzi w interakcję lub pokrywa się z innymi technologiami dostępu do SE, np. SEEK?

O: Na przykład SEEK używa tego samego identyfikatora AID 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 znak 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. Jeśli 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 i przywracanie kopii zapasowych SMS-ów 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. Zdecydowanie zalecamy używanie SHA-256.

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

O: Interfejsy API przewoźnika wymagają wypełnienia pola DeviceAppID-REF-DO. Puste pole jest przeznaczone do celów testowych 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 celowe? Jak kod działa, gdy w REF-DO używany jest tylko znak PKG-REF-DO?

O: W najnowszej wersji usunęliśmy możliwość używania PKG-REF-DO jako pojedynczej wartości w 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ć bardziej szczegółową kontrolę. 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 obowiązywać w przypadku wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).

O: DeviceAppID przechowywanie certyfikatów jest obsługiwane przez istniejącą 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.