Gerätekennungen

Android 10 ändert die Berechtigungen für Gerätekennungen so, dass alle Gerätekennungen jetzt durch die READ_PRIVILEGED_PHONE_STATE geschützt sind. Vor Android 10 waren dauerhafte Gerätekennungen (IMEI / MEID, IMSI, SIM und Build Serial) hinter der Laufzeitberechtigung READ_PHONE_STATE geschützt. Die READ_PRIVILEGED_PHONE_STATE wird nur Apps erteilt, die mit dem Plattformschlüssel signiert sind, sowie privilegierten System-Apps.

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

Diese Änderung wirkt sich auf die folgenden APIs aus:

  • TelephonyManager # getDeviceId
  • TelephonyManager # getImei
  • TelephonyManager # getMeid
  • TelephonyManager # getSimSerialNumber
  • TelephonyManager # getSubscriberId
  • Erstellen Sie # getSerial

Zugriff für Carrier-Apps ohne READ_PRIVILEGED_PHONE_STATE-Berechtigung

Vorinstallierte Carrier-Apps, die sich nicht für die READ_PRIVILEGED_PHONE_STATE qualifizieren, können eine der Optionen in der folgenden Tabelle implementieren.

Möglichkeit Beschreibung Einschränkungen
UICC-Trägerrechte Die Android-Plattform lädt auf der UICC gespeicherte Zertifikate und erteilt Apps, die mit diesen Zertifikaten signiert sind, die Erlaubnis, spezielle Methoden aufzurufen. Ältere Netzbetreiber verfügen über eine große, etablierte SIM-Population, die nicht einfach aktualisiert werden kann. Außerdem können Netzbetreiber, die keine Urheberrechte für neue SIM-Karten haben (z. B. MVNOs, deren SIM-Karten von Mobilfunknetzbetreibern ausgestellt wurden), keine Zertifikate auf den SIM-Karten hinzufügen oder aktualisieren.
OEM-Whitelist OEMs können OP_READ_DEVICE_IDENTIFIER , um Gerätekennungen für Whitelist-Carrier-Apps bereitzustellen. Diese Lösung ist nicht für alle Netzbetreiber skalierbar.
Typzuweisungscode (TAC) Verwenden Sie die in Android 10 eingeführte Methode getTypeAllocationCode , um die TAC verfügbar zu machen, die die Hersteller- und Modellinformationen zurückgibt. Die Informationen in der TAC reichen nicht aus, um ein bestimmtes Gerät zu identifizieren.
MSISDN Netzbetreiber können die unter TelephonyManager mit der PHONE verfügbare Telefonnummer (MSISDN) verwenden, um die IMEI auf ihren Backend-Systemen PHONE . Dies erfordert erhebliche Investitionen für die Luftfahrtunternehmen. Netzbetreiber, die ihre Netzwerkschlüssel mithilfe von IMSI zuordnen, benötigen erhebliche technische Ressourcen, um zu MSISDN zu wechseln.

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

Um diese Lösung zu implementieren, MÜSSEN die Netzbetreiber die folgenden Schritte ausführen:

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

Implementierung

Aktualisieren Sie Ihre Whitelist 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 zum Whitelisting finden Sie unter Whitelisting mit privilegierten 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 READ_PRIVILEGED_PHONE_STATE deklarierte Berechtigung READ_PRIVILEGED_PHONE_STATE. Die App muss diese privilegierte Berechtigung auch auf die Whitelist setzen.
  • Für Apps, die über Google Play bereitgestellt werden, sind Netzbetreiberrechte erforderlich. Weitere Informationen zum Gewähren von Netzbetreiberberechtigungen finden Sie auf der Seite UICC-Trägerberechtigungen .
  • Eine Geräte- oder Profilbesitzer-App, der die Berechtigung READ_PHONE_STATE erteilt wurde.

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

  • Wenn die App auf Pre-Q READ_PHONE_STATE und nicht über die READ_PHONE_STATE , wird die SecurityException ausgelöst. Dies ist das aktuelle Pre-Q-Verhalten, da diese Berechtigung zum Aufrufen dieser APIs erforderlich ist.
  • Wenn die App auf Pre-Q READ_PHONE_STATE und die READ_PHONE_STATE erteilt wurde, 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 ausgerichtet ist und keine der neuen Anforderungen erfüllt, erhält sie eine SecurityException.

Validierung und Prüfung

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

Die folgenden CTS-Tests sind spezifisch für 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 Whitelist gesetzt werden?

Die Anzahl der im Array enthaltenen Zertifikat-Hashes ist unbegrenzt.

Welche CarrierConfig-Parameter in CarrierConfig.xml muss ich verwenden, damit eine App in die Whitelist aufgenommen 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 CarrierConfig-Basisvorlage, 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 Träger-SIM im Gerät befinden, um auf Gerätekennungen zugreifen zu können?

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

Auf Multi-SIM-Geräten verfügt Carrier Nr. 1 nur über Zugriffsrechte für SIM Nr. 1 und umgekehrt.

Wie konvertieren Netzbetreiber das Signaturzertifikat einer App in einen Hash?

CarrierConfig.xml wie folgt vor, um Signaturzertifikate in einen Hash zu konvertieren, 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 , fügen Sie der Carrier-Konfigurationsdatei Folgendes hinzu.

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