Gerätekennungen

Android 10 ändert die Berechtigungen für Gerätekennungen, sodass alle Gerätekennungen jetzt durch die Berechtigung READ_PRIVILEGED_PHONE_STATE geschützt sind. Vor Android 10 waren dauerhafte Gerätekennungen (IMEI/MEID, IMSI, SIM und Build-Seriennummer) durch die Laufzeitberechtigung READ_PHONE_STATE geschützt. Die Berechtigung READ_PRIVILEGED_PHONE_STATE wird nur Apps gewährt, die mit dem Plattformschlüssel signiert sind, und privilegierten System-Apps.

Weitere Informationen zu den neuen Berechtigungsanforderungen finden Sie auf den Javadoc-Seiten für TelephonyManager.java und Build.java .

Diese Änderung betrifft die folgenden APIs:

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

Zugriff für Anbieter-Apps ohne READ_PRIVILEGED_PHONE_STATE-Berechtigung

Vorinstallierte Anbieter-Apps, die nicht für die Berechtigung READ_PRIVILEGED_PHONE_STATE qualifiziert sind, können eine der Optionen in der folgenden Tabelle implementieren.

Möglichkeit Beschreibung Einschränkungen
UICC-Trägerprivilegien Die Android-Plattform lädt auf der UICC gespeicherte Zertifikate und erteilt Apps, die mit diesen Zertifikaten signiert sind, die Berechtigung, spezielle Methoden aufzurufen. Ältere Mobilfunkanbieter verfügen über einen großen, etablierten SIM-Bestand, der nicht einfach aktualisierbar ist. Außerdem können Netzbetreiber, die keine Autorisierungsrechte für neue SIMs haben (z. B. MVNOs, deren SIMs von MNOs ausgestellt wurden), keine Zertifikate auf den SIMs hinzufügen oder aktualisieren.
OEM-Zulassungsliste OEMs können OP_READ_DEVICE_IDENTIFIER verwenden, um Gerätekennungen für zugelassene Anbieter-Apps bereitzustellen. Diese Lösung ist nicht für alle Netzbetreiber skalierbar.
Typzuordnungscode (TAC) Verwenden Sie die in Android 10 eingeführte getTypeAllocationCode Methode, um den TAC verfügbar zu machen, der die Hersteller- und Modellinformationen zurückgibt. Die Informationen im TAC reichen nicht aus, um ein bestimmtes Gerät zu identifizieren.
MSISDN Netzbetreiber können die Telefonnummer (MSISDN), die unter TelephonyManager mit der PHONE Berechtigungsgruppe verfügbar ist, verwenden, um die IMEI auf ihren Backend-Systemen nachzuschlagen. Dies erfordert erhebliche Investitionen für die Transportunternehmen. Betreiber, die ihre Netzwerkschlüssel mithilfe von IMSI zuordnen, benötigen erhebliche technische Ressourcen, um auf MSISDN umzusteigen.

Alle Mobilfunkanbieter-Apps können auf Gerätekennungen zugreifen, indem sie die Datei CarrierConfig.xml mit dem Signaturzertifikat-Hash der Mobilfunkanbieter-App aktualisieren. Wenn die Carrier-App eine Methode zum Lesen privilegierter Informationen aufruft, sucht die Plattform nach einer Übereinstimmung mit dem Signaturzertifikat-Hash der App (SHA-1- oder SHA-256-Signatur des Zertifikats) in der Datei CarrierConfig.xml . Wenn eine Übereinstimmung gefunden wird, werden die angeforderten Informationen zurückgegeben. Wenn keine Übereinstimmung gefunden wird, wird eine Sicherheitsausnahme zurückgegeben.

Um diese Lösung zu implementieren, MÜSSEN Spediteure die folgenden Schritte befolgen:

  1. Aktualisieren Sie CarrierConfig.xml mit dem Signaturzertifikat-Hash der Carrier-App und senden Sie einen Patch .
  2. Fordern Sie OEMs auf, ihren Build mit QPR1+ (empfohlen) ODER diesen erforderlichen Plattform-Patches und dem Patch mit der aktualisierten CarrierConfig.xml Datei aus Schritt 1 oben zu aktualisieren.

Implementierung

Aktualisieren Sie Ihre Zulassungsliste für privilegierte Berechtigungen, um den privilegierten Apps, die Zugriff auf Gerätekennungen benötigen, die Berechtigung READ_PRIVILEGED_PHONE_STATE zu erteilen.

Weitere Informationen zur Zulassungsliste finden Sie unter Zulassungsliste für privilegierte Berechtigungen .

Um die betroffenen APIs aufzurufen, muss eine App eine der folgenden Anforderungen erfüllen:

  • Wenn es sich bei der App um eine vorinstallierte privilegierte Anwendung handelt, benötigt sie die in AndroidManifest.xml deklarierte READ_PRIVILEGED_PHONE_STATE Berechtigung. Die App muss diese privilegierte Berechtigung auch auf die Zulassungsliste setzen.
  • Für Apps, die über Google Play bereitgestellt werden, sind Betreiberrechte erforderlich. Erfahren Sie mehr über die Gewährung von Carrier-Privilegien auf der Seite „Carrier Privileges“ der UICC .
  • Eine Geräte- oder Profilbesitzer-App, der die READ_PHONE_STATE -Berechtigung erteilt wurde.

Eine App, die keine dieser Anforderungen erfüllt, weist das folgende Verhalten auf:

  • Wenn die App auf Pre-Q abzielt und nicht über die erteilte READ_PHONE_STATE Berechtigung verfügt, wird SecurityException ausgelöst. Dies ist das aktuelle Verhalten vor Q, da diese Berechtigung zum Aufrufen dieser APIs erforderlich ist.
  • Wenn die App auf Pre-Q abzielt und über die Berechtigung READ_PHONE_STATE verfügt, erhält sie einen Nullwert für alle TelephonyManager-APIs und Build.UNKNOWN für die Build#getSerial -Methode.
  • Wenn die App auf Android 10 oder höher abzielt und keine der neuen Anforderungen erfüllt, erhält sie eine SecurityException.

Validierung und Tests

Die Compatibility Test Suite (CTS) umfasst Tests zur Überprüfung des erwarteten Zugriffsverhaltens auf Gerätekennungen für Apps mit Betreiberprivilegien, Geräte- und Profilbesitzern sowie für Apps, von denen erwartet wird, dass sie keinen Zugriff auf Gerätekennungen haben.

Die folgenden CTS-Tests beziehen sich speziell auf diese Funktion.

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

Wie viele Apps können in CarrierConfig.xml für ein bestimmtes (MCC, MNC) auf die Zulassungsliste gesetzt werden?

Es gibt keine Begrenzung für die Anzahl der im Array enthaltenen Zertifikat-Hashes.

Welche CarrierConfig-Parameter in CarrierConfig.xml muss ich verwenden, damit eine App auf die Zulassungsliste gesetzt wird?

Verwenden Sie das folgende Konfigurationselement der obersten Ebene in der spezifischen CarrierConfig.xml aus den AOSP-Optionen, die Sie konfigurieren:

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

Gibt es eine Basis-CarrierConfig-Vorlage, die ich verwenden kann?

Verwenden Sie die folgende Vorlage. Dies sollte dem entsprechenden Vermögenswert hinzugefügt werden.

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

Muss sich die SIM-Karte des Mobilfunkanbieters im Gerät befinden, um auf Gerätekennungen zugreifen zu können?

Die verwendete CarrierConfig.xml wird anhand der aktuell eingelegten SIM-Karte ermittelt. Dies bedeutet, dass das Gerät keine Übereinstimmung für den Hash findet und eine Sicherheitsausnahme zurückgibt, wenn die App von Netzbetreiber X versucht, Zugriffsrechte zu erhalten, während die SIM-Karte von Netzbetreiber Y eingelegt ist.

Auf Multi-SIM-Geräten hat Netzbetreiber Nr. 1 nur Zugriffsrechte für SIM Nr. 1 und umgekehrt.

Wie wandeln Netzbetreiber das Signaturzertifikat einer App in einen Hash um?

Gehen Sie wie folgt vor, um Signaturzertifikate in einen Hash umzuwandeln, bevor Sie sie zu CarrierConfig.xml hinzufügen:

  1. Konvertieren Sie die Signatur des Signaturzertifikats mit toByteArray in ein Byte-Array.
  2. Verwenden Sie MessageDigest um das Byte-Array in einen Hash vom Typ „Byte[]“ zu konvertieren.
  3. Konvertieren Sie den Hash von Byte[] in ein Hex-String-Format. Ein Beispiel finden Sie unter 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. Wenn certHashes ein Array der Größe 2 mit den Werten 12345 und 54321 ist, fügen Sie der Trägerkonfigurationsdatei Folgendes hinzu.

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