Uprawnienia przewoźnika UICC

Android 5.1 wprowadził mechanizm nadawania specjalnych uprawnień dla interfejsów API odpowiednich dla właścicieli aplikacji Universal Integrated Circuit Card (UICC). Platforma Android ładuje certyfikaty przechowywane w UICC i zezwala aplikacjom podpisanym tymi certyfikatami na nawiązywanie połączeń z kilkoma specjalnymi interfejsami API.

Android 7.0 rozszerzył tę funkcję, aby obsługiwała inne źródła przechowywania dla reguł uprawnień przewoźników UICC, radykalnie zwiększając liczbę operatorów, którzy mogą korzystać z interfejsów API. Aby uzyskać informacje dotyczące interfejsu API, zobacz CarrierConfigManager ; instrukcje znajdziesz w części Konfiguracja operatora .

Operatorzy mają pełną kontrolę nad UICC, więc ten mechanizm zapewnia bezpieczny i elastyczny sposób zarządzania aplikacjami od operatora sieci komórkowej (MNO) hostowanymi w ogólnych kanałach dystrybucji aplikacji (takich jak Google Play) przy zachowaniu specjalnych uprawnień na urządzeniach i bez konieczności podpisywać aplikacje certyfikatem platformy dla poszczególnych urządzeń lub preinstalować jako aplikację systemową.

Regulamin UICC

Przechowywanie 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. Możesz zaktualizować te zasady za pomocą aktualizacji kart OTA.

Hierarchia danych

Reguły UICC wykorzystują następującą hierarchię danych (kombinacja dwuznakowej litery i cyfry w nawiasach to znacznik obiektu). Każda reguła to REF-AR-DO ( E2 ) i składa się z konkatenacji 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łna nazwa pakietu zdefiniowana w manifeście, zakodowana w formacie ASCII, o maksymalnej długości 127 bajtów.
  • AR-DO ( E3 ) jest rozszerzony o PERM-AR-DO ( DB ), który jest 8-bajtową maską bitową reprezentującą 64 oddzielne uprawnienia.

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

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 na UICC w łańcuchu 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 dodaje obsługę odczytu reguł uprawnień operatora z pliku reguł dostępu (ARF).

Platforma Android najpierw próbuje wybrać aplikację reguły dostępu (ARA) AID A00000015141434C00 . Jeśli nie znajdzie AID w UICC, powraca do ARF, wybierając PKCS15 AID A000000063504B43532D3135 . Następnie Android odczytuje plik reguł kontroli dostępu (ACRF) pod adresem 0x4300 i szuka wpisów z AID FFFFFFFFFFFF . Wpisy z różnymi AID są ignorowane, więc reguły dla innych przypadków użycia 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 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 powyższym przykładzie 0x4310 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Aplikacje podpisane tym certyfikatem otrzymują uprawnienia operatora.

Włączone interfejsy API

Android obsługuje następujące interfejsy API.

Menedżer telefonii

Telefonia Oddzwanianie

TelephonyCallback ma interfejsy z metodą wywołania zwrotnego, które powiadamiają aplikację wywołującą o zmianie zarejestrowanych stanów:

Menedżer subskrypcji

Menedżer SMS-ów

CarrierConfigManager

Aby uzyskać instrukcje, zobacz Konfiguracja operatora .

Menedżer raportów błędów

Metoda uruchamiania raportu o błędzie łączności, która jest wyspecjalizowaną wersją raportu o błędzie, która zawiera tylko informacje dotyczące debugowania problemów związanych z łącznością: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

Menedżer obsługi administracyjnej

Menedżer Euicc

Metoda przełączenia na (włączenia) danej subskrypcji: switchToSubscription

CarrierMessagingService

Usługa, która odbiera połączenia z systemu, gdy nowe wiadomości SMS i MMS są wysyłane lub odbierane. Aby rozszerzyć tę klasę, zadeklaruj usługę w swoim pliku manifestu z uprawnieniem android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE i dołącz filtr intencji do akcji #SERVICE_INTERFACE . Metody obejmują:

  • Metoda filtrowania przychodzących wiadomości SMS: onFilterSms
  • Metoda przechwytywania wiadomości tekstowych SMS wysyłanych z urządzenia: onSendTextSms
  • Metoda przechwytywania binarnych wiadomości SMS wysyłanych z urządzenia: onSendDataSms
  • Metoda przechwytywania długich wiadomości SMS wysyłanych z urządzenia: onSendMultipartTextSms
  • Metoda przechwytywania wiadomości MMS wysyłanych z urządzenia: onSendMms
  • Metoda pobierania otrzymanych wiadomości MMS: onDownloadMms

Usługa Przewoźnika

Usługa udostępniająca systemowi funkcje charakterystyczne dla przewoźnika. Aby rozszerzyć tę klasę, zadeklaruj usługę w pliku manifestu aplikacji z uprawnieniem android.Manifest.permission#BIND_CARRIER_SERVICES i dołącz filtr intencji do akcji CARRIER_SERVICE_INTERFACE . Jeśli usługa ma długotrwałe powiązanie, ustaw android.service.carrier.LONG_LIVED_BINDING na true w metadanych usługi.

Platforma wiąże CarrierService ze specjalnymi flagami, aby proces obsługi przewoźnika przebiegał w specjalnej rezerwowej aplikacji . Zwalnia to aplikację usługi operatora z ograniczeń bezczynności aplikacji i zwiększa prawdopodobieństwo, że pozostanie ona aktywna, gdy pamięć urządzenia jest niska. Jeśli jednak aplikacja usługi przewoźnika ulegnie awarii z jakiegokolwiek powodu, utraci wszystkie powyższe uprawnienia do czasu ponownego uruchomienia aplikacji i przywrócenia powiązania. Dlatego bardzo ważne jest, aby aplikacja usługi przewoźnika była stabilna.

Metody w CarrierService obejmują:

  • Aby zastąpić i ustawić konfiguracje specyficzne dla przewoźnika: onLoadConfig
  • Aby poinformować system o zamierzonej zbliżającej się zmianie sieci operatora przez aplikację operatora: notifyCarrierNetworkChange

Dostawca telefonii

Interfejsy API dostawców treści umożliwiające modyfikacje (wstawianie, usuwanie, aktualizowanie, wysyłanie zapytań) do bazy danych telefonii. Pola wartości są zdefiniowane w Telephony.Carriers ; Aby uzyskać więcej informacji, zapoznaj się z odwołaniem do klasy Telephony

Sugestia dotycząca sieci Wi-Fi

Podczas tworzenia obiektu WifiNetworkSuggestion użyj następujących metod, aby ustawić identyfikator subskrypcji lub grupę subskrypcji:

Platforma Androida

Na wykrytym UICC platforma konstruuje wewnętrzne obiekty UICC, które zawierają reguły uprawnień przewoźnika jako część UICC. UiccCarrierPrivilegeRules.java ładuje reguły, analizuje je z karty UICC i zapisuje w pamięci podręcznej. Gdy wymagane jest sprawdzenie uprawnień, UiccCarrierPrivilegeRules porównuje certyfikat osoby dzwoniącej z własnymi regułami jeden po drugim. Jeśli UICC zostanie usunięty, reguły zostaną zniszczone wraz z obiektem UICC.

Walidacja

Aby zweryfikować implementację za pomocą pakietu testów zgodności (CTS) przy użyciu CtsCarrierApiTestCases.apk , musisz mieć dewelopera UICC z poprawnymi regułami UICC lub obsługą ARF. Poproś wybranego sprzedawcę karty SIM o przygotowanie deweloperskiego UICC z odpowiednim ARF zgodnie z opisem w tej sekcji i użycie tego UICC do przeprowadzenia testów. UICC nie wymaga aktywnej usługi komórkowej, aby przejść testy CTS.

Przygotuj UICC

W przypadku systemu Android 11 i niższych plik CtsCarrierApiTestCases.apk jest 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 .

Począwszy od systemu Android 12, 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 uruchomić testy CTS Carrier API w systemie Android 12, urządzenie musi korzystać z karty SIM z uprawnieniami CTS CTS, spełniającej wymagania określone w najnowszej wersji specyfikacji profilu testowego GSMA TS.48 innej firmy.

Ta sama karta SIM może być również używana w wersjach starszych niż Android 12.

Modyfikowanie profilu CTS SIM

  1. Dodaj: uprawnienia przewoźnika CTS w masterze aplikacji reguł dostępu (ARA-M) lub ARF. Oba podpisy muszą być zakodowane w zasadach uprawnień przewoźnika:
    1. 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. 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 ADF USIM (EF) nieobecne w TS.48 i potrzebne do CTS:
    1. EF_MBDN (6FC7), rozmiar rekordu: 28, numer rekordu: 4
      • Treść
        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. Modyfikuj: Tabela usług USIM: Włącz usługi nr 47, nr 48
    1. EF_UST (6F38)
      • Treść: 9EFFBF1DFFFE0083410310010400406E01
  4. Zmodyfikuj: 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 nazwy przewoźnika 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

Dopasowanie struktury profilu testowego

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

Uruchamianie 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 Carrier API CTS obsługują token urządzenia sim-card-with-certs . Na przykład następujący token urządzenia ogranicza testy interfejsu API przewoźnika do uruchamiania tylko na urządzeniu abcd1234 :

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

W przypadku uruchamiania testu bez użycia tokena urządzenia test jest uruchamiany na wszystkich urządzeniach.

Często zadawane pytania

W jaki sposób można aktualizować certyfikaty w UICC?

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

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

Odp.: Dobrze jest mieć inne zasady bezpieczeństwa w UICC w ramach tego samego AID; platforma odfiltrowuje je automatycznie.

Co się stanie, gdy UICC zostanie usunięty z aplikacji korzystającej z zawartych w nim certyfikatów?

O: Aplikacja traci swoje uprawnienia, ponieważ zasady związane z UICC są niszczone podczas usuwania UICC.

Czy istnieje limit liczby certyfikatów na UICC?

O: Platforma nie ogranicza liczby certyfikatów; ale ponieważ kontrola jest liniowa, zbyt wiele reguł może powodować opóźnienia w sprawdzaniu.

Czy istnieje ograniczenie 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 operatorem.

Czy istnieją interfejsy API, których nie wolno używać tej metody? Jeśli tak, jak je egzekwować? (to znaczy, czy masz testy sprawdzające, które interfejsy API są obsługiwane za pomocą tej metody?)

Odp.: Zobacz sekcję Zgodność behawioralna interfejsu API dokumentu definicji zgodności z systemem Android (CDD). Mamy kilka testów CTS, aby upewnić się, że model uprawnień API nie został zmieniony.

Jak to działa z funkcją 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ę lub pokrywa się z innymi technologiami dostępu SE, na przykład SEEK?

O: Na przykład SEEK używa tego samego AID, co w UICC. Tak więc reguły współistnieją i są filtrowane przez SEEK lub UiccCarrierPrivileges .

Kiedy warto sprawdzić uprawnienia przewoźnika?

Odp.: po załadowaniu stanu karty SIM.

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

O: Nie. Uważamy, że obecne interfejsy API to minimalny zestaw i planujemy użyć maski bitowej do dokładniejszej kontroli ziarnistości w przyszłości.

Czy setOperatorBrandOverride zastępuje WSZYSTKIE inne formy ciągów nazw operatorów? Na przykład SE13, UICC SPN lub sieciowy NITZ?

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

Co robi wywołanie metody injectSmsPdu ?

O: Ta metoda ułatwia tworzenie kopii zapasowych/przywracanie wiadomości SMS w chmurze. Wywołanie injectSmsPdu włącza funkcję przywracania.

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

O: 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 dopuszcza tylko 0 lub 20 bajtów), więc dlaczego wprowadzacie tę zmianę? Czy SHA-1 nie wystarczy, aby uniknąć kolizji? Czy zaproponowałeś już tę zmianę GP, ponieważ może to być wstecznie niezgodne z istniejącym ARA-M/ARF?

O: Aby zapewnić bezpieczeństwo na przyszłość, 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 korzystanie z algorytmu SHA-256.

Jeśli DeviceAppID ma wartość 0 (puste), czy stosujesz regułę do wszystkich aplikacji urządzenia nieobjętych określoną regułą?

O: Interfejsy API Carrier wymagają wypełnienia DeviceAppID-REF-DO . Pusta jest przeznaczona do celów testowych i nie jest zalecana w przypadku wdrożeń operacyjnych.

Zgodnie z twoją specyfikacją, PKG-REF-DO używany sam w sobie, bez DeviceAppID-REF-DO , nie powinien być akceptowany. Ale nadal jest to opisane w tabeli 6-4 specyfikacji jako rozszerzenie definicji REF-DO . Czy to jest celowe? Jak zachowuje się kod, gdy w REF-DO PKG-REF-DO -DO?

O: Opcja posiadania PKG-REF-DO jako pozycji o pojedynczej wartości w REF-DO została usunięta w najnowszej wersji. PKG-REF-DO powinien występować tylko w połączeniu z DeviceAppID-REF-DO .

Zakładamy, że możemy przyznać dostęp do wszystkich uprawnień opartych na operatorach lub mieć bardziej szczegółową kontrolę. Jeśli tak, co definiuje mapowanie między maską bitową a rzeczywistymi uprawnieniami? Jedno pozwolenie na klasę? Jedno pozwolenie na metodę? Czy 64 osobne uprawnienia wystarczą na dłuższą metę?

O: Jest to zarezerwowane na przyszłość i czekamy na sugestie.

Czy możesz dokładniej zdefiniować DeviceAppID dla Androida? To jest 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 ma wtedy zastosowanie do wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).

O: Certyfikaty przechowywania DeviceAppID są obsługiwane przez istniejącą specyfikację. Staraliśmy się zminimalizować zmiany specyfikacji, aby obniżyć barierę adopcji. Aby uzyskać szczegółowe informacje, zobacz Zasady dotyczące UICC .