Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Privilegios de operador de UICC

Android 5.1 introdujo un mecanismo para otorgar privilegios especiales para las API relevantes para los propietarios de aplicaciones de tarjetas de circuitos integrados universales (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 privilegio de operador de UICC, aumentando drásticamente la cantidad de operadores que pueden usar las API. Para una referencia de la API, consulte CarrierConfigManager ; para obtener instrucciones, consulte Configuración de Portador .

Los operadores tienen el 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) mientras retiene 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.

Reglas de la UICC

Almacenamiento en la UICC es compatible con el GlobalPlatform Asegure especificación de control de acceso al elemento . El identificador de aplicación (AID) de la tarjeta es A00000015141434C00 , y el estándar GET DATA comando se utiliza para traer reglas almacenadas en la tarjeta. Puede actualizar estas reglas a través de actualizaciones de tarjetas inalámbricas (OTA).

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 consiste en 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 el SHA-1 (20 bytes) o SHA-256 (32 bytes) de la firma del certificado.
    • PKG-REF-DO ( CA ) es la cadena nombre completo del paquete definido en el manifiesto, ASCII codificado, longitud máxima de 127 bytes.
  • AR-DO ( E3 ) se extiende para incluir PERM-AR-DO ( DB ), que es una máscara de bits 8 bytes, que representa 64 permisos independientes.

Si PKG-REF-DO no está presente, cualquier aplicación firmada por el certificado se otorga el acceso; 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

Compatibilidad con archivos de reglas de acceso (ARF)

Android 7.0 agrega soporte para leer las reglas de privilegios del operador desde el archivo de reglas de acceso (ARF).

Los primeros intentos de la plataforma Android para seleccionar el identificador de aplicación (AID) applet de regla de acceso (ARA) A00000015141434C00 . Si no encuentra la ayuda sobre la UICC, cae de nuevo a ARF seleccionando pkcs15 AID A000000063504B43532D3135 . Android a continuación, lee el archivo de reglas de control de acceso (ACRF) a 0x4300 y busca entradas con AID FFFFFFFFFFFF . Las entradas con diferentes AID se ignoran, por lo que las reglas para otros casos de uso pueden coexistir.

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 para ACCF, que contiene el hash de certificado 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Las aplicaciones firmadas por este certificado tienen privilegios de operador.

API habilitadas

Android admite las siguientes API.

Administrador de telefonía

SmsManager

Método para permitir que la persona que llama para crear nuevos mensajes SMS entrantes: injectSmsPdu .

CarrierConfigManager

Método de notificación de configuración ha cambiado: notifyConfigChangedForSubId . Para obtener instrucciones, consulte Configuración de Portador .

CarrierMessagingService

Servicio que recibe llamadas del sistema cuando se envían o reciben nuevos SMS y MMS. Para extender esta clase, declarar el servicio en el archivo de manifiesto con la android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE permiso e incluyen un filtro de intención con el #SERVICE_INTERFACE acción. Los métodos incluyen:

Proveedor de telefonía

API de proveedores de contenido para permitir modificaciones (insertar, eliminar, actualizar, consultar) a la base de datos de telefonía. Campos de valores se definen en Telephony.Carriers ; para más detalles, consulte la telefonía referencia de la API de developer.android.com.

Plataforma Android

En una UICC detectada, la plataforma construye objetos UICC internos que incluyen reglas de privilegio de operador como parte de la UICC. UiccCarrierPrivilegeRules.java reglas cargas, los analiza desde la tarjeta UICC, y las almacena en caché en la memoria. Cuando se necesita una verificación de privilegio, UiccCarrierPrivilegeRules compara el certificado de la persona que llama con sus propias reglas, uno por uno. Si se elimina la UICC, las reglas se destruyen junto con el objeto UICC.

Validación

Para validar la aplicación a través de prueba de compatibilidad Suite (CTS) usando CtsCarrierApiTestCases.apk , debe tener una UICC desarrollador con las reglas de la UICC correctas o apoyo ARF. Puede pedirle al proveedor de la tarjeta 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 aprobar las pruebas CTS.

Preparando la UICC

Para Android 11 e inferior, CtsCarrierApiTestCases.apk está firmado por aosp-testkey , con 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 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 API portadora CTS en Android 12, el dispositivo tiene que usar una tarjeta SIM con privilegios de transporte CTS cumplimiento de los requisitos especificados en la última versión de terceros GSMA prueba TS.48 Perfil especificación.

La misma SIM también se puede utilizar para versiones anteriores a Android 12.

Modificación del perfil SIM de CTS

  1. Añadir: privilegios CTS portador en ARA-M o IRA. Ambas firmas deben estar codificadas en las reglas de privilegio 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
  1. Crear: ADF USIM FAN no presente en TS.48 y necesarios para CTS:
    1. EF_MBDN (6FC7), Tamaño de registro: 28, Número de registro: 4
      • Contenido
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF… FF
        2. Rec2-n: FF… FF
    2. EF_EXT6 (6FC8), Tamaño de registro: 13, Número de registro: 1
      • Contenido: 00FF… FF
        1. EF_MBI (6FC9), Tamaño de registro: 4, Número de registro: 1
      • Contenido: Rec1: 01010101
        1. EF_MWIS (6FCA), Tamaño de registro: 5, Número de registro: 1
      • Contenido: 0000000000
  2. Modificar: USIM Tabla de servicio: Habilitar servicios n ° 47, n ° 48
    1. EF_UST (6F38)
      • Contenido: 9EFFBF1DFFFE0083410310010400406E01
  3. Modificar: DF-5 GS y DF-SAIP Archivos
    1. DF-5GS - EF_5GS3GPPLOCI (USIM / 5FC0 / 4F01)
      • Contenido: FFFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM / 5FC0 / 4F02)
      • Contenido: FFFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    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
  4. Modificar: cadenas Nombre de la compañía serán Android CTS en los EF respectivos que contienen esta designación:
    1. EF_SPN (USIM / 6F46)
      • Contenido: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM / 6FC5)
      • Contenido: Rec1 430B83413759FE4E934143EA14FF..FF

Coincidencia con la estructura del perfil de prueba

Descargar y que coincida con la última versión de las siguientes estructuras de perfiles de prueba genérica. Estos perfiles no tendrán la regla CTS Carrier Privilege personalizada ni otras modificaciones enumeradas anteriormente.

Ejecutando 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. Pruebas portadora API CTS apoyan la caja de prepago sim-card-with-certs . Por ejemplo, el dispositivo siguiente token pruebas API restringe portadoras se ejecute sólo 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 reglas?

R: Está bien tener otras reglas de seguridad en la UICC bajo la misma 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.

¿Hay algunas API que no puedan utilizar este método? Si es así, ¿cómo las aplica? (es decir, ¿tiene pruebas para validar qué API son compatibles con este método?)

R: Vea la sección "API del comportamiento de compatibilidad" de la definición de documento de compatibilidad de Android (CDD) . Tenemos algunas pruebas CTS para asegurarnos de que el modelo de permisos 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 de alguna manera o se superpone con otras tecnologías de acceso SE, por ejemplo, SEEK?

R: Como ejemplo, SEEK usa la misma AID que en la UICC. Por lo que el co-existen reglas y se filtran por cualquiera solicitarán ni UiccCarrierPrivileges .

¿Cuándo es un buen momento para verificar los privilegios de transportista?

R: Después de que el estado de SIM cargue la transmisión.

¿Pueden los OEM deshabilitar parte de las API de operador?

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 fino en el futuro.

¿El setOperatorBrandOverride prevalecen sobre todas las demás formas de cadenas de nombres de operador? Por ejemplo, ¿SE13, UICC SPN o NITZ basado en red?

R: Consulte la entrada SPN en TelephonyManager

¿Qué dice la injectSmsPdu hacer llamada a un método?

R: Este método facilita la copia de seguridad / restauración de SMS en la nube. El injectSmsPdu llamada activa la función de restauración.

Para el filtrado de SMS, es decir los onFilterSms llamada basándose en el filtrado de puertos SMS UDH? ¿O las aplicaciones del operador 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 apoyar a 32 bytes parece ser incompatible con la especificación GP actual (que permite a 0 o 20 bytes solamente), ¿por qué te presentas este cambio? ¿No es suficiente SHA-1 para evitar colisiones? ¿Ha propuesto ya este cambio a GP, ya que podría ser incompatible con el ARA-M / ARF existente?

R: Para proporcionar seguridad a prueba de futuro, esta extensión introduce SHA-256 para DeviceAppID-REF-DO , además de SHA-1, que es actualmente la única opción en la norma GP SEAC. Recomendamos encarecidamente el uso de SHA-256.

Si DeviceAppID es 0 (vacío), Cómo se aplica la regla a todos los dispositivos no Aplicaciones cubierto por una norma específica?

: Operador API requieren DeviceAppID-REF-DO se rellenará. Estar vacío está destinado a fines de prueba y no se recomienda para implementaciones operativas.

De acuerdo con su especificación, PKG-REF-DO utilizar apenas por sí mismo, sin DeviceAppID-REF-DO , no debe ser aceptado. Pero sigue describe en la Tabla 6-4 como la ampliación de la definición de REF-DO . ¿Es esto a propósito? ¿Cómo se comporta el código cuando sólo se PKG-REF-DO se utiliza en REF-DO ?

A: La opción de tener PKG-REF-DO como un elemento de valor única en el REF-DO fue eliminado en la última versión. PKG-REF-DO sólo debe ocurrir 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 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.

Se puede definir con más detalle DeviceAppID para Android en concreto? Este es el valor hash SHA-1 (20 bytes) del certificado de editor que se utilizó para firmar la aplicación dada, así que ¿no debería el nombre reflejar ese propósito? (El nombre puede resultar confuso para muchos lectores, ya que la regla se aplica a todas las aplicaciones firmadas con el mismo certificado de editor).

R: Los DeviceAppID almacenar certificados se apoya en la especificación existente. Intentamos minimizar los cambios en las especificaciones para reducir la barrera de adopción. Para más detalles, véase Normas sobre la UICC .