Przywileje przewoźnika UICC

W Androidzie 5.1 wprowadzono mechanizm nadawania specjalnych uprawnień dla interfejsów API odpowiednich dla właścicieli aplikacji na uniwersalne karty scalone (UICC). Platforma Android ładuje certyfikaty przechowywane w UICC i udziela aplikacjom podpisanym tymi certyfikatami uprawnień do wykonywania wywołań do kilku specjalnych interfejsów API.

W systemie Android 7.0 rozszerzono tę funkcję, aby obsługiwała inne źródła przechowywania reguł przywilejów operatora UICC, radykalnie zwiększając liczbę operatorów, którzy mogą korzystać z interfejsów API. Informacje na temat interfejsu API można znaleźć w artykule CarrierConfigManager ; instrukcje znajdziesz w 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 do podpisywania aplikacji certyfikatem platformy dla poszczególnych urządzeń lub preinstalowania jako aplikacji systemowej.

Regulamin UICC

Przechowywanie w UICC jest zgodne ze specyfikacją GlobalPlatform Secure Element Access Control . Identyfikator aplikacji (AID) na karcie to A00000015141434C00 , a do pobrania reguł przechowywanych na karcie służy standardowe polecenie GET DATA . Możesz zaktualizować te zasady poprzez aktualizacje kart OTA.

Hierarchia danych

Reguły UICC wykorzystują następującą hierarchię danych (dwuznakowa kombinacja litery i cyfry w nawiasach to znacznik 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 manifeście, zakodowana w formacie ASCII, o maksymalnej długości 127 bajtów.
  • AR-DO ( E3 ) zostało rozszerzone o PERM-AR-DO ( DB ), które jest 8-bajtową maską bitową reprezentującą 64 oddzielne uprawnienia.

Jeśli nie ma PKG-REF-DO , dostęp uzyska każda aplikacja podpisana certyfikatem; 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 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

W systemie Android 7.0 dodano obsługę odczytywania 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, wraca do ARF, wybierając PKCS15 AID A000000063504B43532D3135 . Następnie system Android odczytuje plik reguł kontroli dostępu (ACRF) pod 0x4300 i szuka wpisów o identyfikatorze AID FFFFFFFFFFFF . Wpisy z różnymi identyfikatorami 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 to adres ACCF, który zawiera skrót 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 otrzymują uprawnienia operatora.

Włączone interfejsy API

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

Menedżer telefonii

TelefoniaOddzwonienie

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

Menedżer subskrypcji

Menedżer sms

Menedżer konfiguracji przewoźnika

Aby uzyskać instrukcje, zobacz Konfiguracja operatora .

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

Metoda uruchamiania raportu o błędach łączności, która jest wyspecjalizowaną wersją raportu o błędach zawierającą tylko informacje umożliwiające debugowanie problemów związanych z łącznością: startConnectivityBugreport

Menedżer statystyk sieci

ImsMmTelManager

Menedżer ImsRcs

Menedżer zaopatrzenia

Menedżer Euicc

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

Usługa przesyłania wiadomości przewoźnika

Usługa odbierająca połączenia z systemu w przypadku wysłania lub odebrania nowych wiadomości SMS i MMS. Aby rozszerzyć tę klasę, zadeklaruj usługę w pliku manifestu z uprawnieniem android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE i dołącz filtr intencji za pomocą 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 odebranych wiadomości MMS: onDownloadMms

Usługa przewoźnika

Usługa udostępniająca systemowi funkcje specyficzne dla operatora. Aby rozszerzyć tę klasę, zadeklaruj usługę w pliku manifestu aplikacji z uprawnieniem android.Manifest.permission#BIND_CARRIER_SERVICES i dołącz filtr intencji za pomocą 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 operatora mógł działać w specjalnym zasobniku gotowości aplikacji . Zwalnia to aplikację usługi operatora z ograniczeń bezczynności aplikacji i zwiększa prawdopodobieństwo, że pozostanie aktywna, gdy w urządzeniu będzie mało pamięci. Jeśli jednak aplikacja usługi operatora ulegnie awarii z jakiegokolwiek powodu, utraci wszystkie powyższe uprawnienia do czasu ponownego uruchomienia aplikacji i ponownego ustanowienia powiązania. Dlatego tak ważne jest, aby aplikacja usługi operatora 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 za pomocą aplikacji operatora: notifyCarrierNetworkChange

Dostawca telefonii

Interfejsy API dostawców treści umożliwiające modyfikacje (wstawianie, usuwanie, aktualizacja, wysyłanie zapytań) do telefonicznej bazy danych. Pola wartości są zdefiniowane w Telephony.Carriers ; Więcej szczegółów można znaleźć w dokumentacji 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 przywilejów przewoźnika w ramach UICC. UiccCarrierPrivilegeRules.java ładuje reguły, analizuje je z karty UICC i buforuje w pamięci. Gdy konieczna jest kontrola uprawnień, UiccCarrierPrivilegeRules porównuje certyfikat wywołującego 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ć programistę UICC z poprawnymi regułami UICC lub obsługą ARF. Poproś wybranego dostawcę karty SIM o przygotowanie UICC dla programistów z odpowiednim ARF, jak opisano w tej sekcji, i użyj tego UICC do uruchomienia testów. UICC nie wymaga aktywnej usługi komórkowej, aby przejść testy CTS.

Przygotuj UICC

W przypadku Androida 11 i starszych wersji 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 Androida 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 API operatora CTS w systemie Android 12, urządzenie musi korzystać z karty SIM z uprawnieniami operatora CTS spełniającej wymagania określone w najnowszej wersji specyfikacji profilu testowego GSMA TS.48 innej firmy.

Tej samej karty SIM można używać także w wersjach wcześniejszych niż Android 12.

Modyfikowanie profilu karty SIM CTS

  1. Dodaj: uprawnienia operatora CTS w głównym aplikacji reguł dostępu (ARA-M) lub ARF. Obydwa podpisy muszą być zakodowane w zasadach uprawnień przewoźnika:
    1. Hash1(SHA1) 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), których nie ma w TS.48 i są potrzebne dla 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. Modyfikuj: 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 operatora 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 spersonalizowanych zasad uprawnień przewoźnika CTS ani innych modyfikacji wymienionych powyżej.

Uruchamianie testów

Dla wygody CTS obsługuje token urządzenia, który ogranicza uruchamianie testów 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 API operatora do uruchamiania tylko na urządzeniu abcd1234 :

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

W przypadku uruchomienia testu bez użycia tokena urządzenia, test zostanie uruchomiony na wszystkich urządzeniach.

Często zadawane pytania

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

Odp.: Skorzystaj z istniejącego mechanizmu aktualizacji OTA karty.

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

O: Nie ma nic złego w posiadaniu innych zasad bezpieczeństwa w UICC w ramach tego samego AID; platforma automatycznie je odfiltrowuje.

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

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

Czy istnieje ograniczenie liczby certyfikatów w UICC?

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

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

Odpowiedź: 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, jak je egzekwować? (to znaczy, czy masz testy sprawdzające, które interfejsy API są obsługiwane w przypadku tej metody?)

Odp.: Zobacz sekcję dotyczącą zgodności behawioralnej API w dokumencie definicji zgodności systemu Android (CDD). Przeprowadziliśmy kilka testów CTS, aby upewnić się, że model uprawnień interfejsów API nie ulegnie zmianie.

Jak to działa z funkcją wielu kart SIM?

Odp.: 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. Zatem reguły współistnieją i są filtrowane według SEEK lub UiccCarrierPrivileges .

Kiedy warto sprawdzić uprawnienia operatora?

Odp.: po załadowaniu transmisji stanu karty SIM.

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

O: Nie. Uważamy, że obecne interfejsy API to zestaw minimalny i planujemy używać maski bitowej w celu zapewnienia większej szczegółowoś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, zastąpienie marki operatora ma najwyższy priorytet. Gdy jest ustawiona, zastępuje WSZYSTKIE inne formy ciągów nazw operatorów.

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

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

Czy w przypadku filtrowania wiadomości SMS połączenie onFilterSms opiera się na filtrowaniu portów SMS UDH? A może aplikacje operatora mają dostęp do WSZYSTKICH przychodzących SMS-ów?

Odp.: 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 wprowadzasz tę zmianę? Czy SHA-1 nie wystarczy, aby uniknąć kolizji? Czy proponowałeś już tę zmianę GP, ponieważ mogłaby ona być wstecznie niekompatybilna z istniejącym ARA-M/ARF?

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

Jeśli DeviceAppID ma wartość 0 (pusty), czy stosujesz regułę do wszystkich aplikacji na urządzeniu, które nie są objęte konkretną regułą?

Odp.: Interfejsy API operatora wymagają wypełnienia DeviceAppID-REF-DO . Pusta wartość 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, 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 PKG-REF-DO REF-DO ?

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

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

Odpowiedź: Jest to zarezerwowane na przyszłość i jesteśmy otwarci na sugestie.

Czy możesz dokładniej zdefiniować DeviceAppID dla 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 ma wówczas zastosowanie do wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).

O: Certyfikaty przechowujące 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 na UICC .