Identificateurs de périphérique

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 numéro de série de build) étaient protégés derrière l'autorisation d'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.

Plus d'informations sur les nouvelles exigences d'autorisation sont disponibles dans les pages Javadoc pour TelephonyManager.java et Build.java .

Ce changement affecte les API suivantes :

  • Gestionnaire de téléphonie#getDeviceId
  • Gestionnaire de téléphonie#getImei
  • Gestionnaire de téléphonie#getMeid
  • TelephonyManager#getSimSerialNumber
  • TelephonyManager#getSubscriberId
  • Construire#getSerial

Accès aux applications de l'opérateur sans autorisation READ_PRIVILEGED_PHONE_STATE

Les applications d'opérateur préchargées qui ne sont pas éligibles à l'autorisation READ_PRIVILEGED_PHONE_STATE peuvent implémenter l'une des options du tableau ci-dessous.

Option Description Limites
Privilèges du transporteur 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 disposent d'une vaste population de cartes SIM établies, qui n'est pas facilement mise à jour. De plus, les opérateurs qui ne disposent pas de droits de création sur les nouvelles cartes SIM (par exemple, les MVNO dont les cartes SIM sont émises par des MNO) ne peuvent pas ajouter ou mettre à jour les certificats sur les cartes SIM.
Liste d'autorisation OEM Les OEM peuvent utiliser OP_READ_DEVICE_IDENTIFIER pour fournir des identifiants d'appareil aux applications des opérateurs sur liste autorisée. 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'autorisations 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 réseau à l'aide d'IMSI nécessitent des ressources techniques importantes pour passer à MSISDN .

Toutes les applications de l'opérateur peuvent accéder aux identifiants des appareils 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 plateforme recherche une correspondance avec le 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 :

  1. Mettez à jour CarrierConfig.xml avec le hachage du certificat de signature de l'application de l'opérateur et soumettez un correctif .
  2. Demandez aux OEM de mettre à jour leur version avec QPR1+ (recommandé) OU ces correctifs de plate-forme requis et le correctif contenant le fichier CarrierConfig.xml mis à jour de l'étape 1 ci-dessus.

Mise en œuvre

Mettez à jour votre liste d'autorisations d'autorisations privilégiées pour accorder l'autorisation READ_PRIVILEGED_PHONE_STATE aux applications privilégiées qui nécessitent l'accès aux identifiants d'appareil.

Pour en savoir plus sur la mise sur liste verte, reportez-vous à Liste verte 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 nécessite l'autorisation READ_PRIVILEGED_PHONE_STATE déclarée dans AndroidManifest.xml. L'application doit également autoriser cette autorisation privilégiée.
  • Les applications fournies via Google Play nécessitent des privilèges d'opérateur. Apprenez-en davantage sur l’octroi des privilèges de transporteur sur la page Privilèges de transporteur 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 pré-Q et ne dispose pas de l’autorisation READ_PHONE_STATE , SecurityException est déclenchée. il s'agit du comportement actuel avant Q, car cette autorisation est requise pour appeler ces API.
  • Si l'application cible la version antérieure à Q et dispose de l'autorisation READ_PHONE_STATE , elle 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 ne répond à aucune des nouvelles exigences, elle reçoit une SecurityException.

Validation et tests

La suite de tests de compatibilité (CTS) comprend des tests pour vérifier le comportement attendu d'accès aux identifiants d'appareil pour les applications bénéficiant de privilèges d'opérateur, les propriétaires d'appareils et de profils, ainsi que 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 verte 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 inscrite sur la liste verte ?

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>

Existe-t-il un modèle de base CarrierConfig que je peux utiliser ?

Utilisez le modèle suivant. Cela doit ê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 être 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 alors 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 dispose uniquement de privilèges d'accès pour la 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 :

  1. Convertissez la signature du certificat de signature en un tableau d'octets à l'aide de toByteArray .
  2. Utilisez MessageDigest pour convertir le tableau d'octets en un hachage de type byte[].
  3. Convertissez le hachage de byte[] en un format de chaîne hexadécimale. 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()));
    }
    
  4. Si certHashes est un tableau de taille 2 avec une valeur de 12345 et 54321 , 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>