Droits d'opérateur UICC

Android 5.1 a introduit un mécanisme permettant d'accorder des droits spéciaux aux API pertinentes pour les propriétaires d'applications de carte de circuit intégré universel (UICC). 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 un certain nombre d'API spéciales.

Android 7.0 a étendu cette fonctionnalité afin de prendre en charge d'autres sources de stockage pour les règles de droit de transporteur UICC, ce qui a considérablement augmenté le nombre de transporteurs 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 relatives à UICC

L'espace de stockage de la carte UICC est compatible avec la spécification de contrôle des accès des éléments sécurisés GlobalPlatform. L'identifiant d'application (AID) sur la carte est A00000015141434C00, et la commande standard GET DATA permet d'extraire 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 combinaison de deux caractères lettres et 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 la signature SHA-1 (20 octets) ou SHA-256 (32 octets) du certificat.
    • PKG-REF-DO (CA) correspond à la chaîne complète du nom du package définie dans le fichier manifeste, encodée au format ASCII et ne doit pas dépasser 127 octets.
  • AR-DO (E3) est étendu pour inclure PERM-AR-DO (DB), qui est un masque de 8 bits représentant 64 autorisations distinctes.

Si PKG-REF-DO n'est pas présent, l'accès est accordé à toutes les applications signées par le certificat. Sinon, le certificat et le nom du package doivent correspondre.

Exemple de règle

Le nom de l'application est com.google.android.apps.myapp et le certificat SHA-1 sous forme de chaîne hexadécimale est le suivant:

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

Prise en charge des fichiers de règles d'accès

Android 7.0 permet de lire les règles d'accès de l'opérateur à partir du fichier de règles d'accès (ARF).

La plate-forme Android tente d'abord de sélectionner l'AID A00000015141434C00 de l'application de règle d'accès (ARA). S'il ne trouve pas l'AID sur l'UICC, il revient à l'ARF en sélectionnant l'AID PKCS15 A000000063504B43532D3135. Android lit ensuite le fichier de règles de contrôle d'accès (ACRF) dans 0x4300 et recherche les entrées avec l'AID FFFFFFFFFFFF. Les entrées avec des AID différents sont ignorées, de sorte que les règles pour d'autres cas d'utilisation puissent 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 du fichier de conditions de contrôle des 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.

Gestionnaire de téléphonie

TelephonyCallback

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

SubscriptionManager

Gestionnaire SMS

CarrierConfigManager

  • Méthode pour informer de la modification de la configuration : notifyConfigChangedForSubId.
  • Méthode permettant d'obtenir la configuration de l'opérateur pour l'abonnement par défaut : getConfig
  • Méthode permettant d'obtenir la configuration de l'opérateur pour l'abonnement spécifié : getConfigForSubId

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

BugreportManager

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

Gestionnaire de statistiques réseau

Gestionnaire d'impression

Gestionnaire imsRcs

ProvisioningManager

EuiccManager

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

CarrierMessagingService

Service qui reçoit des 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. Les méthodes sont les suivantes:

  • Méthode de filtrage des SMS entrants : onFilterSms
  • Méthode permettant d'intercepter les SMS envoyés depuis l'appareil : onSendTextSms
  • Méthode permettant d'intercepter les messages SMS binaires envoyés depuis l'appareil: onSendDataSms
  • Méthode permettant d'intercepter les longs SMS 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 sur 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 du transporteur plante pour une raison quelconque, elle perd tous les droits ci-dessus jusqu'à ce que l'application redémarre et que la liaison soit rétablie. Il est donc essentiel de maintenir l'application de service de l'opérateur stable.

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 de l'opérateur par l'application de l'opérateur : notifyCarrierNetworkChange

Fournisseur de téléphonie

Les API de fournisseurs de contenu pour autoriser les modifications (insertion, suppression, mise à jour, requête) de la base de données de téléphonie Les champs de valeurs sont définis dans 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 les méthodes suivantes pour définir un ID d'abonnement ou un groupe d'abonnements:

Plate-forme Android

Lorsqu'une UICC est détectée, la plate-forme crée des objets UICC internes qui incluent des règles d'autorisation de l'opérateur dans la UICC. UiccCarrierPrivilegeRules.java charge les règles, les analyse à partir de la fiche UICC et les met en cache dans la mémoire. Lorsqu'une vérification des privilèges est nécessaire, UiccCarrierPrivilegeRules compare le 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 la suite de tests de compatibilité (CTS) en utilisant CtsCarrierApiTestCases.apk, vous devez disposer d'un UICC de développeur avec les règles UICC appropriées ou la compatibilité ARF. Demandez au fournisseur de cartes 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. L'UICC n'a pas besoin d'un service mobile actif pour réussir les tests CTS.

Préparer l'UICC

Pour Android 11 et versions antérieures, CtsCarrierApiTestCases.apk est signé par aosp-testkey, avec la 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.

Pour exécuter des tests d'API de l'opérateur CTS sous Android 12, l'appareil doit utiliser une carte SIM avec des droits d'opérateur CTS conformes aux exigences spécifiées dans la dernière version de la spécification profil de test GSMA TS.48 tierce.

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 du transporteur CTS dans le maître d'application de règles d'accès (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 de l'enregistrement: 4 
      • Contenu
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), taille de l'enregistrement:13, numéro de l'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 de l'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. Modification: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)
      • Contenu : A0020000FF…FF
    4. DF-SAIP : EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Contenu : A0020000FF…FF
  5. Modification:utilisez la chaîne de nom de l'opérateur Android CTS dans les EF respectifs contenant cette désignation :
    1. EF_SPN (USIM/6F46)
      • Contenu : 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Contenu : Rec1 430B83413759FE4E934143EA14FF..FF

Correspondre à la structure du profil de test

Téléchargez et faites correspondre la dernière version des structures de profil de test génériques suivantes. 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. Les tests CTS de l'API du transporteur sont compatibles avec le jeton d'appareil sim-card-with-certs. Par exemple, le jeton d'appareil suivant limite l'exécution des tests de l'API de l'opérateur à 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 ?

A: 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 les certificats qu'elle contient ?

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 sur la carte UICC est-il limité ?

A: La plate-forme ne limite pas le nombre de certificats. Toutefois, comme la vérification est linéaire, un trop grand nombre de règles peut entraîner une latence de vérification.

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.

Existe-t-il des API interdites à l'utilisation de cette méthode ? Si oui, comment les appliquez-vous ? (autrement dit, avez-vous des tests pour vérifier quelles API sont compatibles avec cette méthode ?)

R: Consultez la section Compatibilité avec le comportement de l'API du document de définition de compatibilité (CDD) Android. Nous effectuons 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.

À quel moment préférez-vous vérifier les avantages de l'opérateur ?

A: Après la diffusion de l'état de la carte SIM chargé.

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évoyons d'utiliser le masque de bits pour un contrôle plus précis à l'avenir.

Est-ce que setOperatorBrandOverride remplace TOUTES les autres formes de chaînes de noms d'opérateurs ? (par exemple, SE13, SPN UICC ou NITZ basé sur le réseau) ?

Oui, le remplacement 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 la méthode injectSmsPdu ?

A: Cette méthode facilite la sauvegarde/restauration des 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 applications de l'opérateur ont-elles accès à TOUS les SMS entrants ?

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

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

R: Pour assurer une sécurité évolutive, 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 non couvertes par une règle spécifique ?

A: Les API de transporteur nécessitent que le champ 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.

Selon votre spécification, PKG-REF-DO utilisé uniquement par lui-même, sans DeviceAppID-REF-DO, ne doit pas être accepté. 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 ?

R: L'option permettant d'avoir PKG-REF-DO comme élément de valeur unique dans REF-DO a été supprimée 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 oui, qu'est-ce qui définit le mappage entre le masque de bits et les autorisations réelles ? Une autorisation par classe ? Une autorisation par méthode ? 64 autorisations distinctes suffisent-elles à long terme ?

R: Cette proposition est réservée pour l'avenir. N'hésitez pas à nous faire part 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 d'éditeur utilisé pour signer l'application donnée. Le nom ne doit-il donc pas refléter cet objectif ? (Ce nom peut prêter à confusion pour de nombreux lecteurs, car la règle s'applique alors à toutes les applications signées avec ce même certificat d'éditeur.)

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