Android 5.1 a introduit un mécanisme permettant d'accorder des privilèges spéciaux pour les 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 une UICC et autorise les applications signées par ces certificats à effectuer des appels à un petit nombre 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 de l'opérateur UICC, ce qui a considérablement augmenté le nombre d'opérateurs pouvant utiliser les API. Pour obtenir une documentation de référence sur l'API, consultez CarrierConfigManager. Pour obtenir des instructions, consultez Configuration de l'opérateur.
Les opérateurs ont un contrôle total sur l'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 (ORM) 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 signer les applications avec le certificat de plate-forme par appareil ni de les 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 les mises à jour OTA (Over-The-Air) 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, une lettre et un chiffre, entre parenthèses correspond à la balise 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) contientDeviceAppID-REF-DOou une concaténation deDeviceAppID-REF-DOetPKG-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 du nom complet du package définie dans le fichier 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 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
Compatibilité avec les fichiers de règles d'accès
Android 7.0 permet de lire les règles relatives aux droits d'accès des opérateurs à 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). Si elle ne trouve pas l'AID sur l'UICC, elle 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) à l'emplacement 0x4300 et recherche les entrées avec l'AID FFFFFFFFFFFF. Les entrées avec des AID différents sont ignorées, ce qui permet aux règles pour d'autres cas d'utilisation de 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. Les applications signées par ce certificat bénéficient de privilèges d'opérateur.
API activées
Android est compatible avec les API suivantes.
TelephonyManager
- Méthode permettant à l'application de l'opérateur de demander un challenge/une réponse à l'UICC :
getIccAuthentication. - Méthode permettant de vérifier si l'application appelante a obtenu des droits d'accès à 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 l'appareil sur "global" :
setPreferredNetworkTypeToGlobal. - Méthodes permettant d'obtenir les identités de l'appareil ou du réseau :
- Identifiant international 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 de la carte SIM :
getSimSerialNumber - ID d'abonnement :
getSubscriptionId - ID d'abonné (IMSI) :
getSubscriberId
- Identifiant international d'équipement mobile (IMEI) :
- Méthode pour obtenir la configuration de l'opérateur :
getCarrierConfig - Méthode permettant d'obtenir le type de réseau pour la transmission de données :
getDataNetworkType - Méthode permettant d'obtenir le type de réseau pour le service vocal :
getVoiceNetworkType - Méthode pour obtenir l'état du service :
getServiceState - Méthode permettant d'obtenir l'état de l'appel de l'abonnement :
getCallStateForSubscription - Méthodes pour obtenir des informations sur l'application UICC SIM (USIM) :
- Numéro de série de la carte SIM :
getSimSerialNumber - Informations sur la carte :
getUiccCardsInfo - GID1 (ID de groupe de niveau 1) :
getGroupIdLevel1 - Chaîne du numéro de téléphone pour la ligne 1 :
getLine1Number - Réseau mobile terrestre public (PLMN) interdit :
getForbiddenPlmns - PLMN équivalent :
getEquivalentHomePlmns
- Numéro de série de la carte SIM :
- Méthodes pour obtenir ou définir le numéro de messagerie vocale :
- Méthode pour envoyer un code spécial du clavier :
sendDialerSpecialCode - Méthode pour réinitialiser le modem radio :
rebootModem - Méthode pour vérifier si le modem est activé pour l'emplacement :
isModemEnabledForSlot - Méthode pour vérifier si la fonctionnalité multi-SIM est prise en charge :
isMultiSimSupported - Méthode permettant de vérifier si le changement de configuration multi-SIM déclenche un redémarrage :
doesSwitchMultiSimConfigTriggerReboot - Méthodes pour obtenir ou définir les modes de sélection du réseau :
- Méthode pour demander une analyse du réseau :
requestNetworkScan - Méthode pour obtenir la configuration du découpage du réseau :
getNetworkSlicingConfiguration - 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 dans les paramètres utilisateur :
- Méthodes pour vérifier ou définir la connexion de données avec un motif :
- Méthode pour obtenir la liste des numéros d'urgence :
getEmergencyNumberList - Méthodes de contrôle des réseaux opportunistes :
- Méthodes pour définir ou effacer la demande de mise à jour de l'intensité du signal mobile :
TelephonyCallback
TelephonyCallback dispose d'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 transfert d'appel a changé :
onCallForwardingIndicatorChanged - L'état de l'appel a changé :
onCallStateChanged - La cause de la déconnexion de l'appel du système multimédia IP (IMS) a changé :
onImsCallDisconnectCauseChanged - Les informations affichées sur la téléphonie ont changé :
onDisplayInfoChanged - 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 de l'abonnement aux données actif a changé :
onActiveDataSubscriptionIdChanged - Le réseau de l'opérateur a changé :
onCarrierNetworkChange - L'enregistrement du réseau ou la mise à jour d'une zone de localisation/de routage/de suivi ont échoué :
onRegistrationFailed - Modification des informations sur le blocage :
onBarringInfoChanged - Les informations de la cellule ont été modifiées :
onCellInfoChanged - La configuration actuelle des canaux physiques a été modifiée :
onPhysicalChannelConfigChanged
SubscriptionManager
- Méthodes permettant d'obtenir diverses informations sur l'abonnement :
- Méthode pour obtenir le nombre d'abonnements actifs :
getActiveSubscriptionInfoCount - Méthodes pour gérer les groupes d'abonnements :
- Méthodes permettant d'obtenir ou de définir la description du forfait de relation de facturation entre un opérateur et un abonné spécifique :
- Méthode permettant de remplacer temporairement le forfait de facturation entre un opérateur et un abonné spécifique pour qu'il soit considéré comme illimité :
setSubscriptionOverrideUnmetered - Méthode permettant de remplacer temporairement le forfait de facturation entre un opérateur et un abonné spécifique pour qu'il soit considéré comme saturé :
setSubscriptionOverrideCongested - Méthode permettant de 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
SmsManager
- Méthode permettant à l'appelant de créer des messages SMS entrants :
injectSmsPdu. - Méthode permettant d'envoyer un SMS sans écrire dans le fournisseur de SMS :
sendTextMessageWithoutPersisting
CarrierConfigManager
- Méthode pour notifier 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.
Créer
Méthode permettant d'obtenir le numéro de série du matériel, le cas échéant :
getSerial
BugreportManager
Méthode pour démarrer un rapport de bug sur la connectivité, qui est une version spécialisée du rapport de bug qui n'inclut que des informations pour le débogage des problèmes liés à la connectivité :
startConnectivityBugreport
NetworkStatsManager
- Méthode pour interroger le récapitulatif de l'utilisation du réseau :
querySummary - Méthode pour interroger l'historique d'utilisation du réseau :
queryDetails - Méthodes pour enregistrer ou annuler l'enregistrement du rappel d'utilisation du réseau :
ImsMmTelManager
- Méthodes pour interroger les paramètres IMS :
- Méthodes pour enregistrer ou annuler l'enregistrement du rappel d'enregistrement IMS MmTel :
ImsRcsManager
- Méthodes pour enregistrer ou annuler l'enregistrement du rappel d'enregistrement IMS RCS :
- Méthodes pour obtenir l'état de l'enregistrement IMS ou le type de transport :
ProvisioningManager
- Méthodes pour enregistrer et annuler l'enregistrement du rappel de mise à jour du provisionnement des fonctionnalités IMS :
- Méthodes liées à l'état du provisionnement pour la fonctionnalité IMS MmTel ou RCS :
EuiccManager
Méthode pour 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. par exemple par l'une des méthodes suivantes :
- 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 messages SMS binaires envoyés depuis l'appareil :
onSendDataSms - Méthode pour intercepter les SMS longs envoyés depuis l'appareil :
onSendMultipartTextSms - Méthode pour intercepter les MMS envoyés depuis l'appareil :
onSendMms - Méthode de téléchargement des MMS reçus :
onDownloadMms
CarrierService
Service qui expose les 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 dispose d'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 service de l'opérateur de s'exécuter dans un
bucket de veille d'application spécial. Cela exempte l'application de service de l'opérateur de la
restriction d'inactivité des applications et augmente la probabilité qu'elle reste active lorsque la mémoire de l'appareil est faible. Toutefois, si l'application de 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 Carrier Services.
Voici quelques méthodes dans CarrierService :
- Pour remplacer et définir les configurations spécifiques à l'opérateur :
onLoadConfig - Pour informer le système d'un changement de réseau de l'opérateur prévu par l'application de l'opérateur :
notifyCarrierNetworkChange
Fournisseur de services de téléphonie
API du fournisseur de contenu permettant de modifier (insérer, supprimer, mettre à jour, interroger) la base de données de téléphonie. Les champs de valeurs sont définis sur
Telephony.Carriers. Pour en savoir plus, consultez la documentation de référence sur 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 :
- Méthode pour définir un ID d'abonnement :
setSubscriptionId - Méthode pour définir un groupe d'abonnements :
setSubscriptionGroup
Plate-forme Android
Sur une UICC détectée, la plate-forme construit des objets UICC internes qui incluent des règles de privilèges de l'opérateur dans 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 droits d'accès est nécessaire, UiccCarrierPrivilegeRules compare le certificat de l'appelant à ses propres règles, une par une. Si la carte UICC est retirée, les règles sont détruites en même temps que l'objet UICC.
Validation
Pour valider l'implémentation via la
Compatibility Test Suite (CTS) à l'aide de CtsCarrierApiTestCases.apk, vous devez disposer d'une carte UICC de développeur avec les règles UICC ou la prise en charge ARF appropriées.
Demandez au fournisseur de carte 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 ne nécessite pas de 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, avec la 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 CTS Carrier API dans Android 12, l'appareil doit utiliser une carte SIM avec des droits CTS Carrier répondant aux exigences spécifiées dans la dernière version de la spécification
GSMA TS.48 Test Profile tierce avec un ADM1 fixe, clé = 55555555 / 0x3535353535353535.
La même carte SIM peut également être utilisée pour les versions antérieures à Android 12.
Modifier le profil SIM CTS
- Ajouter : les droits de l'opérateur CTS dans l'application maître des règles d'accès (ARA-M) ou ARF. Les deux signatures doivent être encodées dans les règles relatives aux droits d'accès de l'opérateur :
- Hash1(SHA1):
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 - 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
- Hash1(SHA1):
- Créer : fichiers élémentaires ADF USIM non présents dans TS.48 et nécessaires pour CTS :
- EF_MBDN (6FC7), taille de l'enregistrement : 28, numéro de l'enregistrement : 4
- Contenu
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-n : FF…FF
- Contenu
- EF_EXT6 (6FC8), taille de l'enregistrement : 13, numéro d'enregistrement : 1
- Contenu : 00FF…FF
- EF_MBI (6FC9), taille de l'enregistrement : 4, numéro d'enregistrement : 1
- Contenu : Rec1 : 01010101
- EF_MWIS (6FCA), taille de l'enregistrement : 5, numéro d'enregistrement : 1
- Contenu : 0000000000
- Contenu : 00FF…FF
- EF_MBDN (6FC7), taille de l'enregistrement : 28, numéro de l'enregistrement : 4
- Modifier : table de service USIM : activer les services n° 47 et 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 l'opérateur 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)
Respecter 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 ne bénéficieront pas de la personnalisation de la règle CTS Carrier Privilege ni des autres modifications listées ci-dessus.
Exécuter des tests
Pour plus de commodité, CTS est compatible avec un jeton d'appareil qui limite l'exécution des tests aux appareils configurés avec le même jeton. Les tests CTS de l'API opérateur sont compatibles avec le jeton d'appareil sim-card-with-certs. Par exemple, le jeton d'appareil suivant limite l'exécution des tests d'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 mettre à jour les certificats sur l'UICC ?
R : Utilisez le mécanisme de mise à jour OTA des cartes existantes.
La règle "UICC" peut-elle coexister avec d'autres règles ?
R : Vous pouvez avoir d'autres règles de sécurité sur l'UICC sous le même AID. La plate-forme les filtre automatiquement.
Que se passe-t-il lorsque la carte UICC est retirée pour une application qui s'appuie sur les certificats qu'elle contient ?
R : L'application perd ses droits d'accès, car les règles associées à l'UICC sont détruites lorsque l'UICC est retirée.
Le nombre de certificats sur l'UICC est-il limité ?
R : 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.
Le nombre d'API que nous pouvons prendre en charge avec cette méthode est-il limité ?
R : Non, mais nous limitons le champ d'application aux API liées aux opérateurs.
Certaines API sont-elles interdites d'utiliser cette méthode ? Si oui, comment les faites-vous respecter ? (c'est-à-dire, avez-vous des tests pour valider les API compatibles 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'a pas changé.
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.
Cette fonctionnalité interagit-elle ou se chevauche-t-elle avec d'autres technologies d'accès à l'élément sécurisé, comme SEEK ?
R : Par exemple, SEEK utilise le même AID que sur l'UICC. Les règles coexistent donc et sont filtrées par SEEK ou UiccCarrierPrivileges.
Quand est-il judicieux de vérifier les droits d'accès de l'opérateur ?
R : Après la diffusion de l'état de la carte SIM chargée.
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. Nous prévoyons d'utiliser le masque de bits pour un contrôle plus précis à l'avenir.
setOperatorBrandOverride remplace-t-il 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 et la restauration des SMS dans le cloud. L'appel injectSmsPdu active la fonctionnalité de restauration.
Pour le filtrage des SMS, l'appel onFilterSms est-il basé sur le filtrage des ports UDH des SMS ? Ou les applications 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 semble incompatible avec la spécification GP actuelle (qui n'autorise que 0 ou 20 octets). Pourquoi introduisez-vous ce changement ? Le SHA-1 n'est-il pas suffisant pour éviter les collisions ? Avez-vous déjà proposé cette modification à GP, car elle pourrait être incompatible avec les ARA-M/ARF existants ?
R : Pour assurer une sécurité à long terme, 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), appliquez-vous la règle à toutes les applications de l'appareil qui ne sont pas couvertes par une règle spécifique ?
R : Les API de transporteur nécessitent que DeviceAppID-REF-DO soit renseigné.
Le fait qu'il soit vide est destiné aux tests 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é. Toutefois, il est toujours décrit dans le tableau 6-4 de la spécification comme étendant la définition de REF-DO. Est-ce intentionnel ? Comment le code se comporte-t-il lorsque seul PKG-REF-DO est utilisé dans REF-DO ?
R : L'option permettant 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 partons du principe 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 cours ? Une autorisation par méthode ? 64 autorisations distinctes suffiront-elles à long terme ?
R : Cette fonctionnalité est réservée pour l'avenir. Nous sommes ouverts à vos suggestions.
Peux-tu 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 devrait-il pas refléter cet objectif ? (Le nom peut être déroutant pour de nombreux lecteurs, car la règle s'applique alors à toutes les applications signées avec le même certificat d'éditeur.)
R : Le stockage des certificats DeviceAppID est pris en charge par la spécification existante. Nous avons essayé de minimiser les modifications de la spécification pour faciliter l'adoption. Pour en savoir plus, consultez Règles concernant l'UICC.