Uprawnienia przewoźnika UICC

Android 5.1 wprowadził mechanizm przyznawania specjalnych uprawnień dla interfejsów API odpowiednich dla właścicieli aplikacji uniwersalnych kart z układami scalonymi (UICC). Platforma Android ładuje certyfikaty przechowywane w UICC i przyznaje aplikacjom podpisanym tymi certyfikatami uprawnienia do wykonywania wywołań kilku specjalnych interfejsów API.

System Android 7.0 rozszerzył tę funkcję o obsługę innych źródeł przechowywania dla reguł uprawnień operatora UICC, znacznie zwiększając liczbę operatorów, którzy mogą korzystać z interfejsów API. Dla odniesienia API, patrz CarrierConfigManager ; Odpowiednie instrukcje można znaleźć Carrier Configuration .

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 potrzeby do podpisywania aplikacji za pomocą certyfikatu platformy na urządzenie lub preinstalacji jako aplikacji systemowej.

Zasady dotyczące UICC

Składowanie na UICC jest kompatybilny z GlobalPlatform Bezpieczne specyfikację Element Access Control . Identyfikator aplikacji (AID) na karcie jest A00000015141434C00 , a średnia GET DATA Polecenie to służy do pobierania zasad zapisanych na karcie. Możesz zaktualizować te zasady poprzez aktualizacje kart OTA.

Hierarchia danych

Reguły UICC wykorzystują następującą hierarchię danych (dwuznakowa kombinacja liter i cyfr w nawiasach jest znacznikiem obiektu). Każda zasada REF-AR-DO ( E2 ) i składa się z konkatenacji REF-DO oraz AR-DO :

  • REF-DO ( E1 ) zawiera DeviceAppID-REF-DO lub konkatenacji DeviceAppID-REF-DO oraz PKG-REF-DO .
    • DeviceAppID-REF-DO ( C1 ) przechowuje SHA-1 (20 bajtów) lub SHA-256 (32 bajtów) podpis certyfikatu.
    • PKG-REF-DO ( CA ) to pełna nazwa pakietu ciąg określony w oczywistym, ASCII zakodowanego, długość max 127 bajtów.
  • AR-DO ( E3 ) jest rozszerzony PERM-AR-DO ( DB ), który jest bitem maski 8 bajtów, co stanowi 64 oddzielnych uprawnienia.

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

Przykład reguły

Nazwa aplikacja jest com.google.android.apps.myapp i certyfikat w ciąg szesnastkowy SHA-1 jest:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

Reguła UICC w ciągu szesnastkowym to:

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

Obsługa pliku reguł dostępu (ARF)

Android 7.0 dodaje obsługę odczytu reguł uprawnień operatora z pliku reguł dostępu (ARF).

Platformy Android Pierwsze próby wybrania reguły dostępu aplet (ARA) Identyfikator aplikacji (AID) A00000015141434C00 . Jeśli nie znajdzie pomocy na UICC, to wraca do ARF wybierając PKCS15 AID A000000063504B43532D3135 . Android następnie odczytuje plik zasad kontroli dostępu (ACRF) na 0x4300 i szuka wpisów z pomocą 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, zawierający mieszania certyfikat 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

Menedżer SMS

Sposób, aby umożliwić osobie dzwoniącej tworzyć nowe przychodzące wiadomości SMS: injectSmsPdu .

Menedżer konfiguracji przewoźnika

Sposób powiadamiania konfigurację Zmieniono: notifyConfigChangedForSubId . Aby uzyskać instrukcje, zobacz Carrier Configuration .

CarrierMessagingService

Usługa odbierająca połączenia z systemu po wysłaniu lub odebraniu nowych wiadomości SMS i MMS. Aby przedłużyć tę klasę, oświadczam usługę w swoim pliku manifestu z android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE zgody i obejmują zamiarem filtr z #SERVICE_INTERFACE działania. Metody obejmują:

Operator telefonii

Interfejsy API dostawcy treści umożliwiające modyfikacje (wstawianie, usuwanie, aktualizowanie, zapytania) bazy danych telefonii. Wartości pól są określone w Telephony.Carriers ; Więcej szczegółów można znaleźć w telefonii odniesienia API na developer.android.com.

Platforma Android

W przypadku wykrytego UICC platforma konstruuje wewnętrzne obiekty UICC, które zawierają reguły uprawnień operatora jako część UICC. UiccCarrierPrivilegeRules.java ładuje zasady, analizuje je z karty UICC i buforuje je w pamięci. Gdy potrzebna jest kontrola przywilej, UiccCarrierPrivilegeRules porównuje certyfikat rozmówcy z własnymi zasadami jeden po drugim. Jeśli UICC zostanie usunięty, reguły zostaną zniszczone wraz z obiektem UICC.

Walidacja

Aby sprawdzić poprawność wykonania przez Compatibility Test Suite (CTS) za pomocą CtsCarrierApiTestCases.apk , trzeba mieć UICC programistów z prawidłowymi zasadami UICC lub wsparcia ARF. Możesz poprosić wybranego dostawcę karty SIM o przygotowanie deweloperskiego UICC z odpowiednim ARF, jak opisano w tej sekcji, i użyć tego UICC do przeprowadzenia testów. UICC nie wymaga aktywnej usługi komórkowej, aby przejść testy CTS.

Przygotowanie UICC

Na Androida 11 i dolne, CtsCarrierApiTestCases.apk podpisuje aosp-testkey o wartości hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Począwszy Androida 12 CtsCarrierApiTestCases.apk podpisuje cts-uicc-2021-testkey wartości hash 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ć nośnik CTS testy API Androida 12, urządzenie musi korzystać z karty SIM z przywilejów nośne CTS spełniające wymogi określone w najnowszej wersji trzeciej GSMA TS.48 testowym Profile specyfikacji.

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

Modyfikowanie profilu CTS SIM

  1. Dodaj: Uprawnienia CTS przewoźnika w ARA-M lub ARF. Oba podpisy muszą być zakodowane w regułach 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. 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
  1. Utwórz: ADF USIM plików EF nie występuje w TS.48 i potrzebne dla CTS:
    1. EF_MBDN (6FC7), rozmiar rekordu: 28, numer rekordu: 4
      • Zadowolony
        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
  2. Zmienić USIM Tabela obsługa: Włączenie usługi n ° 47, n ° 48
    1. EF_UST (6F38)
      • Zawartość: 9EFFBF1DFFFE0083410310010400406E01
  3. AKTUALIZACJA: DF-5GS i DF-SAIP plików
    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
  4. AKTUALIZACJA: Carrier Name struny będą Android CTS w odpowiednich EF zawierających takie oznaczenie:
    1. EF_SPN (USIM/6F46)
      • Zawartość: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Zawartość: Rec1 430B83413759FE4E934143EA14FF..FF

Dopasowanie struktury profilu testowego

Pobierz i dopasować najnowszą wersję następujących struktur profilu podstawowego testowych. Profile te nie będą miały spersonalizowanej reguły CTS Carrier Privilege ani innych modyfikacji wymienionych powyżej.

Przeprowadzanie 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 przewoźnik API CTS obsługiwać urządzenie tokenu sim-card-with-certs . Na przykład, następujące urządzenie znacznik testów API ogranicza nośnych, tylko prowadzony na urządzeniu abcd1234 :

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

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

FAQ

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

O: Użyj istniejącego mechanizmu aktualizacji karty OTA.

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

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

Co się stanie, gdy UICC zostanie usunięty z aplikacji, która opiera się na zawartych w nim certyfikatach?

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

Czy istnieje limit liczby certyfikatów w UICC?

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

Czy istnieje ograniczenie liczby interfejsów API, które możemy obsługiwać tą metodą?

O: Nie, ale ograniczamy zakres do interfejsów API związanych z operatorem.

Czy niektóre interfejsy API nie mogą korzystać z tej metody? Jeśli tak, jak je egzekwujesz? (czyli czy masz testy do sprawdzenia, które interfejsy API są obsługiwane przez tę metodę?)

A: Patrz "API Behavioral Compatibility" w Dokumencie Definicja Android Compatibility (CDD) . Mamy kilka testów CTS, aby upewnić się, że model uprawnień interfejsów API nie uległ zmianie.

Jak to działa z funkcją multi-SIM?

O: Używana jest domyślna karta SIM określona przez użytkownika.

Czy to w jakikolwiek sposób oddziałuje lub pokrywa się z innymi technologiami dostępu SE, na przykład SEEK?

O: Jako przykład, SEEK używa tego samego AID, co w UICC. Więc współistnieją reguł i są filtrowane przez albo poszukiwać lub UiccCarrierPrivileges .

Kiedy jest dobry moment na sprawdzenie uprawnień 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 zestaw minimalny i planujemy w przyszłości używać maski bitowej do dokładniejszej kontroli szczegółowości.

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

A: Patrz wpisu SPN w TelephonyManager

Co oznacza injectSmsPdu wywołanie metody zrobić?

O: Ta metoda ułatwia tworzenie kopii zapasowych/przywracanie SMS-ów w chmurze. injectSmsPdu wywołanie aktywuje funkcję przywracania.

Do filtrowania wiadomości SMS, jest onFilterSms zadzwoń na podstawie filtrowanie portów SMS UDH? A może 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 wspierać 32 bajtów wydaje się być niezgodne z aktualną specyfikacją GP (co pozwala 0 lub 20 bajtów tylko), więc dlaczego wprowadzenie tej zmiany? Czy SHA-1 nie wystarczy, aby uniknąć kolizji? Czy zaproponowałeś już tę zmianę GP, ponieważ może to być wstecznie niekompatybilne z istniejącym ARA-M/ARF?

A: Dla zapewnienia przyszłościowe bezpieczeństwa, rozszerzenie to wprowadza SHA-256 dla DeviceAppID-REF-DO oprócz SHA-1, który jest obecnie jedynym rozwiązaniem w standardzie GP SEAC. Zdecydowanie zalecamy używanie SHA-256.

Jeśli DeviceAppID jest 0 (pusty), należy zastosować regułę do wszystkich apps urządzenia nie objęte zasadą konkretnego?

A: Carrier API wymagają DeviceAppID-REF-DO być wypełniane. Pusty jest przeznaczony do celów testowych i nie jest zalecany w przypadku wdrożeń operacyjnych.

W zależności od specyfikacji, PKG-REF-DO używany tylko przez siebie, bez DeviceAppID-REF-DO , nie powinny być akceptowane. Ale to jeszcze opisane w Tabeli 6-4 jako rozszerzenie definicji REF-DO . Czy to jest celowe? W jaki sposób zachowują się kod gdy tylko PKG-REF-DO jest używany w REF-DO ?

A: możliwość posiadania PKG-REF-DO w jednej pozycji wartości w REF-DO usunięto w najnowszej wersji. PKG-REF-DO powinno nastąpić jedynie w połączeniu z DeviceAppID-REF-DO .

Zakładamy, że możemy przyznać dostęp do wszystkich uprawnień opartych na przewoźniku 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 oddzielne uprawnienia wystarczą na dłuższą metę?

O: Jest to zarezerwowane na przyszłość i chętnie przyjmujemy sugestie.

Można dodatkowo zdefiniować DeviceAppID dla Androida konkretnie? 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 zastosowanie do wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).

A: DeviceAppID certyfikaty przechowywanie jest obsługiwana przez istniejący spec. Staraliśmy się zminimalizować zmiany specyfikacji, aby obniżyć barierę adopcji. Szczegółowe informacje można znaleźć przepisy dotyczące UICC .