Android 10 modifie les autorisations pour les identifiants d'appareil afin que tous les identifiants d'appareil soient désormais protégés par l'autorisation READ_PRIVILEGED_PHONE_STATE
. Avant Android 10, les identifiants d'appareil persistants (IMEI / MEID, IMSI, SIM et build serial) étaient protégés derrière l' READ_PHONE_STATE
exécution READ_PHONE_STATE
. L'autorisation READ_PRIVILEGED_PHONE_STATE
n'est accordée qu'aux applications signées avec la clé de plate-forme et aux applications système privilégiées.
Vous trouverez plus d'informations sur les nouvelles exigences d'autorisation dans les pages Javadoc de TelephonyManager.java et Build.java .
Ce changement affecte les API suivantes:
- TelephonyManager # getDeviceId
- TelephonyManager # getImei
- TelephonyManager # getMeid
- TelephonyManager # getSimSerialNumber
- TelephonyManager # getSubscriberId
- Construire # getSerial
Accès aux applications de l'opérateur sans autorisation READ_PRIVILEGED_PHONE_STATE
Les applications de l'opérateur préchargées qui ne READ_PRIVILEGED_PHONE_STATE
pas les conditions pour l'autorisation READ_PRIVILEGED_PHONE_STATE
peuvent mettre en œuvre l'une des options du tableau ci-dessous.
Option | Description | Limites |
---|---|---|
Privilèges de l'opérateur UICC | La plate-forme Android charge les certificats stockés sur l'UICC et autorise les applications signées par ces certificats à appeler des méthodes spéciales. | Les anciens opérateurs ont une grande population de cartes SIM établies, qui ne peut pas être facilement mise à jour. En outre, les opérateurs qui ne disposent pas des droits de création sur les nouvelles cartes SIM (par exemple, les MVNO qui ont des cartes SIM émises par des ORM) ne peuvent pas ajouter ou mettre à jour des certificats sur les cartes SIM. |
Liste blanche OEM | Les OEM peuvent utiliser OP_READ_DEVICE_IDENTIFIER pour fournir des identifiants d'appareil aux applications des opérateurs sur liste blanche. | Cette solution n'est pas évolutive pour tous les opérateurs. |
Code d'attribution de type (TAC) | Utilisez la méthode getTypeAllocationCode , introduite dans Android 10, pour exposer le TAC qui renvoie les informations sur le fabricant et le modèle. | Les informations contenues dans le TAC sont insuffisantes pour identifier un appareil spécifique. |
MSISDN | Les opérateurs peuvent utiliser le numéro de téléphone (MSISDN), disponible sous TelephonyManager avec le groupe d'autorisation PHONE , pour rechercher l'IMEI sur leurs systèmes backend. | Cela nécessite des investissements importants pour les transporteurs. Les opérateurs qui mappent leurs clés de réseau en utilisant IMSI ont besoin de ressources techniques importantes pour passer à MSISDN . |
Toutes les applications de l'opérateur peuvent accéder aux identifiants de l'appareil en mettant à jour le fichier CarrierConfig.xml
avec le hachage du certificat de signature de l'application de l'opérateur. Lorsque l'application de l'opérateur appelle une méthode pour lire des informations privilégiées, la plate-forme recherche une correspondance du hachage du certificat de signature de l'application (signature SHA-1 ou SHA-256 du certificat) dans le fichier CarrierConfig.xml
. Si une correspondance est trouvée, les informations demandées sont renvoyées. Si aucune correspondance n'est trouvée, une exception de sécurité est renvoyée.
Pour mettre en œuvre cette solution, les transporteurs DOIVENT suivre ces étapes:
- Mettez à jour
CarrierConfig.xml
avec le hachage du certificat de signature de l'application de l'opérateur et soumettez un correctif . - Demandez aux OEM de mettre à jour leur build avec QPR1 + (recommandé) OU ces correctifs de plate-forme requis et le correctif contenant le fichier
CarrierConfig.xml
mis à jour à partir de l'étape 1 ci-dessus.
Mise en œuvre
Mettez à jour votre liste blanche d'autorisations privilégiées pour accorder l'autorisation READ_PRIVILEGED_PHONE_STATE
aux applications privilégiées qui nécessitent un accès aux identifiants d'appareil.
Pour en savoir plus sur la liste blanche, reportez-vous à la section Liste blanche des autorisations privilégiées .
Pour appeler les API concernées, une application doit répondre à l'une des exigences suivantes:
- Si l'application est une application privilégiée préchargée, elle a besoin de l'autorisation
READ_PRIVILEGED_PHONE_STATE
déclarée dans AndroidManifest.xml. L'application doit également ajouter cette autorisation privilégiée à la liste blanche. - Les applications fournies via Google Play nécessitent des privilèges d'opérateur. En savoir plus sur l'octroi de privilèges d'opérateur sur la page Privilèges d' opérateur UICC .
- Une application de propriétaire d'appareil ou de profil qui a reçu l'autorisation
READ_PHONE_STATE
.
Une application qui ne répond à aucune de ces exigences présente le comportement suivant:
- Si l'application cible la pré-Q et ne dispose pas de l'autorisation
READ_PHONE_STATE
,SecurityException
est déclenchée. il s'agit du comportement pré-Q actuel car cette autorisation est requise pour appeler ces API. - Si l'application cible la version pré-Q et que l'autorisation
READ_PHONE_STATE
accordée, elle reçoit une valeur nulle pour toutes les API TelephonyManager etBuild.UNKNOWN
pour la méthodeBuild#getSerial
. - Si l'application cible Android 10 ou version ultérieure et ne répond à aucune des nouvelles exigences, elle reçoit une SecurityException.
Validation et test
La suite de tests de compatibilité (CTS) comprend des tests pour vérifier le comportement d'accès attendu aux identifiants d'appareil pour les applications avec des privilèges d'opérateur, les propriétaires d'appareils et de profils, et les applications qui ne devraient pas avoir accès aux identifiants d'appareil.
Les tests CTS suivants sont spécifiques à cette fonctionnalité.
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
FAQ
Combien d'applications peuvent être ajoutées à la liste blanche dans CarrierConfig.xml
pour un (MCC, MNC) donné?
Il n'y a pas de limite au nombre de hachages de certificats inclus dans le tableau.
Quels paramètres CarrierConfig dans CarrierConfig.xml
dois-je utiliser pour qu'une application soit ajoutée à la liste blanche?
Utilisez l'élément de configuration de niveau supérieur suivant dans le CarrierConfig.xml
spécifique à partir des options AOSP que vous configurez:
<string-array name="carrier_certificate_string_array" num="2"> <item value="BF02262E5EF59FDD53E57059082F1A7914F284B"/> <item value="9F3868A3E1DD19A5311D511A60CF94D975A344B"/> </string-array>
Puis-je utiliser un modèle CarrierConfig de base?
Utilisez le modèle suivant. Cela devrait être ajouté à l' actif concerné .
<?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>
La carte SIM de l'opérateur doit-elle se trouver dans l'appareil pour accéder aux identifiants de l'appareil?
Le CarrierConfig.xml
utilisé est déterminé en fonction de la carte SIM actuellement insérée. Cela signifie que si l'application de l'opérateur X tente d'obtenir des privilèges d'accès pendant que la carte SIM de l'opérateur Y est insérée, l'appareil ne trouvera pas de correspondance pour le hachage et renvoie une exception de sécurité.
Sur les appareils multi-SIM, l'opérateur n ° 1 ne dispose que des privilèges d'accès pour la carte SIM n ° 1 et vice versa.
Comment les opérateurs convertissent-ils le certificat de signature d'une application en hachage?
Pour convertir les certificats de signature en hachage avant de les ajouter à CarrierConfig.xml
, procédez comme suit:
- Convertissez la signature du certificat de signature en un tableau d'octets à l'aide de
toByteArray
. - Utilisez
MessageDigest
pour convertir le tableau d'octets en un hachage de type byte []. Convertissez le hachage d'octet [] en un format de chaîne hexadécimal. Pour un exemple, consultez
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())); }
Si
certHashes
est un tableau de taille2
avec une valeur de12345
et54321
, ajoutez ce qui suit au fichier de configuration de l'opérateur.<string-array name="carrier_certificate_string_array" num="2"> <item value="12345"/> <item value="54321"/> </string-array>