Privilèges du transporteur UICC

Android 5.1 a introduit un mécanisme permettant d'accorder des privilèges spéciaux aux API pertinentes pour les propriétaires d'applications de cartes à circuit intégré universelles (UICC). La plate-forme Android charge les certificats stockés sur un UICC et autorise les applications signées par ces certificats à appeler une poignée d'API spéciales.

Android 7.0 a étendu cette fonctionnalité pour prendre en charge d'autres sources de stockage pour les règles de privilèges des opérateurs UICC, augmentant ainsi considérablement le nombre d'opérateurs pouvant utiliser les API. Pour une référence API, voir CarrierConfigManager ; pour obtenir des instructions, voir Configuration du transporteur .

Les opérateurs ont le contrôle total de l'UICC, ce mécanisme fournit 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 privilèges spéciaux sur les appareils et sans avoir besoin de les utiliser. pour signer des applications avec le certificat de plate-forme par appareil ou préinstaller en tant qu'application système.

Règles sur l'UICC

Le stockage sur l'UICC est compatible avec la spécification GlobalPlatform Secure Element Access Control . L'identifiant d'application (AID) sur la carte est A00000015141434C00 et la commande standard 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 cartes en direct (OTA).

Hiérarchie des données

Les règles UICC utilisent la hiérarchie de données suivante (la combinaison de deux caractères lettre et chiffre entre parenthèses est la balise d'objet). Chaque règle est REF-AR-DO ( E2 ) et consiste en 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 ) est la chaîne de nom complet du package définie dans le manifeste, codée en ASCII, longueur maximale de 127 octets.
  • AR-DO ( E3 ) est étendu pour inclure PERM-AR-DO ( DB ), qui est un masque binaire 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 correspondre.

Exemple de règle

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

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

La règle sur l'UICC en 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 ajoute la prise en charge de la lecture des règles de privilèges 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'application de règles d'accès (ARA) AID A00000015141434C00 . S'il ne trouve pas l'AID sur l'UICC, il revient à l'ARF en sélectionnant PKCS15 AID A000000063504B43532D3135 . Android lit ensuite le fichier de règles de contrôle d'accès (ACRF) à 0x4300 et recherche les entrées avec 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 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 du 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 . Les applications signées par ce certificat bénéficient des privilèges de l'opérateur.

API activées

Android prend en charge les API suivantes.

Gestionnaire de téléphonie

TéléphonieRappel

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

Gestionnaire d'abonnements

Gestionnaire de SMS

CarrierConfigManager

  • Méthode pour notifier la configuration modifiée : notifyConfigChangedForSubId .
  • Méthode pour 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, voir Configuration du transporteur .

Gestionnaire de rapports de bogues

Méthode pour démarrer un rapport de bogue de connectivité, qui est une version spécialisée du rapport de bogue qui inclut uniquement des informations pour le débogage des problèmes liés à la connectivité : startConnectivityBugreport

Gestionnaire de statistiques de réseau

ImsMmTelManager

ImsRcsManager

Gestionnaire de provisionnement

EuiccManager

Méthode pour basculer vers (activer) l'abonnement donné : switchToSubscription

Service de messagerie de l'opérateur

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'intention avec l'action #SERVICE_INTERFACE . Les méthodes comprennent :

  • Méthode pour filtrer les messages SMS entrants : onFilterSms
  • Méthode pour intercepter les messages SMS envoyés depuis l'appareil : onSendTextSms
  • Méthode pour intercepter les messages SMS binaires envoyés depuis l'appareil : onSendDataSms
  • Méthode pour intercepter les longs messages SMS envoyés depuis l'appareil : onSendMultipartTextSms
  • Méthode pour intercepter les messages MMS envoyés depuis l'appareil : onSendMms
  • Méthode pour télécharger les messages MMS reçus : onDownloadMms

TransporteurService

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'intention avec l'action CARRIER_SERVICE_INTERFACE . Si le service a 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 avec des indicateurs spéciaux pour permettre au processus de service de transporteur de s'exécuter dans un compartiment de veille d'application spécial. Cela exempte l'application du service de l'opérateur de la restriction d'inactivité de l'application et la rend plus susceptible de rester en vie lorsque la mémoire de l'appareil est faible. Cependant, si l'application du service de l'opérateur plante pour une raison quelconque, elle perd tous les privilèges ci-dessus jusqu'à ce que l'application redémarre et que la liaison soit rétablie. Il est donc essentiel de maintenir la stabilité de l'application de service de l'opérateur.

Les méthodes de CarrierService incluent :

  • Pour remplacer et définir les configurations spécifiques à l'opérateur : onLoadConfig
  • Pour informer le système d'un changement intentionnel à venir du réseau de l'opérateur par l'application de l'opérateur : notifyCarrierNetworkChange

Fournisseur de téléphonie

API du fournisseur de contenu pour permettre des 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 plus de détails, reportez-vous à la référence de la classe Telephony

WifiRéseauSuggestion

Lors de la création d'un objet WifiNetworkSuggestion , utilisez les méthodes suivantes pour définir un ID d'abonnement ou un groupe d'abonnement :

Plateforme Android

Sur un UICC détecté, la plateforme construit des objets UICC internes qui incluent des règles de privilèges d'opérateur dans le cadre de l'UICC. UiccCarrierPrivilegeRules.java charge les règles, les analyse à partir de la carte UICC et les met en cache en 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 l'UICC est supprimé, les règles sont détruites avec l'objet UICC.

Validation

Pour valider l'implémentation via Compatibility Test Suite (CTS) à l'aide de CtsCarrierApiTestCases.apk , vous devez disposer d'un développeur UICC avec les règles UICC correctes ou la prise en charge ARF. Demandez au fournisseur de carte SIM de votre choix de préparer un UICC de développeur avec le bon ARF comme décrit dans cette section et utilisez cet UICC pour exécuter les tests. L'UICC ne nécessite pas de service cellulaire 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 les tests de l'API de l'opérateur CTS dans Android 12, l'appareil doit utiliser une carte SIM avec les privilèges de l'opérateur CTS répondant aux exigences spécifiées dans la dernière version de la spécification tierce GSMA TS.48 Test Profile .

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

Modification du profil SIM CTS

  1. Ajouter : privilèges de l'opérateur CTS dans le maître d'application de règles d'accès (ARA-M) ou ARF. Les deux signatures doivent être codées dans les règles de privilège du transporteur :
    1. Hachage1(SHA1) 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. 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 nécessaires pour CTS :
    1. EF_MBDN (6FC7), taille d'enregistrement : 28, numéro d'enregistrement : 4
      • Contenu
        1. Rec1 : 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n : FF…FF
    2. EF_EXT6 (6FC8), taille d'enregistrement : 13, numéro d'enregistrement : 1
      • Contenu : 00FF…FF
        1. EF_MBI (6FC9), taille d'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)
      • Contenu : A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Contenu : A0020000FF…FF
  5. Modifier : 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

Correspondance avec la structure du profil de test

Téléchargez et faites correspondre la dernière version des structures de profils de test génériques suivantes. Ces profils ne comporteront pas la règle CTS Carrier Privilege personnalisée ni les autres modifications répertoriées ci-dessus.

Exécution de tests

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

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

Lors de l'exécution d'un test sans utiliser de jeton d'appareil, le test s'exécute sur tous les appareils.

FAQ

Comment mettre à jour les certificats sur l'UICC ?

R : Utilisez le mécanisme de mise à jour OTA de la carte existant.

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

R : C'est bien d'avoir d'autres règles de sécurité sur l'UICC sous le même AID ; la plateforme les filtre automatiquement.

Que se passe-t-il lorsque l'UICC est supprimé pour une application qui s'appuie sur les certificats qu'elle contient ?

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

Y a-t-il une limite au nombre de certificats sur l'UICC ?

R : La plateforme ne limite pas le nombre de certificats ; mais comme la vérification est linéaire, un trop grand nombre de règles peut entraîner une latence pour la vérification.

Y a-t-il une limite au nombre d'API que nous pouvons prendre en charge avec cette méthode ?

R : Non, mais nous limitons la portée aux API liées aux opérateurs.

Existe-t-il certaines API interdites d'utiliser cette méthode ? Si oui, comment les appliquez-vous ? (c'est-à-dire, disposez-vous de tests pour valider quelles API sont prises en charge avec cette méthode ?)

R : Consultez la section Compatibilité comportementale des API du document de définition de compatibilité Android (CDD). 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 ?

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

Est-ce que cela interagit ou se chevauche d'une manière ou d'une autre avec d'autres technologies d'accès SE, par exemple SEEK ?

R : A titre d'exemple, SEEK utilise le même AID que sur l'UICC. Les règles coexistent donc et sont filtrées soit par SEEK, soit UiccCarrierPrivileges .

Quel est le bon moment pour vérifier les privilèges du transporteur ?

R : Après la diffusion chargée de l’état de la carte SIM.

Les OEM peuvent-ils désactiver une partie des API des opérateurs ?

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 fin de la granularité à l’avenir.

setOperatorBrandOverride remplace-t-il TOUTES les autres formes de chaînes de noms d’opérateur ? Par exemple, SE13, UICC SPN 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 noms d'opérateur.

À quoi sert l’appel à la méthode injectSmsPdu ?

R : 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 des ports SMS UDH ? Ou les applications des opérateurs ont-elles accès à TOUS les SMS entrants ?

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

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

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 fortement d'utiliser SHA-256.

Si DeviceAppID est 0 (vide), appliquez-vous la règle à toutes les applications d’appareil non couvertes par une règle spécifique ?

R : Les API de l'opérateur nécessitent DeviceAppID-REF-DO soit renseigné. Être vide est destiné à des fins de test et n'est pas recommandé pour les déploiements opérationnels.

Selon vos spécifications, PKG-REF-DO utilisé seul, sans DeviceAppID-REF-DO , ne devrait pas être accepté. Mais il est toujours décrit dans le tableau 6-4 de la spécification comme étendant la définition de REF-DO . Est-ce exprès ? Comment se comporte le code lorsque seul PKG-REF-DO est utilisé dans REF-DO ?

R : L'option d'avoir PKG-REF-DO comme élément à 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 avoir 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 sont-elles suffisantes à long terme ?

R : Ceci est réservé pour l’avenir et nous apprécions les 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 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 Publisher.)

R : Les certificats de stockage DeviceAppID sont pris en charge par la spécification existante. Nous avons essayé de minimiser les modifications de spécifications afin de réduire les obstacles à l'adoption. Pour plus de détails, voir Règles sur UICC .