Identyfikatory urządzeń

Android 10 zmienia uprawnienia dotyczące identyfikatorów urządzeń, dzięki czemu wszystkie identyfikatory urządzeń są teraz chronione uprawnieniem READ_PRIVILEGED_PHONE_STATE . W READ_PHONE_STATE niż Android 10 trwałe identyfikatory urządzeń (IMEI / MEID, IMSI, SIM i numer seryjny kompilacji) były chronione za uprawnieniem środowiska wykonawczego READ_PHONE_STATE . Uprawnienie READ_PRIVILEGED_PHONE_STATE jest przyznawane tylko aplikacjom podpisanym kluczem platformy i uprzywilejowanym aplikacjom systemowym.

Więcej informacji na temat nowych wymagań dotyczących uprawnień można znaleźć na stronach Javadoc dla TelephonyManager.java i Build.java .

Ta zmiana dotyczy następujących interfejsów API:

  • TelephonyManager # getDeviceId
  • TelephonyManager # getImei
  • TelephonyManager # getMeid
  • TelephonyManager # getSimSerialNumber
  • TelephonyManager # getSubscriberId
  • Kompilacja # getSerial

Dostęp do aplikacji przewoźnika bez uprawnienia READ_PRIVILEGED_PHONE_STATE

Wstępnie załadowane aplikacje przewoźnika, które nie kwalifikują się do uprawnienia READ_PRIVILEGED_PHONE_STATE mogą zaimplementować jedną z opcji przedstawionych w poniższej tabeli.

Opcja Opis Ograniczenia
Przywileje przewoźników UICC Platforma Android ładuje certyfikaty przechowywane na UICC i przyznaje aplikacjom podpisanym przez te certyfikaty uprawnienia do wywoływania metod specjalnych. Starsi operatorzy mają dużą, ugruntowaną populację kart SIM, której nie można łatwo zaktualizować. Ponadto operatorzy, którzy nie mają praw autorskich do nowych kart SIM (na przykład MVNO, którzy mają karty SIM wydane przez operatorów MNO) nie mogą dodawać ani aktualizować certyfikatów na kartach SIM.
Biała lista OEM OP_READ_DEVICE_IDENTIFIER OEM mogą używać OP_READ_DEVICE_IDENTIFIER do dostarczania identyfikatorów urządzeń aplikacjom operatora umieszczonym na białej liście. To rozwiązanie nie jest skalowalne dla wszystkich przewoźników.
Kod przydziału typu (TAC) Użyj metody getTypeAllocationCode wprowadzonej w systemie Android 10, aby udostępnić TAC, który zwraca informacje o producencie i modelu. Informacje zawarte w TAC są niewystarczające, aby zidentyfikować określone urządzenie.
MSISDN Operatorzy mogą korzystać z numeru telefonu (MSISDN), dostępnego w TelephonyManager z grupą uprawnień PHONE , aby wyszukać numer IMEI w swoich systemach zaplecza. Wymaga to znacznych inwestycji dla przewoźników. Operatorzy, którzy mapują swoje klucze sieciowe za pomocą IMSI, wymagają znacznych zasobów technicznych, aby przejść na MSISDN .

Wszystkie aplikacje operatora mogą uzyskać dostęp do identyfikatorów urządzeń, aktualizując plik CarrierConfig.xml za pomocą skrótu certyfikatu podpisywania aplikacji operatora. Gdy aplikacja operatora wywołuje metodę odczytu uprzywilejowanych informacji, platforma szuka zgodności skrótu certyfikatu podpisującego aplikację (podpis certyfikatu SHA-1 lub SHA-256) w pliku CarrierConfig.xml . W przypadku znalezienia dopasowania zwracane są żądane informacje. Jeśli nie zostanie znalezione dopasowanie, zwracany jest wyjątek bezpieczeństwa.

Aby wdrożyć to rozwiązanie, przewoźnicy MUSZĄ wykonać następujące kroki:

  1. Zaktualizuj CarrierConfig.xml certyfikatu podpisywania aplikacji przewoźnika i prześlij poprawkę .
  2. Poproś producentów OEM o zaktualizowanie kompilacji za pomocą QPR1 + (zalecane) LUB te wymagane łatki platformy i łatkę zawierającą zaktualizowany plik CarrierConfig.xml z kroku 1 powyżej.

Realizacja

Zaktualizuj swoją białą listę uprzywilejowanych uprawnień, aby przyznać uprawnienie READ_PRIVILEGED_PHONE_STATE tym uprzywilejowanym aplikacjom, które wymagają dostępu do identyfikatorów urządzeń.

Aby dowiedzieć się więcej o białej liście, zapoznaj się z Białą listą uprawnień uprzywilejowanych .

Aby wywołać interfejsy API, których dotyczy problem, aplikacja musi spełniać jeden z następujących wymagań:

  • Jeśli aplikacja jest wstępnie załadowaną uprzywilejowaną aplikacją, wymaga uprawnienia READ_PRIVILEGED_PHONE_STATE zadeklarowanego w AndroidManifest.xml. Aplikacja musi również dodać to uprzywilejowane uprawnienie do białej listy.
  • Aplikacje dostarczane przez Google Play wymagają uprawnień operatora. Dowiedz się więcej o przyznawaniu przywilejów przewoźnikom na stronie Przywileje przewoźników UICC .
  • Aplikacja właściciela urządzenia lub profilu, której przyznano uprawnienie READ_PHONE_STATE .

Aplikacja, która nie spełnia żadnego z tych wymagań, zachowuje się w następujący sposób:

  • Jeśli aplikacja jest przeznaczona dla wersji wcześniejszej niż Q i nie ma przyznanego uprawnienia READ_PHONE_STATE , wyzwalany jest SecurityException . jest to obecne zachowanie sprzed Q, ponieważ to uprawnienie jest wymagane do wywoływania tych interfejsów API.
  • Jeśli aplikacja jest przeznaczona dla wersji wcześniejszej niż Q i ma przyznane uprawnienie READ_PHONE_STATE , otrzymuje wartość null dla wszystkich interfejsów API TelephonyManager i Build.UNKNOWN dla metody Build#getSerial .
  • Jeśli aplikacja jest przeznaczona dla systemu Android 10 lub nowszego i nie spełnia żadnego z nowych wymagań, otrzymuje wyjątek SecurityException.

Walidacja i testowanie

Zestaw testów zgodności (CTS) obejmuje testy sprawdzające oczekiwane zachowanie dostępu do identyfikatora urządzenia dla aplikacji z uprawnieniami operatora, właścicieli urządzeń i profili oraz tych aplikacji, które nie mają dostępu do identyfikatorów urządzeń.

Poniższe testy CTS są specyficzne dla tej funkcji.

cts-tradefed run cts -m CtsCarrierApiTestCases -t
    android.carrierapi.cts.CarrierApiTest

cts-tradefed run cts -m CtsTelephonyTestCases -t
    android.telephony.cts.TelephonyManagerTest

cts-tradefed run cts -m CtsTelephony3TestCases

cts-tradefed run cts -m CtsPermissionTestCases -t
    android.permission.cts.TelephonyManagerPermissionTest

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCanGetDeviceIdentifiers

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCanGetDeviceIdentifiers

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCannotGetDeviceIdentifiersWithoutPermission

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCannotGetDeviceIdentifiersWithoutPermission

FAQs

Ile aplikacji można umieścić na białej liście w CarrierConfig.xml dla danego (MCC, MNC)?

Nie ma ograniczeń co do liczby skrótów certyfikatów zawartych w tablicy.

Których parametrów CarrierConfig w CarrierConfig.xml muszę użyć, aby aplikacja znalazła się na białej liście?

Użyj następującej konfiguracji element najwyższego poziomu w określonym CarrierConfig.xml z opcji AOSP późniejszej konfiguracji:

<string-array name="carrier_certificate_string_array" num="2">
    <item value="BF02262E5EF59FDD53E57059082F1A7914F284B"/>
    <item value="9F3868A3E1DD19A5311D511A60CF94D975A344B"/>
</string-array>

Czy istnieje podstawowy szablon CarrierConfig, którego mogę użyć?

Użyj następującego szablonu. Należy to dodać do odpowiedniego zasobu .

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<carrier_config>
    <string-array name="carrier_certificate_string_array"
num="1">
        <item value="CERTIFICATE_HASH_HERE"/>
    </string-array>
</carrier_config>

Czy karta SIM operatora musi znajdować się w urządzeniu, aby uzyskać dostęp do identyfikatorów urządzeń?

Używany CarrierConfig.xml jest określany na podstawie aktualnie włożonej karty SIM. Oznacza to, że jeśli aplikacja operatora X próbuje uzyskać uprawnienia dostępu, gdy karta SIM operatora Y jest włożona, urządzenie nie znajdzie dopasowania dla skrótu i ​​zwróci wyjątek bezpieczeństwa.

Na urządzeniach z wieloma kartami SIM operator nr 1 ma uprawnienia dostępu tylko do karty SIM nr 1 i odwrotnie.

W jaki sposób operatorzy konwertują certyfikat podpisywania aplikacji na skrót?

Aby przekonwertować certyfikaty podpisujące na skrót przed dodaniem ich do CarrierConfig.xml , wykonaj następujące czynności:

  1. Przekonwertuj podpis certyfikatu podpisującego na tablicę bajtów za pomocą toByteArray .
  2. Użyj MessageDigest aby przekonwertować tablicę bajtów na skrót typu byte [].
  3. Konwertuj hash z bajtu [] na format ciągu szesnastkowego. Na przykład zobacz IccUtils.java .

    List<String> certHashes = new ArrayList<>();
    PackageInfo pInfo; // Carrier app PackageInfo
    MessageDigest md =
    MessageDigest.getInstance("SHA-256");
    for (Signature signature : pInfo.signatures) {
        certHashes.add(bytesToHexString(md.digest(signature.toByteArray()));
    }
    
  4. Jeśli certHashes jest tablicą o rozmiarze 2 i wartościach 12345 i 54321 , dodaj następujący certHashes do pliku konfiguracyjnego przewoźnika.

    <string-array name="carrier_certificate_string_array" num="2">
        <item value="12345"/>
        <item value="54321"/>
    </string-array>