UICC Carrier Privileges

Android 5.1 wprowadził mechanizm przyznawania specjalnych przywilejów dla APIsrelevant to the owners of universal integrated circuit card (UICC) apps. TheAndroid platforma ładuje certyfikaty przechowywane na UICC i udziela pozwolenia na aplikacje podpisane przez te certyfikaty do wykonywania połączeń do kilku specjalnych API.

Android 7.0 rozszerzył tę funkcję do obsługi innych źródeł przechowywania dla UICCcarrier zasady przywilejów, dramatycznie zwiększając liczbę przewoźników, którzy mogą korzystać z interfejsów API. Odwołanie do API można znaleźć w CarrierConfigManager, a instrukcje w CarrierConfiguration.

Przewoźnicy 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 na ogólnych kanałach dystrybucji aplikacji (takich jak Google Play), zachowując specjalne uprawnienia na urządzeniach i bez potrzeby podpisywania aplikacji certyfikatem platformy per-urządzenie lub preinstalowania jako aplikacja systemowa.

Reguły dotyczące UICC

Przechowywanie danych na UICC jest zgodne ze specyfikacjąGlobalPlatformSecure Element Access Control. Identyfikator aplikacji (AID) na karcie to A00000015141434C00, a standardowe polecenieGET DATA jest używane do pobierania reguł przechowywanych na karcie. Reguły te można aktualizować poprzez aktualizacje OTA (over-the-air) karty.

Hierarchia danych

Reguły UICC używają następującej hierarchii danych (dwuznakowa kombinacja litery i liczby w nawiasie to znacznik obiektu). Każda reguła jestREF-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łny łańcuch nazwy pakietu określony w manifeście, zakodowany w ASCII, maksymalna długość 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 PKG-REF-DO nie jest obecny, każda aplikacja podpisana przez certyfikat ma przyznany 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 certyfikatSHA-1 w łańcuchu heksadecymalnym 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 heksadecymalnym to:

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

Plik reguł dostępu (ARF) obsługuje

Android 7.0 dodaje wsparcie dla odczytu reguł uprawnień przewoźnika z pliku accessrule (ARF).

Platforma Android najpierw próbuje wybrać aplet reguł dostępu (ARA)identyfikator aplikacji (AID) A00000015141434C00. Jeśli nie znajdzie AID na UICC, powraca do ARF wybierając PKCS15 AIDA000000063504B43532D3135. 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, a wpisy dla innych przypadków użycia mogą współistnieć.

Przykładowa zawartość ACRF w łańcuchu heksadecymalnym:

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 jest adresem dla ACCF, który zawiera hash certyfikatu61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Aplikacje podpisane tym certyfikatem mają przyznane uprawnienia przewoźnika.

Uruchomione interfejsy API

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

TelephonyManager

• Metoda umożliwiająca aplikacji przewoźnika zwrócenie się do UICC o wyzwanie/odpowiedź:getIccAuthentication.
• Metoda sprawdzająca, czy aplikacji wywołującej przyznano uprawnienia przewoźnika:hasCarrierPrivileges.
• Metody zastępowania marki i numeru:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• Metody bezpośredniej komunikacji UICC:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• Metody ustawiania trybu urządzenia na globalny:setPreferredNetworkTypeToGlobal.

SmsManager

Metoda pozwalająca rozmówcy na tworzenie nowych przychodzących wiadomości SMS: injectSmsPdu.

CarrierConfigManager

Metoda powiadamiania o zmianie konfiguracji: notifyConfigChangedForSubId. Aby uzyskać instrukcje, zobacz Konfiguracja przewoźnika.

CarrierMessagingService

Usługa, która odbiera wywołania 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 z działaniem #SERVICE_INTERFACE. Metody obejmują:

• onFilterSms
• onSendTextSms
• onSendDataSms
• onSendMultipartTextSms
• onSendMms
• onDownloadMms

Dostawca telefonii

Podstawowe API dostawcy treści umożliwiające modyfikacje (wstawianie, usuwanie, aktualizacja, zapytania)do bazy danych telefonii. Pola wartości są zdefiniowane wTelephony.Carriers; aby uzyskać więcej szczegółów, zapoznaj się z odniesieniem do API telefonii na stronie developer.android.com.

Platforma Android

Na wykrytym urządzeniu UICC platforma konstruuje wewnętrzne obiekty UICC, które zawierają reguły przywilejów przewoźnika jako część urządzenia UICC.UiccCarrierPrivilegeRules.javaWczytuje reguły, parsuje je z karty UICC i buforuje w pamięci. Gdy potrzebne jest sprawdzenie uprawnień, UiccCarrierPrivilegeRules porównuje certyfikat dzwoniącego z własnymi regułami, jedna po drugiej. Jeśli UICC zostanie usunięte, reguły są niszczone wraz z obiektem UICC.

Weryfikacja

W pakiecie Compatibility Test Suite (CTS) znajdują się testy dla API nośnika wCtsCarrierApiTestCases.apk. Ponieważ ta funkcja zależy od certyfikatów na UICC, musisz przygotować UICC do przejścia tych testów.

Przygotowanie UICC

Domyślnie, CtsCarrierApiTestCases.apk jest podpisany przez klucz Androiddeveloper, z wartością hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Testy wypisują również oczekiwany hash certyfikatu, jeśli certyfikaty na UICC się nie zgadzają.

Przykładowe dane wyjściowe:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

Aby zatwierdzić implementację poprzez CTS używającCtsCarrierApiTestCases.apk, musisz mieć deweloperski UICC z poprawnymi regułami UICC lub wsparciem ARF. Możesz poprosić sprzedawcę 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.

Running tests

Dla wygody, CTS obsługuje token urządzenia, który ogranicza testy do uruchomienia tylko na urządzeniach skonfigurowanych z tym samym tokenem. Testy CTS Carrier API obsługują token urządzenia sim-card-with-certs. Na przykład poniższy token urządzenia ogranicza testy API przewoźnika do uruchamiania tylko na urządzeniuabcd1234:

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

W przypadku uruchomienia testu bez użycia tokena urządzenia, test działa na wszystkich urządzeniach.

FAQ

Jak można aktualizować certyfikaty w UICC?

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

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

A: Dobrze jest mieć inne reguły bezpieczeństwa na UICC pod tym samym AID; platforma filtruje je automatycznie.

Co się stanie, gdy UICC zostanie usunięty dla aplikacji, która polega na certyfikatach na nim zawartych?

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

Czy istnieje ograniczenie liczby certyfikatów na UICC?

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

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

A: Nie, ale ograniczamy zakres do interfejsów API związanych z przewoźnikami.

Czy są jakieś interfejsy API, które nie mogą korzystać z tej metody? Jeśli tak, to jak je egzekwujesz? (to znaczy, czy masz testy sprawdzające, które API są obsługiwane za pomocą tej metody?)

A: Zobacz sekcję „Kompatybilność behawioralna API” w dokumencie CDD (Android Compatibility DefinitionDocument). Mamy kilka testów CTS, aby upewnić się, że model uprawnień API nie jest zmieniony.

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

A: Domyślna karta SIM określona przez użytkownika jest używana.

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

A: Jako przykład, SEEK używa tego samego AID, co na UICC. Więc zasadyco-istnieją i są filtrowane przez SEEK lub UiccCarrierPrivileges.

Kiedy jest dobry czas, aby sprawdzić uprawnienia przewoźnika?

A: Po SIM stan załadowany transmisji.

Czy OEMs wyłączyć część API przewoźnika?

A: Nie. Wierzymy, że obecne API są minimalnym zestawem i planujemy użyć maski bitowej do dokładniejszej kontroli granularności w przyszłości.

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

A: Odwołaj się do wpisu SPN wTelephonyManager

Co robi wywołanie metody injectSmsPdu?

A: Ta metoda ułatwia tworzenie kopii zapasowych/przywracanie wiadomości SMS w chmurze. TheinjectSmsPdu call enables the restore function.

For SMS filtering, is the onFilterSms call based onSMS UDH port filtering? Czy też aplikacje operatora mają dostęp do WSZYSTKICH przychodzących wiadomości SMS?

A: Operatorzy mają dostęp do wszystkich danych SMS.

Rozszerzenie DeviceAppID-REF-DO o obsługę 32 bajtów wydaje się być niezgodne z obecną specyfikacją GP (która pozwala tylko na 0 lub 20 bajtów), więc dlaczego wprowadzacie tę zmianę? Czy SHA-1 nie jest wystarczające, aby uniknąć kolizji? Czy zaproponowałeś już tę zmianę w GP, ponieważ może to być wstecznie niezgodne z istniejącymi ARA-M/ARF?

A: Aby zapewnić bezpieczeństwo w przyszłości, 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 używanie SHA-256.

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

A: Interfejsy API przewoźników wymagają, aby DeviceAppID-REF-DO był wypełniony. Pusty jest przeznaczony do celów testowych i nie jest zalecany do 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 opisany w tabeli 6-4 jako rozszerzający definicjęREF-DO. Czy jest to zamierzone? Jak zachowuje się kod, gdy tylko PKG-REF-DO jest używany w REF-DO?

A: Opcja posiadania PKG-REF-DO jako pojedynczego elementu 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 udzielić dostępu do wszystkich uprawnień opartych na nośnikach lub mieć kontrolę drobnoziarnistą. Jeśli tak, to co definiuje mapowanie pomiędzy maską bitową a rzeczywistymi uprawnieniami? Jedno uprawnienie na klasę? Jedno uprawnienie na metodę? Czy 64 oddzielne uprawnienia wystarczą na dłuższą metę?

A: To jest zarezerwowane na przyszłość i mile widziane sugestie.

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

A: DeviceAppID przechowywanie certyfikatów jest obsługiwane przez istniejącą specyfikację. Staraliśmy się zminimalizować zmiany specyfikacji, aby obniżyć barierę dla adopcji. Aby uzyskać szczegółowe informacje, zobacz Reguły dotyczące UICC.