Google 致力于为黑人社区推动种族平等。查看具体举措
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Privilèges des transporteurs UICC

Android 5.1 a introduit un mécanisme pour 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 à passer des appels vers 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 d'API, consultez CarrierConfigManager ; pour obtenir des instructions, consultez Configuration de l'opérateur .

Les opérateurs ont le contrôle total de 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 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 récupérer les règles stockées sur la carte. Vous pouvez mettre à jour ces règles par le biais de mises à jour OTA (Card Over-the-Air).

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 de nom de package complète définie dans le manifeste, encodée en ASCII, d'une 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'identificateur d'application (AID) de l'applet de règle d'accès (ARA) 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 des AID différents sont ignorées, de sorte que les règles 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 pour 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 d'opérateur.

API activées

Android prend en charge les API suivantes.

TelephonyManager

SmsManager

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

CarrierConfigManager

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

TransporteurMessagerieService

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

Fournisseur de téléphonie

API du fournisseur de contenu pour permettre des modifications (insérer, supprimer, mettre à jour, interroger) 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.

Plateforme Android

Sur un UICC détecté, la plate-forme construit des objets UICC internes qui incluent des règles de privilège de l'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 de privilège 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

La suite de tests de compatibilité (CTS) comprend des tests pour les API de transporteur dans CtsCarrierApiTestCases.apk . Étant donné que cette fonctionnalité dépend des certificats sur l'UICC, vous devez préparer l'UICC pour réussir ces tests.

Préparation de l'UICC

Par défaut, CtsCarrierApiTestCases.apk est signé par la clé de développeur Android, 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 . Les tests impriment également le hachage de certificat attendu si les certificats sur l'incompatibilité UICC.

Exemple de sortie:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.
Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

Afin de valider l'implémentation via CTS à l'aide de CtsCarrierApiTestCases.apk , vous devez avoir un développeur UICC avec les règles UICC ou le support ARF corrects. Vous pouvez demander au fournisseur de la carte SIM de votre choix de préparer un développeur UICC avec le bon ARF comme décrit dans cette section et utiliser cet UICC pour exécuter les tests. L'UICC ne nécessite pas de service cellulaire actif pour passer les tests CTS.

Exécution de tests

Pour plus de commodité, CTS prend en charge un jeton d'appareil qui limite 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 de périphérique sim-card-with-certs . Par exemple, le jeton d'appareil suivant limite les tests d'API de l'opérateur à s'exécuter 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 les certificats peuvent-ils être mis à jour sur l'UICC?

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

L'UICC peut-il 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 repose 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 sur le nombre de certificats sur l'UICC?

R: La plateforme ne limite pas le nombre de certificats; mais comme la vérification est linéaire, trop de règles peuvent 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.

Y a-t-il des API interdites d'utiliser cette méthode? Si oui, comment les appliquez-vous? (autrement dit, avez-vous des 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 avons quelques tests CTS pour nous assurer que le modèle d'autorisation des API n'est pas modifié.

Comment cela fonctionne-t-il avec la fonction 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 de quelque manière que ce soit 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. 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?

R: Une fois l'état de la carte SIM chargé, la diffusion.

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

setOperatorBrandOverride remplace-t- setOperatorBrandOverride 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' injectSmsPdu méthode injectSmsPdu ?

R: Cette méthode facilite la sauvegarde / restauration SMS dans le cloud. L'appel injectSmsPdu active la fonction de restauration.

Pour le filtrage SMS, l'appel onFilterSms est- onFilterSms basé sur le filtrage de port SMS UDH? 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 ê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 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 de la norme GP SEAC. Nous vous recommandons vivement d'utiliser SHA-256.

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

R: Les API Carrier nécessitent que DeviceAppID-REF-DO soit renseigné. Le fait d'ê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 le code se comporte-t-il lorsque seul PKG-REF-DO est utilisé dans REF-DO ?

R: L'option d'avoir PKG-REF-DO comme élément de valeur unique dans REF-DO été supprimée dans la dernière version. PKG-REF-DO ne doit se produire qu'en association 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 fin. Si tel est le cas, qu'est-ce qui définit le mappage entre le masque de bits et les autorisations réelles? Une permission par classe? Une autorisation par méthode? 64 autorisations séparées 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 devrait-il donc pas refléter cet objectif? (Le nom peut 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.)

R: Le DeviceAppID stockage des certificats est 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 UICC .