Droits de l'opérateur sur la carte UICC

Android 5.1 introduit un mécanisme permettant d'accorder des droits spéciaux pour les API utiles pour les propriétaires d’applications UICC (Universal Integrated Circuit Card). La plate-forme Android charge les certificats stockés sur une UICC et accorde aux applications signées par ces certificats l'autorisation d'effectuer des appels vers quelques API spéciales.

Android 7.0 a étendu cette fonctionnalité afin de prendre en charge d'autres sources de stockage pour UICC des règles liées aux privilèges de l'opérateur, en augmentant le nombre d'opérateurs pouvant utiliser les API. Pour obtenir une référence de l'API, consultez CarrierConfigManager. Pour obtenir des instructions, consultez Configuration de l'opérateur.

Les opérateurs ont le contrôle total de la carte UICC. Ce mécanisme offre donc un moyen sécurisé et flexible de gérer les applications de l'opérateur de réseau mobile (MNO) hébergées sur des canaux de distribution d'applications génériques (tels que Google Play), tout en conservant des droits spéciaux sur les appareils et sans avoir à signer les applications avec le certificat de plate-forme par appareil ni à les préinstaller en tant qu'application système.

Règles concernant les UICC

Le stockage sur la carte UICC est compatible avec la spécification de contrôle des accès des éléments sécurisés GlobalPlatform. Identifiant de l'application (AID) figurant sur la carte est A00000015141434C00, et le numéro GET DATA est utilisée pour récupérer les règles stockées sur la carte. Vous pouvez mettre à jour ces règles via des mises à jour Over The Air (OTA) de la carte.

Hiérarchie des données

Les règles UICC utilisent la hiérarchie de données suivante (la lettre à deux caractères et la combinaison de chiffres entre parenthèses correspond au tag d'objet). Chaque règle est REF-AR-DO (E2) et se compose d'une concaténation de REF-DO et AR-DO :

  • REF-DO (E1) contient DeviceAppID-REF-DO ou une concaténation de DeviceAppID-REF-DO et PKG-REF-DO.
    • DeviceAppID-REF-DO (C1) stocke l'algorithme SHA-1 (20 octets) ou SHA-256 (32 octets) du certificat.
    • PKG-REF-DO (CA) est la chaîne de nom de package complet définie dans le fichier manifeste, encodée en ASCII, avec une longueur maximale de 127 octets.
  • AR-DO (E3) est étendu pour inclure PERM-AR-DO (DB), qui est un bit de 8 octets représentant 64 autorisations distinctes.

Si PKG-REF-DO n'est pas présent, toute application signée par le certificat se voit accorder l'accès ; Sinon, le certificat et le nom du package doivent tous les deux correspond.

Exemple de règle

Le nom de l'application est com.google.android.apps.myapp et Le certificat SHA-1 au format hexadécimal est:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

La règle concernant l'UICC dans la chaîne hexadécimale est la suivante :

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

Compatibilité avec les fichiers de règles d'accès

Android 7.0 permet désormais de lire les règles de droits d'opérateur à partir de l'accès de règles de pare-feu (ARF).

La plate-forme Android tente d'abord de sélectionner l'application de la règle d'accès. (ARA) AID A00000015141434C00. S'il ne trouve pas l'AID sur l'UICC, il revient à l'ARF en sélectionnant l'AID PKCS15 A000000063504B43532D3135. Android lit ensuite fichier de règles de contrôle d'accès (ACRF) à l'adresse 0x4300 et recherche les entrées avec l'AID FFFFFFFFFFFF. Les entrées avec des AID différents sont ignorées. Par conséquent, des règles pour d'autres cas d'utilisation peuvent coexister.

Exemple de contenu ACRF dans une chaîne hexadécimale:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

Exemple de contenu d'un fichier de conditions de contrôle d'accès (ACCF) :

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

Dans l'exemple ci-dessus, 0x4310 est l'adresse de l'ACCF, qui contient le hachage de certificat 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Les applications signées par ce certificat bénéficient des droits d'opérateur.

API activées

Android est compatible avec les API suivantes.

TelephonyManager

TelephonyCallback

TelephonyCallback dispose d'interfaces avec une méthode de rappel pour avertir l'application appelante lorsque les états enregistrés changent :

Gestionnaire d'abonnements

Gestionnaire SMS

CarrierConfigManager

  • Méthode de notification de la configuration modifiée: <ph type="x-smartling-placeholder"></ph> notifyConfigChangedForSubId.
  • Méthode pour obtenir la configuration de l'opérateur pour l'abonnement par défaut: <ph type="x-smartling-placeholder"></ph> getConfig
  • Méthode permettant d'obtenir la configuration de l'opérateur pour l'abonnement spécifié: <ph type="x-smartling-placeholder"></ph> getConfigForSubId

Pour obtenir des instructions, consultez la section Configuration de l'opérateur.

Gestionnaire de rapport de bug

Méthode permettant de démarrer un rapport de bug de connectivité, qui est une version spécialisée du rapport de bug qui n'inclut que des informations pour déboguer les problèmes liés à la connectivité : startConnectivityBugreport

NetworkStatsManager

Gestionnaire d'impression

ImsRcsManager

ProvisioningManager

EuiccManager

Méthode permettant de passer à l'abonnement donné (l'activer) : switchToSubscription

CarrierMessagingService

Service qui reçoit les appels du système lorsque de nouveaux SMS et MMS sont envoyés ou reçus. Pour étendre cette classe, déclarez le service dans votre fichier manifeste avec l'autorisation android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE et incluez un filtre d'intent avec l'action #SERVICE_INTERFACE. Voici quelques méthodes :

  • Méthode pour filtrer les messages SMS entrants : onFilterSms
  • Méthode d'interception des SMS envoyés depuis l'appareil: <ph type="x-smartling-placeholder"></ph> onSendTextSms
  • Méthode permettant d'intercepter les messages SMS binaires envoyés depuis l'appareil : onSendDataSms
  • Méthode permettant d'intercepter les SMS longs envoyés depuis l'appareil : onSendMultipartTextSms
  • Méthode permettant d'intercepter les messages MMS envoyés depuis l'appareil : onSendMms
  • Méthode pour télécharger les MMS reçus : onDownloadMms

CarrierService

Service qui expose des fonctionnalités spécifiques à l'opérateur au système. Pour étendre cette classe, déclarez le service dans le fichier manifeste de l'application avec l'autorisation android.Manifest.permission#BIND_CARRIER_SERVICES et incluez un filtre d'intent avec l'action CARRIER_SERVICE_INTERFACE. Si le service possède une liaison de longue durée, définissez android.service.carrier.LONG_LIVED_BINDING jusqu'à true dans les métadonnées du service.

La plate-forme lie CarrierService à des indicateurs spéciaux pour permettre au processus de service du transporteur de s'exécuter dans un bucket de veille de l'application spécial. Cela exempte l'application de service du transporteur de la restriction d'inactivité de l'application et augmente la probabilité qu'elle reste active lorsque la mémoire de l'appareil est faible. Toutefois, si l'application du service de l'opérateur plante pour une raison quelconque, il perd tous les privilèges ci-dessus jusqu'à ce que l'application redémarre et que la liaison soit rétablies. Il est donc essentiel de maintenir la stabilité de l'application de service du transporteur.

Les méthodes de CarrierService incluent les suivantes :

  • Pour remplacer et définir les configurations spécifiques au transporteur : onLoadConfig
  • Pour informer le système d'une modification intentionnelle du réseau d'opérateur l'application de l'opérateur: <ph type="x-smartling-placeholder"></ph> notifyCarrierNetworkChange

Fournisseur de téléphonie

API du fournisseur de contenu permettant de modifier (insérer, supprimer, mettre à jour, interroger) la base de données de téléphonie. Les champs de valeurs sont définis <ph type="x-smartling-placeholder"></ph> Telephony.Carriers Pour en savoir plus, consultez la documentation de référence de la classe Telephony.

WifiNetworkSuggestion

Lorsque vous créez un objet WifiNetworkSuggestion, utilisez le code suivant : pour définir un ID d'abonnement ou un groupe d'abonnements:

Plate-forme Android

Sur un UICC détecté, la plate-forme crée des objets UICC internes qui inclure des règles relatives aux droits d'opérateur dans l'UICC. UiccCarrierPrivilegeRules.java charge les règles, les analyse à partir de la carte UICC et les met en cache dans la mémoire. Quand ? une vérification des privilèges est nécessaire, UiccCarrierPrivilegeRules compare les certificat de l'appelant avec ses propres règles, une par une. Si la carte UICC est supprimée, les règles sont détruites avec l'objet UICC.

Validation

Pour valider l'implémentation via Compatibility Test Suite (CTS) avec CtsCarrierApiTestCases.apk, vous devez disposer d'un UICC de développeur compatible avec les règles UICC ou le fichier ARF ; Demandez au fournisseur de carte SIM de votre choix de préparer une UICC de développeur avec l'ARF approprié, comme décrit dans cette section, et utilisez cette UICC pour exécuter les tests. La UICC ne nécessite pas de service mobile actif pour réussir les tests CTS.

Préparer l'UICC

Pour Android 11 ou version antérieure, CtsCarrierApiTestCases.apk correspond à signé par aosp-testkey, avec une valeur de hachage 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81

À partir d'Android 12, CtsCarrierApiTestCases.apk est signé par cts-uicc-2021-testkey, valeur de hachage CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0

Exécuter des tests de l'API d'opérateur CTS sous Android 12, l'appareil doit utiliser une carte SIM avec opérateur CTS droits répondant aux exigences spécifiées dans la dernière version de le tiers spécification GSMA TS.48 Test Profile.

La même carte SIM peut également être utilisée pour les versions antérieures à Android 12.

Modifier le profil SIM CTS

  1. Ajouter:droits d'opérateur CTS dans ARA-M ou ARF. Les deux signatures doivent être encodées dans les règles d'attribution des droits au transporteur :
    1. Hash1(SHA1) : 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. Création : fichiers élémentaires (EF) USIM ADF non présents dans TS.48 et nécessaires pour CTS :
    1. EF_MBDN (6FC7), taille de l'enregistrement: 28, numéro d'enregistrement: 4 <ph type="x-smartling-placeholder">
        </ph>
      • Contenu
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
        2. Rec2-n: FF...FF
    2. EF_EXT6 (6FC8), taille de l'enregistrement : 13, numéro d'enregistrement : 1 
      • Contenu : 00FF…FF
        1. EF_MBI (6FC9), taille de l'enregistrement : 4, numéro d'enregistrement : 1
      • Contenu : Rec1 : 01010101
        1. EF_MWIS (6FCA), taille d'enregistrement : 5, numéro d'enregistrement : 1
      • Contenu : 0000000000
  3. Modifier:Table des services USIM: activer les services n° 47, n° 48
    1. EF_UST (6F38)
      • Contenu : 9EFFBF1DFFFE0083410310010400406E01
  4. Modifier:fichiers DF-5GS et DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Contenu : FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Contenu : FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS : EF SUCI_Calc_Info (USIM/5FC0/4F07) <ph type="x-smartling-placeholder">
        </ph>
      • Contenu : A0020000FF…FF
    4. DF-SAIP : EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01) <ph type="x-smartling-placeholder">
        </ph>
      • Contenu : A0020000FF…FF
  5. Modifier:utiliser la chaîne du nom de l'opérateur Android CTS dans les EF respectifs contenant cette désignation:
    1. EF_SPN (USIM/6F46) <ph type="x-smartling-placeholder">
        </ph>
      • Contenu : 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Contenu : Rec1 430B83413759FE4E934143EA14FF..FF

Correspondre à la structure du profil de test

Téléchargez la dernière version des structures de profils de test génériques suivantes et faites-les correspondre. La règle de privilèges de l'opérateur CTS ne sera pas personnalisée pour ces profils, ni les autres modifications listées ci-dessus.

Exécuter des tests

Pour plus de commodité, CTS prend en charge un jeton d'appareil qui limite l'exécution des tests uniquement sur les appareils configurés avec le même jeton. CTS de l'API de l'opérateur Les tests prennent en charge le jeton d'appareil sim-card-with-certs. Par exemple, le jeton d'appareil suivant limite les tests de l'API du transporteur à l'exécution uniquement sur l'appareil abcd1234 :

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

Lorsque vous exécutez un test sans utiliser de jeton d'appareil, il s'exécute sur tous les appareils.

Questions fréquentes

Comment les certificats peuvent-ils être mis à jour sur l'UICC ?

A: Utiliser le mécanisme de mise à jour OTA de la carte existant.

L'UICC peut-elle coexister avec d'autres règles ?

R: Il est acceptable d'avoir d'autres règles de sécurité sur l'UICC avec le même AID. la plate-forme les filtre automatiquement.

Que se passe-t-il lorsque l'UICC est supprimé pour une application qui repose sur ou de certificats existants ?

A : L'application perd ses droits d'accès, car les règles associées à la carte UICC sont détruites lors de sa suppression.

Le nombre de certificats dans l'UICC est-il limité ?

A: La plate-forme ne limite pas le nombre de certificats. mais comme le est linéaire, un nombre excessif de règles peut entraîner une latence pour le test.

Le nombre d'API compatibles avec cette méthode est-il limité ?

R: Non, mais nous limitons le champ d'application aux API liées aux opérateurs.

Certaines API sont-elles interdites d'utiliser cette méthode ? Si oui, comment vous les appliquez ? (autrement dit, avez-vous des tests pour valider les API compatible avec cette méthode ?)

A: Consultez les Section "API Behavioral Compatibility" de la section "Android Compatibility" (Compatibilité Android) document de définition (CDD). Nous avons des tests CTS pour nous assurer que le modèle d'autorisation des API n'est pas modifié.

Comment cela fonctionne-t-il avec la fonctionnalité multi-SIM ?

A: La carte SIM par défaut spécifiée par l'utilisateur est utilisée.

Cette approche interagit-elle ou se chevauche-t-elle avec d'autres technologies d'accès aux services d'enchères, par exemple SEEK ?

A: Par exemple, SEEK utilise le même AID que sur la UICC. Les règles coexistent donc et sont filtrées par SEEK ou UiccCarrierPrivileges.

Quand est-il judicieux de vérifier les droits d'accès de l'opérateur ?

A: Après le chargement de l'état de la carte SIM.

Les OEM peuvent-ils désactiver une partie des API de l'opérateur ?

R: Non. Nous pensons que les API actuelles constituent l'ensemble minimal, et nous prévoient d'utiliser le masque de bits pour un contrôle plus précis à l'avenir.

setOperatorBrandOverride remplace-t-il TOUTE autre forme de chaîne de nom d'opérateur ? Par exemple, SE13, SPN UICC ou NITZ basé sur le réseau ?

Oui, le forçage de la marque de l'opérateur a la priorité la plus élevée. Lorsqu'il est défini, il remplace TOUTES les autres formes de chaînes de nom d'opérateur.

À quoi sert l'appel de méthode injectSmsPdu ?

R: Cette méthode facilite la sauvegarde/restauration de SMS dans le cloud. L'appel injectSmsPdu active la fonction de restauration.

Pour le filtrage des SMS, l'appel onFilterSms est-il basé sur le filtrage du port UDH des SMS ? Ou les applis des opérateurs ont-elles accès à TOUS les SMS entrants ?

A: Les opérateurs ont accès à toutes les données SMS.

L'extension de DeviceAppID-REF-DO pour prendre en charge 32 octets semblent être n'est pas compatible avec la spécification actuelle de GP (qui autorise uniquement 0 ou 20 octets), alors pourquoi apportez-vous ce changement ? SHA-1 n'est-il pas suffisant pour éviter les collisions ? Avez-vous déjà proposé cette modification à GP, car cela pourrait être rétrocompatible avec les ARA-M/ARF existants ?

A: Pour assurer une sécurité à long terme, cette extension introduit SHA-256 pour DeviceAppID-REF-DO en plus de SHA-1, qui est actuellement la seule option de la norme GP SEAC. Nous vous recommandons vivement d'utiliser SHA-256.

Si DeviceAppID est défini sur 0 (vide), appliquez-vous la règle à toutes les applications de l'appareil qui ne sont pas couvertes par une règle spécifique ?

A : Les API du transporteur exigent que DeviceAppID-REF-DO soit renseigné. La valeur vide est destinée aux tests et n'est pas recommandée pour les déploiements opérationnels.

D'après vos spécifications, PKG-REF-DO utilisé uniquement par elle-même, sans DeviceAppID-REF-DO, ne doit pas être acceptée. Toutefois, le tableau 6-4 de la spécification indique qu'il étend la définition de REF-DO. Est-ce intentionnel ? Comment se comporte le code lorsque seul PKG-REF-DO est utilisé dans REF-DO ?

A: La possibilité d'avoir PKG-REF-DO comme valeur unique élément dans REF-DO a été supprimé dans la dernière version. PKG-REF-DO ne doit apparaître qu'en combinaison avec DeviceAppID-REF-DO.

Nous supposons que nous pouvons accorder l'accès à toutes les autorisations basées sur l'opérateur ou disposer d'un contrôle plus précis. Si c'est le cas, qu'est-ce qui définit le mappage entre le bit et les autorisations réelles ? Une autorisation par classe ? Une autorisation par ? 64 autorisations distinctes suffisent-elles à long terme ?

A: Cela est réservé à l'avenir, et nous sommes à l'écoute de vos suggestions.

Pouvez-vous définir plus précisément DeviceAppID pour Android ? Il s'agit de la valeur de hachage SHA-1 (20 octets) du certificat de l'éditeur utilisé pour signer l'application donnée. Le nom ne devrait-il pas refléter cet objectif ? (Le nom pourrait prêter à confusion pour de nombreux lecteurs, car la règle est alors applicable à toutes les applications signées avec ce même certificat d'éditeur)

A : La spécification existante est compatible avec le stockage de certificats DeviceAppID. Nous avons essayé de minimiser les modifications de la spécification afin de réduire les obstacles à l'adoption. Pour en savoir plus, consultez les Règles concernant les UICC.