Uprawnienia operatora dotyczące kart UICC

W Androidzie 5.1 wprowadzono mechanizm przyznawania specjalnych uprawnień interfejsom API istotne dla właścicieli aplikacji korzystających z uniwersalnych kart obwodów zintegrowanych (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ę na obsługę innych źródeł pamięci dla UICC reguły uprawnień operatora, zwiększyć liczbę operatorów, którzy mogą korzystać z tych interfejsów. Żeby zapoznać się z informacjami o interfejsie API, zobacz CarrierConfigManager; aby uzyskać instrukcje, zobacz Operator Konfiguracja.

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

Przechowywanie danych w UICC jest zgodne z Platforma globalna Specyfikacja kontroli dostępu do bezpiecznego elementu. Identyfikator aplikacji (AID) na karcie to A00000015141434C00, a standardowe polecenie GET DATA służy do pobierania reguł zapisanych na karcie. Możesz aktualizować te reguły 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 konkatenacji REF-DO i AR-DO:

  • REF-DO (E1) zawiera DeviceAppID-REF-DO lub konkatenacja DeviceAppID-REF-DO i PKG-REF-DO.
    • DeviceAppID-REF-DO (C1) przechowuje SHA-1 (20 bajtów) lub podpis SHA-256 (32 bajty) certyfikatu.
    • PKG-REF-DO (CA) to pełna nazwa pakietu ciąg zdefiniowany w pliku manifestu, zakodowany ASCII, maksymalna długość 127 bajtów.
  • AR-DO (E3) został rozszerzony o PERM-AR-DO (DB), czyli 8-bajtową maskę bitową reprezentującą 64 osobne uprawnienia.

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

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 dotycząca UICC w formie ciągu szesnastkowego to:

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

Obsługa pliku reguł dostępu

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

Platforma Androida najpierw próbuje wybrać aplikację reguły dostępu (ARA) AID: A00000015141434C00. Jeśli nie znajdzie AID na karcie UICC, użyje AID karty ARF, wybierając AID PKCS15.A000000063504B43532D3135 Następnie Android odczytuje plik zasad kontroli dostępu (ACRF) pod adresem 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ładowa zawartość ACRF w ciągu 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 powyższym przykładzie 0x4310 to adres dla formatu 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 aplikacji; podpisany tym certyfikatem otrzymują uprawnienia operatora.

Włączone interfejsy API

Android obsługuje te interfejsy API:

TelephonyManager

TelephonyCallback

TelephonyCallback ma interfejsy z metodą wywołania zwrotnego do powiadamiać aplikację do rozmów o zmianie zarejestrowanego stanu:

Menedżer subskrypcji

SmsManager

Menedżer konfiguracji operatora

Instrukcje znajdziesz w artykule Konfiguracja operatora.

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

Metoda uruchamiania zgłoszenia błędu związanego z łącznością, która jest wyspecjalizowaną wersją raport o błędzie zawierający tylko informacje potrzebne do debugowania problemów z łącznością, problemy: startConnectivityBugreport

Menedżer statystyk sieci

Usługa ImsMmTelManager

Usługa ImsRcsManager

Menedżer obsługi administracyjnej

EuiccManager

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

CarrierMessagingService

usługa odbierająca połączenia z systemu po wysłaniu nowych SMS-ów i MMS-ów; odebrane. 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. Do rozszerz tę klasę, zadeklaruj usługę w pliku manifestu aplikacji za pomocą polecenia android.Manifest.permission#BIND_CARRIER_SERVICES i uwzględnić filtr intencji z działaniem CARRIER_SERVICE_INTERFACE. Jeśli usługa ma długotrwałe powiązanie, ustaw android.service.carrier.LONG_LIVED_BINDING do true w metadanych usługi.

Platforma wiąże CarrierService ze specjalnymi flagami, aby umożliwić proces usługi operatora w ramach specjalnego bufora aplikacji. Wyklucza to w niej aplikacje usług operatora ograniczenie nieaktywności aplikacji i zwiększa prawdopodobieństwo przeżycia aplikacji 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 była stabilna.

Metody dostępne w CarrierService to:

dostawca usług telefonicznych,

interfejsy API dostawców treści umożliwiające wprowadzanie zmian (wstawianie, usuwanie, aktualizowanie, zapytanie) w bazie danych telefonii; Pola wartości są zdefiniowane na stronie Telephony.Carriers; Aby dowiedzieć się więcej, zapoznaj się z artykułem odwołanie do zajęć Telephony

Sugestia sieci Wi-Fi

Tworząc obiekt WifiNetworkSuggestion, użyj tego metod ustawiania identyfikatora subskrypcji lub grupy subskrypcji:

Platforma Android

Po wykryciu UICC platforma tworzy wewnętrzne obiekty UICC, które uwzględniać reguły uprawnień operatora w UICC. UiccCarrierPrivilegeRules.java wczytuje reguły, analizuje je z karty UICC i zapisuje w pamięci podręcznej. Kiedy sprawdzenie uprawnień, UiccCarrierPrivilegeRules porównuje certyfikat rozmówcy z własnymi regułami, po kolei. Jeśli UICC zostanie usunięty, są niszczone wraz z obiektem UICC.

Weryfikacja

Aby sprawdzić implementację za pomocą narzędzia Compatibility Test Suite (CTS) w systemie CtsCarrierApiTestCases.apk, musisz mieć deweloper UICC z prawidłowymi regułami UICC lub obsługą ARF. Poproś wybranego dostawcę karty SIM o przygotowanie UICC programisty z użyj prawej ARF zgodnie z opisem w tej sekcji i użyj tego UICC do przeprowadzania testów. Testy CTS można przejść z kartą UICC bez aktywnej usługi komórkowej.

Przygotowanie UICC

W Androidzie 11 i starszych wersjach CtsCarrierApiTestCases.apk to podpisany 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 CtsCarrierApiTestCases.apk to 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 można było przeprowadzać 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 profilu testowego GSMA TS.48 firmy zewnętrznej.

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 masterze aplikacji zasad dostępu (ARA-M) lub w pliku 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: 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. Modyfikowanie: tabela usług USIM: włączanie usług nr 47, n°48
    1. EF_UST (6F38)
      • Treść: 9EFFBF1DFFFE0083410310010400406E01
  4. Modyfikowanie: 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. Modyfikuj: użyj ciągu znaków z nazwą operatora w Android CTS w odpowiednich plikach EF zawierających tę nazwę:
    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ę poniższych ogólnych struktur profili testowych. Te profile nie będą miały spersonalizowanej reguły uprawnień operatora CTS ani innych zmian 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. CTS interfejsu API operatora testy 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 testujesz urządzenie bez użycia tokena urządzenia, test działa na wszystkich urządzenia.

Najczęstsze pytania

Jak zaktualizować certyfikaty w UICC?

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

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

Odp.: nie ma problemu, jeśli w ramach tego samego identyfikatora AID na karcie UICC są też inne reguły bezpieczeństwa. Platforma automatycznie je odfiltrowuje.

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

Odp.: aplikacja traci uprawnienia, ponieważ reguły powiązane z kartą UICC są usuwane po usunięciu karty.

Czy istnieje limit liczby certyfikatów w 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 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 niektóre interfejsy API nie mogą używać tej metody? 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 funkcji wielu kart SIM?

Odpowiedź: używana jest domyślna karta SIM określona przez użytkownika.

Czy to w jakikolwiek sposób wchodzi w interakcję z innym dostępem SE lub się z nim pokrywa np. SEEK?

Odp.: na przykład SEEK używa tego samego identyfikatora AID co 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 API operatora?

Odp.: nie. Uważamy, że obecne interfejsy API stanowią minimalny zestaw, a w przyszłości planujemy użyć maski bitowej, aby uzyskać większą kontrolę nad ustawieniami.

Czy setOperatorBrandOverride zastępuje WSZYSTKIE inne formularze operatora ciągi nazw? Na przykład SE13, UICC SPN lub sieciowy NITZ?

Tak, zastąpienie marki operatora ma najwyższy priorytet. Po ustawieniu zastępuje wszystkie ustawienia lub inne formy ciągów nazw operatorów.

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 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?

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

Wydłużenie terminu DeviceAppID-REF-DO na obsługę Wydaje się, że 32 bajty niezgodne z bieżącą specyfikacją GP (która dopuszcza tylko 0 lub 20 bajtów), więc dlaczego Czy wprowadzacie tę zmianę? Czy SHA-1 nie jest wystarczający do uniknąć kolizji? Czy ta zmiana została już zaproponowana do GP, ponieważ może być niezgodna wstecznie z dotychczasowymi plikami ARA-M/ARF?

O: Aby zapewnić przyszłościowe bezpieczeństwo, w tym rozszerzeniu wprowadzono SHA-256 dla DeviceAppID-REF-DO oprócz SHA-1, który jest obecnie jest jedyną opcją w ramach standardu GP SEAC. Zdecydowanie zalecamy użycie 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łą?

O: 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. Ale W tabelach 6-4 specyfikacji nadal jest opisane jako rozszerzenie definicja słowa REF-DO. Czy to celowe? Jak kod zachowują się, gdy w REF-DO jest używany tylko atrybut PKG-REF-DO?

O: Opcja ustawienia PKG-REF-DO jako jednej wartości element w folderze REF-DO został usunięty w najnowszej wersji. Funkcja PKG-REF-DO powinna występować tylko w połączeniu z funkcją 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 ? 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? (Nazwa może być dezorientująca dla wielu czytelników, ponieważ reguła to wtedy dotyczy wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).

Odpowiedź: certyfikaty DeviceAppID są obsługiwane przez obecną specyfikację. Staraliśmy się zminimalizować zmiany w specyfikacji, aby obniżyć barierę wdrażania. Więcej informacji znajdziesz w artykule Reguły dotyczące kart UICC.