Droits d'opérateur 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 La plate-forme Android charge les certificats stockés sur un UICC et accorde l'autorisation à des applications signées par ces certificats pour appeler 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 au droit d'opérateur, en augmentant le nombre d'opérateurs pouvant utiliser les API. Pour consulter la documentation de référence de l'API, voir CarrierConfigManager. pour obtenir des instructions, voir Opérateur Configuration.

Les opérateurs ont un contrôle total sur UICC. Ce mécanisme leur fournit donc 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 (comme Google Play), tandis que en conservant des privilèges spéciaux sur les appareils, sans avoir à signer des applications avec le certificat de la plate-forme par appareil ou la préinstallation en tant qu'application système.

Règles relatives à UICC

Le stockage sur UICC est compatible avec <ph type="x-smartling-placeholder"></ph> Plate-forme mondiale Spécification du contrôle d'accès au composant sécurisé. Identifiant de l'application (AID) 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 de carte Over The Air (OTA).

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 consiste en une concaténation des éléments suivants : 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 le nom complet du package. chaîne définie dans le fichier manifeste, encodée au format ASCII et ne dépassant pas 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 obtient 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 UICC dans la chaîne hexadécimale est:

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. Si elle 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 du certificat 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 Applications signés par ce certificat se voient accorder des privilèges 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 notifier 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 savoir comment procéder, consultez Carrier Configuration (Configuration de l'opérateur) :

Gestionnaire de rapport de bug

Méthode pour démarrer un rapport de bug de connectivité, qui est une version spécialisée de Le rapport de bug qui ne contient que des informations pour le débogage des problèmes de connectivité problèmes: <ph type="x-smartling-placeholder"></ph> startConnectivityBugreport

Gestionnaire de statistiques réseau

  • Méthode d'interrogation du récapitulatif de l'utilisation du réseau: <ph type="x-smartling-placeholder"></ph> querySummary
  • Méthode pour interroger l'historique d'utilisation du réseau: <ph type="x-smartling-placeholder"></ph> queryDetails
  • Méthodes pour enregistrer ou annuler l'enregistrement d'un rappel d'utilisation du réseau: <ph type="x-smartling-placeholder">

Gestionnaire d'impression

Gestionnaire imsRcs

ProvisioningManager

EuiccManager

Méthode pour passer à (activer) l'abonnement donné: <ph type="x-smartling-placeholder"></ph> switchToSubscription

CarrierMessagingService

Service recevant des appels du système lors de l'envoi de nouveaux SMS et MMS reçues. Pour étendre cette classe, déclarez le service dans votre fichier manifeste avec l'/le/la android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE l'autorisation et inclure un filtre d'intent avec #SERVICE_INTERFACE action. Les méthodes sont les suivantes:

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

Service du transporteur

Service qui expose les fonctionnalités spécifiques à l'opérateur au système. À étendez cette classe, déclarez le service dans le fichier manifeste de l'application avec Autorisation android.Manifest.permission#BIND_CARRIER_SERVICES et inclure 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 associe CarrierService à l'aide d'indicateurs spéciaux pour permettre au de service de transporteur doit s'exécuter dans un environnement bucket de mise en veille des applications. Cela permet d'exempter l'application du service de l'opérateur <ph type="x-smartling-placeholder"></ph> restriction d'inactivité de l'application et augmente les chances qu'elle reste active lorsque l'appareil la mémoire 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 l'application de service de l'opérateur stable.

Voici quelques méthodes dans CarrierService:

  • Pour ignorer et définir les configurations spécifiques à l'opérateur: <ph type="x-smartling-placeholder"></ph> 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 de fournisseurs de contenu permettant les modifications (insertion, suppression, mise à jour, requête) à la base de données téléphonique. Les champs de valeurs sont définis <ph type="x-smartling-placeholder"></ph> Telephony.Carriers Pour en savoir plus, consultez <ph type="x-smartling-placeholder"></ph> la documentation de référence de la classe Telephony.

Wi-FiNetworkSuggestion

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. <ph type="x-smartling-placeholder"></ph> UiccCarrierPrivilegeRules.java charge les règles, les analyse à partir de la fiche 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 UICC est supprimé, le sont détruits 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 la carte SIM de votre choix de préparer un UICC développeur avec le comme décrit dans cette section, et utilisez cet 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 <ph type="x-smartling-placeholder"></ph> 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 dans les règles de privilèges de l'opérateur: <ph type="x-smartling-placeholder">
      </ph>
    1. Hachage 1(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éer:fichiers élémentaires (EF) ADF USIM non présents dans TS.48 et requis pour CTS: <ph type="x-smartling-placeholder">
      </ph>
    1. EF_MBDN (6FC7), taille de l'enregistrement: 28, numéro d'enregistrement: 4 <ph type="x-smartling-placeholder">
        </ph>
      • Contenu <ph type="x-smartling-placeholder">
          </ph>
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
        2. Rec2-n: FF...FF
    2. EF_EXT6 (6FC8), taille de l'enregistrement:13, numéro de l'enregistrement: 1 <ph type="x-smartling-placeholder">
        </ph>
      • Contenu: 00FF...FF <ph type="x-smartling-placeholder">
          </ph>
        1. EF_MBI (6FC9), taille de l'enregistrement: 4, numéro de l'enregistrement: 1
      • Contenu: Rec1: 01010101 <ph type="x-smartling-placeholder">
          </ph>
        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 <ph type="x-smartling-placeholder">
      </ph>
    1. EF_UST (6F38) <ph type="x-smartling-placeholder">
        </ph>
      • Contenu : 9EFFBF1DFFFE0083410310010400406E01
  4. Modifier:fichiers DF-5GS et DF-SAIP <ph type="x-smartling-placeholder">
      </ph>
    1. DF-5GS : EF_5GS3GPPLOCI (USIM/5FC0/4F01) <ph type="x-smartling-placeholder">
        </ph>
      • Contenu : FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS : EF_5GSN3GPPLOCI (USIM/5FC0/4F02) <ph type="x-smartling-placeholder">
        </ph>
      • 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: <ph type="x-smartling-placeholder">
      </ph>
    1. EF_SPN (USIM/6F46) <ph type="x-smartling-placeholder">
        </ph>
      • Contenu : 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5) <ph type="x-smartling-placeholder">
        </ph>
      • 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 concernant les droits d'opérateur CTS ne sera pas personnalisée ni modifiée pour ces profils comme indiqué ci-dessus.

Exécuter des tests

Pour plus de commodité, CTS prend en charge un jeton d'appareil qui limite les tests ne s'exécuteront que 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 l'exécution des tests de l'API de l'opérateur à l'appareil uniquement abcd1234:

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

Lorsque vous exécutez un test sans 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 ?

R: L'application perd ses privilèges, car les règles associées UICC sont détruits lors de la suppression d'UICC.

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 de vérification.

Y a-t-il une limite au nombre d'API que nous pouvons prendre en charge dans ce ?

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 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.

Cela interagit-il d'une manière ou d'une autre avec l'accès d'autres SE par exemple, SEEK ?

R: Par exemple, SEEK utilise le même AID que sur l'UICC. Les règles coexistent et sont filtrés par SEEK ou UiccCarrierPrivileges.

Quel est le meilleur moment pour vérifier les avantages 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 d'opérateurs ?

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.

Est-ce que setOperatorBrandOverride remplace TOUS les autres formulaires ? de l'opérateur des chaînes de nom ? 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 TOUS d'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. La L'appel injectSmsPdu active la fonction de restauration.

Pour le filtrage des SMS, l'appel onFilterSms est-il basé sur Filtrage des ports UDH pour les 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 offrir une sécurité pérenne, cette extension introduit SHA-256. pour DeviceAppID-REF-DO, en plus de SHA-1, qui est actuellement la seule option dans la norme GP SEAC. Nous vous recommandons vivement d'utiliser SHA-256.

Si DeviceAppID est défini sur 0 (vide), la règle est-elle appliquée toutes les applications de l'appareil non soumises à une règle spécifique ?

A: Les API de transporteur nécessitent que le champ DeviceAppID-REF-DO soit renseigné. L'espace de stockage vide est destiné à des fins de test et n'est pas recommandé pour les les déploiements.

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, il est toujours décrit dans le tableau 6-4 de la spécification comme l'extension définition de REF-DO. Est-ce délibéré ? Comment fonctionne le code se comporte-t-il 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 ou avoir 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 ?

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 ? en particulier ? Il s'agit de la valeur de hachage SHA-1 (20 octets) de l'éditeur utilisé pour signer l'application donnée, son nom ne doit donc pas refléter ce l'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: Le stockage des certificats DeviceAppID est pris en charge par le spécification existante. Nous avons essayé de minimiser les changements de spécifications afin de réduire les obstacles à le taux d'adoption. Pour en savoir plus, consultez Règles relatives à UICC.