Android 5.1 a introduit un mécanisme permettant d’accorder des privilèges spéciaux pour les APIspertinentes pour les propriétaires d’apps de cartes à circuits intégrés universelles (UICC). La plateformeAndroid charge les certificats stockés sur une UICC et accorde la permission aux apps signées par ces certificats d’effectuer des appels à 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 transporteurs UICC, augmentant considérablement le nombre de transporteurs pouvant utiliser les API. Pour une référence d’API,voir CarrierConfigManager ; pour des instructions,voir CarrierConfiguration.
Les transporteurs ont le contrôle total de l’UICC, ce mécanisme fournit donc un moyen sûr et flexible de gérer les apps de l’opérateur de réseau mobile (MNO)hébergées sur des canaux de distribution d’apps 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 apps avec le certificat de plateforme par appareil ou de les préinstaller comme app système.
Règles sur l’UICC
Le stockage sur l’UICC est compatible avec la spécificationGlobalPlatformSecure Element Access Control. L’identifiant d’application(AID) sur la carte est A00000015141434C00, et la commande standardGET 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 over-the-air (OTA) de la carte.
Hiérarchie des données
Les règles de l’UICC utilisent la hiérarchie des données suivante (la combinaison lettre et chiffre à deux caractères entre parenthèses est la balise objet). Chaque règle estREF-AR-DO (E2) et consiste en 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 complète du nom du paquet définie dans le manifeste, encodée en ASCII, longueur maximale 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 est autorisée à accéder ; sinon, le certificat et le nom du paquet doivent tous deux correspondre.
Exemple de règle
Le nom de l’application est com.google.android.apps.myapp et le certificatSHA-1 en chaîne hexagonale 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 hexagonale est:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Support 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 transporteur à partir du fichier de règles d’accès (ARF).
La plate-forme Android tente d’abord de sélectionner l’applet de règles d’accès (ARA)identificateur d’application (AID) A00000015141434C00. Si elle ne trouve pas l’AID sur l’UICC, elle se rabat sur ARF en sélectionnant PKCS15 AIDA000000063504B43532D3135. Android lit ensuite le fichier de règles de contrôle d’accès (ACRF) à 0x4300 et recherche les entrées dont l’AID est FFFFFFFFFFFF. Les entrées avec des AIDs différents sont ignorées, les sorules pour d’autres cas d’utilisation peuvent coexister.
Exemple de contenu de l’ACRF en chaîne hexagonale:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Exemple de contenu du fichier des 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 hash du certificat61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Les apps signées par ce certificat se voient accorder des privilèges de transporteur.
API activées
Android prend en charge les API suivantes.
TelephonyManager
- Méthode permettant à l’app de transporteur de demander à l’UICC un défi/réponse:
getIccAuthentication. - Méthode permettant de vérifier si l’app appelante s’est vue accorder des privilèges de transporteur:
hasCarrierPrivileges. - Méthodes pour remplacer la marque et le numéro:
-
setOperatorBrandOverride -
setLine1NumberForDisplay -
setVoiceMailNumber
-
- Méthodes pour la communication directe avec l’UICC :
-
iccOpenLogicalChannel -
iccCloseLogicalChannel -
iccExchangeSimIO -
iccTransmitApduLogicalChannel -
iccTransmitApduBasicChannel -
sendEnvelopeWithStatus
-
- Méthodes pour régler le mode du dispositif sur global:
setPreferredNetworkTypeToGlobal.
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 des instructions, voirCarrier Configuration.
CarrierMessagingService
Service qui reçoit des appels du système lorsque de nouveaux SMS et MMS sont envoyésou reçus. Pour étendre cette classe, déclarez le service dans votre fichier manifeste avec la android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEpermission et incluez un filtre d’intention avec la #SERVICE_INTERFACEaction. Les méthodes comprennent :
-
onFilterSms -
onSendTextSms -
onSendDataSms -
onSendMultipartTextSms -
onSendMms -
onDownloadMms
Fournisseur de téléphonie
Des API de fournisseur de contenu pour permettre les modifications (insertion, suppression, mise à jour, interrogation)de la base de données de téléphonie. Les champs de valeurs sont définis à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 Android
Sur un UICC détecté, la plate-forme construit des objets UICC internes quiincluent des règles de privilège de transporteur en tant que partie de l’UICC.UiccCarrierPrivilegeRules.javacharge 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 retiré, les règles sont détruites en même temps que l’objet UICC.
Validation
La suite de tests de compatibilité (CTS) inclut des tests pour les API des transporteurs dansCtsCarrierApiTestCases.apk. Comme cette fonctionnalité dépend des certificats de l’UICC, vous devez préparer l’UICC pour passer ces tests.
Préparation de l’UICC
Par défaut, CtsCarrierApiTestCases.apk est signé par la clé Androiddeveloper, avec la valeur de hachage61: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’UICC ne correspondent pas.
Exemple de sortie:
junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
Pour valider l’implémentation par CTS en utilisantCtsCarrierApiTestCases.apk, vous devez avoir un UICC développeur avec les règles UICC correctes ou le support ARF. Vous pouvez demander au vendeur de cartes SIM de votre choix de préparer un UICC de développement avec le bon ARF comme décrit dans cette section et utiliser cet UICC pour effectuer les tests. L’UICC n’a pas besoin d’un service cellulaire actif pour passer les tests CTS.
Exécution des tests
Pour plus de commodité, CTS prend en charge un jeton de périphérique qui restreint les tests à exécuter uniquement sur les périphériques 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 de périphérique suivant restreint les tests de l’API de transporteur pour qu’ils s’exécutent uniquement sur le périphériqueabcd1234:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
Lorsqu’on exécute un test sans utiliser de jeton de périphérique, le test s’exécute sur tous les périphériques.
FAQ
Comment les certificats peuvent-ils être mis à jour sur l’UICC ?
A : Utilisez le mécanisme de mise à jour OTA de la carte existante.
L’UICC peut-elle coexister avec d’autres règles ?
A : Il est possible 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 retiré pour une application qui s’appuie sur les certificats qu’il contient ?
A : L’app perd ses privilèges car les règles associées à l’UICC sont détruites lors du retrait de l’UICC.
Y a-t-il une limite au nombre de certificats sur l’UICC ?
A : 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 ?
A : Non, mais nous limitons le champ d’application aux API liées aux transporteurs.
Y a-t-il des API interdites d’utiliser cette méthode ? Si oui, comment les faites-vous respecter ? (c’est-à-dire, avez-vous des tests pour valider quelles API sont prises en charge par cette méthode ?)
A : Voir la section « API Behavioral Compatibility » duAndroid Compatibility DefinitionDocument (CDD). Nous avons quelques tests CTS pour nous assurer que le modèle de permission des API n’est pas modifié.
Comment cela fonctionne-t-il avec la fonctionnalité multi-SIM ?
A : La 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 ?
A : A titre d’exemple, SEEK utilise le même AID que sur l’UICC. Donc les règlesco-existent et sont filtrées soit par SEEK soit par UiccCarrierPrivileges.
Quand est-ce un bon moment pour vérifier les privilèges des transporteurs?
A : Après la diffusion de l’état de la SIM chargée.
Les OEM peuvent-ils désactiver une partie des API des transporteurs ?
A : Non. Nous pensons que les API actuelles constituent l’ensemble minimal, et nous prévoyons d’utiliser le masque binaire pour un contrôle de granularité plus fin à l’avenir.
Est-ce que setOperatorBrandOverride prévaut sur TOUTES les autres formes de chaînes de noms d’opérateurs ? Par exemple, SE13, UICC SPN, ou NITZ basé sur le réseau ?
A : Se référer à l’entrée SPN dansTelephonyManager
Que fait l’appel de la méthode injectSmsPdu ?
A : 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 du port UDH des SMS ? Ou les applications des transporteurs ont-elles accès à TOUS les SMS entrants ?
A : Les transporteurs ont accès à toutes les données SMS.
L’extension de DeviceAppID-REF-DO pour supporter32 octets semble être incompatible avec la spécification GP actuelle (qui autorise 0 ou 20 octets seulement), 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 les ARA-M/ARF existants ?
A : Pour fournir une sécurité à l’épreuve du futur, 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 recommandons fortement l’utilisation de SHA-256.
Si DeviceAppID est 0 (vide), appliquez-vous la règle à toutes les apps de dispositifs qui ne sont pas couvertes par une règle spécifique ?
A : Les API des transporteurs exigent que DeviceAppID-REF-DO soit rempli.Le fait d’être vide est destiné à des fins de test et n’est pas recommandé pour les déploiements opérationnels.
Selon votre spécification, PKG-REF-DO utilisé juste par lui-même, 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 deREF-DO. Est-ce intentionnel ? Comment le code se comporte-t-il lorsque seulement PKG-REF-DO est utilisé dans REF-DO?
A : L’option d’avoir PKG-REF-DO comme un seul élément de valeur 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 permissions basées sur le transporteur ou avoir un contrôle plus fin. Si c’est le cas, qu’est-ce qui définit le mappage entre le bitmask et les permissions réelles ? Une permission par classe ? Une permission par méthode ? Est-ce que 64 permissions distinctes sont suffisantes à long terme ?
A : Ceci est réservé pour l’avenir, et nous accueillons les suggestions.
Pouvez-vous définir davantage DeviceAppID pour Android spécifiquement ? C’est la valeur de hachage SHA-1 (20 octets) du certificat d’éditeur utilisé pour signer l’application donnée, donc 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 apps signées avec ce même certificat d’éditeur.)
A : Le DeviceAppID stockage des certificats est pris en charge par la spécification existante. Nous avons essayé de minimiser les changements de spec pour réduire la barrière d’adoption. Pour plus de détails, voir les règles sur l’UICC.