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
) contientDeviceAppID-REF-DO
ou une concaténation deDeviceAppID-REF-DO
etPKG-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 inclurePERM-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 des fichiers de règles d'accès
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'application de règle d'accès (ARA) AID A00000015141434C00
. 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 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
- Méthode permettant à l'application de l'opérateur de demander à l'UICC un défi/réponse :
getIccAuthentication
. - Méthode pour vérifier si l'application appelante a obtenu les privilèges de l'opérateur :
hasCarrierPrivileges
. - Méthodes pour remplacer la marque et le numéro :
- Méthodes de communication UICC directe :
- Méthode pour définir le mode de périphérique sur global :
setPreferredNetworkTypeToGlobal
. - Méthodes pour obtenir les identités de l'appareil ou du réseau :
- Identité internationale d'équipement mobile (IMEI) :
getImei
- Identifiant d'équipement mobile (MEID) :
getMeid
- Identifiant d'accès au réseau (NAI) :
getNai
- Numéro de série SIM :
getSimSerialNumber
- Identité internationale d'équipement mobile (IMEI) :
- Méthode pour obtenir la configuration de l'opérateur :
getCarrierConfig
- Méthode pour obtenir le type de réseau pour la transmission de données :
getDataNetworkType
- Méthode pour obtenir le type de réseau pour le service vocal :
getVoiceNetworkType
- Méthodes pour obtenir les informations sur l'application UICC SIM (USIM):
- Numéro de série SIM :
getSimSerialNumber
- Informations sur la carte :
getUiccCardsInfo
- GID1 (ID de groupe niveau1) :
getGroupIdLevel1
- Chaîne de numéro de téléphone pour la ligne 1 :
getLine1Number
- Réseau mobile terrestre public (PLMN) interdit :
getForbiddenPlmns
- PLMN domestique équivalent :
getEquivalentHomePlmns
- Numéro de série SIM :
- Méthodes pour obtenir ou définir un numéro de messagerie vocale :
- Méthode pour envoyer un code de numérotation spécial :
sendDialerSpecialCode
- Méthode pour réinitialiser le modem radio :
rebootModem
- Méthodes pour obtenir ou définir les modes de sélection de réseau :
- Méthode pour demander une analyse du réseau :
requestNetworkScan
- Méthodes pour obtenir ou définir les types de réseau autorisés/préférés :
- Méthodes pour vérifier si les données mobiles ou l'itinérance sont activées selon les paramètres utilisateur :
- Méthodes pour vérifier ou définir la connexion de données avec raison :
- Méthode pour obtenir la liste des numéros d'urgence :
getEmergencyNumberList
- Méthodes pour contrôler les réseaux opportunistes :
- Méthodes pour définir ou effacer la demande de mise à jour de la force du signal cellulaire :
TéléphonieRappel
TelephonyCallback
a des interfaces avec une méthode de rappel pour notifier l'application appelante lorsque les états enregistrés changent :
- L'indicateur de message en attente a changé :
onMessageWaitingIndicatorChanged
- L'indicateur de renvoi d'appel a changé :
onCallForwardingIndicatorChanged
- La cause de déconnexion d'appel du système multimédia IP (IMS) a changé :
onImsCallDisconnectCauseChanged
- L'état précis de la connexion de données a changé :
onPreciseDataConnectionStateChanged
- La liste actuelle des numéros d'urgence a changé :
onEmergencyNumberListChanged
- L'ID d'abonnement aux données actives a changé :
onActiveDataSubscriptionIdChanged
- Le réseau de l'opérateur a changé :
onCarrierNetworkChange
- L'enregistrement du réseau ou une mise à jour de la zone de localisation/routage/suivi a échoué :
onRegistrationFailed
- Les informations d'interdiction changent :
onBarringInfoChanged
- La configuration actuelle du canal physique a changé :
onPhysicalChannelConfigChanged
Gestionnaire d'abonnement
- Méthodes pour obtenir diverses informations d'abonnement :
- Méthode pour obtenir le nombre d'abonnements actifs :
getActiveSubscriptionInfoCount
- Méthodes de gestion des groupes d'abonnement :
- Méthodes pour obtenir ou définir la description du plan de relation de facturation entre un opérateur et un abonné spécifique :
- Méthode pour remplacer temporairement le plan de relation de facturation entre un opérateur et un abonné spécifique pour qu'il soit considéré comme illimité :
setSubscriptionOverrideUnmetered
- Méthode pour remplacer temporairement le plan de relation de facturation entre un opérateur et un abonné spécifique pour être considéré comme congestionné :
setSubscriptionOverrideCongested
- Méthode pour vérifier si l'application avec le contexte donné est autorisée à gérer l'abonnement donné en fonction de ses métadonnées :
canManageSubscription
Gestionnaire de SMS
- Méthode permettant à l'appelant de créer de nouveaux SMS entrants :
injectSmsPdu
. - Méthode pour envoyer un message SMS basé sur du texte sans écrire dans le fournisseur de SMS :
sendTextMessageWithoutPersisting
CarrierConfigManager
- Méthode pour notifier la modification de la configuration :
notifyConfigChangedForSubId
. - Méthode pour obtenir la configuration de l'opérateur pour l'abonnement par défaut :
getConfig
- Méthode pour 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 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
NetworkStatsManager
- Méthode pour interroger le résumé de l'utilisation du réseau :
querySummary
- Méthode pour interroger l'historique d'utilisation du réseau :
queryDetails
- Méthodes pour enregistrer ou désenregistrer le rappel d'utilisation du réseau :
ImsMmTelManager
- Méthodes pour enregistrer ou désenregistrer le rappel d'enregistrement IMS MmTel :
ImsRcsManager
- Méthodes pour enregistrer ou désenregistrer le rappel d'enregistrement IMS RCS :
- Méthodes pour obtenir l'état d'enregistrement IMS ou le type de transport :
ProvisioningManager
- Méthodes pour enregistrer et désenregistrer le rappel des mises à jour de provisionnement des fonctionnalités IMS :
- Méthodes liées à l'état d'approvisionnement pour la capacité IMS MmTel ou RCS :
EuiccManager
Méthode pour basculer vers (activer) l'abonnement donné : 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'intention avec l'action #SERVICE_INTERFACE
. Les méthodes incluent :
- Méthode pour filtrer les SMS entrants :
onFilterSms
- Méthode pour intercepter les SMS envoyés depuis l'appareil :
onSendTextSms
- Méthode pour intercepter les SMS binaires envoyés depuis l'appareil :
onSendDataSms
- Méthode pour intercepter les messages SMS longs 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
CarrierService
Service qui expose au système des fonctionnalités spécifiques à l'opérateur. 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 de service de l'opérateur de la restriction d'inactivité de l'application et la rend plus susceptible de rester active lorsque la mémoire de l'appareil est faible. Cependant, si l'application de service de l'opérateur tombe en panne 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 prochain changement intentionnel 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 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 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 :
- Méthode pour définir un ID d'abonnement :
setSubscriptionId
- Méthode pour définir un groupe d'abonnement :
setSubscriptionGroup
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 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 développeur UICC avec le bon ARF comme décrit dans cette section et utilisez cet UICC pour exécuter les tests. L'UICC n'exige 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 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 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
- Ajouter : Privilèges de transporteur CTS dans le maître d'application de règle d'accès (ARA-M) ou ARF. Les deux signatures doivent être encodées dans les règles de privilège du transporteur :
-
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
-
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
-
- Créer : Fichiers élémentaires (EF) ADF USIM non présents dans TS.48 et nécessaires pour CTS :
- EF_MBDN (6FC7), taille d'enregistrement : 28, numéro d'enregistrement : 4
- Contenu
- Rec1 : 566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-n : FF…FF
- Contenu
- EF_EXT6 (6FC8), taille d'enregistrement : 13, numéro d'enregistrement : 1
- Contenu : 00FF…FF
- EF_MBI (6FC9), taille d'enregistrement : 4, numéro d'enregistrement : 1
- Contenu : Rec1 : 01010101
- EF_MWIS (6FCA), taille d'enregistrement : 5, numéro d'enregistrement : 1
- Contenu : 0000000000
- Contenu : 00FF…FF
- EF_MBDN (6FC7), taille d'enregistrement : 28, numéro d'enregistrement : 4
- Modifier : Tableau des services USIM : Activer les services n°47, n°48
- EF_UST (6F38)
- Contenu :
9EFFBF1DFFFE0083410310010400406E01
- Contenu :
- EF_UST (6F38)
- Modifier : fichiers DF-5GS et DF-SAIP
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Contenu :
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Contenu :
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- Contenu :
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Contenu :
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- Contenu :
A0020000FF…FF
- Contenu :
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- Contenu :
A0020000FF…FF
- Contenu :
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Modifier : utilisez la chaîne de nom de transporteur Android CTS dans les EF respectifs contenant cette désignation :
- EF_SPN (USIM/6F46)
- Contenu :
01416E64726F696420435453FF..FF
- Contenu :
- EF_PNN (USIM/6FC5)
- Contenu :
Rec1 430B83413759FE4E934143EA14FF..FF
- Contenu :
- EF_SPN (USIM/6F46)
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 ?
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.
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 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
doit se produire uniquement 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 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 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 .