Identificadores de dispositivos

Android 10 cambia los permisos de identificadores de dispositivos para que todos estén protegidos el permiso READ_PRIVILEGED_PHONE_STATE Antes de Android 10, identificadores de dispositivos persistentes (IMEI/MEID, IMSI, SIM y número de serie de compilación) estaban protegidos Permiso de tiempo de ejecución READ_PHONE_STATE. El permiso READ_PRIVILEGED_PHONE_STATE solo es se otorgan a apps firmadas con la clave de la plataforma y apps del sistema con privilegios.

Puedes obtener más información sobre los nuevos requisitos de permisos en el Páginas de Javadoc para TelephonyManager.java y Build.java.

Este cambio afecta a las siguientes APIs:

  • TelephonyManager#getDeviceId
  • Administrador de telefonía#getImei
  • TelephonyManager#getMeid
  • Administrador de telefonía#getSimSerialNumber
  • TelephonyManager#getSubscriberId
  • Compilación#getSerial

Acceso para apps del operador sin el permiso READ_PRIVILEGED_PHONE_STATE

las apps del operador precargadas que no cumplen con los requisitos para READ_PRIVILEGED_PHONE_STATE permiso puede implementar una de las opciones de la siguiente tabla.

Opción Descripción Limitaciones
Privilegios del operador de UICC La plataforma de Android carga los certificados almacenados en el UICC y otorga permiso a las apps firmadas por estos certificados para realizar llamadas a servicios . Los operadores heredados tienen una gran cantidad de SIM establecida, que no es que se pueden actualizar fácilmente. Además, los proveedores que no tengan derechos de autor sobre Las tarjetas SIM (por ejemplo, los MVNO que tienen SIM emitidas por MNO) no pueden agregar ni actualizar certificados en las SIM.
Incluir OEM en la lista de entidades permitidas Los OEM pueden usar OP_READ_DEVICE_IDENTIFIER para proporcionar identificadores a las apps del operador incluidas en la lista de entidades permitidas. Esta solución no es escalable para todos los operadores.
Código de asignación de tipo (TAC) Usa el getTypeAllocationCode , que se introdujo en Android 10, para exponer el TAC que muestra el fabricante y el modelo información. La información del TAC no es adecuada para identificar un dispositivo específico.
MSISDN Los operadores pueden usar el número de teléfono (MSISDN), disponible en TelephonyManager con el permiso PHONE para buscar el IMEI en los sistemas de backend. Esto requiere una inversión significativa para las empresas de transporte. Operadores que mapean sus claves de red con IMSI requieren una inversión recursos técnicos para cambiar a la MSISDN.

Todas las apps del operador pueden acceder a los identificadores de dispositivos actualizando el archivo CarrierConfig.xml con el hash del certificado de firma de la app del operador. Cuando la app del operador llama a un método de lectura de de la aplicación, la plataforma busca una coincidencia con el certificado de firma de la aplicación. hash (firma SHA-1 o SHA-256 del certificado) en la Archivo CarrierConfig.xml. Si se encuentra una coincidencia, se para que se muestre la información. Si no se encuentra una coincidencia, se aplicará una excepción de seguridad. que se devuelven.

Para implementar esta solución, los operadores DEBEN seguir estos pasos:

  1. Actualizar CarrierConfig.xml por el hash del certificado de firma del app del operador y enviar un parche.
  2. Solicita a los OEM que actualicen su compilación con QPR1+ (recomendado), O BIEN estos parches de plataforma necesarios y el parche que contiene Se actualizó CarrierConfig.xml archivo del paso 1 anterior.

Implementación

Actualiza tu lista de permisos con privilegios para otorgar READ_PRIVILEGED_PHONE_STATE para los usuarios con privilegios apps que requieren acceso a identificadores de dispositivos.

Para obtener más información sobre la lista de entidades permitidas, consulta Información Lista de entidades permitidas de permisos.

Para invocar las APIs afectadas, una app debe cumplir con una de las siguientes condiciones: requisitos:

  • Si la aplicación es una aplicación con privilegios precargada, necesita la Se declaró READ_PRIVILEGED_PHONE_STATE permiso en AndroidManifest.xml La app también debe incluirse en la lista de entidades permitidas este permiso con privilegios.
  • Las apps que se entregan a través de Google Play necesitan privilegios de operador. Más información sobre cómo conceder privilegios de operador en el operador de UICC Privilegios.
  • Una app del propietario del perfil o del dispositivo a la que se le haya otorgado READ_PHONE_STATE.

Una app que no cumpla con ninguno de estos requisitos tiene las siguientes características: comportamiento:

  • Si la app se orienta a campañas anteriores a Q y no tiene READ_PHONE_STATE permiso otorgado, SecurityException . este es el comportamiento previo a Q, ya que este permiso se requiere para invocar estas APIs.
  • Si la app se orienta a campañas anteriores a Q y tiene READ_PHONE_STATE otorgado, recibe un Un valor nulo para todas las APIs de TelephonyManager y para Build.UNKNOWN para el método Build#getSerial.
  • Si la app se orienta a Android 10 o versiones posteriores, y no cumple con ninguno de los nuevos del cliente, recibe una SecurityException.

Validación y prueba

La página de compatibilidad El conjunto de pruebas (CTS) incluye pruebas para verificar el identificador de dispositivo esperado el comportamiento de acceso a las apps con privilegios de operador, el dispositivo y propietarios de perfiles de Google y las apps que no deberían tener acceso al dispositivo identificadores.

Las siguientes pruebas de CTS son específicas para esta función.

cts-tradefed run cts -m CtsCarrierApiTestCases -t
    android.carrierapi.cts.CarrierApiTest

cts-tradefed run cts -m CtsTelephonyTestCases -t
    android.telephony.cts.TelephonyManagerTest

cts-tradefed run cts -m CtsTelephony3TestCases

cts-tradefed run cts -m CtsPermissionTestCases -t
    android.permission.cts.TelephonyManagerPermissionTest

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCanGetDeviceIdentifiers

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCanGetDeviceIdentifiers

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCannotGetDeviceIdentifiersWithoutPermission

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCannotGetDeviceIdentifiersWithoutPermission

Preguntas frecuentes

¿Cuántas apps se pueden incluir en la lista de entidades permitidas de CarrierConfig.xml para un determinado (MCC, MNC)?

No hay límite para la cantidad de hash de certificados incluidos en el array.

¿Qué parámetros de CarrierConfig en CarrierConfig.xml debo usar para que se incluya una app en la lista de entidades permitidas?

Usa el siguiente elemento de configuración de nivel superior dentro del CarrierConfig.xml de las opciones de AOSP que estás configurando:

<string-array name="carrier_certificate_string_array" num="2">
    <item value="BF02262E5EF59FDD53E57059082F1A7914F284B"/>
    <item value="9F3868A3E1DD19A5311D511A60CF94D975A344B"/>
</string-array>

¿Hay una plantilla de CarrierConfig base que pueda usar?

Usa la siguiente plantilla. Esto debe agregarse al recurso relevante.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<carrier_config>
    <string-array name="carrier_certificate_string_array"
num="1">
        <item value="CERTIFICATE_HASH_HERE"/>
    </string-array>
</carrier_config>

¿La SIM del operador tiene que estar en el dispositivo para acceder a los identificadores del dispositivo?

El CarrierConfig.xml que se usa se determina en función de la SIM insertada. Esto significa que si la app del operador X intenta obtener privilegios de acceso mientras la SIM del operador Y está insertada, el dispositivo no encontrará una coincidencia para el hash y devuelve una excepción de seguridad.

En dispositivos multiSIM, el operador núm. 1 solo tiene privilegios de acceso para la tarjeta SIM núm. 1 y vice versa.

¿Cómo convierten los operadores el certificado de firma de una app en un hash?

Para convertir certificados de firma en un hash antes de agregarlos a CarrierConfig.xml, haz lo siguiente:

  1. Convierte la firma del certificado de firma en un array de bytes usando toByteArray
  2. Utilizar MessageDigest para convertir el array de bytes en un hash de byte[].

  3. Convierte el hash de byte[] en un formato de cadena hexadecimal. Por ejemplo, consulta IccUtils.java.

    List<String> certHashes = new ArrayList<>();
PackageInfo pInfo; // Carrier app PackageInfo
MessageDigest md =
MessageDigest.getInstance("SHA-256");
for (Signature signature : pInfo.signatures) {
    certHashes.add(bytesToHexString(md.digest(signature.toByteArray()));
}

  4. Si certHashes es un array de tamaño 2 con un valor de 12345 y 54321, agrega lo siguiente al archivo de configuración del proveedor.

    <string-array name="carrier_certificate_string_array" num="2">
    <item value="12345"/>
    <item value="54321"/>
</string-array>