Android 5.1 introdujo un mecanismo para conceder privilegios especiales para las APIsrelevantes para los propietarios de aplicaciones de la tarjeta de circuito integrado universal (UICC). La plataformaAndroid carga los certificados almacenados en una UICC y concede 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 los portadores de UICC, aumentando drásticamente el número de portadores que pueden utilizar las API. Para obtener una referencia de la API, consulte CarrierConfigManager; para obtener instrucciones, consulte CarrierConfiguration.
Los transportistas tienen el control total de la UICC, por lo que este mecanismo proporciona una forma segura y flexible de gestionar las aplicaciones del operador de red móvil (MNO) alojadas en los canales de distribución de aplicaciones genéricas (como Google Play) a la vez que se mantienen los privilegios especiales en los dispositivos y sin necesidad de firmar las aplicaciones con el certificado de plataforma por dispositivo o preinstalarlas como una aplicación del sistema.
Reglas en la UICC
El almacenamiento en la UICC es compatible con la especificación de control de acceso de elementos seguros de la plataforma global. El identificador de aplicación (AID) en la tarjeta es A00000015141434C00, y el comando estándarGET DATA se utiliza para obtener las reglas almacenadas en la tarjeta. Puede actualizar estas reglas mediante actualizaciones de la tarjeta por aire (OTA).
Jerarquía de datos
Las reglas UICC utilizan la siguiente jerarquía de datos (la combinación de letra y número de dos caracteres entre paréntesis es la etiqueta de objeto). Cada regla esREF-AR-DO (E2) y consiste en 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 completa del nombre del paquete definida en el manifiesto, codificada en ASCII, con una 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, 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 certificadoSHA-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 en la 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 añade soporte para la lectura de reglas de privilegio del portador desde el archivo de reglas de acceso (ARF).
La plataforma Android primero intenta seleccionar el identificador de aplicación (AID) del applet de reglas de acceso (ARA) A00000015141434C00. Si no encuentra el AID en la UICC, vuelve al ARF seleccionando PKCS15 AIDA000000063504B43532D3135. Android entonces lee el archivo de reglas de control de acceso (ACRF) en 0x4300 y busca entradas con AID FFFFFFFFFFFF. Las entradas con diferentes AIDs se ignoran, los sorules 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 del certificado61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. A las aplicaciones firmadas por este certificado se les conceden privilegios de operador.
APIs habilitadas
Android admite las siguientes APIs.
TelephonyManager
- Método para permitir que la aplicación de operador solicite a la UICC un desafío/respuesta:
getIccAuthentication. - Método para comprobar si a la aplicación que llama se le han concedido privilegios de operador:
hasCarrierPrivileges. - Métodos para anular la marca y el número:
-
setOperatorBrandOverride -
setLine1NumberForDisplay -
setVoiceMailNumber
-
- Métodos para la comunicación directa UICC:
-
iccOpenLogicalChannel -
iccCloseLogicalChannel -
iccExchangeSimIO -
iccTransmitApduLogicalChannel -
iccTransmitApduBasicChannel -
sendEnvelopeWithStatus
-
- Métodos para poner el modo del dispositivo en global:
setPreferredNetworkTypeToGlobal.
SmsManager
Método para permitir a la persona que llama crear nuevos mensajes SMS entrantes: injectSmsPdu.
CarrierConfigManager
Método para notificar el cambio de configuración: notifyConfigChangedForSubId. Para obtener instrucciones, consulteCarrier Configuration.
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 android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEpermiso e incluya un filtro de intención con la #SERVICE_INTERFACEacción. Los métodos incluyen:
-
onFilterSms -
onSendTextSms -
onSendDataSms -
onSendMultipartTextSms -
onSendMms -
onDownloadMms
Proveedor de telefonía
Propiedades del proveedor de contenido para permitir modificaciones (insertar, eliminar, actualizar, consultar)en la base de datos de telefonía. Los campos de valores se definen enTelephony.Carriers; para 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 privilegio del operador como parte de la UICC.UiccCarrierPrivilegeRules.javaCarga las reglas, las analiza desde la tarjeta UICC y las almacena en la memoria. Cuando se necesita una comprobación de privilegios, UiccCarrierPrivilegeRules compara el certificado de la llamada con sus propias reglas una por una. Si se retira la UICC, las reglas se destruyen junto con el objeto UICC.
Validación
El conjunto de pruebas de compatibilidad (CTS) incluye pruebas para las API de las compañías enCtsCarrierApiTestCases.apk. Dado que esta función depende de los certificados de la UICC, debe preparar la UICC para superar estas pruebas.
Preparación de la UICC
Por defecto, CtsCarrierApiTestCases.apk está firmada por la clave de Androiddeveloper, con valor hash61: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 del certificado esperado si los certificados en la 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 usandoCtsCarrierApiTestCases.apk, debe tener una UICC de desarrollador con las reglas UICC correctas o soporte ARF. Puede solicitar 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 utilizar esa UICC para ejecutar las pruebas. La UICC no requiere un servicio celular activo para pasar las pruebas CTS.
Ejecución de pruebas
Para mayor comodidad, CTS admite un token de dispositivo que restringe la ejecución de las pruebas sólo en dispositivos configurados con el mismo token. Las pruebas CTS de la API de Carrier admiten el token de dispositivo sim-card-with-certs. Por ejemplo, el siguiente token de dispositivo restringe las pruebas de la API del operador para que se ejecuten sólo en el dispositivoabcd1234:
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.
Pregunta
¿Cómo se pueden actualizar los certificados en la UICC?
A: Utilice el mecanismo de actualización OTA de la tarjeta existente.
¿Puede la UICC coexistir con otras reglas?
A: No hay problema en tener otras reglas de seguridad en la UICC bajo el mismo AID; la plataforma las filtra automáticamente.
¿Qué ocurre cuando se elimina la UICC para una aplicación que depende de los certificados que hay en ella?
A: la aplicación pierde sus privilegios porque las reglas asociadas a la UICC se destruyen al eliminar la UICC.
¿Hay un límite en el número de certificados en la UICC?
A: la plataforma no limita el número de certificados; pero como el chequeo es lineal, demasiadas reglas pueden incurrir en una latencia para el chequeo.
¿Hay algún límite en el número de APIs que podemos admitir con este método?
A: No, pero limitamos el alcance a las APIs relacionadas con el transportista.
¿Hay algunas APIs que tienen prohibido utilizar este método? Si es así, ¿cómo las hacéis cumplir? (es decir, ¿tenéis pruebas para validar qué APIs son compatibles con este método?)
A: Consulta la sección «API Behavioral Compatibility» delAndroid Compatibility DefinitionDocument (CDD). Tenemos algunas pruebas CTS para asegurarnos de que el modelo de permisos de las APIs no se cambie.
¿Cómo funciona esto con la función multi-SIM?
A: Se utiliza la SIM por defecto especificada por el usuario.
¿Esto interactúa o se solapa de alguna manera con otras tecnologías de acceso SE, por ejemplo, SEEK?
A: Como ejemplo, SEEK utiliza el mismo AID que en la UICC. Así que las reglascoexisten y se filtran por SEEK o UiccCarrierPrivileges.
¿Cuándo es un buen momento para comprobar los privilegios del portador?
A: Después de la emisión cargada del estado de la SIM.
¿Pueden los OEMs desactivar parte de las APIs del portador?
A: No. Creemos que las API actuales son el conjunto mínimo, y planeamos utilizar la máscara de bits para un control de granularidad más fino en el futuro.
¿Anula setOperatorBrandOverride TODAS las demás formas de cadenas de nombre de operador? Por ejemplo, SE13, UICC SPN o NITZ basado en la red?
A: Consulte la entrada SPN enTelephonyManager
¿Qué hace la llamada al método injectSmsPdu?
A: 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 del puerto UDH de SMS? ¿O las aplicaciones de los operadores tienen acceso a TODOS los SMS entrantes?
A: Los operadores tienen acceso a todos los datos de los SMS.
La ampliación de DeviceAppID-REF-DO para admitir 32 bytes parece ser incompatible con la actual especificación GP (que sólo permite 0 o 20 bytes), así que ¿por qué se introduce este cambio? ¿No es suficiente SHA-1 para evitar colisiones? ¿Han propuesto ya este cambio a la GP, ya que podría ser incompatible con la actual ARA-M/ARF?
A: 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 el estándar GP SEAC. Recomendamos encarecidamente el uso de SHA-256.
Si DeviceAppID es 0 (vacío), ¿se aplica la regla a todas las aplicaciones de dispositivos que no están cubiertas por una regla específica?
A: Las API de las operadoras requieren que DeviceAppID-REF-DO esté rellenado.Estar vacío está pensado para fines de prueba y no se recomienda para implementaciones operativas.
De acuerdo con su especificación, PKG-REF-DO utilizado solo, sin DeviceAppID-REF-DO, no debería 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 sólo se utiliza PKG-REF-DO en REF-DO?
A: La opción de tener PKG-REF-DO como un elemento de valor único en REF-DO fue eliminada en la última versión. PKG-REF-DO sólo debería aparecer en combinación con DeviceAppID-REF-DO.
Suponemos que podemos conceder acceso a todos los permisos basados en el portador o tener un control más fino. 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?
A: Esto está reservado para el futuro, y aceptamos sugerencias.
¿Puede definir más DeviceAppID para Android específicamente? Se trata del valor hash SHA-1 (20 bytes) del certificado de publicación utilizado para firmar la aplicación dada, por lo que el nombre no debería reflejar ese propósito? (El nombre podría confundir a muchos lectores, ya que la regla es aplicable a todas las aplicaciones firmadas con el mismo certificado de editor).
A: La especificación existente admite el almacenamiento de certificados DeviceAppID. Intentamos minimizar los cambios en la especificación para reducir la barrera de adopción. Para más detalles, consulte las normas sobre UICC.