Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Privilegios de operador de UICC

Android 5.1 introdujo un mecanismo para otorgar privilegios especiales para API relevantes para los propietarios de aplicaciones de tarjeta de circuito integrado universal (UICC). La plataforma Android carga certificados almacenados en un 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 de UICC, aumentando drásticamente el número de operadores que pueden usar las API. Para una referencia de API, vea CarrierConfigManager ; para obtener instrucciones, consulte 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 aplicaciones del operador de red móvil (MNO) alojado en canales de distribución de aplicaciones genéricos (como Google Play) mientras conserva privilegios especiales en dispositivos y sin la necesidad para firmar aplicaciones con el certificado de plataforma por dispositivo o preinstalar como una aplicación del sistema.

Reglas sobre UICC

El almacenamiento en el 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 GET DATA estándar se usa para obtener las reglas almacenadas en la tarjeta. Puede actualizar estas reglas a través de actualizaciones de tarjeta por aire (OTA).

Jerarquía de datos

Las reglas 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 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 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, codificado en ASCII, longitud máxima 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, cualquier aplicación firmada por el certificado tiene 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

Soporte de archivo 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).

La plataforma Android primero intenta seleccionar el identificador de aplicación (AID) del applet de regla de acceso (ARA) A00000015141434C00 . Si no encuentra el AID en el UICC, recurre a ARF seleccionando PKCS15 AID A000000063504B43532D3135 . Luego, Android lee el archivo de reglas de control de acceso (ACRF) a 0x4300 y busca entradas con AID FFFFFFFFFFFF . Las entradas con AID diferentes 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 de 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 es compatible con las siguientes API.

Gerente de telefonía

SmsManager

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

CarrierConfigManager

Método para notificar la configuración modificada: notifyConfigChangedForSubId . Para obtener instrucciones, consulte Configuración del operador .

CarrierMessagingService

Servicio que recibe llamadas del sistema cuando se envían o reciben nuevos SMS y MMS. Para extender 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:

Proveedor de telefonía

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

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 memoria caché. 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 el UICC, las reglas se destruyen junto con el objeto UICC.

Validación

El conjunto de pruebas de compatibilidad (CTS) incluye pruebas para API de operador en CtsCarrierApiTestCases.apk . Debido a que esta función depende de los certificados en el UICC, debe preparar el UICC para pasar estas pruebas.

Preparando la UICC

Por defecto, CtsCarrierApiTestCases.apk está firmado por la clave de desarrollador de Android, con valor hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Las pruebas también imprimen el hash de certificado esperado si los certificados en UICC no coinciden.

Salida de ejemplo:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.
Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

Para validar la implementación a través de CTS usando CtsCarrierApiTestCases.apk , debe tener un UICC de desarrollador con las reglas UICC correctas o soporte ARF. Puede pedirle al proveedor de la tarjeta SIM que elija que prepare un UICC de desarrollador con el ARF correcto como se describe en esta sección y use ese UICC para ejecutar las pruebas. La UICC no requiere un servicio celular activo para pasar las pruebas CTS.

Ejecutando pruebas

Por conveniencia, CTS admite un token de dispositivo que restringe que las pruebas se ejecuten solo en dispositivos configurados con el mismo token. Las pruebas de CTS de la API de operador admiten la sim-card-with-certs tokens del dispositivo sim-card-with-certs . Por ejemplo, el siguiente token de dispositivo restringe las pruebas 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, la prueba se ejecuta en todos los dispositivos.

Preguntas más frecuentes

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

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

¿Puede 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 se basa en los certificados que contiene?

R: La aplicación pierde sus privilegios porque las reglas asociadas con la UICC se destruyen al eliminarla.

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

A: La plataforma no limita la cantidad de certificados; pero como el cheque es lineal, demasiadas reglas pueden incurrir en una latencia para el cheque.

¿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 prohibidas de usar este método? Si es así, ¿cómo los aplica? (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 de CTS para asegurarnos de que el modelo de permisos de las API no se modifique.

¿Cómo funciona esto con la función multi-SIM?

A: Se usa la SIM predeterminada especificada por el usuario.

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

R: Como ejemplo, SEEK usa el mismo AID que en el 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?

A: después de que el estado SIM cargó la transmisión.

¿Pueden los OEM deshabilitar parte de las API del 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.

¿ setOperatorBrandOverride anula TODAS las otras formas de cadenas de nombre de operador? Por ejemplo, SE13, UICC SPN o NITZ basado en red?

A: Consulte la entrada SPN en el Administrador de telefonía

¿Qué hace la injectSmsPdu 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 de onFilterSms basa en el filtrado de puertos UDH de SMS? ¿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 admitir 32 bytes parece ser incompatible con la especificación GP actual (que permite solo 0 o 20 bytes), entonces, ¿por qué está introduciendo este cambio? ¿No es suficiente SHA-1 para evitar colisiones? ¿Ya ha propuesto este cambio a GP, ya que esto podría ser incompatible con ARA-M / ARF existente?

R: Para proporcionar seguridad a prueba de 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 usar SHA-256.

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

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

De acuerdo con sus especificaciones, PKG-REF-DO utilizado solo, sin DeviceAppID-REF-DO , no debe aceptarse. Pero todavía se describe en la Tabla 6-4 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 utiliza PKG-REF-DO en REF-DO ?

R: La opción de tener PKG-REF-DO como un elemento de valor único en REF-DO se eliminó en la última versión. PKG-REF-DO solo debe ocurrir en combinación con DeviceAppID-REF-DO .

Asumimos que podemos otorgar acceso a todos los permisos basados ​​en el operador o tener un control más preciso. 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: Esto está reservado para el futuro, y agradecemos cualquier sugerencia.

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

R: Los certificados de almacenamiento de DeviceAppID son compatibles con la especificación existente. Intentamos minimizar los cambios de especificaciones para reducir la barrera de adopción. Para más detalles, vea las Reglas sobre UICC .