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:
- Aktualisieren Sie
CarrierConfig.xml
mit dem Signaturzertifikat-Hash der Carrier-App und senden Sie einen Patch . - 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, wirdSecurityException
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 undBuild.UNKNOWN
für dieBuild#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:
- 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
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>