Identifiants des appareils

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:

  1. 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.
  2. 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 et Build.UNKNOWN pour la méthode Build#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:

  1. Convertir la signature du certificat de signature en tableau d'octets à l'aide de <ph type="x-smartling-placeholder"></ph> toByteArray.
  2. Utiliser MessageDigest pour convertir le tableau d'octets en hachage dans byte[].

  3. 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()));
}

  4. Si certHashes est un tableau de taille 2 avec une valeur de 12345 et 54321, 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>