Privilèges de 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 carte de circuit intégré universelle (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ège des opérateurs UICC, augmentant considérablement le nombre d'opérateurs pouvant utiliser les API. Pour une référence API, voir CarrierConfigManager ; pour obtenir des instructions, reportez-vous à la section Configuration de l'opérateur .

Les opérateurs ont le contrôle total de l'UICC, ce mécanisme offre donc un moyen sûr 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 le besoin 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 extraire les règles stockées sur la carte. Vous pouvez mettre à jour ces règles via des mises à jour de carte en direct (OTA).

Hiérarchie des données

Les règles UICC utilisent la hiérarchie de données suivante (la combinaison de lettres et de chiffres à deux caractères 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 complète du nom du package définie dans le manifeste, encodée en ASCII, longueur maximale de 127 octets.
  • AR-DO ( E3 ) est étendu pour inclure PERM-AR-DO ( DB ), qui est un masque de bits 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 UICC en chaîne hexadécimale est :

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

Prise en charge du fichier de règles d'accès (ARF)

Android 7.0 ajoute la prise en charge de la lecture des règles de privilège 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'identifiant d'application (AID) A00000015141434C00 de l'applet de règle d'accès (ARA). S'il ne trouve pas l'AID sur l'UICC, il revient à 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 différents AID sont ignorées, de sorte que 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 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.

TelephonyManager

Gestionnaire de SMS

Méthode permettant à l'appelant de créer de nouveaux SMS entrants : injectSmsPdu .

CarrierConfigManager

Méthode pour notifier la modification de la configuration : notifyConfigChangedForSubId . Pour obtenir des instructions, consultez Configuration de l'opérateur .

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

Fournisseur de téléphonie

API du fournisseur de contenu pour permettre 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 plus de détails, reportez-vous à la référence de l'API de téléphonie sur developer.android.com.

Plate-forme Androïd

Sur un UICC détecté, la plate-forme construit des objets UICC internes qui incluent des règles de privilège de transporteur 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 CtsCarrierApiTestCases.apk , vous devez disposer d'un développeur UICC avec les règles UICC correctes ou la prise en charge ARF. Vous pouvez demander au fournisseur de carte SIM de votre choix de préparer un développeur UICC avec le bon ARF comme décrit dans cette section et d'utiliser cet UICC pour exécuter les tests. L'UICC n'exige pas de service cellulaire actif pour réussir les tests CTS.

Préparation de 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 la valeur de hachage cts-uicc-2021-testkey 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 d'opérateur CTS dans Android 12, l'appareil doit utiliser une carte SIM avec des privilèges d'opérateur CTS répondant aux exigences spécifiées dans la dernière version de la spécification tierce du profil de test GSMA TS.48 .

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

Modification du profil SIM CTS

  1. Ajouter : CTS Carrier Privileges en ARA-M ou ARF. Les deux signatures doivent être encodé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. Hachage2(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
  1. Créer : 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
  2. Modifier : Tableau des services USIM : Activer les services n°47, n°48
    1. EF_UST (6F38)
      • Contenu : 9EFFBF1DFFFE0083410310010400406E01
  3. 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
  4. Modifier : les chaînes du nom de l'opérateur doivent être 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

Faire 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. Ces profils n'auront pas la règle CTS Carrier Privilege personnalisée ou d'autres modifications énumérées ci-dessus.

Tests en cours

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 Carrier API CTS 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 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 existante.

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 la 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 plate-forme 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.

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

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

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

R : Consultez la section "Compatibilité comportementale de l'API" du document de définition de compatibilité Android (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 ?

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

Cela interagit-il ou chevauche-t-il d'une quelconque manière avec d'autres technologies d'accès SE, par exemple, SEEK ?

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

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

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

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 précis de la granularité à l'avenir.

Est-ce que setOperatorBrandOverride remplace TOUTES les autres formes de chaînes de nom d'opérateur ? Par exemple, SE13, UICC SPN ou NITZ basé sur le réseau ?

R : Reportez-vous à l'entrée SPN dans TelephonyManager

Que fait l'appel de 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 SMS, l'appel onFilterSms est-il basé sur le filtrage de port UDH SMS ? Ou les applications de l'opérateur 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 incompatible avec la spécification GP actuelle (qui n'autorise que 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 fournir une sécurité à l'épreuve du temps, 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 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 que 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 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 se produire 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 suffisent-elles à long terme ?

R : Ceci est réservé pour l'avenir, et nous accueillons les suggestions.

Pouvez-vous définir plus 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 doit-il donc pas refléter cet objectif ? (Le 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.)

R : Les certificats de stockage DeviceAppID sont pris en charge par la spécification existante. Nous avons essayé de minimiser les changements de spécifications pour abaisser la barrière à l'adoption. Pour plus de détails, voir Règles sur l'UICC .