Identyfikatory urządzeń

Android 10 zmienia uprawnienia dla identyfikatorów urządzeń, dzięki czemu wszystkie identyfikatory urządzeń są teraz chronione uprawnieniem READ_PRIVILEGED_PHONE_STATE . Przed Androidem 10 trwałe identyfikatory urządzeń (IMEI/MEID, IMSI, SIM i numer seryjny kompilacji) były chronione za pomocą uprawnienia wykonawczego READ_PHONE_STATE . Uprawnienie READ_PRIVILEGED_PHONE_STATE jest nadawane 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 dotyczących plików TelephonyManager.java i Build.java .

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

  • Menedżer telefonii#getDeviceId
  • Menedżer telefonii#getImei
  • Menedżer telefonii#getMeid
  • Menedżer telefonii#getSimSerialNumber
  • Menedżer telefonii#getSubscriberId
  • Zbuduj #getSerial

Dostęp dla aplikacji operatora bez pozwolenia READ_PRIVILEGED_PHONE_STATE

Fabrycznie załadowane aplikacje operatora, które nie kwalifikują się do uprawnienia READ_PRIVILEGED_PHONE_STATE , mogą implementować jedną z opcji przedstawionych w poniższej tabeli.

Opcja Opis Ograniczenia
Przywileje przewoźnika UICC Platforma Android ładuje certyfikaty przechowywane w UICC i udziela aplikacjom podpisanym tymi certyfikatami uprawnień do wykonywania wywołań metod specjalnych. Starsi operatorzy mają dużą, ustaloną populację kart SIM, którą nie można łatwo zaktualizować. Ponadto przewoźnicy, którzy nie mają praw autorskich do nowych kart SIM (na przykład operatorzy MVNO posiadający karty SIM wydane przez operatorów MNO) nie mogą dodawać ani aktualizować certyfikatów na kartach SIM.
Lista dozwolonych OEM Producenci OEM mogą używać OP_READ_DEVICE_IDENTIFIER do dostarczania identyfikatorów urządzeń aplikacjom operatorów umieszczonym na liście dozwolonych. To rozwiązanie nie jest skalowalne dla wszystkich operatorów.
Kod przydziału typu (TAC) Użyj metody getTypeAllocationCode wprowadzonej w systemie Android 10, aby wyświetlić TAC, który zwraca informacje o producencie i modelu. Informacje zawarte w TAC nie są wystarczające do zidentyfikowania konkretnego urządzenia.
MSISDN Operatorzy mogą używać numeru telefonu (MSISDN), dostępnego w TelephonyManager z grupą uprawnień PHONE , do sprawdzania numeru IMEI w swoich systemach zaplecza. Wymaga to znacznych inwestycji ze strony przewoźników. Operatorzy mapujący swoje klucze sieciowe przy użyciu 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 informacji uprzywilejowanych, platforma szuka dopasowania skrótu certyfikatu podpisywania aplikacji (podpis certyfikatu SHA-1 lub SHA-256) w pliku CarrierConfig.xml . Jeśli zostanie znalezione dopasowanie, żądane informacje zostaną zwrócone. Jeśli nie zostanie znalezione żadne dopasowanie, zwracany jest wyjątek bezpieczeństwa.

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

  1. Zaktualizuj plik CarrierConfig.xml za pomocą skrótu certyfikatu podpisywania aplikacji operatora i prześlij poprawkę .
  2. Poproś producentów OEM o aktualizację ich wersji za pomocą QPR1+ (zalecane) LUB tych wymaganych poprawek dla platformy i poprawki zawierającej zaktualizowany plik CarrierConfig.xml z kroku 1 powyżej.

Realizacja

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

Więcej informacji na temat umieszczania na liście dozwolonych znajdziesz w artykule Lista dozwolonych uprawnień uprzywilejowanych .

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

  • Jeśli aplikacja jest wstępnie załadowaną aplikacją uprzywilejowaną, wymaga uprawnienia READ_PRIVILEGED_PHONE_STATE zadeklarowanego w pliku AndroidManifest.xml. Aplikacja musi również umieścić to uprzywilejowane uprawnienie na liście dozwolonych.
  • Aplikacje dostarczane za pośrednictwem Google Play wymagają uprawnień operatora. Dowiedz się więcej na temat przyznawania uprawnień przewoźnika na stronie Uprawnienia przewoźnika 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ę następująco:

  • Jeśli aplikacja jest przeznaczona dla wersji pre-Q i nie ma przyznanego uprawnienia READ_PHONE_STATE , wyzwalany jest wyjątek SecurityException . jest to bieżące zachowanie przed Q, ponieważ to uprawnienie jest wymagane do wywołania tych interfejsów API.
  • Jeśli aplikacja jest przeznaczona dla wersji pre-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

Pakiet testów zgodności (CTS) obejmuje testy sprawdzające oczekiwane zachowanie dostępu do identyfikatora urządzenia w przypadku aplikacji z uprawnieniami operatora, właścicieli urządzeń i profili oraz tych aplikacji, które nie będą miały 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

Często zadawane pytania

Ile aplikacji może znajdować się na liście dozwolonych w CarrierConfig.xml dla danego konta (MCC, MNC)?

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

Jakich parametrów CarrierConfig w CarrierConfig.xml muszę użyć, aby aplikacja została umieszczona na liście dozwolonych?

Użyj następującego elementu konfiguracji najwyższego poziomu w konkretnym CarrierConfig.xml z konfigurowanych opcji AOSP:

<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ć?

Skorzystaj z poniższego 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ądzenia?

Używany plik CarrierConfig.xml jest określany na podstawie aktualnie włożonej karty SIM. Oznacza to, że jeśli aplikacja operatora X spróbuje uzyskać uprawnienia dostępu, gdy włożona jest karta SIM operatora Y, 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 podpisywania na skrót przed dodaniem ich do CarrierConfig.xml , wykonaj następujące czynności:

  1. Konwertuj podpis certyfikatu podpisującego na tablicę bajtów za pomocą toByteArray .
  2. Użyj MessageDigest aby przekonwertować tablicę bajtów na skrót typu bajt [].
  3. Konwertuj skrót 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 wpis do pliku konfiguracyjnego operatora.

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