Android 5.1 introdujo un mecanismo para otorgar privilegios especiales para las APIs pertinentes a los propietarios de apps de tarjetas de circuitos integrados universales (UICC). La plataforma de Android carga los certificados almacenados en una UICC y otorga permiso a las apps firmadas por estos certificados para realizar llamadas a un conjunto de APIs especiales.
Android 7.0 extendió esta función para admitir otras fuentes de almacenamiento para las reglas de privilegios de operador de la UICC, lo que aumentó drásticamente la cantidad de operadores que pueden usar las APIs. Para obtener una referencia de la API, consulta CarrierConfigManager; para obtener instrucciones, consulta Configuración del operador.
Los operadores tienen control total de la UICC, por lo que este mecanismo proporciona una forma segura y flexible de administrar las apps del operador de red móvil (ORM) alojadas en canales genéricos de distribución de apps (como Google Play) y, al mismo tiempo, conservar privilegios especiales en los dispositivos sin necesidad de firmar las apps con el certificado de la plataforma por dispositivo ni preinstalarlas como apps del sistema.
Reglas sobre la UICC
El almacenamiento en la UICC es compatible con la
especificación de control de acceso al elemento seguro de GlobalPlatform. El identificador de la app (AID) en la tarjeta es A00000015141434C00, y el comando estándar GET DATA se usa para recuperar las reglas almacenadas en la tarjeta. Puedes actualizar estas reglas a través de actualizaciones inalámbricas (OTA) de la tarjeta.
Jerarquía de datos
Las reglas de la UICC usan la siguiente jerarquía de datos (la combinación de dos caracteres alfanuméricos entre paréntesis es la etiqueta del objeto). Cada regla es REF-AR-DO (E2) y consta de una concatenación de REF-DO y AR-DO:
REF-DO(E1) contieneDeviceAppID-REF-DOo una concatenación deDeviceAppID-REF-DOyPKG-REF-DO.DeviceAppID-REF-DO(C1) almacena la firma SHA-1 (20 bytes) o SHA-256 (32 bytes) del certificado.PKG-REF-DO(CA) es la cadena del nombre completo del paquete definida en el manifiesto, codificada en ASCII y con una longitud máxima de 127 bytes.
AR-DO(E3) se extiende para incluirPERM-AR-DO(DB), que es una máscara de bits de 8 bytes que representa 64 permisos separados.
Si PKG-REF-DO no está presente, se otorga acceso a cualquier app firmada por el certificado. De lo contrario, deben coincidir el certificado y el nombre del paquete.
Ejemplo de regla
El nombre de la app es com.google.android.apps.myapp y el certificado SHA-1 en cadena hexadecimal es el siguiente:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
La regla sobre la UICC en la cadena hexadecimal es la siguiente:
E243 <= 43 is value length in hex
E135
C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
E30A
DB08 0000000000000001
Compatibilidad con archivos de reglas de acceso
Android 7.0 agrega compatibilidad para leer reglas de privilegios del operador desde el archivo de reglas de acceso (ARF).
La plataforma de Android primero intenta seleccionar el AID de la aplicación de regla de acceso (ARA) A00000015141434C00. Si no encuentra el AID en la UICC, recurre al ARF seleccionando el AID de PKCS15 A000000063504B43532D3135. Luego, Android lee el archivo de reglas de control de acceso (ACRF) en 0x4300 y busca entradas con el AID FFFFFFFFFFFF. Se ignoran las entradas con diferentes AIDs, por lo que pueden coexistir reglas para otros casos de uso.
Ejemplo de contenido de ACRF en cadena hexadecimal:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Ejemplo de contenido del archivo de condiciones de control de acceso (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
En el ejemplo anterior, 0x4310 es la dirección de ACCF, que contiene el hash del certificado 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Las apps firmadas con este certificado obtienen privilegios de operador.
APIs habilitadas
Android admite las siguientes APIs.
TelephonyManager
- Método para permitir que la app del operador solicite un desafío/respuesta a la UICC:
getIccAuthentication. - Método para verificar si la app que realiza la llamada tiene privilegios de operador:
hasCarrierPrivileges. - Métodos para anular la marca y el número:
- Métodos para la comunicación directa con la UICC:
- Método para establecer el modo del dispositivo como global:
setPreferredNetworkTypeToGlobal. - Métodos para obtener las identidades de la red o el dispositivo:
- Identidad internacional de equipo móvil (IMEI):
getImei - Identificador de equipo móvil (MEID):
getMeid - Identificador de acceso a la red (NAI):
getNai - Número de serie de la SIM:
getSimSerialNumber
- Identidad internacional de equipo móvil (IMEI):
- Método para obtener la configuración del operador:
getCarrierConfig - Método para obtener el tipo de red para la transmisión de datos:
getDataNetworkType - Método para obtener el tipo de red para el servicio de voz:
getVoiceNetworkType - Métodos para obtener información sobre la app de la UICC SIM (USIM):
- Número de serie de la SIM:
getSimSerialNumber - Información de la tarjeta:
getUiccCardsInfo - GID1 (ID de grupo, nivel 1):
getGroupIdLevel1 - Cadena del número de teléfono para la línea 1:
getLine1Number - Red móvil pública terrestre (PLMN) prohibida:
getForbiddenPlmns - PLMN de casa equivalente:
getEquivalentHomePlmns
- Número de serie de la SIM:
- Métodos para obtener o establecer el número de buzón de voz:
- Método para enviar un código especial del marcador:
sendDialerSpecialCode - Método para restablecer el módem de radio:
rebootModem - Métodos para obtener o establecer modos de selección de red:
- Método para solicitar una búsqueda de red:
requestNetworkScan - Métodos para obtener o establecer los tipos de red permitidos o preferidos:
- Métodos para verificar si los datos móviles o el roaming están habilitados según la configuración del usuario:
- Métodos para verificar o establecer la conexión de datos con un motivo:
- Método para obtener la lista de números de emergencia:
getEmergencyNumberList - Métodos para controlar las redes oportunistas:
- Métodos para establecer o borrar la solicitud de actualización de la intensidad de la señal celular:
TelephonyCallback
TelephonyCallback tiene interfaces con un método de devolución de llamada para notificar a la app que realiza la llamada cuando cambian los estados registrados:
- El indicador de mensaje en espera cambió:
onMessageWaitingIndicatorChanged - Cambió el indicador de desvío de llamadas:
onCallForwardingIndicatorChanged - Se cambió la causa de desconexión de la llamada del sistema multimedia de IP (IMS):
onImsCallDisconnectCauseChanged - Cambió el estado preciso de la conexión de datos:
onPreciseDataConnectionStateChanged - La lista actual de números de emergencia cambió:
onEmergencyNumberListChanged - Cambió el ID de la suscripción de datos activa:
onActiveDataSubscriptionIdChanged - Cambió la red del operador:
onCarrierNetworkChange - No se pudo registrar la red ni actualizar la ubicación, el enrutamiento o el área de seguimiento:
onRegistrationFailed - Cambio en la información de bloqueo:
onBarringInfoChanged - Cambió la configuración actual del canal físico:
onPhysicalChannelConfigChanged
SubscriptionManager
- Métodos para obtener diversa información sobre las suscripciones:
- Método para obtener la cantidad de suscripciones activas:
getActiveSubscriptionInfoCount - Métodos para administrar grupos de suscripciones:
- Métodos para obtener o establecer la descripción del plan de relación de facturación entre un operador y un suscriptor específico:
- Método para anular temporalmente el plan de relación de facturación entre un operador y un suscriptor específico para que se considere sin medición:
setSubscriptionOverrideUnmetered - Método para anular temporalmente el plan de relación de facturación entre un operador y un suscriptor específico para que se considere congestionado:
setSubscriptionOverrideCongested - Método para verificar si la app con el contexto determinado está autorizada para administrar la suscripción determinada según sus metadatos:
canManageSubscription
SmsManager
- Método para permitir que el llamador cree mensajes SMS entrantes nuevos:
injectSmsPdu. - Método para enviar un mensaje SMS basado en texto sin escribir en el proveedor de SMS:
sendTextMessageWithoutPersisting
CarrierConfigManager
- Método para notificar que cambió la configuración:
notifyConfigChangedForSubId. - Método para obtener la configuración del operador de la suscripción predeterminada:
getConfig - Método para obtener la configuración del operador para la suscripción especificada:
getConfigForSubId
Para obtener instrucciones, consulta Configuración del operador.
BugreportManager
Método para iniciar un informe de errores de conectividad, que es una versión especializada del informe de errores que incluye solo información para depurar problemas relacionados con la conectividad:
startConnectivityBugreport
NetworkStatsManager
- Método para consultar el resumen del uso de la red:
querySummary - Método para consultar el historial de uso de la red:
queryDetails - Métodos para registrar o cancelar el registro de la devolución de llamada de uso de red:
ImsMmTelManager
- Métodos para registrar o cancelar el registro de la devolución de llamada de registro de IMS MmTel:
ImsRcsManager
- Métodos para registrar o cancelar el registro de la devolución de llamada de registro de RCS de IMS:
- Métodos para obtener el estado de registro de IMS o el tipo de transporte:
ProvisioningManager
- Métodos para registrar y cancelar el registro de la devolución de llamada de actualizaciones de aprovisionamiento de funciones de IMS:
- Métodos relacionados con el estado de aprovisionamiento para la capacidad de IMS MmTel o RCS:
EuiccManager
Método para cambiar a la suscripción determinada (habilitarla):
switchToSubscription
CarrierMessagingService
Servicio que recibe llamadas del sistema cuando se envían o reciben mensajes SMS y MMS nuevos. Para extender esta clase, declara el servicio en tu archivo de manifiesto con el permiso android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE y, luego, incluye un filtro de intents con la acción #SERVICE_INTERFACE. Se incluyen los siguientes métodos:
- Método para filtrar mensajes SMS entrantes:
onFilterSms - Método para interceptar mensajes SMS enviados desde el dispositivo:
onSendTextSms - Método para interceptar mensajes SMS binarios enviados desde el dispositivo:
onSendDataSms - Método para interceptar mensajes SMS largos enviados desde el dispositivo:
onSendMultipartTextSms - Método para interceptar mensajes MMS enviados desde el dispositivo:
onSendMms - Método para descargar los mensajes MMS recibidos:
onDownloadMms
CarrierService
Servicio que expone funcionalidades específicas del operador al sistema. Para extender esta clase, declara el servicio en el archivo de manifiesto de la app con el permiso android.Manifest.permission#BIND_CARRIER_SERVICES y, luego, incluye un filtro de intents con la acción CARRIER_SERVICE_INTERFACE.
Si el servicio tiene una vinculación de larga duración, configura android.service.carrier.LONG_LIVED_BINDING como true en los metadatos del servicio.
La plataforma vincula CarrierService con marcas especiales para permitir que el servicio de operador se ejecute en un
cubo de espera de la app especial. Esto exime a la app de servicio de operador de la
restricción de inactividad de la app y hace que sea más probable que se mantenga activa cuando la memoria del dispositivo es baja. Sin embargo, si la app de servicio de operador falla por algún motivo, pierde todos los privilegios anteriores hasta que se reinicia la app y se restablece la vinculación. Por lo tanto, es fundamental mantener la estabilidad de la app de servicios del operador.
Los métodos en CarrierService incluyen los siguientes:
- Para anular y establecer las configuraciones específicas del operador, haz lo siguiente:
onLoadConfig - Para informar al sistema sobre un cambio de red de operador intencional y próximo por parte de la app del operador, haz lo siguiente:
notifyCarrierNetworkChange
Proveedor de telefonía
APIs de proveedores de contenido para permitir modificaciones (inserción, eliminación, actualización, consulta) en la base de datos de telefonía. Los campos de valores se definen en
Telephony.Carriers. Para obtener más detalles, consulta la
referencia de la clase Telephony.
WifiNetworkSuggestion
Cuando compiles un objeto WifiNetworkSuggestion, usa los siguientes métodos para establecer un ID de suscripción o un grupo de suscripciones:
- Método para establecer un ID de suscripción:
setSubscriptionId - Método para establecer un grupo de suscripciones:
setSubscriptionGroup
Plataforma de Android
En una UICC detectada, la plataforma crea objetos internos de UICC que incluyen reglas de privilegios de operador como parte de la UICC.
UiccCarrierPrivilegeRules.java
carga reglas, las analiza desde la tarjeta UICC y las almacena en caché en la memoria. Cuando se necesita una verificación de privilegios, UiccCarrierPrivilegeRules compara el certificado de la entidad llamadora con sus propias reglas una por una. Si se quita la UICC, las reglas se destruyen junto con el objeto de la UICC.
Validación
Para validar la implementación a través del
conjunto de pruebas de compatibilidad (CTS) con CtsCarrierApiTestCases.apk, debes tener una UICC del desarrollador con las reglas de UICC correctas o compatibilidad con ARF.
Pídele al proveedor de tarjetas SIM que elijas que prepare una UICC para desarrolladores con el ARF correcto, como se describe en esta sección, y usa esa UICC para ejecutar las pruebas. La UICC no requiere servicio celular activo para pasar las pruebas de CTS.
Prepara la UICC
En Android 11 y versiones anteriores, CtsCarrierApiTestCases.apk está firmado por aosp-testkey, con el valor de hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81.
A partir de Android 12, CtsCarrierApiTestCases.apk está firmado por cts-uicc-2021-testkey, valor de hash 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.
Para ejecutar las pruebas de la API del operador de CTS en Android 12, el dispositivo debe usar una SIM con privilegios de operador de CTS que cumpla con los requisitos especificados en la versión más reciente de la especificación del perfil de prueba de GSMA TS.48 de terceros.
La misma SIM también se puede usar para versiones anteriores a Android 12.
Modifica el perfil de SIM de CTS
- Agregar: Privilegios de operador de CTS en la app principal de la regla de acceso (ARA-M) o en el ARF. Ambas firmas deben estar codificadas en las reglas de privilegios de operador:
- 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):
- Crear: Los archivos elementales (EF) de USIM de ADF no están presentes en TS.48 y son necesarios para las CTS:
- EF_MBDN (6FC7), tamaño del registro: 28, número de registro: 4
- Contenido
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-n: FF…FF
- Contenido
- EF_EXT6 (6FC8), tamaño del registro:13, número de registro: 1
- Contenido: 00FF…FF
- EF_MBI (6FC9), tamaño del registro: 4, número de registro: 1
- Contenido: Rec1: 01010101
- EF_MWIS (6FCA), tamaño del registro: 5, número de registro: 1
- Contenido: 0000000000
- Contenido: 00FF…FF
- EF_MBDN (6FC7), tamaño del registro: 28, número de registro: 4
- Modificación: Tabla de servicios de USIM: Habilita los servicios núm. 47 y 48.
- EF_UST (6F38)
- Contenido:
9EFFBF1DFFFE0083410310010400406E01
- Contenido:
- EF_UST (6F38)
- Modificación: Archivos DF-5GS y DF-SAIP
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Contenido:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Contenido:
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- Contenido:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Contenido:
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- Contenido:
A0020000FF…FF
- Contenido:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- Contenido:
A0020000FF…FF
- Contenido:
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Modificación: Usa la cadena del nombre del operador Android CTS
en los EF respectivos que contengan esta designación:
- EF_SPN (USIM/6F46)
- Contenido:
01416E64726F696420435453FF..FF
- Contenido:
- EF_PNN (USIM/6FC5)
- Contenido:
Rec1 430B83413759FE4E934143EA14FF..FF
- Contenido:
- EF_SPN (USIM/6F46)
Coincide con la estructura del perfil de prueba
Descarga y haz coincidir la versión más reciente de las siguientes estructuras de perfiles de prueba genéricos. Estos perfiles no tendrán personalizada la regla de privilegios de operador de CTS ni otras modificaciones mencionadas anteriormente.
- GSMA TS.48 Generic Test Profile Structure (Estructura de perfil de prueba genérico de GSMA TS.48)
- Ejemplo de perfil TS.48 en formato DER de eSIM
Cómo ejecutar pruebas
Para mayor comodidad, CTS admite un token de dispositivo que restringe la ejecución de pruebas solo en dispositivos configurados con el mismo token. Las pruebas de CTS de la API de Carrier admiten el token del dispositivo sim-card-with-certs. Por ejemplo, el siguiente token del dispositivo restringe las pruebas de la API del operador para que se ejecuten solo en el dispositivo abcd1234:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
Cuando ejecutas una prueba sin usar un token de dispositivo, la prueba se ejecuta en todos los dispositivos.
Preguntas frecuentes
¿Cómo se pueden actualizar los certificados en la UICC?
R.: Usa el mecanismo de actualización OTA de tarjetas existente.
¿Puede coexistir la UICC con otras reglas?
R.: No hay problema con tener otras reglas de seguridad en la UICC con el mismo AID; la plataforma las filtra automáticamente.
¿Qué sucede cuando se quita la UICC de una app que depende de los certificados que contiene?
R.: La app pierde sus privilegios porque las reglas asociadas con la UICC se destruyen cuando se quita la UICC.
¿Existe un límite para la cantidad de certificados en la UICC?
R.: La plataforma no limita la cantidad de certificados, pero, como la verificación es lineal, demasiadas reglas pueden generar latencia en la verificación.
¿Existe un límite para la cantidad de APIs que podemos admitir con este método?
R.: No, pero limitamos el alcance a las APIs relacionadas con operadores.
¿Hay algunas APIs que no pueden usar este método? Si es así, ¿cómo las aplicas? (es decir, ¿tienes pruebas para validar qué APIs se admiten con este método?)
R.: Consulta la sección Compatibilidad de comportamiento de la API del Documento de definición de compatibilidad de Android (CDD). Tenemos algunas pruebas de CTS para asegurarnos de que el modelo de permisos de las APIs no cambie.
¿Cómo funciona con la función de SIM múltiple?
R.: Se usa el SIM predeterminado que especificó el usuario.
¿De alguna manera interactúa o se superpone con otras tecnologías de acceso al SE, por ejemplo, SEEK?
R.: Como ejemplo, SEEK usa el mismo AID que en la UICC. Por lo tanto, las reglas coexisten y se filtran por SEEK o UiccCarrierPrivileges.
¿Cuándo es un buen momento para verificar los privilegios del operador?
R.: Después de la transmisión de carga del estado de la SIM.
¿Los OEM pueden inhabilitar parte de las APIs de operadores?
R.: No. Creemos que las APIs actuales son el conjunto mínimo, y planeamos usar la máscara de bits para un control de granularidad más preciso en el futuro.
¿setOperatorBrandOverride anula TODAS las demás formas de cadenas de nombres de operadores? Por ejemplo, ¿SE13, UICC SPN o NITZ basada en la red?
Sí, la anulación de la marca del operador tiene la prioridad más alta. Cuando se establece, anula TODAS las demás formas de cadenas de nombres de operadores.
¿Qué hace la llamada al método injectSmsPdu?
R.: Este método facilita la copia de seguridad y el restablecimiento de SMS en la nube. La llamada a injectSmsPdu habilita la función de restablecimiento.
Para el filtrado de SMS, ¿la llamada onFilterSms se basa en el filtrado de puertos de UDH de SMS? ¿O las apps de operadores tienen acceso a TODOS los SMS entrantes?
R.: Los operadores tienen acceso a todos los datos de SMS.
La extensión de DeviceAppID-REF-DO para admitir 32 bytes parece ser incompatible con la especificación actual de GP (que solo permite 0 o 20 bytes), entonces, ¿por qué se introduce este cambio? ¿No es suficiente SHA-1 para evitar colisiones? ¿Ya propusiste este cambio a GP, ya que podría ser incompatible con las versiones anteriores de ARA-M/ARF existentes?
R.: Para brindar seguridad a largo plazo, esta extensión introduce SHA-256 para DeviceAppID-REF-DO, además de SHA-1, que actualmente es la única opción en el estándar de SEAC de GP. Te recomendamos que uses SHA-256.
Si DeviceAppID es 0 (vacío), ¿aplicarás la regla a todas las apps para dispositivos que no estén cubiertas por una regla específica?
R.: Las APIs de la empresa de transporte requieren que se complete DeviceAppID-REF-DO.
Estar vacío está pensado para fines de prueba y no se recomienda para implementaciones operativas.
Según tus especificaciones, PKG-REF-DO no se debe aceptar si se usa solo, sin DeviceAppID-REF-DO. Sin embargo, en la Tabla 6-4 de la especificación, se describe que extiende la definición de REF-DO. ¿Es a propósito? ¿Cómo se comporta el código cuando solo se usa PKG-REF-DO en REF-DO?
R.: En la versión más reciente, se quitó la opción de tener PKG-REF-DO como un solo elemento de valor en REF-DO.
PKG-REF-DO solo debe aparecer en combinación con DeviceAppID-REF-DO.
Suponemos que podemos otorgar acceso a todos los permisos basados en el operador o tener un control más detallado. Si es así, ¿qué define la asignación entre la máscara de bits y los permisos reales? ¿Un permiso por clase? ¿Un permiso por método? ¿Son suficientes 64 permisos separados a largo plazo?
R.: Esta opción está reservada para el futuro, y agradecemos las sugerencias.
¿Puedes definir mejor DeviceAppID para Android específicamente? Este es el valor de hash SHA-1 (20 bytes) del certificado de publicador que se usa para firmar la app determinada, por lo que el nombre debería reflejar ese propósito. (El nombre podría confundir a muchos lectores, ya que la regla se aplica a todas las apps firmadas con el mismo certificado de publicador).
R.: La especificación existente admite el almacenamiento de certificados de DeviceAppID. Intentamos minimizar los cambios en la especificación para reducir las barreras de adopción. Para obtener más información, consulta Reglas en la UICC.