Android 10 modifie les autorisations pour
les identifiants d'appareils, de sorte que tous les identifiants d'appareils soient protégés
l'autorisation READ_PRIVILEGED_PHONE_STATE
. Avant le
Android 10, identifiants permanents d'appareils
(IMEI/MEID, IMSI, carte SIM et numéro de série) étaient protégés par le
Autorisation d'exécution READ_PHONE_STATE
.
L'autorisation READ_PRIVILEGED_PHONE_STATE
n'est
accordé aux applications signées avec la clé de
plateforme et les applications système privilégiées.
Pour en savoir plus sur les nouvelles autorisations requises, consultez les Pages Javadoc pour TelephonyManager.java et Build.java.
Ce changement a une incidence sur les API suivantes:
- TelephonyManager#getDeviceId
- TelephonyManager#getImei
- TelephonyManager#getMeid
- TelephonyManager#getSimSerialNumber
- TelephonyManager#getSubscriberId
- Build#getSerial
Accès pour les applis d'opérateurs qui ne disposent pas de l'autorisation READ_PRIVILEGED_PHONE_STATE
Applications d'opérateur préchargées qui ne sont pas éligibles
READ_PRIVILEGED_PHONE_STATE
peut implémenter l'une des options du tableau ci-dessous.
Option possible | Description | Limites |
---|---|---|
Droits d'opérateur UICC | La plate-forme Android charge les certificats stockés dans UICC et accorde l'autorisation d'appeler les applications signées à l'aide de ces certificats méthodes. | Les anciens opérateurs ont un nombre important de cartes SIM bien établies, ce qui n'est pas le cas facilement mises à jour. De plus, les opérateurs qui ne disposent pas de droits de création Il n'est pas possible d'ajouter des cartes SIM (par exemple, les MVNOs qui ont des cartes SIM émises par des opérateurs de réseau mobile). mettre à jour les certificats sur les cartes SIM. |
Liste d'autorisation OEM | Les OEM peuvent utiliser OP_READ_DEVICE_IDENTIFIER pour fournir l'appareil
aux applications d'opérateurs figurant sur la liste d'autorisation. |
Cette solution n'est pas évolutive pour tous les opérateurs. |
Code d'allocation de type (TAC) | Utilisez les
getTypeAllocationCode
, introduite dans
Android 10, pour afficher le TAC qui renvoie le fabricant et le modèle
de l'utilisateur. |
Les informations du TAC ne permettent pas d'identifier un appareil spécifique. |
MSISDN | Les opérateurs peuvent utiliser le numéro de téléphone (MSISDN), disponible sous
TelephonyManager avec l'autorisation PHONE
pour rechercher le code IMEI sur
leurs systèmes backend. |
Cela nécessite un investissement important de la part des opérateurs. Opérateurs qui mappent leurs clés réseau à l'aide d'IMSI nécessitent de nombreuses ressources techniques pour passer à MSISDN. |
Toutes les applis d'opérateurs peuvent accéder aux identifiants des appareils en mettant à jour
le fichier CarrierConfig.xml
avec le hachage du certificat de signature
l'application de l'opérateur. Lorsque l'application de l'opérateur appelle une méthode de lecture des données
la plate-forme recherche une correspondance avec le certificat de signature de l'application
(signature SHA-1 ou SHA-256 du certificat) dans le
CarrierConfig.xml
. En cas de correspondance, les
les informations sont renvoyées. Si aucune correspondance n'est trouvée, une exception de sécurité est
renvoyé.
Pour mettre en œuvre cette solution, les opérateurs DOIVENT suivre ces étapes:
- Mettre à jour
<ph type="x-smartling-placeholder"></ph>
CarrierConfig.xml
par le hachage du certificat de signature du l'application de l'opérateur et envoyer un correctif. - Demandez aux OEM de mettre à jour leur build avec QPR1+ (recommandé) OU ces
correctifs requis de la plate-forme et le correctif contenant
mis à jour le fichier
CarrierConfig.xml
de l'étape 1 ci-dessus.
Implémentation
Mettez à jour votre liste d'autorisation d'autorisations privilégiées
Autorisation READ_PRIVILEGED_PHONE_STATE
pour les utilisateurs privilégiés
les applications qui ont besoin d'accéder
aux identifiants des appareils.
Pour en savoir plus sur l'ajout à la liste d'autorisation, reportez-vous à la section Ajout à la liste d'autorisation des autorisations
Pour appeler les API concernées, une application doit répondre à l'un des critères suivants configuration requise:
- Si l'application est une application privilégiée préchargée, elle a besoin du
Autorisation
READ_PRIVILEGED_PHONE_STATE
déclarée dans AndroidManifest.xml. L'application doit également ajouter une liste d'autorisation cette autorisation privilégiée. - Les applications distribuées via Google Play doivent disposer de droits d'opérateur. En savoir plus sur l'attribution de droits d'opérateur sur la page Opérateur de l'UICC Droits.
- Une application de propriétaire d'un appareil ou d'un profil disposant du
Autorisation
READ_PHONE_STATE
.
Une application qui ne répond à aucune de ces exigences présente les caractéristiques suivantes : comportement:
- Si l'application cible avant le test Q et n'inclut pas
Autorisation
READ_PHONE_STATE
accordée,SecurityException
est déclenché. Il s'agit du comportement actuel avant le QT, car cette autorisation est nécessaire pour appeler ces API. - Si l'application cible avant le test Q et qu'elle dispose du
Autorisation
READ_PHONE_STATE
accordée, il 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 que ne rencontre aucun des nouveaux il reçoit une SecurityException.
Validation et test
La section Compatibilité La suite de tests (CTS) inclut des tests pour valider l'identifiant d'appareil attendu le comportement d'accès pour les applications disposant des droits d'opérateur, les propriétaires du profil et les applications qui ne sont pas censées avoir accès à l'appareil identifiants.
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
Questions fréquentes
Combien d'applications peuvent être ajoutées à la liste d'autorisation dans CarrierConfig.xml
pour un CM donné (CM, MNC) ?
Le nombre de hachages de certificats inclus dans le tableau n'est pas limité.
Quels paramètres CarrierConfig dans CarrierConfig.xml
dois-je utiliser pour qu'une application soit ajoutée à la liste d'autorisation ?
Utilisez l'élément de configuration de premier niveau suivant dans le
CarrierConfig.xml
à partir des options AOSP que vous configurez:
<string-array name="carrier_certificate_string_array" num="2"> <item value="BF02262E5EF59FDD53E57059082F1A7914F284B"/> <item value="9F3868A3E1DD19A5311D511A60CF94D975A344B"/> </string-array>
Existe-t-il un modèle CarrierConfig de base que je peux utiliser ?
Utilisez le modèle suivant. Il doit être ajouté <ph type="x-smartling-placeholder"></ph> l'asset le plus pertinent.
<?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 être insérée dans l'appareil pour accéder aux identifiants de l'appareil ?
La CarrierConfig.xml
utilisée est déterminée en fonction de la
SIM actuellement insérée. Cela signifie que si l'application
de l'opérateur X tente
obtiennent des privilèges d'accès lorsque la carte SIM de l'opérateur Y est insérée, l'appareil ne trouve pas
une correspondance pour le hachage
et renvoie une exception de sécurité.
Sur les appareils avec plusieurs cartes SIM, l'opérateur 1 ne dispose de privilèges d'accès que pour la carte SIM 1 et vice versa.
Comment les opérateurs convertissent-ils le certificat de signature d'une application en hachage ?
Pour convertir des certificats de signature en hachage avant de les ajouter
CarrierConfig.xml
, procédez comme suit:
- Convertir la signature du certificat de signature en tableau d'octets à l'aide de
<ph type="x-smartling-placeholder"></ph>
toByteArray
. - Utiliser
MessageDigest
pour convertir le tableau d'octets en hachage dans byte[]. -
Convertissez le hachage byte[] en un format de chaîne hexadécimale. Par exemple, voir
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 le code suivant 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>