Android 5.1 introdujo un mecanismo para otorgar privilegios especiales para las API relevantes para los propietarios de aplicaciones de tarjetas de circuito integrado universal (UICC). La plataforma Android carga certificados almacenados en una UICC y otorga permiso a las aplicaciones firmadas por estos certificados para realizar llamadas a un puñado de API especiales.
Android 7.0 amplió esta función para admitir otras fuentes de almacenamiento para las reglas de privilegios de operador UICC, lo que aumentó drásticamente la cantidad de operadores que pueden usar las API. Para obtener una referencia de API, consulte CarrierConfigManager ; para obtener instrucciones, consulte 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 aplicaciones del operador de red móvil (MNO) alojadas en canales de distribución de aplicaciones genéricas (como Google Play) manteniendo privilegios especiales en los dispositivos y sin la necesidad. para firmar aplicaciones con el certificado de plataforma por dispositivo o preinstalarlas como una aplicación del sistema.
Normas sobre la UICC
El almacenamiento en la UICC es compatible con la especificación GlobalPlatform Secure Element Access Control . El identificador de aplicación (AID) en la tarjeta es A00000015141434C00 y el comando estándar GET DATA se utiliza para recuperar las reglas almacenadas en la tarjeta. Puede actualizar estas reglas mediante actualizaciones inalámbricas (OTA) de la tarjeta.
Jerarquía de datos
Las reglas de la UICC utilizan la siguiente jerarquía de datos (la combinación de letras y números de dos caracteres 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 de nombre de paquete completo definida en el manifiesto, codificada en ASCII, longitud máxima de 127 bytes.
-
-
AR-DO(E3) se amplía 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 concede acceso a cualquier aplicación firmada por el certificado; de lo contrario, tanto el certificado como el nombre del paquete deben coincidir.
Ejemplo de regla
El nombre de la aplicación es com.google.android.apps.myapp y el certificado SHA-1 en cadena hexadecimal es:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
La regla sobre UICC en cadena hexadecimal es:
E243 <= 43 is value length in hex
E135
C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
E30A
DB08 0000000000000001
Soporte de archivos de reglas de acceso
Android 7.0 agrega soporte para leer reglas de privilegios del operador desde el archivo de reglas de acceso (ARF).
La plataforma Android primero intenta seleccionar la aplicación de reglas de acceso (ARA) AID A00000015141434C00 . Si no encuentra el AID en la UICC, recurre a ARF seleccionando PKCS15 AID A000000063504B43532D3135 . Luego, Android lee el archivo de reglas de control de acceso (ACRF) en 0x4300 y busca entradas con AID FFFFFFFFFFFF . Las entradas con diferentes AID se ignoran, por lo que pueden coexistir reglas para otros casos de uso.
Ejemplo de contenido 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 aplicaciones firmadas con este certificado reciben privilegios de operador.
API habilitadas
Android admite las siguientes API.
Administrador de telefonía
- Método para permitir que la aplicación del operador solicite a la UICC un desafío/respuesta:
getIccAuthentication. - Método para verificar si a la aplicación de llamadas se le han otorgado privilegios de operador:
hasCarrierPrivileges. - Métodos para anular la marca y el número:
- Métodos de comunicación directa de la UICC:
- Método para configurar el modo del dispositivo en global:
setPreferredNetworkTypeToGlobal. - Métodos para obtener las identidades del dispositivo o de la red:
- 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 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 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 aplicación UICC SIM (USIM):
- Número de serie de SIM:
getSimSerialNumber - Información de la tarjeta:
getUiccCardsInfo - GID1 (ID de grupo nivel1):
getGroupIdLevel1 - Cadena de número de teléfono para la línea 1:
getLine1Number - Red móvil terrestre pública prohibida (PLMN):
getForbiddenPlmns - PLMN de origen equivalente:
getEquivalentHomePlmns
- Número de serie de SIM:
- Métodos para obtener o configurar el número de correo de voz:
- Método para enviar un código de marcador especial:
sendDialerSpecialCode - Método para resetear el radio módem:
rebootModem - Métodos para obtener o configurar modos de selección de red:
- Método para solicitar un escaneo de red:
requestNetworkScan - Métodos para obtener o configurar los tipos de red permitidos/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 configurar la conexión de datos con motivo:
- Método para obtener la lista de números de emergencia:
getEmergencyNumberList - Métodos para controlar las redes oportunistas:
- Métodos para configurar o borrar la solicitud de actualización de la intensidad de la señal celular:
TelefoníaDevolución de llamada
TelephonyCallback tiene interfaces con un método de devolución de llamada para notificar a la aplicación de llamadas cuando cambian los estados registrados:
- El indicador de mensaje en espera cambió:
onMessageWaitingIndicatorChanged - El indicador de desvío de llamadas cambió:
onCallForwardingIndicatorChanged - La causa de desconexión de llamadas del sistema multimedia IP (IMS) cambió:
onImsCallDisconnectCauseChanged - El estado preciso de la conexión de datos cambió:
onPreciseDataConnectionStateChanged - La lista actual de números de emergencia cambió:
onEmergencyNumberListChanged - El ID de suscripción de datos activo cambió:
onActiveDataSubscriptionIdChanged - La red del operador cambió:
onCarrierNetworkChange - Error en el registro de red o en la actualización de ubicación/enrutamiento/área de seguimiento:
onRegistrationFailed - El cambio de información de restricción:
onBarringInfoChanged - La configuración actual del canal físico cambió:
onPhysicalChannelConfigChanged
Administrador de suscripciones
- Métodos para obtener diversa información de suscripción:
- Método para obtener el número de suscripciones activas:
getActiveSubscriptionInfoCount - Métodos para gestionar grupos de suscripción:
- Métodos para obtener o configurar 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 no medido:
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 comprobar si la aplicación con el contexto dado está autorizada para gestionar la suscripción determinada según sus metadatos:
canManageSubscription
Administrador de SMS
- Método para permitir que la persona que llama cree nuevos mensajes SMS entrantes:
injectSmsPdu. - Método para enviar un mensaje SMS basado en texto sin escribir en el proveedor de SMS:
sendTextMessageWithoutPersisting
Administrador de configuración del operador
- Método para notificar el cambio de configuración:
notifyConfigChangedForSubId. - Método para obtener la configuración del operador para la suscripción predeterminada:
getConfig - Método para obtener la configuración del operador para la suscripción especificada:
getConfigForSubId
Para obtener instrucciones, consulte Configuración del operador .
Administrador de informes de errores
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
Administrador de estadísticas de red
- Método para consultar el resumen de 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 devolución de llamada de uso de la red:
ImsMmTelManager
- Métodos para registrar o cancelar el registro de devolución de llamada de registro de IMS MmTel:
ImsRcsManager
- Métodos para registrar o cancelar el registro de devolución de llamada de registro de IMS RCS:
- Métodos para obtener el estado de registro del IMS o el tipo de transporte:
Administrador de aprovisionamiento
- Métodos para registrar y cancelar el registro de devolución de llamada de actualizaciones de aprovisionamiento de funciones de IMS:
- Métodos relacionados con el estado de aprovisionamiento para la capacidad IMS MmTel o RCS:
Administrador de Euicc
Método para cambiar a (habilitar) la suscripción dada: switchToSubscription
Servicio de mensajería del operador
Servicio que recibe llamadas del sistema cuando se envían o reciben nuevos SMS y MMS. Para ampliar esta clase, declare el servicio en su archivo de manifiesto con el permiso android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE e incluya un filtro de intención con la acción #SERVICE_INTERFACE . Los métodos incluyen:
- Método para filtrar mensajes SMS entrantes:
onFilterSms - Método para interceptar mensajes de texto 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 mensajes MMS recibidos:
onDownloadMms
Servicio de transportista
Servicio que expone funcionalidades específicas del operador al sistema. Para ampliar esta clase, declare el servicio en el archivo de manifiesto de la aplicación con el permiso android.Manifest.permission#BIND_CARRIER_SERVICES e incluya un filtro de intención con la acción CARRIER_SERVICE_INTERFACE . Si el servicio tiene un enlace de larga duración, configure android.service.carrier.LONG_LIVED_BINDING en true en los metadatos del servicio.
La plataforma vincula CarrierService con indicadores especiales para permitir que el proceso de servicio del operador se ejecute en un depósito de aplicación en espera especial. Esto exime a la aplicación de servicio del operador de la restricción de inactividad de la aplicación y hace que sea más probable que permanezca activa cuando la memoria del dispositivo es baja. Sin embargo, si la aplicación del servicio del operador falla por algún motivo, pierde todos los privilegios anteriores hasta que la aplicación se reinicie y se restablezca el enlace. Por lo tanto, es fundamental mantener estable la aplicación del servicio del operador.
Los métodos en CarrierService incluyen:
- Para anular y establecer las configuraciones específicas del operador:
onLoadConfig - Para informar al sistema de un próximo cambio intencional en la red del operador mediante la aplicación del operador:
notifyCarrierNetworkChange
Proveedor de telefonía
API de proveedor de contenido para permitir modificaciones (insertar, eliminar, actualizar, consultar) en la base de datos de telefonía. Los campos de valores se definen en Telephony.Carriers ; para más detalles, consulte la referencia de clases Telephony
WifiRedSugerencia
Al crear un objeto WifiNetworkSuggestion , utilice los siguientes métodos para configurar un ID de suscripción o un grupo de suscripción:
- Método para establecer un ID de suscripción:
setSubscriptionId - Método para configurar un grupo de suscripción:
setSubscriptionGroup
plataforma Android
En una UICC detectada, la plataforma construye objetos UICC internos 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 persona que llama con sus propias reglas una por una. Si se elimina la UICC, las reglas se destruyen junto con el objeto UICC.
Validación
Para validar la implementación a través de Compatibility Test Suite (CTS) usando CtsCarrierApiTestCases.apk , debe tener una UICC de desarrollador con las reglas UICC correctas o soporte ARF. Pídale al proveedor de tarjetas SIM de su elección que prepare una UICC de desarrollador con el ARF correcto como se describe en esta sección y use esa UICC para ejecutar las pruebas. La UICC no requiere un servicio celular activo para pasar las pruebas CTS.
Preparar la UICC
Para Android 11 y versiones anteriores, CtsCarrierApiTestCases.apk está firmado por aosp-testkey , con valor 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 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 pruebas de API de operador CTS en Android 12, el dispositivo debe usar una SIM con privilegios de operador CTS que cumplan con los requisitos especificados en la última versión de la especificación de perfil de prueba GSMA TS.48 de terceros.
La misma SIM también se podrá utilizar para versiones anteriores a Android 12.
Modificación del perfil SIM de CTS
- Agregar: privilegios del operador CTS en la aplicación maestra de reglas de acceso (ARA-M) o ARF. Ambas firmas deben estar codificadas en las reglas de privilegio del operador:
- Hash1(SHA1)
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
- Hash1(SHA1)
- Crear: archivos elementales (EF) ADF USIM que no están presentes en TS.48 y son necesarios para CTS:
- EF_MBDN (6FC7), tamaño de registro: 28, número de registro: 4
- Contenido
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-n: FF…FF
- Contenido
- EF_EXT6 (6FC8), tamaño de registro: 13, número de registro: 1
- Contenido: 00FF…FF
- EF_MBI (6FC9), tamaño de registro: 4, número de registro: 1
- Contenido: Rec1: 01010101
- EF_MWIS (6FCA), tamaño de registro: 5, número de registro: 1
- Contenido: 0000000000
- Contenido: 00FF…FF
- EF_MBDN (6FC7), tamaño de registro: 28, número de registro: 4
- Modificar: Tabla de servicios USIM: Habilitar servicios n°47, n°48
- EF_UST (6F38)
- Contenido:
9EFFBF1DFFFE0083410310010400406E01
- Contenido:
- EF_UST (6F38)
- Modificar: 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)
- Modificar: use la cadena de 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)
Coincidencia con la estructura del perfil de prueba
Descargue y combine la última versión de las siguientes estructuras genéricas de perfiles de prueba. Estos perfiles no tendrán la regla CTS Carrier Privilege personalizada ni otras modificaciones enumeradas anteriormente.
Ejecución de pruebas
Para mayor comodidad, CTS admite un token de dispositivo que restringe las pruebas para que se ejecuten solo en dispositivos configurados con el mismo token. Las pruebas Carrier API CTS admiten la sim-card-with-certs . Por ejemplo, el siguiente token de dispositivo restringe las pruebas de API del operador para que se ejecuten solo en el dispositivo abcd1234 :
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
Cuando se ejecuta una prueba sin utilizar un token de dispositivo, la prueba se ejecuta en todos los dispositivos.
Preguntas más frecuentes
¿Cómo se pueden actualizar los certificados en la UICC?
R: Utilice el mecanismo de actualización OTA de la tarjeta existente.
¿Puede la UICC coexistir con otras normas?
R: Está bien tener otras reglas de seguridad en la UICC bajo el mismo AID; la plataforma los filtra automáticamente.
¿Qué sucede cuando se elimina la UICC para una aplicación que depende de los certificados que contiene?
R: La aplicación pierde sus privilegios porque las reglas asociadas con la UICC se destruyen al eliminar la UICC.
¿Existe un límite en el número de certificados en la UICC?
R: La plataforma no limita la cantidad de certificados; pero debido a que la verificación es lineal, demasiadas reglas pueden generar una latencia para la verificación.
¿Existe un límite en la cantidad de API que podemos admitir con este método?
R: No, pero limitamos el alcance a las API relacionadas con el operador.
¿Existen algunas API que tienen prohibido utilizar este método? Si es así, ¿cómo se hacen cumplir? (Es decir, ¿tiene pruebas para validar qué API son compatibles con este método?)
R: Consulte la sección Compatibilidad de comportamiento de API del Documento de definición de compatibilidad de Android (CDD). Tenemos algunas pruebas CTS para asegurarnos de que el modelo de permiso de las API no cambie.
¿Cómo funciona esto con la función multi-SIM?
R: Se utiliza la SIM predeterminada especificada por el usuario.
¿Esto interactúa o se superpone de alguna manera con otras tecnologías de acceso SE, por ejemplo, SEEK?
R: Como ejemplo, SEEK utiliza el mismo AID que la UICC. Por lo tanto, las reglas coexisten y se filtran mediante SEEK o UiccCarrierPrivileges .
¿Cuándo es un buen momento para comprobar los privilegios del operador?
R: Después de la transmisión del estado cargado de la SIM.
¿Pueden los OEM desactivar parte de las API de los operadores?
R: No. Creemos que las API 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 basado en red?
Sí, la anulación de la marca del operador tiene la máxima prioridad. Cuando está configurado, 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/restauración de SMS en la nube. La llamada injectSmsPdu habilita la función de restauración.
Para el filtrado de SMS, ¿la llamada onFilterSms se basa en el filtrado de puertos SMS UDH? ¿O las aplicaciones de los 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 GP actual (que permite solo 0 o 20 bytes), entonces, ¿por qué introduce este cambio? ¿No es suficiente SHA-1 para evitar colisiones? ¿Ha propuesto ya este cambio a GP, ya que podría ser incompatible con versiones anteriores de ARA-M/ARF existentes?
R: Para brindar seguridad preparada para el futuro, esta extensión presenta SHA-256 para DeviceAppID-REF-DO además de SHA-1, que actualmente es la única opción en el estándar GP SEAC. Recomendamos encarecidamente utilizar SHA-256.
Si DeviceAppID es 0 (vacío), ¿se aplica la regla a todas las aplicaciones del dispositivo que no están cubiertas por una regla específica?
R: Las API del operador 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 su especificación, PKG-REF-DO usado solo, sin DeviceAppID-REF-DO , no debería aceptarse. Pero todavía se describe en la Tabla 6-4 de la especificación como una extensión de la definición de REF-DO . ¿Es esto a propósito? ¿Cómo se comporta el código cuando solo se usa PKG-REF-DO en REF-DO ?
R: La opción de tener PKG-REF-DO como elemento de valor único en REF-DO se eliminó en la última versión. PKG-REF-DO debe ocurrir solo en combinación con DeviceAppID-REF-DO .
Asumimos que podemos otorgar acceso a todos los permisos basados en operadores o tener un control más detallado. Si es así, ¿qué define el mapeo 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: Esto está reservado para el futuro y agradecemos sugerencias.
¿Puedes definir aún más DeviceAppID para Android específicamente? Este es el valor hash SHA-1 (20 bytes) del certificado del editor utilizado para firmar la aplicación determinada, entonces, ¿no debería el nombre reflejar ese propósito? (El nombre podría resultar confuso para muchos lectores, ya que la regla se aplica a todas las aplicaciones firmadas con el mismo certificado de editor).
R: La especificación existente admite el almacenamiento de certificados DeviceAppID . Intentamos minimizar los cambios en las especificaciones para reducir la barrera de adopción. Para obtener más información, consulte Normas sobre la UICC .