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:
- Aktualisieren Sie
CarrierConfig.xml
mit dem Signaturzertifikat-Hash der Carrier-App und senden Sie einen Patch . - 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 dieREAD_PHONE_STATE
, wird dieSecurityException
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 dieREAD_PHONE_STATE
erteilt wurde, erhält sie einen Nullwert für alle TelephonyManager-APIs undBuild.UNKNOWN
für dieBuild#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:
- Konvertieren Sie die Signatur des Signaturzertifikats mit
toByteArray
in ein Byte-Array. - Verwenden Sie
MessageDigest
, um das Byte-Array in einen Hash vom Typ Byte [] zu konvertieren. 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())); }
Wenn
certHashes
ein Array der Größe2
mit den Werten12345
und54321
, 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>