Privilegios de operador de UICC

En Android 5.1, se introdujo un mecanismo para otorgar privilegios especiales a las APIs relevantes para los propietarios de apps de tarjetas de circuitos integrados universales (UICC). La plataforma de Android carga certificados almacenados en una UICC y otorga permiso a las apps firmadas por estos certificados para realizar llamadas a algunas APIs especiales.

Android 7.0 extendió esta función para admitir otras fuentes de almacenamiento para UICC reglas de privilegios de operador, y así aumentar la cantidad de proveedores 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 el control total de la UICC, por lo que este mecanismo proporciona una forma segura y flexible de administrar apps del operador de red móvil (MNO) alojadas en canales de distribución de apps genéricos (como Google Play) y, al mismo tiempo, conservar privilegios especiales en los dispositivos y sin necesidad de firmar apps con el certificado de plataforma por dispositivo ni preinstalarlas como una app del sistema.

Reglas en UICC

El almacenamiento en UICC es compatible con el Plataforma Global Especificación del control de acceso al elemento seguro. El identificador de app (AID) en la tarjeta es A00000015141434C00, y el comando GET DATA estándar se usa para recuperar las reglas almacenadas en la tarjeta. Puedes actualizar estas reglas mediante actualizaciones inalámbricas (OTA) de las tarjetas.

Jerarquía de datos

Las reglas de la UICC usan la siguiente jerarquía de datos (la combinación de letra y número 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) contiene DeviceAppID-REF-DO o una concatenación de DeviceAppID-REF-DO y PKG-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 completa del nombre del paquete definida en el manifiesto, codificada en ASCII, con una longitud máxima de 127 bytes.
  • AR-DO (E3) se extiende para incluir PERM-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 le otorga acceso a cualquier app firmada por el certificado. De lo contrario, el certificado y el nombre del paquete deben coincidir.

Ejemplo de regla

El nombre de la app es com.google.android.apps.myapp y el 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 de UICC en 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 A00000015141434C00 de AID de la aplicación de reglas de acceso (ARA). Si no encuentra el AID en el UICC, recurre al ARF seleccionando AID PKCS15 A000000063504B43532D3135 Luego, Android lee la archivo de reglas de control de acceso (ACRF) en 0x4300 y busca entradas con el AID FFFFFFFFFFFF. Se ignoran las entradas con AIDs diferentes, por lo que las reglas para otros casos de uso pueden coexistir.

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 que firman este certificado obtienen privilegios del operador.

APIs habilitadas

Android admite las siguientes APIs.

TelephonyManager

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:

SubscriptionManager

Administrador de SMS

CarrierConfigManager

  • Método para notificar que cambió la 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 proveedor 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 de el informe de errores que solo incluye información para depurar los errores relacionados con la conectividad problemas: startConnectivityBugreport

Administrador de estadísticas de red

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

Método para cambiar a (habilitar) la suscripción determinada: switchToSubscription

Servicio de mensajería del proveedor

Es un servicio que recibe llamadas del sistema cuando se envían o reciben SMS y MMS nuevos. Para extender esta clase, declara el servicio en tu archivo de manifiesto con android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE permiso e incluir un filtro de intents con el valor #SERVICE_INTERFACE acción. Entre los métodos, se incluyen los siguientes:

  • Método para filtrar los mensajes SMS entrantes: onFilterSms
  • Método para interceptar mensajes SMS de texto 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 los mensajes MMS enviados desde el dispositivo: onSendMms
  • Método para descargar los mensajes MMS recibidos: onDownloadMms

CarrierService

Servicio que expone funciones 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 incluye un filtro de intents con la acción CARRIER_SERVICE_INTERFACE. Si el servicio tiene una vinculación de larga duración, establece android.service.carrier.LONG_LIVED_BINDING en true en los metadatos del servicio.

La plataforma vincula CarrierService con marcas especiales para permitir que el proceso del servicio del operador se ejecute en un bucket de modo de espera de la app especial. Esto exime a la app del servicio del operador de la restricción de inactividad de la app y aumenta las probabilidades de que permanezca activa cuando la memoria del dispositivo esté baja. Sin embargo, si la app del servicio del operador falla por algún motivo, pierde todos los privilegios anteriores hasta que se reinicia la app y se vuelve a establecer la vinculación. Por lo tanto, es fundamental mantener estable la app de servicio del operador.

Entre los métodos de CarrierService, se incluyen los siguientes:

  • Para anular y establecer las configuraciones específicas del operador, haz lo siguiente: onLoadConfig
  • Para informar al sistema sobre un próximo cambio intencional en la red del operador la app del operador: notifyCarrierNetworkChange

Proveedor de telefonía

API de proveedor de contenido para permitir modificaciones (inserción, eliminación, actualización, consulta) a 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:

Plataforma de Android

En un UICC detectado, la plataforma construye objetos UICC internos que incluir reglas de privilegios de proveedor 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 del llamador con sus propias reglas una por una. Si se quita el UICC, el se destruyen junto con el objeto UICC.

Validación

Validar la implementación a través de Conjunto de pruebas de compatibilidad (CTS) con CtsCarrierApiTestCases.apk debe contar con un UICC de desarrollador con las reglas de UICC o la asistencia de ARF correctas. 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 un servicio celular activo para aprobar las pruebas de CTS.

Prepara la UICC

En Android 11 y versiones anteriores, aosp-testkey firma CtsCarrierApiTestCases.apk, 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 es 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 pruebas de la API del operador de CTS en Android 12, el dispositivo debe usar una SIM con privilegios de operador de CTS que cumplan con los requisitos especificados en la versión más reciente de la especificación del perfil de prueba 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

  1. Agregar: Privilegios de proveedor del CTS en instancia principal de la app de regla de acceso (ARA-M) o ARF. Ambas firmas deben estar codificadas en las reglas de privilegios del operador:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. 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
  2. Crear: Archivos elementales (EF) de USIM de ADF que no están presentes en el TS.48 y que se necesitan para CTS:
    1. EF_MBDN (6FC7), tamaño del registro: 28, número de registro: 4
      • Contenido
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
        2. Rec2-n: FF...FF
    2. EF_EXT6 (6FC8), tamaño del registro: 13, número de registro: 1 
      • Contenido: 00FF…FF
        1. EF_MBI (6FC9), tamaño del registro: 4, número de registro: 1
      • Contenido: Rec1: 01010101
        1. EF_MWIS (6FCA), tamaño del registro: 5, número de registro: 1
      • Contenido: 0000000000
  3. Modificar: Tabla de servicios USIM: habilitar servicios n° 47, n° 48
    1. EF_UST (6F38)
      • Contenido: 9EFFBF1DFFFE0083410310010400406E01
  4. Modificar: archivos DF-5GS y DF-SAIP
    1. DF-5GS: EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Contenido: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Contenido: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Contenido: A0020000FF…FF
    4. DF-SAIP: EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Contenido: A0020000FF…FF
  5. Modificación: Usa la cadena de nombre del operador Android CTS en los EF respectivos que contengan esta designación:
    1. EF_SPN (USIM/6F46)
      • Contenido: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Contenido: Rec1 430B83413759FE4E934143EA14FF..FF

Coincidir 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 privilegio del operador de CTS ni otras modificaciones que se mencionaron anteriormente.

Cómo ejecutar 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. CTS de API de Carrier las pruebas admiten el token de dispositivo 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 usar un token de dispositivo, esta se ejecuta en todos los dispositivos.

Preguntas frecuentes

¿Cómo se pueden actualizar los certificados en la UICC?

A: Usar el mecanismo de actualización OTA de la tarjeta existente

¿UICC puede coexistir con otras reglas?

A: Está bien 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?

A: La app pierde sus privilegios porque las reglas asociadas con la UICC se destruyen cuando se quita.

¿Existe un límite para la cantidad de certificados en el UICC?

A: La plataforma no limita la cantidad de certificados. sino porque la verificación es lineal, por lo que demasiadas reglas pueden generar una latencia para la verificación.

¿Existe un límite para la cantidad de APIs que podemos admitir con esto? método?

R.: No, pero limitamos el alcance a las APIs relacionadas con los proveedores.

¿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 son compatibles con este método?).

A: Consulta la Sección Compatibilidad de comportamiento de la API de Compatibilidad con Android Documento de definición (CDD). Tenemos algunas pruebas de CTS para asegurarnos de que no se cambie el modelo de permisos de las APIs.

¿Cómo funciona esto con la función de varias SIM?

A: Se usa la SIM predeterminada que especifica el usuario.

¿De alguna manera, esto interactúa o se superpone con otras tecnologías de acceso a la SE, por ejemplo, SEEK?

A: A modo de ejemplo, SEEK usa el mismo AID que en el UICC. Entonces, las reglas coexistir y se filtran con SEEK o UiccCarrierPrivileges

¿Cuándo es un buen momento para verificar los privilegios del operador?

A: Después de la transmisión del estado cargado de la SIM

¿Los OEM pueden inhabilitar parte de las APIs de los 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 mayor nivel de detalle 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 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?

A: Este método facilita el restablecimiento o la copia de seguridad de SMS en la nube. El La llamada a injectSmsPdu habilita la función de restablecimiento.

En el caso del filtrado de SMS, ¿la llamada a onFilterSms se basa en el filtrado de puertos UDH de SMS? ¿Las apps del operador tienen acceso a TODOS los SMS entrantes?

A: Las empresas de telecomunicaciones 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). ¿Por qué implementas este cambio? No es suficiente SHA-1 para evitar las colisiones? ¿Ya propusiste este cambio a GP, ya que podría ser incompatible con las versiones anteriores de ARA-M/ARF?

R.: Para ofrecer 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. Te recomendamos que uses SHA-256.

Si DeviceAppID es 0 (vacío), ¿aplicas la regla a todas las apps para dispositivos que no están cubiertas por una regla específica?

A: Las APIs de operador requieren que se propague DeviceAppID-REF-DO. Estar vacío está destinado a fines de prueba y no se recomienda para fines operativos de Google Cloud.

Según tu especificación, no se debe aceptar PKG-REF-DO solo, sin DeviceAppID-REF-DO. Sin embargo, en la tabla 6-4 de la especificación, se describe como una extensión de la definición de REF-DO. ¿Es intencional? ¿Cómo se comporta el código cuando solo se usa PKG-REF-DO en REF-DO?

A: La opción de tener PKG-REF-DO como un solo elemento de valor en REF-DO se quitó en la versión más reciente. PKG-REF-DO solo debe ocurrir en combinación con DeviceAppID-REF-DO

Supón 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? ¿64 permisos diferentes son suficientes a largo plazo?

A: Esto se reserva para el futuro, y agradecemos las sugerencias.

¿Puedes definir DeviceAppID para Android de forma más específica? Este es el valor de hash SHA-1 (20 bytes) del certificado del publicador que se usa para firmar la app determinada, por lo que el nombre debería reflejar ese propósito. (El nombre podría ser confuso para muchos lectores, ya que la regla entonces se aplica a todas las aplicaciones firmadas con el mismo certificado de publicador).

A: El certificado de almacenamiento DeviceAppID es compatible con el especificación existente. Intentamos minimizar los cambios de especificaciones para reducir la barrera la adopción. Para conocer más detalles, consulta Reglas sobre UICC.