Uprawnienia operatora 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 w UICC i przyznaje uprawnienia aplikacji podpisanych tymi certyfikatami, które wywołują niektóre specjalne interfejsy 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 UICC, więc ten mechanizm zapewnia bezpieczny i elastyczny sposób zarządzania aplikacjami przez operatora sieci komórkowej są hostowane w ogólnych kanałach dystrybucji aplikacji (takich jak Google Play). zachowywanie specjalnych uprawnień na urządzeniach i bez konieczności podpisywania aplikacji za pomocą certyfikatu platformy dla konkretnego urządzenia lub zainstalować wstępnie jako aplikację systemową.

Reguły UICC

Przechowywanie danych w UICC jest zgodne z Platforma globalna Specyfikacja kontroli dostępu do bezpiecznego elementu. Identyfikator aplikacji (AID) na karcie to A00000015141434C00 i standardowy GET DATA służy do pobierania reguł zapisanych na karcie. Możesz zmienić te reguły za pomocą bezprzewodowych aktualizacji danych karty.

Hierarchia danych

Reguły UICC wykorzystują następującą hierarchię danych (dwuznakowe litery i kombinacji liczb w nawiasach jest tagiem 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.
  • Rozszerzenie AR-DO (E3) zostało rozszerzone o: PERM-AR-DO (DB), czyli 8-bajtowy bit reprezentująca 64 osobne uprawnienia.

Jeśli nie widzisz PKG-REF-DO: dowolna aplikacja podpisana za pomocą certyfikatu ma przyznany dostęp; W przeciwnym razie zarówno certyfikat, jak i nazwa pakietu muszą dopasowania.

Przykład reguły

Nazwa aplikacji to com.google.android.apps.myapp, Certyfikat SHA-1 w ciągu szesnastkowym to:

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ł 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 w UICC, wraca do ARF (AID PKCS15). A000000063504B43532D3135 Android następnie odczytuje pliku reguł kontroli dostępu (ACRF) pod adresem 0x4300 i szuka wpisów z pomocą AID: FFFFFFFFFFFF. Wpisy z różnymi AID są ignorowane, więc mogą współistnieć z regułami dotyczącymi innych zastosowań.

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 poniższe interfejsy API.

Menedżer telefonii

Połączenie zwrotne

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

Menedżer subskrypcji

Menedżer SMS-ów

Menedżer konfiguracji operatora

Instrukcje znajdziesz w materiałach na temat 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

Metoda przełączenia na (włączenia) danej subskrypcji: 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 za pomocą parametru android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE i uwzględnij filtr intencji za pomocą funkcji #SERVICE_INTERFACE działania. Dostępne metody:

Usługa operatora

Usługa, która udostępnia systemowi funkcje właściwe dla operatora. 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 specjalnymi flagami, dzięki którym obsługi klienta w specjalnej zasobnika gotowości aplikacji. Wykluczy to w aplikacji 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 z jakiegoś powodu aplikacja usługi operatora ulegnie awarii, traci wszystkie powyższe uprawnienia, dopóki aplikacja nie uruchomi się ponownie i nie zostanie utworzone powiązanie przywrócona. Dlatego ważne jest, aby aplikacja usługi operatora była stabilna.

Metody dostępne w CarrierService to:

  • Aby zastąpić i ustawić konfiguracje specyficzne dla operatora: onLoadConfig
  • Aby poinformować system o planowanej zbliżającej się zmianie sieci operatora, należy aplikację operatora: notifyCarrierNetworkChange

Dostawca usług telefonicznych

Interfejsy API dostawcy treści umożliwiające wprowadzanie zmian (wstawianie, usuwanie, aktualizowanie, zapytanie) z bazą danych telefonicznych. 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, każdy 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. UICC nie wymaga aktywnej sieci komórkowej, aby przejść testy CTS.

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

Uruchamianie testów interfejsu CTS interfejsu API operatora na Androidzie 12, urządzenie musi używać karty SIM u operatora CTS uprawnienia spełniające wymagania określone w najnowszej wersji aplikacji zewnętrzna Specyfikacja profilu testowego GSMA TS.48.

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 ARA-M lub ARF aplikacji. Oba podpisy muszą być zakodowane w regułach uprawnień operatora:
    1. Hasz1(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. Tworzenie: pliki podstawowe (EF) ADF USIM nie występują w TS.48 i wymagane w przypadku CTS:
    1. EF_MBDN (6FC7), rozmiar rekordu: 28, numer rekordu: 4
      • Content (sieć partnerska),
        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. Modyfikowanie: użyj ciągu z nazwą operatora Android CTS. w odpowiednich 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ę 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 aby przeprowadzać testy tylko na urządzeniach skonfigurowanych przy użyciu tego samego tokena. CTS interfejsu API operatora testy obsługują token urządzenia sim-card-with-certs. Przykład: poniższy 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 testujesz urządzenie bez użycia tokena urządzenia, test działa na wszystkich urządzenia.

Najczęstsze pytania

Jak zaktualizować certyfikaty w UICC?

Użyj dotychczasowego mechanizmu aktualizacji OTA karty.

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

O: W obrębie tego samego interfejsu AID mogą występować inne reguły zabezpieczeń w UICC. a platforma automatycznie je odfiltrowuje.

Co się stanie, gdy usuniemy UICC w przypadku aplikacji, która korzysta z tagu jego certyfikaty?

O: Aplikacja traci swoje uprawnienia, ponieważ reguły powiązane z atrybutem Zostaną zniszczone po usunięciu UICC.

Czy istnieje limit liczby certyfikatów w UICC?

O: Platforma nie ogranicza liczby certyfikatów. ale ponieważ jest liniowy, zbyt wiele reguł może spowodować opóźnienie sprawdzenia.

Czy istnieje ograniczenie liczby interfejsów API, które możemy w tym celu obsługiwać? ? .

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 i wyegzekwujesz ich przestrzeganie? (czyli czy przeprowadzasz testy sprawdzające, które interfejsy API są jest obsługiwane w przypadku tej metody?).

O: Zobacz Sekcja dotycząca zgodności interfejsu API z zgodnością behawioralną w artykule dotyczącym zgodności z Androidem. dokument definicji (CDD). Mamy testy CTS, by upewnić się, model uprawnień tych interfejsów API nie ulegnie zmianie.

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 to w jakikolwiek sposób wchodzi w interakcję z innym dostępem SE lub się z nim pokrywa np. SEEK?

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

Kiedy należy sprawdzić uprawnienia operatora?

O. Po wysłaniu transmisji stanu karty SIM.

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

O: Nie. Uważamy, że obecne interfejsy API mają jedynie minimalny zestaw. planujemy w przyszłości użyć maski bitowej, aby w przyszłości uzyskać bardziej precyzyjną kontrolę.

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?

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

Czy w przypadku filtrowania SMS-ów połączenie onFilterSms jest oparte na Filtrować porty UDH SMS? Czy aplikacje operatora mają dostęp do WSZYSTKICH przychodzących SMS-ów?

O: Operatorzy mają dostęp do wszystkich danych SMS-ów.

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 zaproponowałeś już tę zmianę w Google Preferred, ponieważ być niezgodne wstecznie z istniejącym plikiem 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 ma wartość 0 (puste), czy reguła jest stosowana do wszystkich aplikacji na urządzeniu, których nie obejmuje konkretna reguła?

O: Interfejsy API operatora wymagają wypełnienia pola DeviceAppID-REF-DO. Puste pole jest przeznaczone do celów testowych i nie jest zalecane ze względu na wdrożeniach. .

Zgodnie z Twoją specyfikacją urządzenie PKG-REF-DO używane tylko przez sam, bez DeviceAppID-REF-DO, nie powinien być akceptowany. 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 mają większą kontrolę. Jeśli tak, co definiuje mapowanie między bitem a rzeczywiste uprawnienia? 1 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ć DeviceAppID dla Androida konkretnie? To jest wartość skrótu SHA-1 (20 bajtów) wydawcy certyfikat użyty do podpisania danej aplikacji, więc nazwa nie powinna odzwierciedlać tego jaki jest cel? (Nazwa może być dezorientująca dla wielu czytelników, ponieważ reguła to wtedy dotyczy wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).

O. DeviceAppID przechowywania certyfikatów jest obsługiwane przez według obecnej specyfikacji. Staraliśmy się zminimalizować zmiany w specyfikacjach, by obniżyć barierę rozpowszechnienia. Szczegółowe informacje znajdziesz w artykule Reguły UICC.